Aircraft and the current flight code.

[Argh]

Ok, I've taken a long look at the flight code again.

1. Aircraft do not actually use the value of Acceleration or Brakerate. they use hardcoded values, which cannot be changed without resulting in huge problems with the aircraft (i.e., it never lands, steers horribly, etc.).

2. Aircraft do not actually use the value of Turnrate. This was a bit of a surprise, tbh, I would have thought people would have noticed that every aircraft in the game has exactly the same real rate of turn, and the only thing that changes is their relative velocity...

3. Aircraft constantly steer when it's not necessary, over-correct or under-correct. This is because the code for handling steering is very crude, and does not take terrain changes into account in a useful way.

4. Aircraft have a hardcoded crash sequence, with a hardcoded effect buried in the code.

To correct these problems is going to take a bit. Here's what I've done, thus far:

1. Crash sequence and hardcoded effect are now gone.
2. I'm now attempting to clean up the flightcode, taking out a lot of the logic, and tying it back into standard values (brakerate, maxvelocity, turnrate, acceleration).

I would appreciate some assistance with this task, if anybody has free brain cells and is interested in this problem. Some of this involves bits of Spring I don't understand very well, and some of it involves matrix math I don't understand very well. That said, the basic logic is not terribly complex, it's mainly a matter of making the code respond to values that are already present in the game designs.

Thus far, I'm looking at the behaviors of aircraft like this:

1. All aircraft need a standard way to accelerate, decelerate, turn, gain and lose height. They all must analyze the terrain and perform basic avoidance of other aircraft.

2. It would be a better simulation if aircraft rose based on their angle of attack, instead of going straight up and down like helicopters.

After reading the code, it looks like it'd be very easy to change that behavior, if it wasn't for all of the other stuff that's screwed up by hardcoded logic right now.

3. It would be nice if this code continues the pattern of sending a signal to COB, so that we know when they're moving, so I will leave the COBfunc call in. It's interesting that it used to be an Activate() call, then became StartMoving() at some point in the past. I will not be changing that.

4. It would be nice if it used the SlowUpdate to perform the potential-collision stuff and changed the height of the aircraft.

5. It would be nice if it allowed users to define what pattern of movement occurs in combat. Right now, it's all hardcoded stuff, very inflexible, totally random.

First things first... here's the basic logic that should be used:

STATES

Aircraft should have the following states:

1. Takeoff
2. Landing
3. Moving
4. Dodging
5. Attacking
6. Landed

Note that these are somewhat different than at current.

NEW / CHANGED VARIABLES

Aircraft should use the following variables in their Unit and weapon TDFs to determine behaviors:

1. PreFlightHeight (float, default == wantedHeight + GroundHeight): this is the height that aircraft should rise, vertically, before starting normal flight. Default to preserve old flight behaviors (i.e., VTOL), setting this value to 0 would result in aircraft that begin flight immediately (and would begin Dodge behavior on their first SlowUpdate, heading towards wantedHeight).

2. turnRateX,Y,Z (float, default == turnRate): the maximum turnrate of the aircraft on the three axis. Needs to change to reflect 3D nature of flight, in OTA they didn't bother, as aircraft didn't collide.

3. MaxWeaponRange (float, default == 0): the maximum range of any weapons on the Aircraft, whose OnlyTargetCategory != "NIL".

4. RandomAlt (float, default == 0): this is a random number, from 0 to RandomAlt, added to the wantedHeight of a particular aircraft, to reduce collisions a bit, and to look more realistic.

5. VerticalOffsetSpeed (float, default = 0): this is an offset distance that aircraft can move in the Y axis, per frame. Useful for helicopters, where we don't want them to turn on the Z axis very much to change their altitude, but we need a way for them to move up and down.

6. VerticalOffsetAcc (float, default = 0): the acceleration rate, per frame, of VerticalOffsetSpeed.

MAIN LOOP, pseudocode:

For each SlowUpdate {

check state
check for enemy units within MaxWeaponRange

if (current height <= PreFlightHeight) then { state = Takeoff, call Takeoff(), exit loop }

else {

if (Dodging logic fails) then {state = Dodging, call Dodging(), exit loop}

else {

if (enemy unit positions < MaxWeaponRange) then { state = Attacking, call Attacking(), exit loop }

else {

if (at reserved landing site, not at right height yet) then { state = Landing, call Landing(), exit loop }

else {

if (at reserved landing site, and current positions <= Preflightheight) then { state = Landed, call Landed(), exit loop}

else {

state = Moving, call Moving(), exit loop.

}}}}}

I'm not sure that leaving Fuel and Damage in their current format, if this is really going to get re-written, is such a hot idea. It added a lot of bloat to the current code, and adds a lot of weird problems. Personally, I think it would be better to do that via LUA, by changing the movement orders and shutting down the weapons.

If we need to come up with a LUA solution that can be present in Spring to automatically handle reverse-compatibility, so that old mods work correctly without having to be changed, that's certainly possible, but I think it'd be better to cut that extra fat out of the main loop here, it's a lot of extra hassle for something that isn't universally required. Moreover, such a solution would lend itself to a broader ammunition and automated repair system.

That's pretty much where I'm at. Anybody wanting to see the current source, verify my statements, or understand why I wrote a wall of text about this stuff and the issues of rewriting such a big piece of game logic, can view the current source here.

[Forboding Angel]

Actually, aircraft do follow acceleration and brakerate, just not very well. Also, those 2 values are mixed with a hardcoded value as well which causes spring to come up with a magic number.

Also, set accel for a gunship to 5 and maxspeed 20.
Now try it for a fighter, notice something?

aircraft are fucked.

[yuritch]

I see you dropped the CRASHING state completely. Do you think it's better done via LUA? It may be a bit too complex to simulate the death spiral...
Also, you check for enemies using MaxWeaponRange, but what if longest-ranged weapon cannot target them (OnlyTargetCategory doesn't allow it), but shorter-range weapons can? For ex. a fighter that has long-range air-to-air only missiles, but can still attack land units using an autocannon (which has a much shorter range).
All in all, that rewrite seems like a good thing. As I understand it, it will allow for proper take-off behaviours on planes (non-VTOL) without any extra LUA tricks (like those used in S'44 for the airfield and fighters). But your post seems to suggest planes will still land vertically, maybe that needs changing too?

[KDR_11k]

Gunships are TAAirMoveType, fighters are AirMoveType. Fighters just use a different set of tags for their turnrate, acceleration and braking.

Also range checks should be done vs Weapon1 like it is for ground units. Leave it up to the modder to decide which weapon has priority.

[Peet]

Don't remove crashing entirely, make it toggleable (defaulting to on, to keep the current behaviour).

[ILMTitan]

Deciding whether/which units to attack, and therefore when the aircraft goes into an attacking state is the job of the CommandAI, not the move type.

Edit: The attacking function should run while in full flight and owner->userTarget.

[Guessmyname]

Don't remove crashing entirely, make it toggleable (defaulting to on, to keep the current behaviour).

Yeah, I like the crashing thing. Though I do suppose un-hardcoding the SFX it emits while crashing.

[[Krogoth86]]

Well I haven't tried it lately but can those "dying" aircrafts still shoot? That's something I really hated on that prescripted behaviour...

[yuritch]

Yes, they can shoot while crashing. And there is a way to prevent it on the unit script side - use get CRASHING to find out if the plane is in this state, and jam weapons if so.
Of course, all the plane scripts will have to be modified and recompiled for this to work.

[Guessmyname]

Yes, they can shoot while crashing. And there is a way to prevent it on the unit script side - use get CRASHING to find out if the plane is in this state, and jam weapons if so.
Of course, all the plane scripts will have to be modified and recompiled for this to work.

I actually quite like the shooting-while-dying thing. It makes it seem like the pilot / crew are still aboard and going down with their craft.

[KDR_11k]

It's horrible for balancing though.

[det]

I hate random crashing planes. I wouldn't mind a "crash while EMP'd" option though.

[Warlord Zsinj]

I'd really like someone to sit down and have a look at this. It's very badly borked, and it makes aircraft balancing an absolute nightmare.

[smartie]

Airplanes seem to work fine in most mods. And why get rid of stuff like crashing and the fuel system? It works fine as it is.

[KDR_11k]

Airplanes seem to work fine in most mods. And why get rid of stuff like crashing and the fuel system? It works fine as it is.

They work in existing mods because when they don't they don't get included. Crashing lets the unit live longer and the fuel system is pretty limited for handling ammo.

[Argh]

They work in existing mods because when they don't they don't get included.

QFT. Players have no idea how many things, representing many man-hours of time, have gotten scrapped because of this stuff.

[smartie]

What bothers me is you're talking about scrapping an entire working system and redoing it from start. It's just seems like it's going to create a lot of headaches. Look at how other mods do things before you scrap the whole system. Theres also a whole lot of varibles you can set for airplanes using FBI tags. Stuff like the amount of rudder, it uses, the amount it banks on turns, it's all listed under control varibles for aircraft.

There's no reason to get rid of features like crashing. If you really don't want to you can write a patch that lets you turn it off with a FBI tag. Or you can do what BA does and remove crashing damage and have weapons ignore the crashing units. The same thing with the fuel system. It works, so why get rid of it? If you want to add in a system where ammo and fuel are seperate then why not do so? You don't need to take out fuel to do it. If you have a way to get the whole fuel system working with lua then put that up here so we can use it. If it's better no one will need to use the hardcoded behaviour and it can be gotten rid of.

[smartie]

What if you added in a tag like "useNewFlightCode" so this could be put in the next version while still keeping the old flight code along with it.

[ILMTitan]

While I agree that keeping current functionality (crashing etc.) on by default is a good thing, anyone who doesn't think the the air move type code needs a major rewrite is either foolish or hasn't seen the code. It uses a goto for peet's sake.

[Peet]

I assure you that adding a goto in no way aided me.