Page 2 of 3
Posted: 21 Feb 2007, 12:04
by FLOZi
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.
Posted: 21 Feb 2007, 12:54
by KDR_11k
I think it should use the upright tag even with hovers, maybe with a default of 1 if the tag is absent.
Posted: 21 Feb 2007, 15:57
by Pxtl
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)?
Posted: 21 Feb 2007, 19:38
by FLOZi
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)?
Who knows? Plus, its easier to code script get/set of it.
Posted: 21 Feb 2007, 21:09
by Fanger
im completely fine with the ability to call it via script..
As flozi said you can either just straight up disable it in the create..
or as would make more sense use the terrain differentiation stuff to set it depending on whether the unit is over water...
Posted: 21 Feb 2007, 21:38
by FLOZi
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.
Posted: 21 Feb 2007, 22:43
by yuritch
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)?
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.
Posted: 21 Feb 2007, 23:42
by Fanger
are you kidding Ive wanted this for so long..
the GD amphbious units in EE are not intended to go underwater.. I have since the beginning of EE wanted them to go across the surface.. only they look retarded doing this currently...
heck I might do the same thing with URC..
Posted: 22 Feb 2007, 07:14
by yuritch
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.
Posted: 05 Mar 2007, 07:16
by yuritch
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.
Posted: 05 Mar 2007, 07:37
by trepan
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 ...
Posted: 05 Mar 2007, 10:32
by FLOZi
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.
FTW. Sometimes backwards compatability hacks are required, sometimes it will just be far neater to avoid them.
Posted: 05 Mar 2007, 13:38
by zwzsg
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.
Posted: 05 Mar 2007, 16:52
by yuritch
zwzsg wrote:I still think it's retarded to implement a "CanBeTransported" tag while there is already a "cantbetransported" tag.
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.
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...
Posted: 05 Mar 2007, 17:24
by Neddie
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..."
Posted: 05 Mar 2007, 17:48
by yuritch
The patch to disable movetype check is simple:
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 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).
Posted: 05 Mar 2007, 18:29
by KDR_11k
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..."
Katamari Damacy Spring.
Posted: 05 Mar 2007, 18:36
by Pxtl
In that case, the only real question is one of backwards-compatibility - use CanBeTransported and sensibly avoid negating booleans, or be compatible with OTA (a concept which is rapidly diminishing in value).
Either way, the current system is unjustifiably silly.
Posted: 05 Mar 2007, 22:47
by manored
I know this is a bit off topic, but it may affect that modification later:
Im almost sure (unleash one of BA moders made it propositally what would make no sense for me) that amphibious units can be loaded while underwater but cannot be unloaded on water.
Posted: 05 Mar 2007, 22:54
by Peet
Yeah I've noticed that too...rather annoying at times.