sanderd17

Apparently, there is already a ticket for that, so you certainly shouldn't create one. http://trac.wildfiregames.com/ticket/1088

That warning comes from the AI. The AI keeps a reason why a unit is garrisoned (to know when to ungarrison it again). So when you garrison units from the AI somewhere, you will get this warning. If this happens when playing a regular game, then it's a bug in the AI, and it's best to post the replay file, so it can be reproduced.

Starting a game from one side, and letting someone rejoin, just like when his game crashed, would be possible with some GUI work I guess. Letting two people start at the same time (which is needed if you want to keep it a bit fair) will need quite some more work.

It's not that easy to let people start at the same time. If you're willing to work on it, you can create a ticket to track your progress and ask for feedback. But otherwise there's not a lot of use in creating a ticket when nobody is going to work on it.

To fix the persians, what about adding a tech to the apadana that enables champions to train from the barracks? So it still requires the apadana to be build to get champs, but once you have that building, you can spit out more champs.

@Palaxin, updating it for Atlas should be quite simple (at least theoretically). The current piece of code just isn't optimised for recalculation of terrain. But @trompetin17 is working on a new Atlas interface, so it's not a good time to change code interfacing between Atlas and the rest of the game, as it will have to be redone anyway.

Thanks for the report, that's fixed now.

Units on walls doesn't need 3D pathfinding (units on gates would need that, but nobody is supposed to pass below a wall). The main problem is that walls are too thin, and our obstruction raster is not precise enough. So depending on the placement (how the obstructions get rasterized), the walls are passable or not. Units on walls should be possible if walls are made a lot fatter (IIRC, they needed to be at least 3 times as thick). But then you get other gameplay issues wrt where to place walls. The second problem is that it's hard to move your units on the walls. If you task your units to some point, you target the wall piece completely, and thus the unit just doesn't move as he's already on the wall piece.

At least their skin colour should stay mostly the same.

According to this source, the mahouts of the Carthaginian war elephants were Indian. So the riders should probably use an Indian unit texture.

It looks like the Golden eagle would be best wrt habitat and fame. Do watch out, when you use pictures to texture from, the pictures should be licensed as CC-BY-SA or compatible (CC-0 and CC-BY are both compatible). Wikipedia always mentions the license, and Google also has the option to search for pictures labelled for "reuse with modification". And also keep track of what pictures you used, so they can be credited correctly.

Does this happen with just the public mod too?

Ok, thanks for the report, I think I found the issue now. Can you try updating again?

Is it exactly the same error (including the same line numbers)? And does it happen on every game immediately after loading? Or are there certain maps or civs where it happens?

Are you on Windows? And if so, do you use the autobuild we provide?

The current AI in 0 A.D. is completely deterministic. So it doesn't need to store data, and will run the same game if it starts from the same seed (given that the other game events are the same). So the only thing that needs to be remembered are the commands given by users. Btw, having an AI to be deterministic is also great for testing it. It means that starting a replay runs the AI decision code again, and makes it possible to find rare errors in the AI code. While if the AI would store its decisions, the AI code wouldn't have to run again, and some rare problems wouldn't be reproducible. It also has disadvantages though, like visual replays could be a lot smoother if the AI didn't have to make its decisions again. Or when an AI shouldn't be deterministic, it could learn from older games while playing. But for that purpose, a different AI API should be written (one that acts more like a player and less like a part of the simulation).

I'm sorry, but that's not a diff, that's a list of changed files. A diff is something like this: http://trac.wildfiregames.com/attachment/ticket/3983/damageAndSeasonVariants.diff where you can see the differences and apply them with a single command. When someone sends in contributions, we require it to be in a nicely readable diff format, so it looks like we're requiring more work from our volunteers than from someone who's asking us a favour. Also, the link you PMed me doesn't work (I have no access), and in Linux, it's not a habit to spread binaries. They need to be compiled correctly against the libraries the distro provides (my binary build on Arch Linux won't work for someone with Ubuntu or Debian, and the difference between 32-bit and 64-bit also matters). And technically, you could also be violating our license (GPLv2+) when you spread the game in binary form but don't want to give the source code to everyone. But I guess there are some exceptions on copyright for educational purposes, so it should probably be fine from a legal PoV. And even if I get the library, I don't feel like debugging a piece of code that's new to me. So after all, I guess I'll leave the testing for the Windows users. It would have been nice though if you told it in your first post that it's only for Windows. The majority of devs here uses Linux almost exclusively.

Doesn't help when using Linux

Can you offer your changes as a diff? I don't feel like downloading and compiling 0 A.D. again from scratch in one day, and I like to see what I get (instead of running code from a random person on a forum).

The problem with that is that different food resources need different ways to gather them. F.e. skittish animals can only really be gathered by cavalry, fish need fishing boats, for berries it's better to use females, ...

Spy units come with a lot of design difficulties. Like you should probably be able to attack a unit that comes to spy for you. But how would that go? If the cursor changes to an attack cursor when hovering it, it will be clear enough that it's a spy. Also, there's no such thing as a generic female. Citizens of different civs are dressed differently. And letting the citizen change clothes based on what enemy you're sending it to will be very weird. Also, how would you decide what enemy you send it to (what apparent ownership is given) when you have multiple enemies?

Terrain can also be important for gameplay. At least the difference between passable and impassable terrain. And when a map is well-made, that difference is reflected in the terrain texture (cliffs for impassable terrain). The terrain could be faded though, but we'd need to find a good fading function (what operation to execute on the RGB values to fade it).

A falcon would also be nice, certainly the kestrel has a nice flying pattern, where it can stay totally still in the air to spot a prey, then take a dive and move on. I wonder how well this could be scripted, but it would be a nice challenge for us. https://en.wikipedia.org/wiki/Kestrel

Thanks for your work on this. If you want the actor to be used in the main game (rather than just in some mod), you should watch out a bit for historical accuracy though. Parrots only appear in tropical regions, and the only civilisation we have in a tropical region are the Mauryans (in India), so any parrots that are from Africa or the Americas can't be included in the game. So the texture should represent one of the parrot or parakeet species that appeared in India around that period (so also no modern species that were introduced to India and now live there). Perhaps you can take some inspiration from this list: https://en.wikipedia.org/wiki/List_of_birds_of_India#Parrots_and_allies But once the parrot is textured, there's the problem of behaviour/animation. Parrots and parakeets are notably reluctant to fly. They prefer to climb trees rather than flying from branch to branch. This is very different behaviour from hawks. So having a parrot flying around constantly like the hawk does would harm realism IMO, and letting parrots sit on the ground would also be quite lame (they prefer to stay in trees). So I have no good idea on how to give parrots realistic behaviour. Perhaps it could be an actor that can be placed on Mauryan buildings (and India-specific trees), with some simple animations of just walking left and right once in a while. Other ideas are welcome. EDIT: thinking of it, the modelling and texturing depends on the wanted behaviour. If the wings of the parrot won't ever be opened in-game, the inside shouldn't be textured and should probably have less geometry (the geometry of the wing and the body can be merged).

1. Fields currently always give the same profit. The difference is purely graphical. Though it it's planned to variate this a bit in the future. Fire now, we have to wait until someone is willing to start on it though. 2. You can change those things in the settings file. Please read http://trac.wildfiregames.com/wiki/Manual_Settings carefully to know how to do that. Also note that zooming out far can cause more performance issues, which is one of the reasons why it's limited by default.