Aircraft demands and how to execute the requests

[Pxtl]

Give a ba bomber a cruise alt of 500 or 1000 and watch the gheyness ensue.

That's because the turn radius is AFAIK computed from the ground (unless that got fixed) so a cruise alt greater than the turn radius means the plane is always "too far away". Increase the turn radius.

Maybe I'm silly here, but how does turn-radius get effected by altitude? How does that even make sense?

[lurker]

Distance from the target.

[Argh]

Here's my wishlist:

1. Allow planes to immediately begin accelerating in a forward direction when taking off. I discussed how to make such a thing work, using terrain-height detection along the vector of the current flightpath. It's dumb that everything is VTOL when there are clearly better ways.

2. Implement the smarter terrain-detection system I outlined well over a year ago, where it's checking ahead of the aircraft on its current vector to decide what altitude it should attempt to reach before the next slowUpdate (or even longer- if it hasn't triggered a new maneuvering state since last slowUpdate, note that, and keep the altitude check, if enough points were checked far enough ahead).

It'll cut the performance requirements down a lot, on long flightpaths, and make aircraft a lot more natural-looking as well.

3. Implement smarter landing procedures. Planes should plan a diagonal landing at a given valid site. This can be done with a periodic raytest- if the ray doesn't intersect terrain, then immediately start changing the plane's vector to eventually intercept the point on the ground, and have the plane decelerate at the same time its altitude drops. This is all very artificial, and ideally there should be some limits (i.e., predict if the plane can actually meet the vector requirements given its turn rate, and if no, then circle around to find another landing pass), but it would look better than what the engine does now, and would be a start towards something better.

4. If a site is reserved by a plane that's landing, ground Units on your allyTeam should be given the equivalent of a BuggerOff command.

5. Rewrite the main flight code, where everything is tied together and cannot be separated gracefully. The easiest way to do this is to have a few new variables, all doing what MaxAcc is currently doing (to keep plane maneuver code intact, since that's "fun" to mess with), but one for each type of maneuver. So, when looping, use X... when doing a barrel-roll, use Y, when diving, use Z.

This is probably the single-easiest way to to clean this area up, short of a complete rewrite, which nobody's managed to do, despite several tries by various folks. Get more control over each distinct behavior. That would make writing new behaviors a lot easier, too.

6. When an AirMoveType Unit is created, it should be given a random height, within a range specified by the game designer.

[Gota]

air transports with multiple (visible) load points that can pick up units and deploy them all at the same time. Although this has probably more to do with transport behaviour than air behaviour

This should be implemented modside since most mods do not have appropriate scale for such a system to be necessarily...
Supcom's scale is much bigger hence there is a bigger need for a transport system to move units form place to place faster...

[Otherside]

air transports with multiple (visible) load points that can pick up units and deploy them all at the same time. Although this has probably more to do with transport behaviour than air behaviour

This should be implemented modside since most mods do not have appropriate scale for such a system to be necessarily...
Supcom's scale is much bigger hence there is a bigger need for a transport system to move units form place to place faster...

Spring is an engine not a game and not OTA

Im sure alot of mods/games would find this option useful and it would not need to be for supreme com scale

[Gota]

I think the fact we don't have such a transport system modside is proof that no mod needs it enough.
It's done with lua in supcom as well if I'm not mistaken.

[AF]

May I make clear that the scope of which this thread pertain is aircraft movement.

Transportation behaviour is a layer ontop of movement. Your request however for multiple load points merits that I point a great big fat finger in zwzsg's direction if not at starwars and p.u.r.e altogether, both of which implement exactly what you wanted.

The air movement code governs movement behaviour of aircraft, and only movement.

Since we have plenty of requests, how do you guys believe the system should be assembled?

Someone put forth that we created modular behaviors that we piece together or combine, what sort of basic building blocks are we talking of here and how are they intended to be combined?

[Gota]

Truly a hard question.
I just want to add that the necessity for these building blocks originated in the clumsy default behavior.
I think the basic problem arises when units are forced to move to places and at times when the player does not which them to.
This is why land movement is relatively fine because these elements are not so prevalent.
So what can be done to allow aircraft to be different than land by moving on it's own unlike land units yet allow for the same amount of control by the player?

IMO the best way is to separate it into 2 categories.
1 is how they behave when no orders are given by the player and 2 is how they behave when orders ARE given by the player.

In 1 they behave unlike land units doing all kinds of acrobatic feats.
In 2 they act very conservatively and do as they are told without side stepping from the orders,acting a lot like land units.

If i have a group of fighters sitting around and they spot another fighter they will rise up and start doing stuff trying to attack it on their own,acting less conservative about their movements.
On the other hand if i spot a fighter and take my group of fighters and command them they will act much more conservatively and have much more strict movements.

And a modder should be able to decide if he wants to have the same type of movement for 1 and for 2 or not.
What you think?

[Neddie]

I think that isn't a mechanistic explanation of how this would work, though suggesting two layers of behaviour would affect the system.

[Gota]

Well i can see 2 clear cases as an example.
Me giving them a move order and them themselves engaging a target while in patrol..
Me giving a move attack order to some place and them engaging in targets they meet along the way...

[Pxtl]

I'm still not sure why "behaves like land units" is desirable, except for blocking. I mean, if you had a unit that
1) Always faced the direction of travel, like a fighter, but
2) Could stop and float in mid-air and
3) Could use a turret as its primary weapon and
4) Would not automatically circle the target like a gunship

Then it would functionally be a flying tank, except that it would use aircraft-style obstacle avoidance (that is, 3D collision based instead of 2D grid-based), right?

Plus those little aircraft bennies that need a little TLC like land-at and fuel.

Meanwhile, rules 1-4 are all things that would be desirable in a single fully-generic aircraft class. So I'd rather see a single fully-generic aircraft class that focused on gameplay effects instead of avionics and would be appropriate for both gunships, fighters, and transports.

Then again, my modding work is half-abandoned crap, so I'm not necessarily one of the biggest stakeholders here.

[Pressure Line]

mostly possible Pxtl. theres a tag that kills gunship airstrafing, meaning they sit in the air and shoot at their target. (i think the tag is "airStrafe". anyway, you set it to 0 and the gunship will now float stationary in the air and shoot, instead of it scooting sideways like a brawler)

[Pressure Line]

Solution to Gota's problem, will probably need some tweaks.

Fake weapon!

Code: Select all

[LOCKBREAKER]
{
	name=Lock Breaker;
	rendertype=0;
	lineofsight=1;
	turret=1;
	range=360;
	minintensity=1;
	reloadtime=1;
	energypershot=0;
	weaponvelocity=2500;
	areaofeffect=14;
	firestarter=90;
	beamlaser=1;
	thickness=3;
	corethickness=0.2;
	laserflaresize=10;
	targetmoveerror=0.2;
	beamtime=0.15;
	rgbcolor=0 0 1;
	tolerance=10000;
	impulsefactor=0.123;
	impulseboost=0.123;
	cratermult=0;
	craterboost=0;
	noselfdamage=1;
	projectiles=0;
	toairweapon=1;
	[DAMAGE]
	{
		default=1;
	}
}

In the unit .fbi/.lua!

Code: Select all

	weapon2=LOCKBREAKER;
	OnlyTargetCategory2=VTOL;
	weaponmaindir2=0 0 -1;
	maxangledif2=180;
	weaponslaveto2=1;

Code: Select all

	Drag=0.00;
	maxBank=0.4;
	maxPitch=0.225;0.45
	maxRudder=0.016;

In the script!

At the start or in an include...

Code: Select all

#define CHANGE_TARGET	98

With the rest of the weapon code...

Code: Select all

QueryWeapon2(piecenum)
{
	piecenum = rearthrust; //or some other suitable location, it doesnt really matter.
}

AimWeapon2(heading, pitch)
{
	sleep 30;
	return( TRUE );
}

FireWeapon2()
{
	set CHANGE_TARGET to 1;
}

This stuff should break the target lock of a fighter if its intended target is too close behind it, forcing it to choose another target. It also has changes to .fbi/.lua values to make the figters handle more like ota gunships. Tested, seems to work quite well, but ymmv.

NOW SHUT UP BECAUSE I DONT WANT TO HEAR ANY MORE ABOUT IT!

[AF]

How about a profile defining flight behaviour. The profile can then be attached to an order, or multiple profiles attached to an order allowing random selection. A default profile would act as a template for those orders with undefined sets of flight behaviours. A set of transition behaviours too.

I wrote the patch that added the tag that stopped brawlers strafing in circles around the target. Indeed sometimes it is desirable to have units flying that behave like ground units in the air. Just ask anyone who made a space mod, or smoth and his giant gundam commanders

[yuritch]

1. Allow planes to immediately begin accelerating in a forward direction when taking off. I discussed how to make such a thing work, using terrain-height detection along the vector of the current flightpath. It's dumb that everything is VTOL when there are clearly better ways.

I even did such a patch once, and it mostly worked, but I lost interest to that (since we don't need takeoffs/landings in S44 now with all the air being called in from offmap). The patch file is still on the forum, attached to that post.
The idea was to change plane state to AIRCRAFT_FLYING immediately after take-off. There was a catch - the plane needs to be at at least its hitsphere radius height from the ground, else ground collision will not allow it to fly and it will 'skate' on the ground until reaching some kind of slope to jump-start from. And of course that did nothing related to landing, so it still landed in a VTOL fashion.

[KDR_11k]

Oh, right: Gunships, when told not to strafe, try to stay in one position, if they overshoot it they'll fly back to it (and overshoot it again). They should just stop wherever they end up and shoot from there while holding still.

[Forboding Angel]

Give a ba bomber a cruise alt of 500 or 1000 and watch the gheyness ensue.

That's because the turn radius is AFAIK computed from the ground (unless that got fixed) so a cruise alt greater than the turn radius means the plane is always "too far away". Increase the turn radius.

You do realize that turnradius is also affected by maxaccel don't you?

Maxaccel should NOT be needed, it shouldn't even exist! But Instead if we want even remotely non-retard behavior we HAVE to use maxaccel0.3, and then maxaccel causes a new form of retardation.

Make aircraft follow maxvelocity, turnradius, turnrate and hitbox sizes like everything else!!!

Aircraft have their own little set of rules that makes 0 sense. Just make them follow the above tags correctly without the 0.000001 modifier that they have now.

[Gota]

By the way.
Anyone knows how to remove the Fly/land button?

[CarRepairer]

By the way.
Anyone knows how to remove the Fly/land button?

Yes.

[Gota]

Why are you not logged into the lobby?