Basically, here's what I want:
Aircraft with a TransportCapacity > 1 and MustLand = 1 should do the following:
1. When they reach the center of the loading-area circle, they must land at the nearest valid landing site (might want to invoke a Bugger-Off style of call here, to push other Units away from the transport).
2. They should then execute the TransportPickup(unitid) script section of the COB, just like ground transports do.
3. If unloading, they must land, then execute TransportDrop(unitid).
IOW, the difference between a ground transport and an air transport with MustLand = 1 is that the air transport has canFly = 1 and uses CAirMoveType.
I know this probably seems like a minor thing, devs. But it's not. Currently, the CAirMoveType code makes all air transports use QueryTransport(piecenum), BeginTransport(), EndTransport(), and my tests have determined that this code is entirely unsuitable for fast-loading behaviors. These transports fly to the unit they want to transport, have to turn to match the rotational centroid of the unit they are transporting, then move until the position of the QueryTransport Piece matches the origin of the transported model. This is incredibly inefficient, and does not allow for fast loading / unloading of multiple units.
If anybody knows a method around all of this, that allows the aircraft to remain aircraft, is 100% not-buggy, and will result in the proper behaviors (i.e., transport lands like a helicopter, drops troops off, then can take off again), I'm interested in looking at the BOS code. Thus far, though, I've determined that many of the things that I would like to try have proven to not work, or even worse, crash Spring. Spring's expectation that all air transports are basically just Atlases with different graphics is extremely annoying...
MustLand for Air Transports
Moderator: Moderators
Got an example script? Especially the function that would make it load the cargo? Because that's the big problem here- if you try to invoke TransportPickup(unitid), it doesn't work, or ignores commands (for example, you cannot attach-unit).
Now, one possible resolution would be a custom LuaRules script that maybe could have the transport not even be a transport, in the Spring sense, but just an aircraft that could go to a location and grab all appropriate Units and store them (somehow), but I don't have the foggiest how that could be done, frankly. If anybody has working code showing how to:
1. Substitute the button for Load / Unload for this Unit so that it would point to this custom load script
2. Have the Unit, on the user clicking Load, check for all appropriate Units in a circular area around the transport
3. Put those Units into some sort of off-board storage, and maybe even do a callback through COB to allow for animations, etc., to take place (could do this with a COB that ran cyclically, looking for a state change that would be passed from LUA)
4. Would, inversely, place those Units back onto the map (at appropriate positions, and after appropriate checks, of course- can't just dump infantry into the ocean, for example)
... I'm interested in implementing this. That may very well be a superior way of dealing with this issue, although it'd be nice if Spring's default behavior was just plain fixed. You would not believe how buggy and kludged it actually feels, now that I've played with it. It's worse, by far, than the aircraft code issues (which I have mainly gotten resolved at this point, after much experimentation).
Heck, if it was made just a little fancier, then between steps 2 and 3, it could cause all Units within that radius, but farther away than X, get Move orders that sent them towards that aircraft...
Problem is, as usual, I don't have time right now to do this myself. So any exploration of the practical aspects of getting this done, or a script that actually gets this done, even if a little crude, would be extremely helpful.
Now, one possible resolution would be a custom LuaRules script that maybe could have the transport not even be a transport, in the Spring sense, but just an aircraft that could go to a location and grab all appropriate Units and store them (somehow), but I don't have the foggiest how that could be done, frankly. If anybody has working code showing how to:
1. Substitute the button for Load / Unload for this Unit so that it would point to this custom load script
2. Have the Unit, on the user clicking Load, check for all appropriate Units in a circular area around the transport
3. Put those Units into some sort of off-board storage, and maybe even do a callback through COB to allow for animations, etc., to take place (could do this with a COB that ran cyclically, looking for a state change that would be passed from LUA)
4. Would, inversely, place those Units back onto the map (at appropriate positions, and after appropriate checks, of course- can't just dump infantry into the ocean, for example)
... I'm interested in implementing this. That may very well be a superior way of dealing with this issue, although it'd be nice if Spring's default behavior was just plain fixed. You would not believe how buggy and kludged it actually feels, now that I've played with it. It's worse, by far, than the aircraft code issues (which I have mainly gotten resolved at this point, after much experimentation).
Heck, if it was made just a little fancier, then between steps 2 and 3, it could cause all Units within that radius, but farther away than X, get Move orders that sent them towards that aircraft...
Problem is, as usual, I don't have time right now to do this myself. So any exploration of the practical aspects of getting this done, or a script that actually gets this done, even if a little crude, would be extremely helpful.
The way Spring handles air transport is very truthful to how TA did it. Down to how it's unsuitable for fast mass load/unload.
But then of some will say it's just a script hackery and that that they want more hard coded behavior and more FBI tags.
Although this time, it's true that for this one, I have to keep a list of all units and "weight" in some .h file, which makes quite incovenient to adapt to a large mod, and also it's very disrepectful of FBI tags. But those lists might be used by other scripted hackery too. And instead of listing all units in .h, maybe you could read other units FBI and transportability with some lua?
Argh wrote:If anybody knows a method around all of this, that allows the aircraft to remain aircraft, is 100% not-buggy, and will result in the proper behaviors (i.e., transport lands like a helicopter, drops troops off, then can take off again), I'm interested in looking at the BOS code.
I have this: Spring_dropship.zip. Use the stop button to make it land, then it will load every XTA mobile units around. And ignore everything else. Use the attack button to unload them all.Problem is, as usual, I don't have time right now to do this myself. So any exploration of the practical aspects of getting this done, or a script that actually gets this done, even if a little crude, would be extremely helpful.
But then of some will say it's just a script hackery and that that they want more hard coded behavior and more FBI tags.
Although this time, it's true that for this one, I have to keep a list of all units and "weight" in some .h file, which makes quite incovenient to adapt to a large mod, and also it's very disrepectful of FBI tags. But those lists might be used by other scripted hackery too. And instead of listing all units in .h, maybe you could read other units FBI and transportability with some lua?
I'm curious - is it possible to make a plane that behaves like an (immobile) ground-unit when landed, and otherwise behaves like a plane? Since that sounds like what you're designing here.
If not, then it sounds almost like a whole new movement-class. After all, a player might want the same behaviour for a builder (must land before using nanolathe, do full open/close animation) or a combat-unit (an airborne equivalent to the starcraft Siege Tank).
After all, this "land, then do your normal ordered action" behaviour you desire could be applied to a wide number of things.
Obviously, if it's simpler to just implement the "landing transport" than the "general purpose landing air unit" then ignore me. I was just thinking that this could be more versatile than just a transport.
If not, then it sounds almost like a whole new movement-class. After all, a player might want the same behaviour for a builder (must land before using nanolathe, do full open/close animation) or a combat-unit (an airborne equivalent to the starcraft Siege Tank).
After all, this "land, then do your normal ordered action" behaviour you desire could be applied to a wide number of things.
Obviously, if it's simpler to just implement the "landing transport" than the "general purpose landing air unit" then ignore me. I was just thinking that this could be more versatile than just a transport.
What happens when the player use a too large loading circle area? Would the TransportPickup(unitid) use no range restriction and accept to load even units from the other side of the map? Would the engine, upon seeing the TransportPickup refused to load the unit, would make the plane takeoff, move abit, land, thus making the whole process even more inefficent than the regular loading method for plane? Would the engine be hardcoded to only ask the script to load units in a [80] radius? Would the engine ask once to load far units, let the script refuse and not ask it to load them again?Argh wrote:Aircraft with a TransportCapacity > 1 and MustLand = 1 should do the following:
...
Oh, and Pxtl, while it's true some people might want MustLand for many other actions, I know Argh want his air transport to have weapons that are fired even when flying. Here comes MustLandTransport, MustLandBuild, MustLandWeapon1, and a dozen others!
Better have a set FORCELAND to TRUE; script command imo. The engine would try to call both BeginTransport() and TransportPickup(id), in Argh's plane TransportPickup(id) would start with a set FORCELAND to TRUE; which would make the plane immediatly land on the nearest spot, then the TransportPickup(id) would proceed on its next lines (waiting to have landed can be done with current commands), do the loading, and do a set FORCELAND to FALSE; when it's done, then ends, at which point, the engine would call TransportPickup(id) with a new id, and then the script would either load this again, or it won't do anything, in which case the engine would make plane take-off and fly over the next unit, then retry TransportPickup(id) command.
zswswgszswg (never can remember how to spell your nick), I just thought of that air-weapon land-transport problem the moment after I posted. Your suggestion is probably best, since AIs would probably still behave sensibly with the MustLand command, so the AI "hints" that the TDF files provide aren't necessary... the only challenge is that, for example, if a plane can't land on water, the AI might not know that it can't do it's action on the water (particularly relevant if you're talking about a MustLand weapon).
I think the fact is that the mustland transports would probably involve the same behaviour as a ground unit - land, grab everything in reach, takeoff and move again, grab everything in reach, etc. Cumbersome, but the same problem you'd have with any other crane-based-mass-transport (albeit with more overhead in movement). Annoying, but consistent. The transporting AI would need to be improved to try and find the ideal location to load/unload from (if it doesn't already), but that could be applied to all transports, not just aircraft.
I think the fact is that the mustland transports would probably involve the same behaviour as a ground unit - land, grab everything in reach, takeoff and move again, grab everything in reach, etc. Cumbersome, but the same problem you'd have with any other crane-based-mass-transport (albeit with more overhead in movement). Annoying, but consistent. The transporting AI would need to be improved to try and find the ideal location to load/unload from (if it doesn't already), but that could be applied to all transports, not just aircraft.
