sanderd17

I don't like unused code, as it's never exactly what we need, or it gets forgotten and re-implemented. So it would be great if you start working on it. (And darn, a summer Ramadan again? Good luck )

They have been merged.

A saved game will never replace the commands.txt. A saved game only saves the current state, while commands.txt saves the history of all actions.Otoh, a commands.txt can't replace a saved game either, as replaying the commands.txt to get to the last state takes way too long. You can't have saved games that take 15 minutes to load. And it's easy to make a proof the AI can be saved game compatible, the current state of the AI is a proof of that. We just lack the man-power to implement it. It will cause a lot of code cleanup on the AI side, which is hard when the AIs are constantly changing, without any AI dev caring about saved games.

For the moment, camera position is completely not-synchronised (you can't have all players on a map look at the same point). So it's not controlled by the simulation, which means triggers (that are in the simulation) can't control it either. It should be possible however to send camera position changes to the gui. But it would require some more code. Getting the camera position won't be possible.

Ok, there are already some things I see that will be hard to do. We have no cinematics (that's something missing in general, not just for triggers), and triggers can't ask for special GUI windows (like the selection you propose). The other things should be possible. Though may require some extra code to make them easier.

Yes, I'd say it wouldn't be too difficult to turn 0 A.D. into a city building game. It would mostly need a different gui, and different simulation scripts. So if you're an artist, you can start working on art for our engine, and some programmer might drop by. In the mean time, your art can be used as eye-candy here (if you release it as CC-BY-SA), so your work won't be lost.

I believe the elite wanted to keep most stuff Hellenistic. So I'd assume it would be the same for the music.

The gcc directory is build/workspaces/gcc. But that directory is only created after a successful build-workspaces. But I think a possible problem is you have periods in your directory, I don't believe all the build scripts can cope with that.

Really? Never saw that, and don't find a recent commit about implementing stamina.

There is, it writes the commands.txt while you're playing.

mozjs24 is spidermonkey. Also, don't think we require python for compilation, but it won't hurt if you install it anyway.

You have to hold the ALT key to select special entities in Atlas. When you get it selected, you can move it. Gaia is a player that's just not controlled. So a trigger point can belong to gaia or to anyone of the players for that map. Note that it doesn't make any difference for the interface who owns the trigger point. It's in the trigger code that you can make the difference. There are currently 11 different trigger point models, if that's what you mean. We hope that's enough for now, and if more are needed, we can ask Pureon to make some extra (Pureon made these too). But you can place as many trigger points on the map as you want, you'll just have to find a different way of distinguishing them (through owner, through position, ...) If you have a model that fits a bit for usage in Atlas, you can just make new trigger points. The references don't even need to be single letters (like "A", "B", ...), it can also be a word. A mod can even add the trigger point component to existing entities, and give it a reference like "CivilCentre". I didn't do that, as I liked to keep the triggers a bit more separated than that. But if it's needed in the future, it's possible.

Select them in Atlas, and place then on the map. Simple as that. Getting then is just something like this.GetTriggerPoints("A"), to get all A points in a list (which you can filter by owner later on if you want).

If you don't have all system libraries (or not the right ones), remove the relevant "--with" arguments. In this case, remove the "--with=mozjs24".

If you are really a great map+triggers maker, you could propose some triggers to be implemented. You do the maps, we do the triggers It would give us a better overview of what's needed, and more reference implementations.

I did that, and nobody complained or modified it this far.

The bullet path is calculated in the simulation (the path determines where it drops, so how much damage it deals). So that can't be changed through animation. It's either having a realistic animation, but unrealistic damage compared to where the arrow/rock/whatever goes, or an realistic damage with less realistic animation.

If you're working on triggers, and would like more/other default helpers or more trigger events (or even different event data is still possible as it's still young), we invite you to join #0ad-dev on Quakenet to discuss it with us.

You need to modify some of the specific names. Some contain an English "of", or some are just plain English, like specific plant names.

I guess this helps: http://trac.wildfiregames.com/wiki/Localization Though to test the newest translations, you also have to install the newest mean version of the game. I.e. go through the SVN installation guide: http://trac.wildfiregames.com/wiki/TortoiseSVN_Guide

You should have got a mail asking for your data (like forum username to get the batch). Didn't you get that? The responses are gathered now, and we will process them, so you should have your batch soonish if you filled in the survey.

It's done in Atlas, but only a part of the screen is captured.

For every attack type (pierce, hack and crush) AttackValue * (0.9 ^ ArmourValue) The percentage you find in the gui is the precalculated (0.9 ^ ArmourValue). So it's literally the percentage of the attack that comes through. And it's summed for all attack types.

Buildings aren't that complicated. Natural meshes (trees, animals, units, ...) require a lot more triangles to fill the same space. So that's not really an issue. Without capturing, I don't really see how to make these maps interesting to play. But they'd give nice screenshots of course.

We have no guides because it changes too fast. Basically, first get the available food (put your females on the berries, your cavalry on the chicken/sheep, and your infantry on the wood). Spawn females and soldiers. Build houses to get up your pop cap, build farms when the natural food is nearly depleted, and build barracks for even faster unit production and a real boom. As for attacking, try to micro your units around well enough. Ranged units are normally quite vulnerable when caught by melee units, so watch out for them. But just read the tooltips to see who counters who.