480 bytes of doom

Alrighty, I just spent some time trying to analyze 480 bytes I mentioned in the .acm analysis topic.

The situation:

I started a custom combat mission, with 1 wingman, 1 enemy F-22 and 1 enemy EF2000. → 4 Planes in total. Loadout: Guns only.

I then dumped the 480 bytes (which are stored right after each other, so 4× a chunk of 480 bytes) and tried to do some color-coding, to see what was the same for every plane, what was the same for all the F-22’s, what was the same for ALLY vs ENEMY.

Here is the result: VERSION 1

(I will also upload the photoshop work file to box.net so that the color layers can be worked upon.)

OVERVIEW:

Legend:

Green: accounted for (4 bytes X pos, 4 bytes altitude, 4 bytes Y pos / 4 bytes FUEL amount (float) / 60 bytes of ammo array (1 byte weaponID, 2 bytes ammount) / 2 bytes chaffs ammount & 2 bytes flares ammount

Yellow: possibly pitch, yaw & roll – edit: confirmed.

PITCH: doing a looping starting nose slightly up will go like this: 65k → 49k → 65k/0k → 16k → 0k

YAW: starting North → East → South → West → North will be: 0 → 16k → 32k → 49k → 65k/0

ROLL: flying straight, then tilting to the left to make a complete aileron roll will be: 0 → 16k → 32k → 49k → 65k/0

Orange: 2× a counter byte I noticed, will also have to further investigate (01,02,03,04 / CE,CF,D0,D1)

Red: shows all bytes that are the same for that type of plane (F-22 vs EF2000)

Blue: shows all bytes that are the same for planes of the same nation (friendly / hostile)

Purple: these bytes are the same for ALL the planes

Black: these bytes didn’t have a constant value and were twitching quickly when viewed in cheat engine – have been disregarded for now

here are the 4 chunks without any colors

plane 1: lead F-22

00 00 00 00 00 00 00 00 00 00 00 0A E1 01 00 00

this line of code comes right before the 480 byte long chunk. It has an element that reoccurs (E1 01 00 00) at the very end of the chunks aswell, possibly an opcode? maybe initializing the plane? dunno yet …

6D 73 5C 05 57 F2 FE FF 06 00 D4 01 66 FF FE 3F
2D 00 3F 02 00 00 01 00 00 00 00 00 00 00 00 00
00 CE 43 00 00 00 00 00 00 21 0C 00 00 00 00 00
00 00 02 00 21 5D 6A 8E AF D4 11 41 7F 99 6B 22
2B 25 2A 41 B9 9F 6F 60 56 8C 84 C0 CF DE 54 9D
3E 88 72 40 1A AD D0 F1 38 E7 87 BF 63 27 99 24
DC 58 0A 40 90 A0 9C 83 25 16 B3 3F 4B 6B DD EF
CC 87 72 40 AC 68 26 35 A9 28 F2 BF 04 0C C9 3F
64 53 72 3C 2F 0A 8F BB 65 9A BA 20 F5 9F C0 9C
F0 B9 EF B8 00 00 00 00 39 F3 4F BF 00 00 00 00
11 C0 EF B8 43 39 94 43 68 3E 94 43 9D 07 C9 3F
E9 CC 80 CE 6E B7 1E 3F 02 04 4A 05 EC FF EF BF
C9 F7 F6 E1 70 DF 71 BF 2B EB 9E 9B 1A FF EF 3F
2E FA A1 88 39 97 0B 3F 9F 09 31 CF 55 4A 8E 3F
F2 99 C1 13 24 4A 8E BF 6C AC 0D F8 C1 E0 71 BF
C9 A5 C7 A4 06 FF EF 3F 6A C8 38 3C C0 6F 25 B8
05 5D C8 66 00 00 00 5C 44 2E 7B BB 45 05 01 02
00 00 06 00 00 00 00 00 04 00 FF FF 00 00 00 00
04 00 8B 74 C9 BA FF FF 00 00 00 00 09 00 00 00
00 00 00 4B 9A 99 19 3F 00 FF FF 3E 9A 34 2B 48
4E 19 93 43 FF FF 00 00 00 00 00 00 FF FF 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 E0 06 13 96 00 96 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 56 4A E1 B9 F0 6D A8 40
00 00 00 00 00 00 00 FF FF 00 00 72 E1 01 00 00

plane 2: wingman F-22

14 47 5C 05 7C F2 FE FF F5 5B D3 01 64 FF FF 3F
0F 00 44 02 00 00 02 00 00 00 00 00 00 00 00 00
00 CF 43 00 00 00 00 00 00 21 0C 00 40 01 00 00
00 00 01 00 99 D0 C0 50 6F CE 11 41 37 56 5E DC
52 24 2A 41 DB 61 8C B7 8E 89 84 C0 85 EC 33 E7
4C AA 72 40 4E D2 CE 68 2B 37 85 BF 1A 1C E6 3A
25 48 11 40 57 FB 1A BC 15 93 79 3F 91 BC FF 19
B1 A9 72 40 C0 2A 25 94 C7 3F C3 BF 92 0F C9 3F
20 7E 75 3C 07 52 C1 BA A5 D8 89 39 4B 94 29 B9
EF 80 F1 B7 39 D8 8B 39 9D C0 4B B7 D6 77 0E B8
28 EB EF B7 67 56 95 43 89 4D 95 43 2B 0F C9 3F
69 62 CD A4 13 47 E2 3E 48 27 22 B8 FD FF EF BF
50 9E 7D 02 B4 29 58 BF ED 46 73 96 14 FF EF 3F
BE FB 34 32 A4 10 EC BE 90 EB 55 56 78 AF 8E 3F
7F 22 96 CC 78 AF 8E BF 67 61 67 77 8E 29 58 BF
CE 2D 96 4E 12 FF EF 3F 6A 02 6D 3C 43 79 11 B8
05 5D C8 66 00 00 00 5C 44 23 71 BB 45 05 01 03
00 00 02 00 00 00 00 00 04 00 01 00 00 00 00 00
FF FF 00 00 00 00 FF FF 00 00 00 00 09 00 00 00
00 00 00 4C F4 5D 19 3F 55 95 0C 3F 25 B2 1C 48
01 45 94 43 FF FF 00 00 00 00 00 00 FF FF 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 E0 06 13 96 00 96 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 DE 5D C7 B9 18 0D 8E 40
80 2F 7D 00 00 00 00 FF FF 00 00 0A E1 01 00 00

plane 3: enemy F-22

8D 09 6C 05 81 17 FF FF FF 63 D4 01 FE F5 FF BF
0D 00 32 02 00 00 03 00 00 00 00 00 08 00 00 00
00 D0 43 00 00 00 00 00 00 21 0C 02 00 00 01 00
00 00 FF FF 1A D2 88 A5 7E D8 11 41 6D AB CD 2E
2E 71 2A 41 A7 42 87 BA 6B B7 81 C0 13 CF 37 10
F7 F5 71 40 23 B2 32 E4 26 77 9C BF 4C 90 93 BB
0A 6B 41 40 22 8C E0 E4 97 6F 9A BF AE B0 27 9D
EE F9 71 C0 78 1B 8D CD F0 F6 40 C0 D5 14 C9 BF
9F 88 7B 3E B8 21 A5 BA 8A 9D 80 3E 06 42 1C BB
5E 39 8B B8 1B 06 63 3E 8F EF 64 BB 0F 12 BA B8
7B 5E C5 B9 01 BD 90 43 75 CF 8F 43 CC 12 C9 BF
57 C4 DD A3 9D 4E 23 BF B2 9C B7 68 FE FF EF 3F
83 DB E5 E6 52 09 54 3F 03 69 2A 46 18 0A EF BF
2A 90 91 35 5D 40 24 3F 32 10 F8 82 60 20 CF BF
97 F5 91 8C 60 20 CF BF 56 FA FD F8 97 05 54 BF
3E D5 E3 AE 16 0A EF 3F 4A 0F F7 3D 6B 63 C9 B8
05 5D C8 66 00 00 00 5C 44 00 80 BB 45 01 00 03
00 04 02 00 00 00 00 00 FF FF 01 00 5F 06 0F BB
FF FF 00 00 00 00 FF FF 00 00 00 00 0A 1E 00 00
00 00 00 47 9A 99 19 3F 00 00 00 00 00 00 00 00
85 1E 7E 43 FF FF 00 00 00 00 00 00 FF FF 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 E0 06 14 96 00 96 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 F1 99 BC 3C 58 01 0E C1
00 00 00 00 00 00 00 FF FF 00 00 73 E1 01 00 00

plane 4: enemy EF2000

C4 96 6C 05 8C 1C FF FF 00 00 D4 01 63 F7 01 C0
00 00 CE 01 00 00 04 00 00 00 00 00 08 00 00 00
00 D1 43 00 00 00 00 00 10 21 0C 02 00 00 02 00
00 00 FF FF BA 95 4F 4F AF D4 11 41 9F 34 2F D9
DE 73 2A 41 B7 81 0C 8B 05 55 81 C0 E9 BD 31 D2
1A A0 6D 40 8B D7 B9 FD 72 6E 54 3F 78 7A DE 32
40 E4 38 40 C7 95 30 7E 84 47 53 3F C0 0D F6 9D
5A A1 6D C0 30 DC 5C FC 4E E7 37 C0 99 0F C9 BF
19 8E 58 3E B5 38 9A 38 B3 5A 52 3E 69 B2 F7 38
A8 FC 7C 36 99 D4 39 3E 7E 8F 22 39 78 6E A4 36
C1 C8 9B 37 8C 4E 6E 43 D5 0A 6D 43 B1 0F C9 BF
53 8B 40 33 38 02 E0 3E E5 BE 98 FE FF FF EF 3F
7A C4 E9 86 1B D9 12 BF C0 E1 D7 6C 7E 49 EF BF
82 5D BD 69 53 FF DF BE 65 59 59 2E 39 DE CA BF
08 41 59 2E 39 DE CA BF 66 E3 CB 35 24 D9 12 3F
A5 A0 70 6B 7E 49 EF 3F F5 4E D6 3D 49 96 AF 36
06 FE C8 66 00 00 C0 80 43 5A E3 79 45 01 00 04
00 04 01 00 02 01 02 00 FF FF 01 00 8B 74 C9 BA
FF FF 00 00 00 00 FF FF 00 00 00 00 0A 1E 00 00
00 00 00 50 9A 99 19 3F 00 00 80 3F CA 0E 16 48
89 60 75 43 FF FF 00 00 00 00 00 00 FF FF 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 01 03 02 14 96 00 96 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 3A CE 24 3C CD C0 7F 40
00 00 00 00 00 00 00 FF FF 00 00 6D E1 01 00 00

there also seems to be a terminating section that comes right after the 4th chunk …

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 FF FF 00 00 00 00 00 04 00 00 50 15 00 FF FF
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Anyways, further testing is already ongoing, I’m comparing two chunks, one where I have an enemy targeted and locked, one where i don’t … I will update this as I go along …

I’m hoping that we can find out what exactly gets loaded in these 480 bytes. Also I’m hoping this will somehow reveal the mechanics of loading a plane into memory …

I’ve noticed, that having other mobile units in the mission causes the 2nd, 3rd and 4th chunk not to align anymore, suggesting the chunks might be smaller for less complex units?? I will also have to dump the memory section with only a truck or something like that to further analyze the change …

… Now I’ve got to take a short break ^^

PS. I’ve already noticed some stuff, like bytes that are the same for me and my wingman, different for the enmy F-22 and yet again different for the EF2000, suggesting they may relate to which flight the plane is in. I ran out of colors for this though, but I will get to it! Also noticed for example all computer controlled planes having the same bytes, with only my plane having a different value → this also makes sense to have that stored somehow …

//edit: short edit to CONFIRM PITCH YAW & ROLL

That’s just epic! 👍

Well I have a few more results on bytes that I could account for and find out what they do:

new info has been marked with RED

offset
00–03	4 B	X pos
04–07	4 B	Altitude
08–0B	4 B	Y pos
0C–0D	2 B	Pitch
0E–0F	2 B	Yaw
10–11	2 B	Roll
1C	1 B	Allegiance
21	1 B	One of the counter bytes: relates to 3D model/texture I’m guessing – since:
22	1 B	Overrides 3D model (42&43 default values) 41 cloud layer tile 40 road crossing terrain tile 3F crash as soon as this value is entered 30 explosion effect 00 SU-37 01 747 or 737 I believe the counter byte above points to another region in memory, where each plane’s graphics and stuff gets described. The default value for the override 3D model is 42 for all planes when the top skin is selected in the options, and it’s 43 for all planes when the bottom skin is selected. Also I got an error message when changing this stuff mentioning couldn’t get address (…) and had 4 bytes mentioned there. I clicked it away to fast before I realized I should have written down what it said. HOWEVER, I did notice this: Assuming the counter byte was 7C (during takeoff mission I believe) → increasing this by 1 to 7D would change the graphics model of my F-22 to an F-22 with the gears UP! Even while it was on the ground. It will still behave as though the gears were down though. I can taxi and everything. (It would first be a low resolution model, then pressing F7 it would refresh and show a high res model) Doing the same thing after takeoff, with the gears still down, will have the same result – the model will change to reflect gears up, but i will still see gears on the HUD. also pressing G to retract the gears will refresh the model, and the gears will suddenly reappear and the retraction animation will start and the gears will then be up. Strangely enough, none of these events change the counter byte, suggesting all the different variations of the model are stored in as an offset in relation to the standard model found at the 7C address?? Raising the counter high enough will result in the plane becoming other plane models in the world, be that a Learjet, or F-16 or stuff like that. Also another interesting fact: While doing the landing mission, raising the counter of the plane by 1 (BD → BE) will NOT result in gears up, but it will result in a model showing gears DOWN and CANOPY OPEN … This leads me to believe that the game already anticipates the next model of the plane based on waypoints? So that’s why increasing the counter byte during the takeoff mission made it gears up, canopy closed, and increasing the same byte during the landing mission will result in a model showing gears down and canopy open … However the 3d model override might not affect collision boxes I believe, since I was able to fly through the ground tile. But maybe collision with ground tiles is handled differently – still stuff to find out here, will keep on it … Alright so lets continue:
29	1 B	Airbrakes 21 off 23 air & groundbrakes on 20 Will stop you from changing the airbrakes with B – as in the hydraulics failure test landing. The hydraulics failure automatically turns off the airbreaks, and sets the value to 20, so you can’t reenable them. Setting the value back to on (23) will result in them getting turned back off after a second and the value will be set to 20 again.
2C	1 B	Wingman memory offset? 00 lead 40 nr2 80 nr3 C0 nr4 Not sure about this but it seems plausible – wonder where I should start counting off the 64 bytes?
2D	1 B	Wingman rank offset? 00 lead 01 nr2 02 nr3 03 nr4
2E	1 B	Determines which flight/mission you’re in, starting from 0, then 1, then 2 etc … Not sure if escort/WW flights would have the same value – this is also something I need to further investigate upon …
109–10C	4 B	Fuel amount (as floating point value)
126	2 B	Could relate to targeting? To finalize what I mentioned last post: After doing a comparison with a target enabled and then no target, the only difference I found was a 00 00 → FF FF byte change, which is still a bit too vague to clearly define whats going on …
16F–1AA	60 B	Loadout array: 20 pylons with (2 bytes ID / 4 bytes AMOUNT)
1AB	1 B	Currently selected pylon 13 cannons 00 left far hardpoint 01 right far HP 02 left near HP 03 right near HP 04/05 left/right AIM-9X box 06–0B internal bomb bay positions; from left to right: 1, 6, 2, 5, 3, 4 0C/0D internal bomb bay combined positions 2+3 and 4+5 (used for AGM-65 Maverick for example) AI planes will use 14 as an auto selector maybe?? Note that might match the array above. it starts on 0h and ends on 13h, giving 20 pylons to choose from – there still remains questions about the autoselector of the AI planes though …
1AC–1AF	2×2 B	Chaff ammount and flare ammount

That’s it for now, I’ve also updated the color overlayer, but it might be more confusing than helpful … there is a bunch of data, that seems to relate to movement/flight path calculation, but it’s very complex …

I did a test, where on the ground I would take a snapshot of the plane as it is when the game loads it. Then I would fire up both engines and wait until they reached 50% IDLE. Again a snapshot.

The surprise: a quarter of the values mostly around the mid section have changed!

It’s a mess I’m currently working to sort out, I will upload the version 2 of the photoshop file and jpeg if anyone is interested, but it isnt really as informative at the moment …

YELLOW is the stuff belonging to flight path or propulsion or movement

BROWN is something related to plane type

the layer names give a bit more info on what exactly I was trying to highlight, find the PSD on ██████████

Here’s the JPEG:

That’s it for now, Eagle out

You’re a gem Eagle. 👍

I haven’t had time to digest all that you’ve done yet, but this seems to tie in with what we know about the models. The model file (.3) needs input from somewhere giving values for damage state, camo, gear etc.

Also, recent work on the ssd files points to certain parts of the file acting as a lookup table in order to modify the visible model, based on some input criteria which may be related to your following comment:

Eagle_Flight

Strangely enough, none of these events change the counter byte, suggesting all the different variations of the model are stored in as an offset in relation to the standard model found at the 7C address??

Okay I’ve noticed some discrepancy from what I stated earlier:

the 3d model override offset:

22: 42/43 – which I thought should only have these values turned up to be a 45 in one mission … not sure why …

also setting the counter from 42 to say 45 gave me this error: emm: bad getadr (457B)

Further investigation is ongoing! 🫡

EDIT:

Okay these seem to be related to the custom skins of the different nationalities …

I’m guessing 42 and 43 are the standard USA skins …

A funny thing happens when I start a campain, start a mission with the top skin selected, quit the flight, go to the options, change the camo to the bottom option, then go back to the campain and start a new mission →

The counter increases by 3

…? 😲

Eagle_Flight

A funny thing happens when I start a campain, start a mission with the top skin selected, quit the flight, go to the options, change the camo to the bottom option, then go back to the campain and start a new mission →

But when you quit the flight in the campaign, the flight will still be there … and you could reenter the same plane if you select an AWACS mission. The fact that you’re creating a new flight may explain the increment.

I’m trying to tie in your observations with the ssd file analysis, but so far can’t explain anything.

One question: If you change this value, does the skin of the whole F22 change or just the control surfaces? The 3d models of the F22 control surfaces are separate and seem to be handled differently to the rest of the plane.

mikew

The fact that you’re creating a new flight may explain the increment.

Seems correct, and quite interesting.

mikew

I’m trying to tie in your observations with the ssd file analysis, but so far can’t explain anything.

So far I haven’t established very much anyways, but this is a progressive learning subject … I’m sure more will become clear

mikew

One question: If you change this value, does the skin of the whole F22 change or just the control surfaces? The 3d models of the F22 control surfaces are separate and seem to be handled differently to the rest of the plane.

I believe the control surfaces of the override model are in place. although they don’t seem to be animated. (except maybe awacs radar dish, but dont quote me on that one)

I’ve done a bit more testing:

starting a custom mission with only a ground target I would have the following:

counter: B6

override: 42

okay so setting the counter to B7 →

I get a flying tank

alright, counter back to B6

Override: 00

I get an enemy plane, but there wasn’t any selected for this mission

Override: 01

Override: 02

Override: 03

Override: 04

Override: 05

Override: 06

Override: 07

Override: 08 gave me a crash …

also while I had for example override: 04, but set the counter up to B7, the plane would still be replaced by the bomb model and not the tank.

Apart from the visuals, is the sound also affected?

Yeah I got tank sound effects // sometimes no sound effects

Aha, it would then seem as though you are somehow affecting which SSD is called. Unfortunately, I don’t know how the ssd information is indexed for mobile units.

Look up in the sky!!! – Is it a bird?!?! – … or a plane???!!!!! – NO!!!

It’s … SUPERDUMMY!!

And with his laser-beam-cannon-eyeballs, he’s here to save the day from the civilian DHOW invasion!

mikew

Aha, it would then seem as though you are somehow affecting which SSD is called. Unfortunately, I don’t know how the ssd information is indexed for mobile units.

Okay, I think that is a step forward! I was also wondering on what could explain the order in which the files are being loaded?

On a side note:

I hope I didn’t confuse myself concerning which one of the two bytes I actually modified …

Anyways I did this test: custom mission, stealth loadout

Counter: something around A7 if I remember correctly

Override: 42

Anyways I would set the counter to 00–10 and always get the dummy.

Finally I’d crash. Alrighty, then shortly start a takeoff mission. Okay in the pit. Shift+Q to exit mission. OK.

Now restart a custom mission → crash. I believe the counter might not always get reinitiated? Weird …

Anyways more to come.

Heh, great stealth! The plane is so invisible, all you can see is the pilot. 🙂

While I’m following what you’re doing here, I’m afraid that I can’t yet explain anything. 🙁

The sound and visual behaviour (and maybe other things) of the F-22 is defined by the f22.ssd file, which when loaded on startup just becomes a chunk of memory.

My theory is that when a new F-22 object is created in the game, this chunk of memory is used as a lookup table in order to quickly obtain a set of parameters to feed to the 3D system in order to render the plane.

Now, I was hoping that your 480 bytes, which appears to hold the current state of a particular plane, would provide the input for this process as a set of pointers … but I haven’t yet been able to make such a connection.

Hopefully, the Eureka moment is not too far away, so keep up the good work. 👍

mikew

Heh, great stealth! The plane is so invisible, all you can see is the pilot. 🙂

While I’m following what you’re doing here, I’m afraid that I can’t yet explain anything. 🙁

The sound and visual behaviour (and maybe other things) of the F-22 is defined by the f22.ssd file, which when loaded on startup just becomes a chunk of memory.

I noticed that the flight behavior is also changed with some of the choices, however I cannot determine if it’s the like a default flight model? I noticed sometimes it definitely doesn’t turn as sharp and crisp as the F-22. But I haven’t done any testing to confirm if it’s the same alternative flight model for all the planes etc.

mikew

My theory is that when a new F-22 object is created in the game, this chunk of memory is used as a lookup table in order to quickly obtain a set of parameters to feed to the 3D system in order to render the plane.

That could suggest, that the entire SSD file should basically be found at least in parts stored in the memory? Following up, the SSD file would already have sections mapped out which would become accessible and would change when loaded by the 3d simulator part?

I would believe the mission files to be the look-up table for which ssd files would get loaded? Maybe also which part of the map should get loaded into memory (by the waypoints)? Along with some other parameters like time of day …

Side note:

I wonder if we could enable a further view of the terrain …?? Do we know how many tiles are allowed to be loaded at once? or the distance radius at which tiles either get loaded into memory / kicked out? (almost like in the .acm file, where sometimes it would mention SU-27 LEAD entered the area / left the area etc … the ground tiles would also only partially get loaded …)

back to topic:

mikew

Now, I was hoping that your 480 bytes, which appears to hold the current state of a particular plane, would provide the input for this process as a set of pointers … but I haven’t yet been able to make such a connection.

These 480 bytes seem more or less self contained … However the pointer 0066c4c0 points directly first byte of the players airplane. Following are 480 byte chunks for each plane. Ground/Sea units do not appear on this list of 480 byte chunks.

However the beginning of the 480 bytes might be some sort of header - containing basic data that every object might have?

Maybe we should be looking out for certain HEX strings from the SSD files in the memory area …? Certain OPCODES?

mikew

Hopefully, the Eureka moment is not too far away, so keep up the good work. 👍

Hopefully the Eureka moments will be plentiful ^^

Eagle_Flight

I noticed that the flight behavior is also changed with some of the choices, however I cannot determine if it’s the like a default flight model? I noticed sometimes it definitely doesn’t turn as sharp and crisp as the F-22. But I haven’t done any testing to confirm if it’s the same alternative flight model for all the planes etc.

Well, those 480 bytes contain the current position and attitude of the plane, so it wouldn't be surprising if other parameters associated with the flight model are present as well.

Eagle_Flight

That could suggest, that the entire SSD file should basically be found at least in parts stored in the memory? Following up, the SSD file would already have sections mapped out which would become accessible and would change when loaded by the 3d simulator part?

I don't believe the contents of the SSD are changed in memory, but sections are copied to somewhere else depending on the state of the object in question. So, for instance, if the gear is down the appropriate info is sent to the 3d rendering stage.

Eagle_Flight

I would believe the mission files to be the look-up table for which ssd files would get loaded? Maybe also which part of the map should get loaded into memory (by the waypoints)? Along with some other parameters like time of day …

Yes, good point. If an ssd file is missing, the game only complains if that vehicle is part of the mission.

Eagle_Flight

Side note:

I wonder if we could enable a further view of the terrain …?? Do we know how many tiles are allowed to be loaded at once? or the distance radius at which tiles either get loaded into memory / kicked out? (almost like in the .acm file, where sometimes it would mention SU-27 LEAD entered the area / left the area etc … the ground tiles would also only partially get loaded …)

I think the whole terrain is always loaded, but only a few tiles are visible. There are only a few hundred unique terrain tiles, and most of these only have 25 vertices. There is no real difference between the ACMI view and normal view. The ACMI view just doesn't texture or colour the polygons.

Eagle_Flight

back to topic:

These 480 bytes seem more or less self contained … However the pointer 0066c4c0 points directly first byte of the players airplane. Following are 480 byte chunks for each plane. Ground/Sea units do not appear on this list of 480 byte chunks.

However the beginning of the 480 bytes might be some sort of header - containing basic data that every object might have?

Maybe we should be looking out for certain HEX strings from the SSD files in the memory area …? Certain OPCODES?

Isn't the start of the 480 bytes the position of the plane, or are there other bytes before this?

See the first post flight - lead will have some header bytes before the 480 chunk

EDIT:

(sry to answer so promptly and snappy - I was on a mobile connection when I posted this …)

I guess we might be trying to find a sort of a begin object opcode or next object opcode to tell the game: watch out, be ready to load another item into the simulator.

what i ment was maybe something like this:

byte string before first f22:

00 00 00 00 00 00 00 00 00 00 00 0A E1 01 00 00

[480 byte chunks]

now within that 480 byte chunk we have the final 3 rows of 16 bytes (=48 bytes) that look like this:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 56 4A E1 B9 F0 6D A8 40
00 00 00 00 00 00 00 FF FF 00 00 72 E1 01 00 00

and the E1 01 00 00 is reappearing here. I believe if looked at as little endian format, this would give the hex value 000001E1 - which would turn out to be 481. But why would it be counting 1 more byte than the 480 expected? Also what about the bits with 0A or 72 just before the the E1 01 00 00?

I have no idea what those numbers may mean … although something seems vaguely familiar.

I need to go back to the SSD thread for a while, and try and decode some more blocks.

Could this be the breakthrough we need to assign the high detail F-22s to the wingmen?

Just a minor update:

I've picked up something interesting:

Two bytes at 2A & 2B seem to contain the status of bomb bays & side panels … But I don't know to what extent the status is defined by these bytes (i.e. the model in-game doesn't update to show any visual change, however there is some change noticeable in the behaviour when it comes to shooting missiles from the bombs bay if the mentioned value is tampered with etc)

The value is little endian 2 bytes long in memory, I believe …

These are the converted values

gears don't seem to affect this value … neither does changing radio frequency … nor does canopy …

I will have to do a further test for gear the values and canopy …

Great work!

Hopefully this will all make sense one day.

mikew

Great work!

Hopefully this will all make sense one day.

Well further investigation shows that the previously mentioned 2 byte value sometimes also has +400 added to it - for example in the landing training mission - but there is no obvious difference that I am aware of, so I'm not sure what that does …

Some more interesting info:

Byte at offset 28 will define the gear status when it comes to functionality, but it will not update the 3d model

It will also change the brakes byte at offset 29 with proper input:

So on the ground, with gears down, i can pause the game, switch this value from 60 to 00, go back to game, unpause, and the plane will sink a bit, until it hits the ground so to say - it will then begin to slightly tilt on one side. No damage will get taken though, I think the plane has to be moving with some speed for that to happen.

Further more, I can then reactivate the gears, and the plane will get pushed back off the ground a bit. It may remain a bit tilted, but after taxiing a bit that goes away.

Now when it comes to the 3D model, something interesting has come to my attention: I tried to land the plane with the gears down only by tweaking this value, not by pressing G - with success! No gears were visible, but the plane still landed and behaved as though the gears were down.

I also noticed something else different: The sound that it made when touching down only with tweaked gears, not with 3D model gears - was that of when you belly land / crash land. This was only for initial touchdown. When rolling on the ground, you still heard the bumps from the pavement. The 3D model still showed no gears.

Also note that the following byte, offset 29, contained the air brake status: (nothing new)

→ on = +2

→ toggleable = +21

However, by tweaking the byte at 28 with +80, it would add 2 to this byte, and therefore turning airbakes on.

I've only recently started to notice this kind of data storage:

A byte will not only just contain a 0 or a 1 for OFF and ON, but it will instead contain a sum of predefined values … You just have to ensure that no two combinations will ever give the same value …

I think this works on a binary principle?

looking back at the open bays status:

The same applies to the byte at offset 28:

And the byte at 29:

EDIT:

The next obvious step I think will be to try out values that have some binary switches flipped and try to isolate what they might do ^^

Somehow exciting! ^^

Cool!

I wonder if that byte at 29 has something to do with the damage system? I.e. if hydraulic failure is simulated, one of those bits is set, which stops the brakes and gear from being moved.

Eagle_Flight

looking back at the open bays status:

10111001100 = 5CC	landing mission + all bays open
10000001100 = 40C	landing mission only engines on
00111001100 = 1CC	all bays open
00110001100 = 18C	bomb bay closed
00100001100 = 10C	bomb bay and right panel closed
00000001100 = 0C	all closed, only engines

I hope you keep at it, this may come together after a while. Some of the .ssd project results from several months ago, when I was playing around with the F-22 weapons bay doors, determined the Block 4 pointers for bay door closing were in the 0771 cluster area:

;Block4 Starts 122 Length.346

ad004402980398036c04400540054005400540054005400588
05880588058805a705be05be05c006c006c306c606c606c606
1a076e07710771077107710771077107710771077107710771
077107710771077107f5077e08b308e8081d0952097a09a209
ca09f2091a0a420a6a0a920aba0ae20a0a0b320b5a0b820baa
0bd20bfa0bfa0bfa0bfa0bfa0bfa0bfa0b3e0c820cc60c0a0d
4e0d920dd60d1a0e5e0ea20ee60ee60ee60ee60ee60ee60ee6
0e270f270f6c0fad0fba0fbd0fca0fd70fda0fe70ff40ff70f
0410111014102110241040112512ca126c130a149a14681536
164a1654165a167b169816b916d616f6161617361756175917
5c17681778177b1785178f179917a317ad17b717c117cb17d5
17df17e917f317fd17071811181b18201825187f18c118d918
e518e818e818e818521a551a651aa61ae71a281b691bc41b05
1c241c3b1c451c481c4b1c4e1c511c541cd81cd21d

If you look at the end of that cluster you see f507 which has direct effect on bay door closing animation.

F507 is at static hex address 00ce and points to address 10b8 which is Block4_pointer_42:

;Block4_Pointer_42 Starts 4280 Length.276

0b0032000000
150000000700000400030002000100000500
150004000700000400030002000100000500
150005000700000400030002000100000500
150006000700000400030002000100000500
15000f000700000400030002000100000500
150010000700000400030002000100000500
150011000700000400030002000100000500
150012000700000400030002000100000500
150013000700000400030002000100000500
150014000700000400030002000100000500
150015000700000400030002000100000500
150016000700000400030002000100000500
150017000700000400030002000100000500
15002a000400070003000500
0000
85005f000000020018011e006400000001000000
0000

The sequential nature of the 1500 lines suggest the process of sequential closing of doors. Altering/modifying these sequential numbers, in f22.ssd, effects the in-game bay door closing animations. Exactly how this is communicated into memory is what we could benefit from knowing.

:bump:

… for my convenience. 🙂