1. The Air-Land morph bug is a big problem for me because I would like to make "VTOL"s.
(but this probably is going to be done at the same time as water morph)
Please elaborate
2. Rotating turrets could be a nice feature.
Again, please elaborate
3. Attacking while moving (with turrets or airplanes that drop bombs while flying over at full speed)
Yea, we were talking about this at one point and I agree. If I get your meaning on #2, then they would share some of the same functionality as you would have a portion of the model (a set of meshes) for the rotating and non-rotating parts of your unit or you would have one model for the base and another for the rotating part. This is also something that's been discussed with "housed units", that can attack while the housing unit is moving or engaging in other actions.
4. Buildings which can be entered on multiple floors. This is I think a pretty difficult thing but would allow walkable walls, putting archers on castle walls (that must be coool).
4b. Underground floors... I don't really know about this, you would have to make shure you can still see your units...
Yea, those will take more radical alterations of the engine, as walkable walls will as well. Perhaps we can think this one out more in the future, but I'm not thinking it's a 0.3.x feature.
5. Building rotation (maybe this already exists) and other shapes than squares (thx javamonger).
Now you can't place a building over another, even with it's 'passable' tiles.
Right, we discussed this in #glest, I think that's something that can go in 0.3 and I'm already working on some complimentary features, like being able to restrict a build site (or any skill execution) to the proximity to another unit type or map object type, that way, you can have add-on structures similar to starcraft (and I want to do that for the FPM crypt). This will also support the FPM grove because it is supposed to be built in a treed area.
About water units:
Water buildings? How would they be implemented?
(i think they should be partly build on the shore)
so there should be land, water, submerged, shore and air if I'm right.
Will have to think more on that one. I've only thought through water-moving units, by adding multiple move skills, each with a set of restrictions on water depth, that way a unit can start swimming (but slower) when entering water. But I hadn't thought of how to manage a static water structure. This poses challenges for how the cell map is managed as you may want to specify which cells must be on land and which in water.
6. Resource costs for skills.
Already in the works, as are locally stored resources. There is also a skill in the 0.3 branch (very unstable) that allows the restoration of either HP, EP or a locally stored resource (the later of which isn't actually implemented yet), so you can have, for instance, a refuling station and tanks with a finite amount of fuel.
7. Building/Unit limit (only 1 hero or a maximum of 4 royal guards...)
Interesting. This should already be possible with a static, hidden resource and a starting value implemented in faction.xml. Add a resource like "royal-guards" or "heros" and add <display value="false"/>, this doesn't appear to be documented in the glest wikia and should be added. Then, you simply add a resource requirement to your hero and/or guard, etc.
8. Effects:
-Poison (slowly drains hp)
-Fatigue (or something, drains mp)
-Invisibility (makes unit invisible)
-Slow (slows unit down)
-Stone (stones unit permanently [or until recovered by magic or maybe a mason], only for use in campaigns much to dangerous)
-Freeze (freezes unit for a while, cannot use any skill [except unfreeze maybe], armor changes to 'ice' [higher defence], fire attacks could bring it back earlier [maybe the effect has some kind of hp])
Already done! Except for invisibility and maybe stone & freeze, although you can probably make stone & freeze work right now, you wont get the visuals that it should have. Invisibility will need to be added for the FPM acolyte, but it will be a selective visibility. I think we'll have to define "vision fields" and then specify which units can see those fields and which can't.
For the stone, you use an effect, add <permanent/> to the <flags>, and set the speed multiplier of all skills to zero. This is a hack and if they receive another effect which adds to their skill speed multipliers, it will partially undo the effect (maybe you can also add a huge negative static modifier, I'm not 100% certain I check to correct negative skill speed values
. Check out the
wikia reference here. Freeze would be the same hack as stone, also, you can have a skill (like a repair/restore skill) remove negative effects as a mechanism for cancelling the stone/freeze, but what's sorely needed is the ability to alter available commands (will be added for FPM acolyte again) and induce better visual effects and even secondary models on the target unit's animation.
Be aware that setting the move speed negative probably still causes the units to move in the opposite direction that they intended to. I left this in because it looked cool when testing, like they were being blown backwards (which may be desirable for some attacks). Also, don't bother with any of the ai-hints for now because they aren't hooked up yet.
9. Boosts: All units within range have raised Strenght, MP reg, HP reg and other
See above wikia page and look at the emanations, it's already done. You can look at the FPM paladin for an example. For an example of a negative emanation that effects enemies, look at the crusader.
10. I don't know if this will improve anything but some units could have both a male and a female version which is randomly chosen.
Yea, I like that idea, to have a "media variant" for each unit, so it chooses from a different pool of animations, models and sounds. Probably a post 0.3 or 0.4 feature, but a very worthwhile one, I would like to see if personally.
11. Random stats: not every swordsman would have the same hp or other stats. The random range, of course, has to be choosable by the tech tree creator.
Yea, that could be useful, but probably low priority. Perhaps the unit's definition could just define a variance, much like damage variance is specified.
