Ok... here's the dealio: I want to have flying transports that actually act reasonably well in my mod. I've been fighting this issue for some time now, and I'm getting frustrated. I've kludged around things for awhile, but I'm still not happy with the results.
There are a lot of a problems with this type of Unit:
1. It will not pick up Units until it and the Unit are aligned on the Y-axis. This means it has to jack around, wasting time on turning behavior, when it should just pick up the Unit and be done with it.
2. It always uses the origin of the S3O as the point that verifies it's in range. It needs to use a spherical area.
3. Spring crashes if I ATTACH-UNIT to piecenum -1, which does not cause a crash with ground transports (piecenum -1 is basically off the playing field, and makes the Unit invisible, except for the Icon).
4. Transports that carry Units attached to piecenum -1 still show the icons of the carried Units. They should not do so.
5. There is no quick way to get it to release the Units. Same problem as when picking them up, only worse, because the flight code then has to find a new place to "land", and invariably jacks around.
Basically, flying transports are completely useless, compared to most games, in large part because they're doing stuff very specifically geared towards OTA, where a flying transport usually just picked up one Unit at a time.
I want a simplified flying transport, that just does the following:
LOADING
1. Is given a circular area to try to pick things up in.
2. Lands in that circle, and sends a call to BeginTransport(), so that we can start animations showing that it is now picking things up.
3. Insta-loads everything that qualifies (unit count, mass, etc.) that is within a spherical area defined for the Transport (airTransportSphere, perhaps?). Icons should be hidden and the Units should quit being drawn immediately.
UNLOADING
1. Is given a circular area to drop things off on.
2. Lands in that circle, and sends a call to EndTransport(), so that we can start animations showing that it is now dropping things off.
3. Deploys the Units in a square around the Unit, with an appropriate hole in the center where the transport is. Units that are too big to fit into the grid should be posted first- this step needs to check and evaluate the footprints of the Units being transported, so that it makes sense. Again, the process should be instant- no futzing about with arms moving around or whatever. Just put the Units back down on the ground.
That's all I want- not a full transferral of ground-transport behaviors, even though that'd be closer to ideal, because it'd allow for animations to interact with transported Units. I can live without that, and will confuse things visually with FX. But I really, really, really need this for my mod.
There simply isn't any way around this problem that works well 100% of the time. I've tried, for example, building a fake flying vehicle, based off of early work in NanoBlobs (the Wolf used to not really fly), and it "flies", but it is clearly not flying anything like regular aircraft, and due to the fact that I cannot move the collision-sphere around at all, there are lots of serious limitations.
I've tried various tweaks with the flying transports, such as making them turn nearly-instantly, and this doesn't work terribly well, either. While I've been able to improve their behaviors so that they don't "jitter" as much, they're still bringing their origin into perfect alignment with the origin of the model they're transporting, etc., etc., etc., which looks like crap, if your flying transport is supposed to behave, say, like a modern helicopter, and land on the ground to let troops on and off.
I know this is a fairly major feature request, and if I could code it, I would, but frankly, I dunno where to start, at all. Flying transports have their very own movement / pathing code, etc., and it's not exactly light reading.
Flying Transports, Again.
Moderator: Moderators
Flying Transports, Again.
Last edited by Argh on 25 Jul 2007, 01:25, edited 1 time in total.
Well, on my list of Things To Do This Week, Trepan, is to finally start the process of learning how to integrate the new LUA stuff.
I'm really not opposed to using LuaRules for this particular problem, if it'll get it dealt with. I'm just having a hard time seeing how it's going to get around all of the hard-coded crap involved in this Unit type...
I'm really not opposed to using LuaRules for this particular problem, if it'll get it dealt with. I'm just having a hard time seeing how it's going to get around all of the hard-coded crap involved in this Unit type...
You could make a non-transport into a transporter with LuaRules (although the
lua Spring.GetUnitIsTransporting() and Spring.GetUnitTransporter() call won't
work with that trick). Here are some related calls:
Spring.SetUnitHealth(unitID, { paralyze = math.huge } )
Spring.SetUnitNoDraw(unitID, true)
Spring.SetUnitNoSelect(unitID, true)
Spring.SetUnitNoMinimap(unitID, true)
Spring.InsertUnitCmdDesc(unitID, { ... } )
CommandFallback()
-- insert a custom command after the move to load
-- insert a custom command after the move to unload
There are plenty of examples in the CA mod's LuaRules to get you started
(assuming you already know some lua; if not, start there
lua Spring.GetUnitIsTransporting() and Spring.GetUnitTransporter() call won't
work with that trick). Here are some related calls:
Spring.SetUnitHealth(unitID, { paralyze = math.huge } )
Spring.SetUnitNoDraw(unitID, true)
Spring.SetUnitNoSelect(unitID, true)
Spring.SetUnitNoMinimap(unitID, true)
Spring.InsertUnitCmdDesc(unitID, { ... } )
CommandFallback()
-- insert a custom command after the move to load
-- insert a custom command after the move to unload
There are plenty of examples in the CA mod's LuaRules to get you started
(assuming you already know some lua; if not, start there
Last edited by trepan on 25 Jul 2007, 01:53, edited 1 time in total.
