sanderd17

If every tree would have an aura (and thus a range query), even just starting a game would be a nightmare (you can try if you want, just copy the aura code from some hero to the tree template). There are too many trees on the map to make it feasible this way. Basing it on terrain type would be a bit better, but still too much work for now.

The developer overlay is only for development purposes, so we shouldn't advertise it to other people any more than we do now. It's mentioned in the manual, and it's a menu setting anyway.

We don't have the ability to differentiate between sorts of terrain, and we don't plan to add it, as it would require a lot more calculations, so cause a lot of lag.

Can you at least give the start of the error, with the real path. there isn't a lot to see here.

Finding one capable of doing it is a whole lot more difficult though. We can pay him for about 6 months only. So he should be willing to give up his job for only 6 months. Next to that, not every programmer can do it. There are very few who have the capabilities of improving it. And on top of it, the particular problem, the pathfinding is due to gameplay reasons completely tied to the rest of the game (the software is quite modular, but every aspect in the game requests something position based). If the the programmer we find, would want to do it purely for the money, and only invest the time in it we can pay him to invest, 6 months would barely be enough to get to know our engine. So basically, we need a top programmer, who's willing to learn to know the project before starting to work on it, and who's willing to give up his job for 6 months. I think trying to attract more programmers who want to work for free on a free project is a more viable approach. The money can be used for that attractive purpose rather than just for paying one person.

I didn't know you wanted a specific type. In those days, the boundaries of the different Germanic (including the Frankish) counties were rather changeable.

This is one of our most ancient fortresses: https://www.google.com/search?tbm=isch&q=Gravensteen As you see, it's indeed not what you'd would draw at first. It isn't rectangular, but follows the terrain. The entrance is a bit higher than the rest of the walls. But the highest is on the opposite part of the entrance, though not completely against the wall. So I really like a-symmetric designs.

We are doing pretty well though. Since the A15 release. There have been more than 10 commits per day. And a lot of small features added.

Or at least run the game in a terminal, and copy paste the output here after the error.

It all looks very clean to me. Gallic buildings can use a lot more organic shapes. Nothing perfectly straight or round. It will cost more polies, but that's not so bad for a building. The building itself looks quite big for its footprint though. Can you compare with other farms? I have no idea if it's going the right direction, as I don't know the wanted direction. That's something for the art team.

Such a proximity feature would be very temporary if we can get proper formations working in the not-so-far future. Btw, every unit needs a counter. pikemen counter all cavalry, so they can't counter other infantry.

Btw, the other problem is that moving siege towers aren't attackable (units keep chasing them without attacking). But this should be fixed in a few days.

The problem with this is that it can cause a lot of micro. If your units get damage when the tower is destroyed, but not when you eject them when the tower is at f.e. 10hp, a good micro player will eject his units just before the destroy point. I do agree that there should be some way to punish those units that are ejected. Keeping trac of the damage being dealt while the unit was in the tower, and applying a fraction of the damage to the unit seems too complicated to me. And it defeats the purpose of garrisoning, which is defense for the unit. Maybe we can disable the fighting ability of unit who are just ungarrisoned? So when an ungarrison happens in the middle of a battle, they are in serious problems. But I have no idea how we would make it look natural.

Euh, melee infantry also adds arrows to ships (I guess ships have the bows available )

Note that we aren't at version 15, but at version 0.0.15 for now. Or to omit all the zeros, "Alpha 15".

This is not possible yet, but we're thinking about how to do it. You can give two attacks already, but the selection between the two won't be very good.

Newcivs: if you clean and build the workspaces every time, you are losing a lot of time. Such a script isn't wanted, because the required steps depend on the actual changes. Most of the time, a make will do.

The siege towers have been fixed AFAIK. They now only fire 0.5 arrows per soldier. Are you sure you're talking about the current version? Changing it to 0.25 isn't hard, but I don't think it's really needed.

Did you try in game too? Some options are disabled in Atlas.

Maybe we should make the CC arrows stronger and the range bigger (but don't give (a lot of) extra arrows for garrisoned soldiers). This way, people could be working in the protection of the CC, and rushes should be countered easier.

(note for the saving settings, Santa has a patch for it on Trac)

I don't think anyone will use it if you have 300 units. So I don't think it will ever be included.

You can't use a diff with binary files, so as long as you're working with sounds, zipping them, or including them separately is good enough. As I don't use the tortoise front-end, I can't answer your actual question.

I'd like to work on formations, like two formations really attacking each other, but it will cost a lot of time, so I highly doubt it will be ready for the next release. I certainly think we should try to get translations in the game.

I don't understand what you want. The names look pretty individual to me.