I can't even say how appalled I am. It's bad. Really, really bad. I'd forgotten just how bad.
It vibrates whenever it reaches a destination. Just sits there, in mid-air, vibrating like it's having a seizure.
It cannot seem to find a valid landing-spot. It's an 8X8, it shouldn't be having this problem on the map I picked to test with.
Until I lowered its acceleration to the same values as the Arm Atlas, it would skid about, like it was coated with an invisible layer of grease.
Once it reaches the destination, it air-drops the Units as it should, then... er... unless I give it a path, it just stops and gets killed. It's not even smart enough to keep moving, like a bomber.
It doesn't bank on turns. It basically just acts like it's a hovercraft with Upright=1, except that even hovercraft don't look this retarded.
Ok, instead of just bitching, I'm going to propose a plan, for new air-transports, that will not be retarded. These would not be backwards-compatible- I can see clearly that this code was designed just for OTA mods, and will never, ever work right for PURE.
Here's what I think we should have:
1. A variable, called "TransportType", that is basically a flag for any type of transport, like WeaponType. This would call up the appropriate behaviors.
2. If TransportType==ParaDrop, then:
A. The Transport will use the Bomber code, or a clone with appropriate changes, for pathfinding and general flight behavior. Not the CAirTransportMoveType code, which is terrifyingly bad. It should behave as a Bomber that's armed with a secondary weapon (i.e., it'll fire at targets of opportunity, but the "bombs" control the Unit) if in combat, so that we can, OMG, maybe have Transports that are armed and act like armed aircraft.
B. When unloading, it will dive to a height "ParaDropheight" (we need to specify this, the current bomber code does a few things automatically which are counter-productive), then begin unloading Units at a time interval "ParaDropSpeed". Now that I've tested the code, I'm 100% convinced that game designers need to control this speed- the current code drops far too slowly for me (it also almost invariably drops two Units on the same place, too- but that's a bug), yet for some mods, slower dropping speeds may be more appropriate.
C. It will drop until it is unloaded. None of this "select the appropriate-sized circle and hope it's big enough" stuff. I see where that was going, ExitWound, and I appreciate the thought, but I just don't think it works correctly. That, and I don't think that users are likely to ever want to do the whole "drop some here, drop some there" behaviors in a real game. However, it could be a flag or whatever- what you wrote works, it just doesn't deliver what I was hoping it would.
The user selects a point, the transport attempts to pathfind to that point, then starts moving in a straight line, dropping units until it has finished. It won't be perfect, but it'll be better than what we've got.
D. It will load by going to the nearest-valid location near the center of the load radius, then it will automatically put all Units > TransportWeight / TransportSize / TransportCapacity into itself. The only calls to COB should be to BeginTransport() and EndTransport()- if users want to attach-piece at that point, for fancy visual representations, great, but it should default to being invisible storage. The way it works right now, where it expects the Transport to line up a Piece with the Unit it's going to carry, is completely inappropriate to anything but OTA clones, frankly.
3. If TransportType=="Helicopter", then:
A. It should use the Fighter code for flight and pathfinding. It should use HoverAttack=1 behavior, if available.
B. It should use Land Flood to unload, after landing. All Units should be unloaded during that frame.
C. Like ParaDrop, it should just call BeginTransport / EndTransport.
D. It should, like ParaDrop, load in one frame, whilst calling BeginTransport (that way, we can do stuff like FX, keep it from moving for a few seconds, etc., and provide a good illusion of realistic behavior...).
I don't even think it's worth trying to "fix" the current Air Transport code any more. It was designed for one game- OTA. It works for one game- OTA. It sucks for anything trying to act differently. ParaDrop and Helicopter would cover a far larger gamut of games, and would be visually less sucky. If I need to make videos showing the vibrations, the stupid pathfinding results, the "skating" behavior when the Unit has a Acceleration value over 0.5 or so, so be it... or you can just trust me, because it's all definately happening.
For now, instead of an exciting, cool air transport in PURE, that can swoop in, drop your army into the middle of an enemy's base, retro-rockets flaring as the Shells brake and then deploy... I have something that's not worth showing off. I'm not going to include this feature in PURE until it's addressed- second-rate is not acceptable, when the rest of the game is working so nicely...
