Actually, it might be better to leave hovers upright=1 as default, (to maintain compatibility, and because it really makes sense for them to be upright over water) but of course it can be overridden with a simple set UPRIGHT to FALSE; in Create().
I can remove the non-transportableness easily enough, but I might be tempted to make it a seperate issue.
Hovers can't be transported
Moderator: Moderators
Maybe I'm just silly... but why would you ever want upright=0 for any floating units? Why isn't the behaviour _always_ to be upright when on the surface of the water? Isn't this something that can safely be defaulted (normally I argue against default anything... but in this case the default seems silly)?
Who knows? Plus, its easier to code script get/set of it.Pxtl wrote:Maybe I'm just silly... but why would you ever want upright=0 for any floating units? Why isn't the behaviour _always_ to be upright when on the surface of the water? Isn't this something that can safely be defaulted (normally I argue against default anything... but in this case the default seems silly)?
I decided to submit it in that form, i.e. purely the implementation for the COB call, without affecting current defaults for hovers.
http://spring.clan-sy.com/mantis/view.php?id=445
As you can tell if you look at the diff, its really very simple. Probably simply the case that noone realised it would be useful before and it hadn't been asked for.
http://spring.clan-sy.com/mantis/view.php?id=445
As you can tell if you look at the diff, its really very simple. Probably simply the case that noone realised it would be useful before and it hadn't been asked for.
It can be useful sometimes. Imagine some quite big unit with hover movetype (the unit is not the classic hovercraft, but something more like wheeled amphibious vehicle instead) that can cross shallow water without being afloat (the water is too shallow for that). That unit will need to be Upright=0. But if it enters deep water (deep enough for it), it floats up and is upright=1 from now on.Pxtl wrote:Maybe I'm just silly... but why would you ever want upright=0 for any floating units? Why isn't the behaviour _always_ to be upright when on the surface of the water? Isn't this something that can safely be defaulted (normally I argue against default anything... but in this case the default seems silly)?
I already have a few such units completed (only they still use script to follow slopes on land as engine changes are not in released version yet). If you want, I can upload them somewhere or mail them to you.
Main features: they follow slopes while on land, they float on the surface while in water (and create some wakes), their water speed is lower than land speed, they switch to floating mode when the water is deep enough (the depth required is set in script), they emit engine sounds while moving.
Problems so far: they are not transportable (as they are hovers), they leave tracks on sea bottom while floating, the texturing is very simple.
Main features: they follow slopes while on land, they float on the surface while in water (and create some wakes), their water speed is lower than land speed, they switch to floating mode when the water is deep enough (the depth required is set in script), they emit engine sounds while moving.
Problems so far: they are not transportable (as they are hovers), they leave tracks on sea bottom while floating, the texturing is very simple.
So is anyone working on non-transportable hovers problem?
I can probably try to make a patch myself, but first I need to know what is the best solution. The possibilities as I see them now are:
1. Remove non-transportable hovers, ships and aircraft check completely - let their transportability be decided by size and mass (like for the ground units). Can have side effects like ships suddenly becoming air-transportable in some mods.
2. Add an FBI tag that controls transportability, like CanBeTransported=0|1, defaults to 0. If set to 0, uses the current method (so present mods are unaffected). If set to 1, allows transportation of a unit. In either case size and mass restrictions apply. This can be confusing as people may think CanBeTransported=0 always makes the unit untransportable when in fact it's not, and adding more tags is not such a good idea all by itself.
So, if someone has a better idea, post it here.
I can probably try to make a patch myself, but first I need to know what is the best solution. The possibilities as I see them now are:
1. Remove non-transportable hovers, ships and aircraft check completely - let their transportability be decided by size and mass (like for the ground units). Can have side effects like ships suddenly becoming air-transportable in some mods.
2. Add an FBI tag that controls transportability, like CanBeTransported=0|1, defaults to 0. If set to 0, uses the current method (so present mods are unaffected). If set to 1, allows transportation of a unit. In either case size and mass restrictions apply. This can be confusing as people may think CanBeTransported=0 always makes the unit untransportable when in fact it's not, and adding more tags is not such a good idea all by itself.
So, if someone has a better idea, post it here.
If you do implement CanBeTransported,
you could set it up with 0, 1, and some
other value as the default.
0 - can never be transported
1 - can always be transported
2 - set as is currently done (default value)
You could also use an empty string as
the default value, or a "default" magic
tag, or "auto", or ...
you could set it up with 0, 1, and some
other value as the default.
0 - can never be transported
1 - can always be transported
2 - set as is currently done (default value)
You could also use an empty string as
the default value, or a "default" magic
tag, or "auto", or ...
FTW. Sometimes backwards compatability hacks are required, sometimes it will just be far neater to avoid them.1. Remove non-transportable hovers, ships and aircraft check completely - let their transportability be decided by size and mass (like for the ground units). Can have side effects like ships suddenly becoming air-transportable in some mods.
For info, the only thing that prevented ships to be transported in TA was that the smallest ship had a 4x4 footprint while every transport was limited to transporting 3x3 sized units. But third party transports with higher "transportsize" could load and unload ships very well, without hacks. And in old TA, genuine Cavedog hovers and planes could be loaded fine by genuine Cavedog transports last time I checked.
So this is not a backward compatibility hack, this is just a pointless and annoying hack.
I still think it's retarded to implement a "CanBeTransported" tag while there is already a "cantbetransported" tag. And I fail to see why any mobile unit, be it plane, hover, or ships, must default to intransportable. The only thing that I understand might be better left untransportable by default are buildings (but I hope it's overridable). But I thought and hope building were just hard coded to have ultra heavy mass by default, and that being untransportable was just a consequence of that.
So this is not a backward compatibility hack, this is just a pointless and annoying hack.
I still think it's retarded to implement a "CanBeTransported" tag while there is already a "cantbetransported" tag. And I fail to see why any mobile unit, be it plane, hover, or ships, must default to intransportable. The only thing that I understand might be better left untransportable by default are buildings (but I hope it's overridable). But I thought and hope building were just hard coded to have ultra heavy mass by default, and that being untransportable was just a consequence of that.
Sorry to inform you, but as of current SVN revision (I'm not sure about past versions) CantBeTransported tag is not read by the Spring engine (or at least I wasn't able to find the code that reads it), so it is non-existant.zwzsg wrote:I still think it's retarded to implement a "CanBeTransported" tag while there is already a "cantbetransported" tag.
Removing the movetype check from transportability condition will be easy, I'll post the required changes here soon. We'll need someone with SVN commit access though...
Just make sure you don't end up with that one LLTA air transport...
"WTH? Where did all my units go? Oh my god, this dense stack of ugly models is over two hundred units in size! Oh no, I can't self-destruct any of it, toggle the transport and unload, or, indeed, destroy it through conventional means because it sucks up units that come within four elmos..."
"WTH? Where did all my units go? Oh my god, this dense stack of ugly models is over two hundred units in size! Oh no, I can't self-destruct any of it, toggle the transport and unload, or, indeed, destroy it through conventional means because it sucks up units that come within four elmos..."
The patch to disable movetype check is simple:
I submitted it into Mantis: http://spring.clan-sy.com/mantis/view.php?id=460
I have compiled the game with that patch and was able to load hover units and small aircraft into transports (haven't tried with ships yet).
Code: Select all
Index: TransportCAI.cpp
===================================================================
--- TransportCAI.cpp (revision 3456)
+++ TransportCAI.cpp (working copy)
@@ -273,8 +273,6 @@
// don't transport cloaked enemies
if (unit->isCloaked && !gs->AlliedTeams(unit->team, owner->team))
return false;
- if(unit->unitDef->canhover || unit->unitDef->floater || unit->unitDef->canfly)
- return false;
if(unit->xsize > owner->unitDef->transportSize*2)
return false;
if(!transport->CanTransport(unit))
I have compiled the game with that patch and was able to load hover units and small aircraft into transports (haven't tried with ships yet).
Katamari Damacy Spring.neddiedrow wrote:Just make sure you don't end up with that one LLTA air transport...
"WTH? Where did all my units go? Oh my god, this dense stack of ugly models is over two hundred units in size! Oh no, I can't self-destruct any of it, toggle the transport and unload, or, indeed, destroy it through conventional means because it sucks up units that come within four elmos..."
