Ahoy there!

[silnarm]

Forgive the crappy screen capture, but you get the idea...





Still lots of work to be done yet, but a good start...

[assassin]

SWEET!!!!!!!!! 
This opens up a whole new area in glest. I think you should try and make it so that land units can walk in "shallow" water and sea units can travel in both shallow and deep water. Of course, in this someone would have to implement "transport" units to carry units around.

Anyway, great work!

[titi]

Currently its only the movement of these units!
But how to create such water units!?
If you create a water unit on land, what will happen?
I creating/initial positioning of these units will be the next big step which makes water units usable.

But for now, please only focus on the movement!

[ElimiNator]

you could have a dock that goes at at the edge of the water and spawns them in the water?

And it looks GREAT! 

[silnarm]

... I think you should try and make it so that land units can walk in "shallow" water and sea units can travel in both shallow and deep water....

"land" units can still walk in shallow water... but the 'land' field is now the 'walkable' field, and boats can either define "any_water" which obviously gives them the behaviour you suggest, or "deep_water" which only allows them on non-fordable water cells (and there is also an 'amphibious' field).

But how to create such water units!?
If you create a water unit on land, what will happen?

Yeah, it's purely movement for the moment, to test it out I modified the technician to morph first into a intermediate unit, that travels in the field 'amphibious', to get out onto the ocean, then that unit morphs into the 'ocean only' version, to test the path finding.

So 'morphing' is the only way to do it at the moment, and trying to morph to a unit that can't move on the current terrain will throw up the "Invalid Position" message.

As I said, plenty of work to be done yet... probably first on the list is making it work without having to change any existing xml! I've, hopefully temporarily, broken xml compatibility to do this.

you could have a dock that goes at at the edge of the water and spawns them in the water?

I was thinking a dock/shipyard style building that had to be built partially on land, partially over water. I've already added some things to the code to make this pretty straight forward, the mod maker would then specify which bits had to be on land, and which on water, probably in a manner similar to how cellmaps are done now.

But first I need to clean up the path finder and get that out...  boats are coming though, don't doubt it!

[Omega]

This is great. You are a fantastic asset to Glest silnarm! We (speaking for the Glest community) hope to see much more of you in the future!

[John.d.h]

YAY! 

My mind is already RACING with possibilities for this!  Marines with amphibious landing craft, fish men attacking from the sea, giant sea serpents, ahhhh!  I think my head might explode!

Yeah, it's purely movement for the moment, to test it out I modified the technician to morph first into a intermediate unit, that travels in the field 'amphibious', to get out onto the ocean, then that unit morphs into the 'ocean only' version, to test the path finding.

So 'morphing' is the only way to do it at the moment, and trying to morph to a unit that can't move on the current terrain will throw up the "Invalid Position" message.

So what does the amphibious field do?  Is that just units that can travel on both land and water, or is it a separate area altogether?

[-Archmage-]

WOW

Awesome, i can't wait to try it sometime

[silnarm]

... hope to see much more of you in the future!

Count on it

My mind is already RACING with possibilities for this!  Marines with amphibious landing craft, fish men attacking from the sea, giant sea serpents, ahhhh!  I think my head might explode!

Hmmm... fishmen.. might need another field or two...  In fact, we should nut out what fields we do want... a topic for next week perhaps

So what does the amphibious field do?  Is that just units that can travel on both land and water, or is it a separate area altogether?

The former, it's the 'combination' of land and water fields.

[ElimiNator]

I think that you should make half water & half land units (for a dock).
And how far are you done making water units (I can't wait!) 

[wciow]

 Nice work silnarm

I'm looking forward to making so water units when this gets released.

[ElimiNator]

Could you make the die skill a morph skill and turn a horse man into a spear man?

[silnarm]

Could you make the die skill a morph skill and turn a horse man into a spear man?

Certainly an interesting idea, but I'm afraid I'm looking at too many things at once already...
Might look into it later though.

[John.d.h]

I think there's already a "morph on death" feature in the works.  That's not really what this thread is about though. >.>

Hmmm... fishmen.. might need another field or two...  In fact, we should nut out what fields we do want... a topic for next week perhaps

So what does the amphibious field do?  Is that just units that can travel on both land and water, or is it a separate area altogether?

The former, it's the 'combination' of land and water fields.

Instead of having an amphibious field, maybe you could just enable multiple fields for the unit?  There could be for example shallow water, deep water, fordable water, air, and land.  Regular land units would only have land and fordable water; semi-aquatic units like crocodiles would be defined with shallow water, fordable water, and land; small boats with fordable, shallow, and deep water; battleships with deep water only; and some truly amphibious thing would be defined for everything but air.  These are just examples, of course.  While we're at it, an "unwalkable" field could be useful for cliffs and other obstructions, and maybe an "impassable" field for barriers that couldn't be walked through or flown over.

[silnarm]

Instead of having an amphibious field, maybe you could just enable multiple fields for the unit?  There could be for example shallow water, deep water, fordable water, air, and land.  Regular land units would only have land and fordable water; semi-aquatic units like crocodiles would be defined with shallow water, fordable water, and land; small boats with fordable, shallow, and deep water; battleships with deep water only; and some truly amphibious thing would be defined for everything but air.  These are just examples, of course.

The problem with this approach is potential inefficiency with the 'map metrics'. If we allow any combination of fields to be specified then we need to keep 2^(n-1) individual metrics for each map cell, where n is the number of fields. For your example, you specified 5 fields, so that's 16 'metric fields', which is precisely how many my current code will accommodate. Do we really need to support, say, a fordable water + air combination?

Although... come to think of it, we might be able to build just the combinations we need at runtime, so we have the basic fields all pre-calculated, and when we load a unit with a combination of fields (that we haven't already seen yet) we build the metrics for it from the base ones.  Hmmm... I think that should work, but I just thought of it, so let me think some more and get back to you

While we're at it, an "unwalkable" field could be useful for cliffs and other obstructions, and maybe an "impassable" field for barriers that couldn't be walked through or flown over.

I might be able to go you one better here, and add a 'maximum slope' variable. So any sufficiently steep inclines will automagically be impassable. Could probably even be defined by the map, if/when we get around to a new map format.
We can already make areas unwalkable with the 'invisible wall' tileset object, something for the air might be good. Is this what you meant?

[John.d.h]

The problem with this approach is potential inefficiency with the 'map metrics'. If we allow any combination of fields to be specified then we need to keep 2^(n-1) individual metrics for each map cell, where n is the number of fields. For your example, you specified 5 fields, so that's 16 'metric fields', which is precisely how many my current code will accommodate. Do we really need to support, say, a fordable water + air combination?

Maybe a "flying" variable?  If a unit was defined as flying, then we wouldn't even have to define fields for it, and that way air couldn't be paired with anything else (maybe not even its own field anymore?).  That would cut it down to 8, I believe.  How many do we currently have to deal with?

Although... come to think of it, we might be able to build just the combinations we need at runtime, so we have the basic fields all pre-calculated, and when we load a unit with a combination of fields (that we haven't already seen yet) we build the metrics for it from the base ones.  Hmmm... I think that should work, but I just thought of it, so let me think some more and get back to you

Interesting thought.

I might be able to go you one better here, and add a 'maximum slope' variable. So any sufficiently steep inclines will automagically be impassable. Could probably even be defined by the map, if/when we get around to a new map format.

I'm not too keen on the idea of a maximum slope per se, since somebody might want to make a unit that can climb (think Colonel Burton from C&C:Generals) or step over cliffs (like the Protoss Colossus from SC2), so I was thinking those unit would just be defined for the unwalkable field.  Maybe there would be a way to define whether or not a unit was affected by maximum slope?  Then I think that would work just fine.

We can already make areas unwalkable with the 'invisible wall' tileset object, something for the air might be good. Is this what you meant?

Yeah, pretty much.  I was just thinking of the impassable black void tile in Age of Mythology, but I guess it would be better to have it as an object rather than a field.

Edit: Today, I came up with another idea.  Instead of having a bunch of water fields, could we define units as being able to traverse certain heights, dependent on the water level of the map?  For example, if h is the water height of the map, a unit might be able to go anywhere between h-2 and h-4 (shallow water), while another might be able to go anywhere above h-1 (I think this is the way land units behave already).  Then there would be a variable for travel type, where a unit would be either walking, floating, or flying.  Walking units would always stay on the ground (if its underwater, it would walk along the bottom like a lobster), floating units would stay at h when on the water and stay at ground level when on land, and flying units would always stay in the air.  This way, water might not have to be a field at all.

[silnarm]

I'm not too keen on the idea of a maximum slope per se, since somebody might want to make a unit that can climb (think Colonel Burton from C&C:Generals) or step over cliffs (like the Protoss Colossus from SC2), so I was thinking those unit would just be defined for the unwalkable field.  Maybe there would be a way to define whether or not a unit was affected by maximum slope?  Then I think that would work just fine.

How about have maximum slope defined on a per unit basis? We'll set some reasonable default, so if a unit's xml doesn't specify it'll get the default value, otherwise it could do something like:
<max-slope value="0.75" />
Which would only let that unit type 'climb' slopes up to a gradient of three quarters.

Edit: Today, I came up with another idea.  Instead of having a bunch of water fields, could we define units as being able to traverse certain heights, dependent on the water level of the map?  For example, if h is the water height of the map, a unit might be able to go anywhere between h-2 and h-4 (shallow water), while another might be able to go anywhere above h-1 (I think this is the way land units behave already).

I didn't like this at first thought, as I thought it would complicate the pathfinding horribly, but then I thought, we can just store the depth of a water cell in with the metrics and use it in the same way (it currently tells us how much 'space' is around a cell, do determine quickly if a unit of a given size can occupy the cell).  We'll still need a water field, but we can now get by with one.

Then there would be a variable for travel type, where a unit would be either walking, floating, or flying.  Walking units would always stay on the ground (if its underwater, it would walk along the bottom like a lobster), floating units would stay at h when on the water and stay at ground level when on land, and flying units would always stay in the air.  This way, water might not have to be a field at all.

The rest sounds 'kinda-sorta' like what I've done already
What was "Field" has effectively been replaced by two types,
Zone: This is the 'zone' the unit occupies, current 'attack-fields' now specify zones, and I have
two zones defined: 'surface' and 'air' (and a commented out 'sub-surface').  To restore xml compatability the code still expects <attack-fields> with embedded <field> elements, and 'land' is interpreted as 'surface', if it can currently attack land, it will now also be able to attack water units (because water and land are in the same zone, surface).

Field: This is now strictly a field of movement, atm I have 'walkable', 'air', 'any_water', 'deep_water' and 'amphibious'. A Field indirectly specifies a zone, obviously the 'air' zone/field match and all the other (current) fields 'map' to the surface zone.

Then instead of your travel type for a unit, I had a terrain (or surface) type for each cell, with values 'land', 'fordable', & 'deep_water'.  The walkable field is then essentially the surface zone + land and fordable terrain types. any_water is the surface zone + fordable & deep_water types, etc.

It might seem overly complicated, but it is flexible...

Of course, given the discussion above, maybe this level of flexibility can be obtained easier...

[modman]

This is definitely very cool.
Sorry for bursting your bubble, but there is a problem that could occur from not being able to morph from one field to another.

[John.d.h]

How about have maximum slope defined on a per unit basis? We'll set some reasonable default, so if a unit's xml doesn't specify it'll get the default value, otherwise it could do something like:
<max-slope value="0.75" />
Which would only let that unit type 'climb' slopes up to a gradient of three quarters.

Hmm... I like that.  It's a lot harder to push a catapult up a hill than it is to walk, so being able to change the maximum slope for each unit would be helpful, but setting a default would make it so that people who don't want to be bothered with it don't need to.  Setting a default would also make it easier to be backwards-compatible with the XMLs already in place.

I didn't like this at first thought, as I thought it would complicate the pathfinding horribly, but then I thought, we can just store the depth of a water cell in with the metrics and use it in the same way (it currently tells us how much 'space' is around a cell, do determine quickly if a unit of a given size can occupy the cell).  We'll still need a water field, but we can now get by with one.

Sounds like progress.

This is definitely very cool.
Sorry for bursting your bubble, but there is a problem that could occur from not being able to morph from one field to another.

Why do you say that?

[modman]

Some ideas like a unit moving from the aquatic field to the land will not work.  So no alligators, for instance.

[John.d.h]

Some ideas like a unit moving from the aquatic field to the land will not work.  So no alligators, for instance.

I'm not sure what you mean.

[silnarm]

Some ideas like a unit moving from the aquatic field to the land will not work.  So no alligators, for instance.

Amphibious field?

And if/when we add the sub-surface zone, we can have an underwater field, and combine it with other fields as we see fit, so John's fishmen coming out the a sea could be a reality...

'switching' fields is no problem.

[modman]

OK, thanks.  I get it now.

My concern (minor) is that the fields will hardly be used.  There are not a lot of things for all three fields.

For the underwater field, will you be able to see the units there, because otherwise it will be downright confusing!

[silnarm]

My concern (minor) is that the fields will hardly be used.  There are not a lot of things for all three fields.

For the underwater field, will you be able to see the units there, because otherwise it will be downright confusing!

I just want to keep it as flexible as possible, who knows how the engine might be used in the future...

And yes, seeing underwater units would be an issue that would need to be dealt with, but the sub-surface zone doesn't exist yet... let's just get stuff floating on the water first

[John.d.h]

For future reference, farther down the road.

https://forum.megaglest.org/index.php?topic=4001.0