How to make a unit only able to move in deep water?

[AnyNameYouWish]

I'm making a Naga RPG and I have changed submerged units to be able to move, and move faster than they do on land. There are two problems I'm running into:

1. I have set the submerged unit's movement types to 'float', but they can still move in shallow water. I want them to only be able to move in deep water. Is there a way to accomplish this? I know the submerge ability only works in deep water already, how does it detect that?
2. When submerged and moving, the units overlap. I could handwave this as them being underwater and thus their bubble trails overlap because they don't all need to be strictly next to each other like on land or shallow water, but if possible I'd like to also rectify this.

 

[Bleeq]

If you figure something out for (1) I'd like to hear about it. I want to make a unit morph into stationary (a la siege tank or machine gun nest or something) and the easiest way would be to change their movement to float. If you totally remove etheir ability to move they won't turn to target enemies anymore.
Except if they gain float in shallow water then they can still move again, so perhaps it's possible to change them to float, but restrict their movement in shallows, or change this for all floating units (as there are unlikely to be any legitimate boat or ship units on the maps).

Regarding 2, I personally don't see it as a major issue but basically what you want is to include some form of collision between the units, right?
Maybe you could create dummy units that are invisible but still collide with each other, and simply have the bubbles follow those invisible units?
Or the other way round; the units become invis and the bubbles are dummies which follow them for graphical effect.

Don't ships and boats have collision with each other anyway? If so just copy one of those but replace their model/graphics with the submerged graphics.

 

[Bleeq]

Actually I've been playing around and the Prop Window (propulsion) method works to make a unit stationary. There were older posts saying it messed with their attack animations but I'm not having that problem. Maybe it is because I'm giving the unit a base prop window of 0 in OE?
There was a minor problem that giving the stationary unit a move order would turn it passive because it would remain attempting to fill that order despite not being able to move.
But it was an easy fix have a trigger catch those orders, and order the unit to Stop afterwards to clear its orders.
Note though that the stop order can't be given immediately after the move or it won't cancel it out, so a tiny wait will fix that.

Sorry this wasn't related to shallow water, but hopefully someone else might find it from google or something :/

 

[Luashine]

I don't know the answer but I'd like to start with some theory crafting to come closer to an answer.

Terrain types​

wc3-file-formats/specs/w3e at main · Luashine/wc3-file-formats - "Water" is a separate terrain flag. This probably implies "deep water"

Pathing​

I think the correct file was war3mapPath.tga or war3map.wpm
The colors have reserved meaning for walkability/flyability/buildability/blight. There's no "swimability" flag.

Unit movement types​

https://world-editor-tutorials.thehelper.net/uniteditor.php#break5

Movement - Type (Movement Type)
Defines the type of movement the unit/building/hero is to have. Movement type affects things such as the ability to move over particular terrain, and what spells the unit/building/hero can be subject to. It also affects which Unit Editor fields have an effect on the unit/building/hero.

I don't have access to WE right now, so looking at code (arrived at through SetUnitPathing) will have to do:

constant pathingtype        PATHING_TYPE_ANY                = ConvertPathingType(0)
constant pathingtype        PATHING_TYPE_WALKABILITY        = ConvertPathingType(1)
constant pathingtype        PATHING_TYPE_FLYABILITY         = ConvertPathingType(2)
constant pathingtype        PATHING_TYPE_BUILDABILITY       = ConvertPathingType(3)
constant pathingtype        PATHING_TYPE_PEONHARVESTPATHING = ConvertPathingType(4)
constant pathingtype        PATHING_TYPE_BLIGHTPATHING      = ConvertPathingType(5)
constant pathingtype        PATHING_TYPE_FLOATABILITY       = ConvertPathingType(6)
constant pathingtype        PATHING_TYPE_AMPHIBIOUSPATHING  = ConvertPathingType(7)

Walkability, but nothing about swimming. Either floatability or amphibiouspathing

Putting the puzzle pieces together​

If neither "floatability or amphibiouspathing" helps, then it's probably because the abilities, the movement and their pathing are only controlled deep inside game's code. Water movement is not a "first class citizen" judging by the features above, maybe it was added late on into the game. So the support is limited only to what was required by game designers at the time.

I know the submerge ability only works in deep water already, how does it detect that?

Like many abilities, they have custom logic. Maybe it's possible to detect the triggering (disengagement) of Submerge and move the unit to nearby deep water tile? Another option as someone else suggested is to drain life/mana when moving across wrong tiles.

---

Why it's bad to push the boundaries of something unintended by the base game: [General] - Pathing Issue: Returning Resources over deep water

Something like this is useful to read to get an idea: [JASS] - How to check for deep and shallow water ?
Going the opposite direction can help too: Adding new movement types. "Is it possible to add new movement types in the Object Editor (like an anti-float movement type that prevents going in any water)?"
What else to try? Custom path maps and pathing blockers to manually separate deep from shallow water: Pathing - Everything about it

Edit, PS: I am not a map maker. All this info was created through search of existing topics, reading and the correct working approach. If this post answers your question, I believe you could've arrived here yourself Though I doubt it's exactly an easy "don't allow shallow water" solution as we wanted.

 

[Luashine]

2. When submerged and moving, the units overlap. I could handwave this as them being underwater and thus their bubble trails overlap because they don't all need to be strictly next to each other like on land or shallow water, but if possible I'd like to also rectify this.

Again refer to https://world-editor-tutorials.thehelper.net/uniteditor.php#break5
This is probably what you want. It's possible the Submerge ability toggles it in code. It would be interesting to test and tinker with, in code too, using ConvertUnitIntegerField and ConvertUnitBooleanField, BlzGetUnitBooleanField etc. Although I always think these functions are buggy (maybe they are).

Movement - Group Separation - Enabled (Boolean)
Defines whether to allow/deny flying units/heroes to physically separate from each other when issued a move order. If set to false, the units/heroes will be allowed to bunch on top of each other when moving.

Movement - Group Separation - Group Number (Integer)
Unknown.

Movement - Group Separation - Parameter (Integer)
Unknown.

Movement - Group Separation - Priority (Integer)
Unknown.

 

[Luashine]

One more thing, I missed this. The pathing types flags:

// Pathing Flag
    constant pathingflag    PATHING_FLAG_UNWALKABLE             = ConvertPathingFlag(2)
    constant pathingflag    PATHING_FLAG_UNFLYABLE              = ConvertPathingFlag(4)
    constant pathingflag    PATHING_FLAG_UNBUILDABLE            = ConvertPathingFlag(8)
    constant pathingflag    PATHING_FLAG_UNPEONHARVEST          = ConvertPathingFlag(16)
    constant pathingflag    PATHING_FLAG_BLIGHTED               = ConvertPathingFlag(32)
    constant pathingflag    PATHING_FLAG_UNFLOATABLE            = ConvertPathingFlag(64)
    constant pathingflag    PATHING_FLAG_UNAMPHIBIOUS           = ConvertPathingFlag(128)
    constant pathingflag    PATHING_FLAG_UNITEMPLACABLE         = ConvertPathingFlag(256)

I have no idea how these would come about, but the anti-float and anti-amphibious sound like what you looked for.
This is a new and unfinished API from 1.31. There's nothing you can do with these but it hints what might be possible within the engine... or this was a plan that was never finished.