Another thing dearly needed: minimum attack range. It's rediculous that an archer is still shooting at a swordsman once it reaches the Archer. This would force the AI to use secondary attacks, for instance like in Aryin's model; I believe he had a secondary sword. There are so many times I thought of this, but this is the first time it has been mentioned by me.
It is already possible to configure a composit attack command that will execute different attacks based upon things like range to target. Take a look at the battle mech and Lich in the FPM mod for example XML. However, I want support for ranged units to actually back away from their targets and attempt to fire at max range! I can't remember if I've already opened an enhancement request for that or not. But I do know that I have already begun to accomodate this functionality in 0.3 in the new AttackSkillPreferences class (see
https://glest.codemonger.org/svn/repos/gae/branches/0.3/source/game/types/command_type.h and also the TargetingRules class in
https://glest.codemonger.org/svn/repos/gae/branches/0.3/source/game/types/skill_type.h for an idea of the flexibility that's coming)
Another thing is that I want Glest to terminate only after it finds all the errors in a faction, then save a file to the Glest directory. This would help sooo much with faction making.
Yea, I agree, but it's a real pain in the arse! The issue is that the initialization of one object is often dependent on the initialization of an object before it. But I know it makes things a real pain when modding because you have to keep restarting the game to find each new error!
So maybe you can open an enhancement bug for this idea please.
On a related topic, you may be glad to know that 0.2.12's will support telling you which files do not match when playing a network game rather than just saying that your files don't match!
Make a debug mode for Glest. It's harder to make, but can save more time later. (But who am I to give orders for anyone )
Yea, maybe this is the solution. Maybe if you define DEBUG_XML when compiling then it will support this? I don't want this in two different places though because that would be a maintenance nightmare. Perhaps if DEBUG_XML is defined and an option is added to the .ini then it will attempt to accumulate all of the errors and display them at the end. However, there are a lot of issues that can happen if one load fails, it can create cascading problems, so it may be easiest to implement if we have the basic contract that it may not be as stable with that .ini "debug xml" setting on.
I agree. Another common thing game developers do is have obvious stand-in textures for missing ones so they can be visually seen and fixed without getting in the way of other testing.
Yea, that sounds like a good idea.
Finally, Bridges:
My answer is that I don't really know right now (to most of the questions). This is probably best discussed in the
Requirements: new map format thread.