Hovers can't be transported

[yuritch]

I'm currently experimenting with some "truly amphibious" units. That is, they behave like land units while on land (follow the slopes) and float on the water surface while in water (like hovers do). Using set MAX_SPEED I can decrease their speed in ampibious mode, so that works fine (most real world amphibious units are much slower in water then they are on land).
However, to be able to make them float, I had to give them the hover MoveType and CanHover=1 (and some script to follow the slope while on land, like the one in Nanoblobs Demon for ex.). From that time on the units cannot be loaded into a transport (load cursor just doesn't appear while targeting them). I tried various tags like Mass to no effect.
I then looked into Spring source and found something interesting (in TransportCAI.cpp, function CanTransport):

Code: Select all

if(unit->unitDef->canhover || unit->unitDef->floater || unit->unitDef->canfly)
return false;

That means any units with CanHover=1 (or CanFloat=1 or CanFly=1) just cannot be transported, engine doesn't allow to load them. Of course, they probably can be loaded using heavy scripting, but I'd like to avoid that solution.
So, does anyone have an idea what could be done?
BTW, there was another small glitch with those units. If set to leave tracks, they still do that while in the water. Tracks appearing on the sea bottom under a floating unit look strange. That's minor though.

[SpikedHelmet]

Make a patch, and change "return false" to "return true"?

[KDR_11k]

No, that'd make all hovers, planes and ships transportable regardless of the other values.

[kujeger]

Code: Select all

if(unit->unitDef->canhover || unit->unitDef->floater || unit->unitDef->canfly) 
return false;

to

Code: Select all

if(unit->unitDef->floater || unit->unitDef->canfly) 
return false;
if(unit->unitDef->canhover)
return true;

?


edit: Or maybe a new flag, "unitTransportable" ?

[yuritch]

What can be an acceptable solution then? A new FBI tag (like CanAlwaysBeTransported=1 or OverrideTransportability=1)?
Or can the unit be made to behave like a hover without being CanHover=1? I had to make it hover because ordinary ground units cannot stay at the water surface. Of course, I can use scripting to raise unit's model to surface level if it is under water, but AFAIK the hitsphere will remain below water and that will cause more problems.
Edit (to previous poster):

Code: Select all

if(unit->unitDef->floater || unit->unitDef->canfly) 
return false; 
if(unit->unitDef->canhover) 
return true;

That will make ALL hovers in ALL mods transportable. That's a bit too much.
UnitTransportable is a bit unclear. If it defaults to 1, we still have the transportable ships problem. If it defaults to 0, we'll have "nothing is transportable" problem.

[Saktoth]

I see no reason why hovers in all mods shouldnt be transportable, IMO its an oversight and would be welcomed in most mods.

Making air and ships transportable is another kettle of fish, but i dont see why the engine should forbid them from being so entirely.

[kujeger]

UnitTransportable is a bit unclear. If it defaults to 1, we still have the transportable ships problem. If it defaults to 0, we'll have "nothing is transportable" problem.

Well, you can have the current On-Off hardcode translate to defaults. That way things will be the way they are now by default, but being overrideable.

[zwzsg]

So we'll have both canbetransported and cantbetransported tags?

Personnaly I fail to see the reason why hovers and ships must be hardcoded to be untransportable.

[FLOZi]

So we'll have both canbetransported and cantbetransported tags?

Personnaly I fail to see the reason why hovers and ships must be hardcoded to be untransportable.

I 100% agree, it is a limitation added into Spring, not even one inherited from TA. And should be removed with haste.

[Peet]

+1

[Forboding Angel]

+2

[Fanger]

+3 to this..

and could some one also make hovers be able to follow terrain normally (no scripting required) or at least allow it to be toggalble ala the upright=1 tag, cause even the scripting in nanoblobz does not even come close to actual ground units..

[FLOZi]

+3 to this..

and could some one also make hovers be able to follow terrain normally (no scripting required) or at least allow it to be toggalble ala the upright=1 tag, cause even the scripting in nanoblobz does not even come close to actual ground units..

I've made a patch which gives control of UPRIGHT via the script, and killed off hovers being upright by default. Using this method you can script a hover to be upright when on water and non-upright on land, or you can just use the upright=1; tag to keep current behaviour.

[Fanger]

THAT IS MADE OF WIN AND GOD!

and that is going in the next version of spring???

GOD I HOPE SO!

[Zoombie]

Nice job, Flozi.

[FLOZi]

THAT IS MADE OF WIN AND GOD!

and that is going in the next version of spring???

GOD I HOPE SO!

I need to submit it on mantis and have it checked over, but hopefully.

It's not perfect visually though, there is a bit of nastyness when the unit changes between, but with a better script (the one i used to test was really quite crude) it's probably not too bad.

[Fanger]

the possiblity is still great, and Im sure the scripting can be tweaked, but calling that is still awesome..

[Argh]

I've made a patch which gives control of UPRIGHT via the script, and killed off hovers being upright by default. Using this method you can script a hover to be upright when on water and non-upright on land, or you can just use the upright=1; tag to keep current behaviour.

Yay! I can finally get rid of that hacky, nasty, cpu-intensive workaround code

[Fanger]

I KNOW ITS GREAT... i think flozi deserves a cookie for this..

[yuritch]

+1 to Upright=0 hovers (and +10 to set UPRIGHT).
What about the non-transportable things? Will those be removed too?