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

tl;dr I haven't done anything... :(

 

On 12/1/2019 at 3:10 PM, Krycztij said:

Maybe you can find the constants in the code to give it more kick …

OK! I'll just try and change some parameters in the existing code. Some things feel better, but others worse.

Need a more logical approach, so look at Flightgear's JSBsim to see if it'll be of any use.

Looks promising, but do we want to try and simulate physics but then have to add in some 'compensation' when the emergent behaviour isn't what we expect?...and then do this for every plane. But we might also want fantasy planes, so how do we handle those?

So, we need a model that feels realistic for planes like the KC-135, plus anything we make up.

 

Something table based maybe? We know the inputs, so it's just a  case of coming up with a transfer function to get the 'expected' outputs for each plane.

I'll come back to this after some beer...

Share this post


Link to post
Share on other sites

The preferred approach would be:

  1. Write a plugin that can parse data from FSX (table-based) or implements the dynamic simulation from X-plane (open source, just feed in its code)
  2. When TFXplorer calls the plugin to simulate a plane, get from TFXplorer parameters like AoA, speed, …
  3. table lookup or dispatch to X-plane
  4. Forward results to TFXplorer

Some adjustments would need to be made for time delta. TFXplorer currently runs with a fixed 240 Hz simulation rate, which is bad for many many reasons, and this would need translation to the rate of other simulations.

 

More adjustments would need to be made for keyboard/joystick controls (I guess FSX has a few hundred more functions than TFXplorer has now).

 

Visuals would be a different beast.

 

But this way we could use any flight physics from any system we care to implement.

Share this post


Link to post
Share on other sites
On 11/27/2019 at 1:35 PM, mikew said:

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. :)

The weapons stuff is very interesting. Going back to TAW code and looking at the 159 byte weapons block, it was possible to modify the loadouts, similar to what Mike displayed for TFX, using modifications at position 94. Now that I have compiled the blocks for each weapon, including those not used in-game, in document format, the next objective is t o define the function of each entry. 

Below  is the disassembled code for AIM120C:

 

DGROUP:006708C2                 dd offset unk_6751F6
DGROUP:006708C6 off_6708C6      dd offset aAim120c      ; DATA XREF: sub_4B90D8+D9r
DGROUP:006708C6                                         ; "AIM120C"
DGROUP:006708CA                 dd offset aAim120c      ; "AIM120C"
DGROUP:006708CE                 db    0
DGROUP:006708CF                 db    0
DGROUP:006708D0                 db    0
DGROUP:006708D1                 db    0
DGROUP:006708D2                 dd offset aXaim120c     ; "xaim120c"
DGROUP:006708D6                 dd offset aFzaim12c     ; "fzaim12c"
DGROUP:006708DA                 db    0
DGROUP:006708DB                 db    0
DGROUP:006708DC                 db    0
DGROUP:006708DD                 db    0
DGROUP:006708DE                 db    0
DGROUP:006708DF                 db    0
DGROUP:006708E0                 db    0
DGROUP:006708E1                 db    0
DGROUP:006708E2                 db    0
DGROUP:006708E3                 db    0
DGROUP:006708E4                 db    0
DGROUP:006708E5                 db    0
DGROUP:006708E6                 db    0
DGROUP:006708E7                 db    0
DGROUP:006708E8                 db    0
DGROUP:006708E9                 db    0
DGROUP:006708EA                 db    0
DGROUP:006708EB                 db    0
DGROUP:006708EC                 db    0
DGROUP:006708ED                 db    0
DGROUP:006708EE                 db    0
DGROUP:006708EF                 db    0
DGROUP:006708F0                 db    0
DGROUP:006708F1                 db    0
DGROUP:006708F2                 db    0
DGROUP:006708F3                 db    0
DGROUP:006708F4                 dd offset aFxaim12c     ; "fxaim12c"
DGROUP:006708F8                 dd offset aFyaim12c     ; "fyaim12c"
DGROUP:006708FC                 dd offset aFzaim12c     ; "fzaim12c"
DGROUP:00670900                 dd offset aF0aim12c     ; "f0aim12c"
DGROUP:00670904                 dd offset aF1aim12c     ; "f1aim12c"
DGROUP:00670908                 dd offset aF2aim12c     ; "f2aim12c"
DGROUP:0067090C                 db    0
DGROUP:0067090D                 db    0
DGROUP:0067090E                 db    0
DGROUP:0067090F                 db    0
DGROUP:00670910                 db    0
DGROUP:00670911                 db    0
DGROUP:00670912                 db    0
DGROUP:00670913                 db    0
DGROUP:00670914                 db    0
DGROUP:00670915                 db    0
DGROUP:00670916                 db    0
DGROUP:00670917                 db    0
DGROUP:00670918                 db    0
DGROUP:00670919                 db    0
DGROUP:0067091A                 db    0
DGROUP:0067091B                 db    0
DGROUP:0067091C                 db    0
DGROUP:0067091D                 db    0
DGROUP:0067091E                 db    1
DGROUP:0067091F                 db 0AAh ; ¬
DGROUP:00670920                 db  55h ; U
DGROUP:00670921                 db  55h ; U
DGROUP:00670922                 db    0
DGROUP:00670923                 db    2
DGROUP:00670924                 db    1
DGROUP:00670925                 db    0
DGROUP:00670926                 db    0
DGROUP:00670927                 db  16h
DGROUP:00670928                 db  43h ; C
DGROUP:00670929                 db  0Ch
DGROUP:0067092A                 db    8
DGROUP:0067092B                 db 0E4h ; S
DGROUP:0067092C                 db  31h ; 1
DGROUP:0067092D                 db    0
DGROUP:0067092E                 db    0
DGROUP:0067092F                 db 0FFh
DGROUP:00670930                 db 0FFh
DGROUP:00670931                 db    1
DGROUP:00670932                 db  6Fh ; o
DGROUP:00670933                 db  12h
DGROUP:00670934                 db    3
DGROUP:00670935                 db  3Ah ; :
DGROUP:00670936                 db    0
DGROUP:00670937                 db  64h ; d
DGROUP:00670938                 db    0
DGROUP:00670939                 db    0
DGROUP:0067093A                 db 0A0h ; á
DGROUP:0067093B                 db  41h ; A
DGROUP:0067093C                 db 0A6h ; ª
DGROUP:0067093D                 db  9Bh ; ¢
DGROUP:0067093E                 db  44h ; D
DGROUP:0067093F                 db  3Bh ; ;
DGROUP:00670940                 db 0CDh ; -
DGROUP:00670941                 db 0CCh ; ¦
DGROUP:00670942                 db  4Ch ; L
DGROUP:00670943                 db  3Dh ; =
DGROUP:00670944                 db    0
DGROUP:00670945                 db    0
DGROUP:00670946                 db  80h ; Ç
DGROUP:00670947                 db  3Eh ; >
DGROUP:00670948                 db    0
DGROUP:00670949                 db  70h ; p
DGROUP:0067094A                 db  94h ; ö
DGROUP:0067094B                 db  46h ; F
DGROUP:0067094C                 db    0
DGROUP:0067094D                 db    0
DGROUP:0067094E                 db  0Ch
DGROUP:0067094F                 db  42h ; B
DGROUP:00670950                 db    0
DGROUP:00670951                 db    0
DGROUP:00670952                 db  20h
DGROUP:00670953                 db  41h ; A
DGROUP:00670954                 db    0
DGROUP:00670955                 db    0
DGROUP:00670956                 db 0F0h ; =
DGROUP:00670957                 db  41h ; A
DGROUP:00670958                 dd offset aWamraam_lbm  ; "wamraam.lbm"
DGROUP:0067095C                 dd offset aFamraam_lbm  ; "famraam.lbm"
DGROUP:00670960                 db  55h ; U

 

Refresh my memory on how these weapons blocks work .🙂

Share this post


Link to post
Share on other sites
On 12/8/2019 at 8:15 PM, DrKevDog said:

Refresh my memory on how these weapons blocks work .🙂

That's data, and we'd have to decompile the routines that use that data to find out what it does and I don't remember doing that. :(

 

What the hell have MS done with Win10 file handling?

I use a USB memory sticks to transfer data files between PCs, and have many directories with lots of small files, eg the 3/ directories for all versions of TFX.

I understand why this will be slower than transferring them zipped, but while it'll take 30 seconds or so with Win 7 or Linux, it's about 10 minutes on Win 10. :wtf:

Share this post


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

I understand why this will be slower than transferring them zipped, but while it'll take 30 seconds or so with Win 7 or Linux, it's about 10 minutes on Win 10. :wtf:

 

Just now switching to Windows 10, and already noticed git and 7-Zip being 2–3× faster when Windows Defender is disabled.

Share this post


Link to post
Share on other sites

Hmmn, interesting.

I won't try disabling Defender just yet though. Probably wouldn't be allowed to anyway....

My main Win10 tip is to make sure you set your network connection to 'metered' which seems to stop the spontaneous updating.

 

Share this post


Link to post
Share on other sites

End of an era. I updated my Win7 PC (that was my main machine 2011-2018) to Win10 while it's still free to do so. Not that I'll be using it much again, but at least it should be safe to connect to the internet after tomorrow...
So, Win10/Linux from now on and I'm still looking for some cross-platform 'no strings attached' development environment.

 

Now, I never did fix that KC-135. I wonder how practical would it be to use its dll in isolation from TFXplorer for flight model testing?

Probably not very...:D

 

Share this post


Link to post
Share on other sites
On 1/13/2020 at 3:06 PM, mikew said:

So, Win10/Linux from now on and I'm still looking for some cross-platform 'no strings attached' development environment.

 

I did some experiments going from MSBuild to makefiles, but so far it was a disaster :D

Share this post


Link to post
Share on other sites

Since I have Python everywhere, I've been using SCons for my experiments.

Probably good enough for hobby use, especially if you start a project from scratch with it.

 

It's pretty much impossible to convert an existing MSVS project to SCons though. I found that out while using a PC that has the Windows SDK, but not Visual Studio.

 

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...