Glest Advanced Engine

[daniel.santos]

no, this isn't the wrong thread for feature requests.  I know that this has been mentioned before.  Please file a feature request bug report at http://bugs.codemonger.org. Note that the Lich in the FPM mod was originally supposed to be able to control up to 2 enemy units and we've floated ideas about some units being able to take control of wild animals and such.  Overall, I agree that there needs to be a "take ownership" skill added, but there isn't a bug report for it yet (and bug reports keep good ideas from getting lost )

[John.d.h]

I'll post it as soon as I get the confirmation email from the site.  It sure is taking a while, though.

[ZaggyDad]

I just had an idea. You could make a sort of "height map" and "size limit map" for units so that archers could get on walls instead of just having them going on it when you garrison them. (and actually, that word doesn't work for it, anyway. ) It could work like the cell maps, except the height map would have a number for the height of the cell, and on the size limit map, it would have a number of the size of the unit allowed to move around in the cell. Basically it would be to prevent horses and stuff from going up stairs that are too steep.

Code: [Select]

<heightmap value="true">
<levelHeightmap value="1">
<row value="0000"/>
<row value="0000"/>
<row value="0000"/>
<row value="0000"/>
</levelHeightmap>
<levelHeightmap value="2">
<row value="4443"/>
<row value="4443"/>
<row value="4442"/>
<row value="3322"/>
</levelHeightmap>
</heightmap>
<sizeLimitMap value="true">
<limitMap level="1">
<row value="0100"/>
<row value="1111"/>
<row value="0100"/>
<row value="0100"/>
<limitMap level="2">
<row value="0001"/>
<row value="0101"/>
<row value="0001"/>
<row value="0111"/>
</limitMap>
</sizeLimitMap>
I thought about having it have multiple levels and that you would have to right-click on a part that's on that level to get them to go up there. For repairing, what it could do is if you right-click on a secondary level, the worker will go to that level to work on repairing it, instead of not going where you want him to, and just repairing. And maybe to tell Glest which parts you have to right-click on to go to the next level, it could have some sort of level map.

Code: [Select]

<levelMap value="true">
<levelCellmap level="1">
<row value="1011"/>
<row value="0000"/>
<row value="1011"/>
<row value="1011"/>
</levelCellmap>
</levelCellmap level="2">
<row value="1110"/>
<row value="1010"/>
<row value="1110"/>
<row value="1000"/>
</levelCellmap>
</levelMap>
Since the level cell maps would probably be the same as the normal cell maps would with levels, they could be used for both unit walkability limits along with telling where to put the units. The thing to tell the computer where to move the unit could be invisible planes above the cells you want the units to move to, conformed to the heightmap. Basically cells of ground in the air, eh?

I'm not saying that garrisoning shouldn't be integrated, though.

Btw, I used the barracks as an example. Not that it was really worth it to put that spot on the very top for units to stand. 

Edit: Er, Daniel, I forgot my password on the Bugzilla, so I can't put up a "bug" report on it, so could you send my password to zaggy1024 at gmail.com? *looks somewhat annoyed at self*

[daniel.santos]

Well, first for the bugzilla issues, you *should* be able to reset it yourself.  That is, if I had postfix ACTUALLY RUNNING!     But it's up now so please try because I don't really know where or how passwords are stored in the database and I would rather not know or look at anybody's password anyway.

As for the cellmap, this is a good idea.  It may not be the *right* idea, but it's a very good one and a very good start at examining these concepts.  I think that my preference is towards a less cell/block dependent scheme and one that's more in the direction of using the models themselves and collision detection.  Then, to make the game rules match, we make sure that projectiles are properly launched.

None the less, this brings up the topic of garrisoning and units residing on top of another.  This is probably a really good time to recap the possibilities here.

• Units might be garrisoned *inside* another unit, like a worker hiding inside of a castle.  Maybe (like Rise of Nations or something) these units heal up while there.  So different rules may apply while they reside there.  I'm personally in support of unit garrisoning adding attacks to a building unit.  We also have the idea for FPM of a mobile "shed" where a limited number of units (maybe 4) can be inside of this armored shed and be able to attack from within while the shed takes damage (protecting the units inside)
• Units might be *riding* on another unit.  This is a situation where a unit is residing on another unit that is mobile and their model (or an alternate model) remains visible.  For instance, units on the deck of a ship.  If they have a ranged attack, they should be able to use it from the deck of the ship.  This might require additional models and animation sequences.  A modern day soldier may be sitting on a tank and firing from there.  Maybe there is some other unit that has their own attack like a griffin or dragon, and an archer can ride atop them firing missiles as their mount performs their own attacks.
• Finally, units may reside on top of a non-mobile unit, like an archer on a castle wall.  Here, the archer may be provided partial protection due to the parapets (either reduced damage or a chance they are missed entirely).  I don't know if this should be any different than the above item really.  But this would include climbing stairs & such and I would very much like for this to be a nice seamless and natural both in appearance and feel (when a unit climbs stairs to get to the top of a castle wall for instance).  I believe that will be quite the challenge and I don't quite have a pretty paradigm cooked up in my head for this yet.
  

So the height & level maps is nice thinking.  It provides a way for the modder to specify in the XML exactly how tall each portion of a unit is and which parts of the unit are traversable at various heights.  However, the engine does collision detection using the model's verticies (I *believe* that's correct) and this is slatedto be replaced by ODE (doing the same thing, really, just better).  So there's a bit of a conflict here, do we let the model define where it can be hit or do we let it be overridden in the XML.  If we allow it to be overridden, we'll have to do extra code and it can end up looking funny if a projectile catches it on the corner of one of these invisible cell/height cubes where there is no part of a model behind it.

In short, I don't have a good answer for this but it's a very important thing to start exploring, so thanks for your ideas!  As for traversability and specifying what are "stairs" (i.e., something that can be climbed) I'm not certain how this should be done yet, but whatever we come up with, I want it to be inclusive of a multitude of possibilities and well thought out.

[gameboy]

I think we let the model define where it can be hit.
As for the stairs it could be another model combined with the main building.

[John.d.h]

I don't wanna change the direction of the thread away from walls (as I believe this is one of the biggest additions we need) but I had another thought.  How about a forest fire effect?  I was thinking about how in Sun and Moon, Sun doesn't use wood in any of their buildings, units, or technologies, but Moon does, so it would be advantageous for them to be able to burn down all the forests they come across, thereby depriving their enemies of important resources.  There could be varying degrees of burnt trees as well.  Some would just have the leaves burnt off and be blackened but still usable as wood, while others might be charred and unusable, and others might be turned completely into ash.  I think making all fire attacks start forest fires, like in Stronghold, would be a bit excessive (albeit maybe more realistic) because it might become too rampant, but having a special ability to start them might be cool.

[ZaggyDad]

I think we let the model define where it can be hit.
As for the stairs it could be another model combined with the main building.

Another model for the stairs? What's the use of that?

[gameboy]

we could define the stairs without going into to all that scripting, with a separate model for the stairs we could tell the engine which model is climbable and which is the main structure that can't be climbed.
 

[modman]

If the engine were designed in a way which it knew where the actual "matter" was and where the "thin air" was, then all that would have to happen is the unit would have a variable on how high it could step up (Thus you could forget all this "where's the stairs" stuff).

[wciow]

If the engine were designed in a way which it knew where the actual "matter" was and where the "thin air" was, then all that would have to happen is the unit would have a variable on how high it could step up (Thus you could forget all this "where's the stairs" stuff).

I believe this is exactly why Daniel plans to integrate a 'real' physics library. The current system of judging position based soley on tiles will never be accurate enough.

[daniel.santos]

If the engine were designed in a way which it knew where the actual "matter" was and where the "thin air" was, then all that would have to happen is the unit would have a variable on how high it could step up (Thus you could forget all this "where's the stairs" stuff).

I believe this is exactly why Daniel plans to integrate a 'real' physics library. The current system of judging position based soley on tiles will never be accurate enough.

Yes, and I suspect that modman may have the best approach here as well.  Remember that the current engine does do collision detection for projectiles, so it's not 100% based on tiles.  I believe the collision detection is being done via OpenGL and I'll just be moving it to ODE, which is designed for physics & collision detection, including more advanced functions than what the current Glest engine offers.   (Example, have you ever had a projectile type that sometimes missed it's target, went right through it because it's speed was too high? I have.)  Sorry I haven't attended this conversation more closely, I've been tied up with some other stuff.  None the less, I'm still thinking that some type of meta-data should be able to specify if a model's surface is supposed to be walkable or not.  I want to be able to keep track of which unit each unit resides in or upon at all times so that bonuses and other such rules can be properly applied.  Thus, as soon as a unit begins to climb the stairs of a walkable castle defence wall, it should probably begin to apply it's defensive bonuses at that time (or perhaps the stairs are a separate unit which have no or lessor bonuses?)  I guess that's something to hash out at some point.

[ZaggyDad]

Why would you want the stairs separate? Sounds like a waste of time to me.

[modman]

OK, then if we use my "matter/non-matter" approach, there is no need for size value, and units will never walk through one another!

Also, die animations can be improved because the units can have a force applied to them and react appropriately.

[ZaggyDad]

OK, then if we use my "matter/non-matter" approach, there is no need for size value, and units will never walk through one another!

Also, die animations can be improved because the units can have a force applied to them and react appropriately.

A force applied to them? What d'you mean?

I was thinking the size limit would help keep catapults or whatnot from going up onto the roof of, say, a castle.

[Hectichermit]

    How bout just a garrison ability for a unit type, infantry, calvary, siege, etc are types....only infantry can be garrisoned, you can have different abilities for unit types. With garrison just use an array and the limit is based on the array the array size is based on the walls size while each number in the array also contains a position on the wall.
   You can include an animation for stairs the animation switchs models based on which are garrisoned,  lets say you garrison a swordsman then an animation of a swordsman would play walking up the stairs or if you garrison an archer then you play the animation with an archer.
   Since the wall is based on an array then if we have a siege unit with a ladder then it would "attack" the position near where a player selects which shows an animation of a ladder being put upon the wall allows other infantry to climb up the ladder and take a position. You can have wall upgrades, like on LOR Battle for Middleearth that upgrades walls with trebuches or catapults or even secret passages lol

[-Archmage-]

i have a question

does GAE allow you too use .blend files instead of having to use g3d, cause i can model(not animate yet though), but i don't know how to export to g3d

anyway if it doesn't i'll live, or anyway maybe you could configure GAE so that it will allow you too use .blend files

[modman]

The forces would have to do with impact attack types, and also soft-body animations.
I was thinking that there would be a boolean tag that would say whether or not the unit can climb.

[maxpower]

I have a question about the latest development:
Is GAE already ported to Glest 3.2.1?

[hailstone]

No 3.2.1 changes have been merged yet.

[-Archmage-]

i have noticed that the particle projectiles are messed up they go so fast, are you planning to fix that?

[silnarm]

verarticus,
This problem is unrelated to the bugs modman pointed out.  I actually took a quick stab at fixing this and broke the red circles on other things so I backed out the change.  This is annoying because any time any unit issues a command with another unit as a target, a red circle appears, and it should only do that for orders that YOU issue yourself and not even for "auto-commands" (auto-repair, auto-attack, etc.)

This was irritating me somewhat, so I spent the weekend trying to make some sense out of the code...
Something I haven't done for a while, so much easier these days... how did we ever get by without "find all references" ?
Anyway, back to the point, the Flashing red circles...

Fixed.
Open up command.cpp, at around about line 70 (sorry, I've edited a bunch of stuff... but it should be about there somewhere)
find
if(unit && !isAuto())
and replace it with
if ( unit && !isAuto() && !unit->getFaction()->getCpuControl() )

This fixes the problem for the AI's buildings, but it might still happen on network games ? I haven't looked at any of the network code yet (and I didn't want to for a while yet, if ever!) but ideally this might actually be,

if ( unit && !isAuto() && !unit->getFaction()->getCpuControl()
&& !unit->getFaction()->getNetworkControl() )

Of course, someone would first need to add getNetworkControl() to Faction.

The reason you lag before a big attack is the path finder <img src="{SMILIES_PATH}/icon_sad.gif" alt="" title="Sad" /> that's on the list to be fixed.  When a lot of units are moving, they are all using the path finder and it's inefficient.

I'm not sure if I'm having the same problem, but I get a slow down usually after 5-10 minutes, sometimes it comes good again, only to slip back latter, and other times it just comes and stays
My initial investigations have left me stumped so far, but I can say it does not appear to be the pathfinder... will keep investigating and let you know what I find.

[ZaggyDad]

    How bout just a garrison ability for a unit type, infantry, calvary, siege, etc are types....only infantry can be garrisoned, you can have different abilities for unit types. With garrison just use an array and the limit is based on the array the array size is based on the walls size while each number in the array also contains a position on the wall.
   You can include an animation for stairs the animation switchs models based on which are garrisoned,  lets say you garrison a swordsman then an animation of a swordsman would play walking up the stairs or if you garrison an archer then you play the animation with an archer.
   Since the wall is based on an array then if we have a siege unit with a ladder then it would "attack" the position near where a player selects which shows an animation of a ladder being put upon the wall allows other infantry to climb up the ladder and take a position. You can have wall upgrades, like on LOR Battle for Middleearth that upgrades walls with trebuches or catapults or even secret passages lol

If you want that, then you can do the animations. Yikes. And what if you added infantry? You might miss the stairs thing, and then you'd be stuck not being able to garrison them. It should just use the running anim unless it has a stairs-specific anim.

Btw, Daniel, what's coming in the next release? (It isn't 0.3.0, is it?)