Air Transports. A Rant.

Air Transports. A Rant.

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderator: Moderators

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Air Transports. A Rant.

Post by Argh »

:?

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...
User avatar
Snipawolf
Posts: 4357
Joined: 12 Dec 2005, 01:49

Post by Snipawolf »

Sounds like +1 if you ask me.

I am going to have air transports, and this needs to be fixed. Adding parachutes could be annoying, I am remaking all of my infantry soon, so I can hope that we have a thumbs up on it soon. If not, I will have to remodel/remap/redo origins and a ton of stuff, which isn't much fun.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14637
Joined: 17 Nov 2005, 02:43

Re: Air Transports. A Rant.

Post by Forboding Angel »

Argh wrote:Made a lot of sense
I am experiencing this as well. My transport in Evolution is 8x8 also, and the jittery thing looks terrible, plus the way they work is so damn annoying :(
User avatar
smoth
Posts: 22306
Joined: 13 Jan 2005, 00:46

Post by smoth »

I have a 12 by 12.

:P
User avatar
Snipawolf
Posts: 4357
Joined: 12 Dec 2005, 01:49

Post by Snipawolf »

Mine will probably be even larger, heh. If I made it to scale of the universe I have stolen it from, it would be even larger than 20x20 :P
User avatar
smoth
Posts: 22306
Joined: 13 Jan 2005, 00:46

Post by smoth »

I could always give the whitebase/gaw their transport abilities and shut you all up :).
Warlord Zsinj
Imperial Winter Developer
Posts: 3742
Joined: 24 Aug 2004, 08:59

Post by Warlord Zsinj »

Arr, I'll join the chorus of 'transports make me sad'.

Really, it's a serious weakpoint both visually and functionally. Supreme Commander showed that very strong and functional transport mechanics are a big selling point for players.
User avatar
Forboding Angel
Evolution RTS Developer
Posts: 14637
Joined: 17 Nov 2005, 02:43

Post by Forboding Angel »

hueg 32x32 transport would be hueg :P
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

LOL. Let's not have a transport e-peen thing. After testing it, I don't think it has anything to do with size, either.
User avatar
Fanger
Expand & Exterminate Developer
Posts: 1509
Joined: 22 Nov 2005, 22:58

Post by Fanger »

Hey guys I heard the bomber code was borked...

image related:

Image
User avatar
smoth
Posts: 22306
Joined: 13 Jan 2005, 00:46

Post by smoth »

Forboding Angel wrote:hueg 32x32 transport would be hueg :P
they are 40X40.


argh, what if there was an invisible arm bound to a particle system to make it look like the units are poofed into the transport?
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Can't do it that way, unless something's been fixed- last time I tested, attach-piece to piece 0 (i.e., invisible attachment) caused Spring to crash, with Air Transports. Moreover, they don't make calls to COB to activate the move / turn stuff that ground transports do- you've gotta go look at the code for Air Transports, it's incredibly specialized.

Anyhow, that's not the meat of the issue anyhow. The main thing is that Air Transports use a CMoveType that doesn't resemble an aircraft, don't do proper loading behaviors, and are generally screwy. It'd be better to start with a different MoveType, and leave the current code in the Dark Ages, where it belongs, imo. I will take a look at the code issues tonight, see whether I can move this forward, past the bitching stage and into the practical reality stage- I really want to see proper airdrops and helicopter-type behaviors in PURE, it's well-worth patching the engine if nobody else wants this badly enough. I just dunno whether I'll be able to straighten out the somewhat-spaghetti-like nature of the MoveType code enough to understand where I need to do stuff- except for the search / filtering to do insta-load, everything else is already available, somewhere in Spring...
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6193
Joined: 29 Apr 2005, 01:14

Post by FLOZi »

Can't do it that way, unless something's been fixed- last time I tested, attach-piece to piece 0 (i.e., invisible attachment) caused Spring to crash, with Air Transports.
Well, that sucks, but you could use SetSFXOccupy() and get TRANSPORT_ID to make units hide all their pieces when loaded by the air trans.

Anyway, yeah, that's the least of the problems (though it should be fixed).
User avatar
Pxtl
Posts: 6112
Joined: 23 Oct 2004, 01:43

Post by Pxtl »

I think we need better default-behaviour for units that are trapped in regions that they can't move. They need to die, or roll downhill, or something, so that we can juts say "screw it, unload the suckers".

Otherwise, it's annoying when you get units that are blasted out into the water (where they can't exist) and suchlike. We're never going to avoid all these possibilities, so it's better to just be able to handle them.

This is related to Argh's desire for better unloading, since mass airdrop approaches are also going to produce more "stuck" units.
User avatar
Guessmyname
Posts: 3301
Joined: 28 Apr 2005, 21:07

Post by Guessmyname »

We've already got part of sliding thing for units on slopes too big for them to pass.
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

You could just make them kill themselves via checking whether they're underwater. Angular stuff should be able to be handled by adding a SlideTolerance, as of 0.76b, although it would not be a perfect solution, and I admit I haven't tested it yet...
User avatar
Neddie
Community Lead
Posts: 9406
Joined: 10 Apr 2006, 05:05

Post by Neddie »

Woah, Fang, easy there! Don't we have... another thread for bomber code?
User avatar
EXit_W0und
Posts: 164
Joined: 22 Dec 2005, 01:33

Post by EXit_W0und »

Looks like I'll be going back to the drawing board :/

Things didn't quite turn out as I'd hoped & you're right the majority of the issues stem from the transports movement code. Tbh I was originally wary about modifying the normal aircraft flight code to be able to accomade transportation
but after trying to twist the transport ai backwards to work the with the transport flight code I realize I should've just done that in the first place.

The drop rate of troops is impeded a bit in terms of accuracy and speed because its dealt with inside the slow update - so i'm going to rethink that.
That should also resolve the issue of units getting clumped together when being dropped.

But before I go and get stuck in again, I want to discuss it a tad more so that this time its done right.

For the area unload using the paratroop drop, do you recon it would be better for the transport to make several passes over that area till its empty? Or have it ignore the size of the area and just unload everything in the same straight line (from the point the command was given to the centre of the circle)?

Regarding invisible attachment, it would be easy to move units to/from anywhere inside a certain radius (dictated by a tag) directly into the transport so we'd effectively have teleportation.

I have been working on a flood style load - but this occasionally suffers from units getting stuck en route to the transport on each other. To combat this the transport gives up on loading these after x amount of time. This is probably acceptable for infantry style units which can maneuver out of each others way for the most part and so don't get stuck too often, but i can see this becoming a problem for more cumbersome units.

I also considered having set entry/exit points, to work with doors on the sides of the transport. But this might exacerbate the units getting caught on each other.

Lastly, I think the original transport style could maybe still be cleaned up to remove the worst of its problems - but i'm going to prioritize using the normal aircraft code first.

If anyone has useful insight on the tricky bits of the flight code, now would be a good time to share them :)
Last edited by EXit_W0und on 20 Nov 2007, 23:23, edited 1 time in total.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6193
Joined: 29 Apr 2005, 01:14

Post by FLOZi »

EXit_W0und wrote: For the area unload using the paratroop drop, do you recon it would be better for the transport to make several passes over that area till its empty? Or have it ignore the size of the area and just unload everything in the same straight line (from the point the command was given to the centre of the circle)?
Tag please!
I have been working on a flood style load - but this occasionally suffers from units getting stuck en route to the transport on each other. To combat this the transport gives up on loading these after x amount of time.
Tag for x please!
User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

And a tag for the size- it needs to be a fixed arc, for most games, and game designers should figure out ways to depict it (circle a point around, emit-sfx, use LUA, or whatever).
Post Reply

Return to “Engine”

cron