Jump to content
COMBATSIM Forum
mikew

TFXplorer and Windows 10

Recommended Posts

On 11/26/2019 at 5:51 PM, Krycztij said:

This probably broke when I made the tile size variable instead of constant because the place names had a very special rendering path (they need software screen projection). I’ll check it out as well.

If the architecture has changed, then I don't really see a need to fix this as I can go back to the Release build for exploration. The weapons stuff looks far more interesting to work on. :)

Share this post


Link to post
Share on other sites

Ha, certainly drifting to the left but can largely be compensated for by turning the right engine off. Can't go very fast though.

Need to find the heaviest stores now... :)

leftweps.png.54fb13099eb8b5a1e69c1a66882f4e58.png

 

When flying along at about 8100ft, the airspeed is indicated thus:

mach2.png.5d682c7270d86f44d2c279c38890e6f1.png

At that altitude, shouldn't Mach 2.01 correspond with something over 1200 Knots?

1124 is close to what would be expected for 'Equivalent Airspeed' although I'm not sure if that's displayed to the pilot.

Share this post


Link to post
Share on other sites

Good question! I just got lost in Wikipedia’s airspeed articles, so please check for me. The number is computed via TAW’s code. Have a look at TFX F22.hpp (1084) :

void updateSpeeds_5FFFDC() {
	globalVelocity_BUGGY = rotation(velocity, &planeToWorld_xAxis);
	globalVelocity_BUGGY = globalVelocity_BUGGY + changeInSpeed;
	newVelocity_BUGGY    = inverseRotation(globalVelocity_BUGGY, &planeToWorld_xAxis);

	squaredAirSpeed = squared(velocity.x) + squared(velocity.y) + squared(velocity.z);
	if(0.001 > squaredAirSpeed) {
		squaredAirSpeed = 0.001;
	}
	airSpeed = sqrt(squaredAirSpeed);
	indicatedAirspeed = sqrt(currAirDensity / airDensityAtSeaLevel) * velocity.x; // <<<<<<<<<<<< THIS GOES TO THE HUD
	groundSpeed = sqrt(squared(globalVelocity_BUGGY.x) + squared(globalVelocity_BUGGY.y));
	currDragFactor = currAirDensity * 0.5 * squaredAirSpeed; // first part of drag equation
	machNumber = airSpeed / currSpeedOfSound;
	trackAngle = wrappedToRange(0.0, atan2(globalVelocity_BUGGY.y, globalVelocity_BUGGY.x), twoPi);
}

Is indicatedAirspeed misnamed?

 

Please consider air temperature and humidity in the bottom-left corner. While TAW had a completely static air temperature and humidity, TFXplorer’s varies with time of day and altitude. This, in turn, has an influence on the Mach number.

 

If you hit SHIFT+S to jump two hours forward, you should actually see your airspeed and Mach number changing.

 

Check out UAW weather.cpp for computation of temperature and humidity. Oh boy, you can spend weeks tuning this. I remember spending two evenings trying to get information on relative humidity of the stratosphere, until I gave up, guessed, and returned to actual programming :D 

 

Of course these hard-coded numbers would, for a start, be provided on a per-terrain basis – so that EF2000’s Norway is colder than TAW’s Red Sea – and eventually be simulated in a grid, maybe from real weather data. But for now it’s enough to have the planes use an API for it.

 

Please also consider that temperature/humidity drives the contrail simulation, which is very, VERY CPU-demanding in itself. I.e. your contrails will be thicker in the morning, and I still didn’t manage to extend this level of detail to all 2000 planes currently in flight over the Red Sea.

Share this post


Link to post
Share on other sites
On 11/28/2019 at 10:21 PM, Krycztij said:

Is indicatedAirspeed misnamed?

Sort of. The equation used is indeed that for 'Equivalent Airspeed', but it's probably a way to simulate the 'Indicated Airspeed' that you might get from a pitot tube system.

The TAW manual also shows this value as 'Indicated Airspeed', so we're all good.

 

I've been going through TFX F22.hpp, and it brought back some memories that I thought I'd got rid of...

What I've forgotten is how the cross section is defined for drag purposes. Is it those tables?

I assume that the pulling to the left in my example above is caused by weight distribution and not drag from each missile and the pylons.

Share this post


Link to post
Share on other sites
On 11/29/2019 at 11:44 PM, mikew said:

The equation used is indeed that for 'Equivalent Airspeed', but it's probably a way to simulate the 'Indicated Airspeed' that you might get from a pitot tube system.

The TAW manual also shows this value as 'Indicated Airspeed', so we're all good.

I’ll rather rename it to equivalentAirspeed in the physics source, keep the name indicatedAirspeed in the HUD source, and comment the assignment indicatedAirspeed = equivalentAirspeed as willful.

 

On 11/29/2019 at 11:44 PM, mikew said:

What I've forgotten is how the cross section is defined for drag purposes. Is it those tables?

I think so; I never bothered to analyze.

 

On 11/29/2019 at 11:44 PM, mikew said:

I assume that the pulling to the left in my example above is caused by weight distribution and not drag from each missile and the pylons.

Exactly. No drag computation so far, because I’d have to consider lift as well, and it gets arbitrarily complex from there. And we haven’t even gotton to radar cross section yet …

Share this post


Link to post
Share on other sites
1 hour ago, Krycztij said:

No drag computation so far, because I’d have to consider lift as well, and it gets arbitrarily complex from there

Indeed. Even if we had all the dimensions of the F22, it would be difficult to reproduce its handling characteristics as we'll never know exactly what the flight control computer does.

 

I'm intrigued by your KC-135 code. Can I fly it in some way?

Share this post


Link to post
Share on other sites
11 minutes ago, mikew said:

I'm intrigued by your KC-135 code. Can I fly it in some way?

It’s just the old F-22 code from TFXplorer before we reversed TAW’s code, and all handling characteristics slowed down.

Go to TFXplorer.cpp (2671) and change asInt("F22 ") to asInt("K135"). You will realize the F-22 uses to crash on spawn because it spawns in the KC-135’s place.

It’s a pain to even get it to take off and on stall it will enter an infinite loop and crash (not the program, the plane actually doing loopings until it crashes into the ground), so enjoy with caution ;)

Share this post


Link to post
Share on other sites

Cool! I can't get it to take off because I can't start the engines.

If I F5 from altitude. I can fly around but I don't think there's any thrust. I know the K-135 has 4 engines, but should the HUD show some active engine status?

Share this post


Link to post
Share on other sites

Yeah, HUD is broken. After spawning, hit the same buttons to start the engines like on the F-22. I don’t know if joystick throttle works, but hit numpad max-afterburner for maximum throttle. Worked for me :-)

I think thrust is just way too low for this one. Maybe you can find the constants in the code to give it more kick …

 

You can see thrust indirectly via contrails at great altitude. Contrails are generated from fuel burnt, so if you see any, the engines must be running.

 

 

Share this post


Link to post
Share on other sites

Ah, see what you mean...

The maximum power may not be too far off, but it seems the power drops to zero if I back off the throttle just a bit.

I've got a joystick connected now, and turning the sound up helps as the 'spooling up' noises are present.

 

 

Share this post


Link to post
Share on other sites

Not sure what to suggest...

If I reduce the fuel weight from 200000lbs to 20000lbs, the performance is a lot more sprightly and I can just about catch the other planes.

The performance then is a bit too good in that I can also fly upside down.

You have the correct (well, wikipedia) thrust levels, so maybe reducing the drag would help. Hard to say.

 

Since this is already packaged into a DLL, I'm wondering whether it would be worth trying to create some test program to run various scenarios and plot the results in some way.

Probably easier said than done though. :unsure:

Share this post


Link to post
Share on other sites

It’s a lot of guesswork, hardly any "real" physics. Drag may be the actual problem (it sure is to the spinning). Drag is defined for three axes and I just tweaked until it was to some degreee useful …

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...