Currently aircraft fly at a single standard altitude, changing only to land, to fire or to compensate for slopes. This is all well and good, but I think the system might be improved by allowing game developers to define a range of cruise altitude (MaxAlt, MinAlt) and a rate of change to either extreme (AltitudeChangeRate). CruiseAlt would continue to function as a midpoint for cruising altitude, the aircraft would reach CruiseAlt, then oscillate up and down to either extreme at the AltitudeChangeRate. Use of these new tags would be optional; CruiseAlt in lieu of the other tags would function the same way it has for years. If somebody defined a MaxAlt and MinAlt without defining a CruiseAlt, the engine would just average the two to generate the CruiseAlt.

Projects that would probably benefit include 1944, NOTA, Gundam RTS and Evolution RTS.

Personally, I think aircraft should figure out max/min cruiseAlts at game start, and then they won't have to oscillate at all, because they'd always be gauranteed to fly > min cruiseAlt. Their weapon behaviors could be changed a bit to compensate. It would fix a lot of problems, especially with maps featuring a lot of height differentials, and they wouldn't need to hug terrain, which would save a lot of CPU.

That isn't precisely the behavior I wanted to model. Aircraft don't fly at 900m above the surface continuously in engagement range... it looks and is a little lazy to have them at a single cruise altitude all the time, hence suggesting they move along a defined range. Having them moving up and down would also help with the clumping they tend to suffer from.

As a specific example, assume you have a Core Booster from Gundam RTS. At present it moves up to cruise altitude and stays there - the movement is awkward, it appears to be flowing along an invisible plane. With my proposed changes, assuming smoth implemented Min and MaxAlt, the Core Booster would float up and down during travel, giving the impression of navigating around air currents, adjusting to maintain line of sight, tracking targets in the distance, etc.

i support this idea, though i have to say, how would you balance a dog figth, make the figther move up to max altitude and swing back down? if it is being targeted???? what about a bit to the side, like lateral distance ??

Now talking about space battles, it would be nice if ships could go to a higher plane and stay there. Hmm if you could define the altitude by a button, or a rigth click and drag, would be like homeworld.

still looks very interesting, i migth even get back to my old FF remake ;P
anyways ill watch this thread for updates

Actually, yeah, they do, unless they're really near the ground, or having to fly over something really high. The only time they're going to change altitude a lot is during combat. And if that was the only time that the aircraft were using lots of CPU, I'd be happy.

I specified engagement range to avoid this confusion. Games occur at a combat scale, there is neither time nor reason for aircraft in a particular Spring match to move to and maintain cruising altitudes. Possible exceptions may be made for transports or aircraft which come in from off map - like our gliders.

Yup, this is a good idea, and would add a pretty spiffy feature while maintaining compatibility. Somebody just has to implement it.

A few questions, though:
If you ask a unit with a really low altitudechangerate to climb up a steep cliff, will it take forever just to rise high enough to do the climb?
Will there be some form of estimation that'll allow aircraft to change their altitude in advance so that they don't get held up at cliffs and the such?
Will this cause conflicts with maps with altitudes above a craft's maxaltitude or valleys below the minaltitude?
If so, how could these conflicts be mitigated?

I discussed a method for smoothing out aircraft responses to sharp cliffs some time ago.

What was implemented instead by imbaczek is actually pretty good- the smoothheightmesh helped a lot with the behaviors. That said, it's still basically doing the same things it always has- checking every game frame to see if it's at cruisealt vs. groundheight, and adjusting.

And Neddie, I'm not wanting to split hairs on this. Basically, what you're calling "engagement range" could be defined as "when the aircraft's weapons are 1.5x from max range from a valid target" or thereabouts, and aircraft could use simpler behaviors while just cruising. Right now, aircraft are terrifically expensive when you have a swarm on Patrol, even if they aren't in combat, and that's something I'd like to see fixed.

Agreed it's a good idea, my problem is I have trouble envisioning it. Maybe because in evo I've just worked around it but honestly, something shouldn't require a workaround to behave normally.

Good idea and it would be nice to have, in general, more control over aircraft movement and attack.
There is still some strange behavior when moving aircraft, for example if you tell a BA bomber to turn back to a point right behind it, it will keep flying for a while without turning but if you tell it to turn back to a point far behind it it will start turning right away...

It Would be nice to separate attacking behavior from movement behavior when it comes to aircraft.

If you don't want to split hairs, don't. What I'm calling "engagement range" encompasses all activity on a Spring battle field because a match represents battle within a small region where there is no remote assurance of safety anywhere, nor is there ubiquitous radar/land presence. That is what I meant by combat scale; aircraft generally do not fly at cruising altitudes without the expectation of safety at those altitudes - they move around clouds, they minimize radar visibility by lowering altitude, etcetera. You cited a realistic precedent for the current lazy, ugly behaviour and I preempted, then responded again to it.

I agree that expense is a problem, and I'm reasonably certain that this can be added with minimal additional expense at the same time that some of the already present behaviours and patterns could be tightened up and optimized.

My motivation for making this suggestion is three-fold;
1. Appearance/Immersion - we have a fairly complex aircraft system, but it still looks like basic movement across a single plane ninety percent of the time. It is ugly and awkward.
2. Dispersion - planes clump and cluster. If they're always at the same altitude, this just gets silly.
3. Gameplay/Balance - more variables, more emergent complexity, but in this case the player isn't forced to change anything.
4. Backwards Compatibility - can be implemented in a way which doesn't break unmaintained or simplified game content.

Honestly, I keep wondering how hard it would be to completely gut and replace the aircraft code. It's completely over-spec for what it does (flight-sim physics model for an RTS???), and results in massive processor drain and bizarre bugs.

That said, realistically, I'm never gonna do it, so whatever.

And that's what everybody, including me, has said, when we look at the damn thing, lol. It's pretty scary code.


I'm pretty tempted to see what can be done about these issues using MoveCtrl at some point, frankly, as it'd be a snap to simply force aircraft to stay > some fiat distance from the ground, and fairly simple to just turn them every gameframe a little bit for wide turns and various altitudes during patrol / movement, and then release them from MoveCtrl when they are in combat. Maybe after I'm done with other game mechanics stuff.

Even for what it offers it seems to be a little overkill. I think we can have more features and a lesser load, but I of course can't really toy with it, hence making this request.