Ace Combat levels
Ace Combat levels
I had an idea during my quest to give TFXplorer a decent modding API: I have a few levels from old Ace Combat games readily extracted, so why not use them?
So I spent last week’s evenings writing an extension that imports the levels from Ace Combat 3: Electrosphere (AC3) into TFXplorer.
I haven’t pushed the extension to our repository (yet?) because the code is not really production-ready, but this experiment gave me some really interesting insights and was well worth it!
Starting
I wrote a new extension from scratch. This reminded me that the current workflow is a mess beyond words, but there is little chance to improve it until I finished my work on the sound/rendering API ¯\_(ツ)_/¯
Jumping through hoops
I was pretty quick at listing a new scenario on our scenario selection screen. But I had to do some work before the level would actually load: Define placeholders for rendering, physics, in-game maps, and so on. It felt like drag at the time, but it paid off later.
I left everything blank except the rendering part. I copied some code for loading AC3 data from other projects of mine, and alas I was able to draw their triangle data! AC3 terrain is tile-based just like EF2000/TAW’s, so I could let TFXplorer manage visibility for me and saturate its callbacks perfectly.
(The weird color is intentional – if you don’t define sky colors, TFXplorer will force the most annoying preset onto you, so you never forget to fix it.)
Adding textures took me some more time because of the weird quirks of the PlayStation GPU, and it was not really related to TFXplorer or its API. It all went pretty smooth!
Brightness
I had a level now and I was very proud, but it looked way too dark. This was due to the way the PlayStation GPU performed blending of textures and vertex colors.
Just hard-coding a different brightness would break the EF2000/TAW levels, so this was not an option. After all, I did this to figure out what my API was still missing! So I added a new brightness control to the renderer. This quickly broke rendering of HUD and text in a testament to TFXplorer’s insane rendering complexity, but I figured it out.
We would have needed a way to control brightness anyway to get a handle on day/night cycles. The fact that the stars are currently visible at day is a consequence of everything being drawn always in the same brightness. I did feel the urge to add a way of controlling white point, shutter time, and tone mapping; but this would have had me sidetracked for weeks, so I stopped.
AC3 has beautiful levels of varying brightness. Day, dusk, night and even indoor (more on that later). This showed another bug – temperature and humidity from the scenario not being honored! Compared to the EF2000/TAW graphics I normally see in TFXplorer, this is really something to look at. Getting the sky colors into the engine (readily provided by AC3) required a little rewiring of parameters, but went otherwise smoothly.
Physics
This was really nice to look at, but now I felt an itch. There’s these beautiful levels (40+ of them) with runways, highways, bridges, skyscrapers, mountains, canyons. But all I could do was look at them. Meh. I wanted to actually fly through the cities! I wanted to land on the bridges so badly!
So I filled my physics callbacks with a ray-triangle collision function I found on the internet and just iterated the same triangles I used for rendering. It worked remarkably well, and I would now crash into mountains and buildings instead of just passing through them. I could even land in the weirdest places!
There was a problem, though. My plane would explode with no apparent reason, and it was worst in the tunnel level. (Did I mention that Ace Combat is obsessed with tunnels? Every iteration has a tunnel level. AC3 even has a whole underground city level.) I ultimately tracked it down to a bug in TFXplorer’s handling of objects transitioning between terrain tiles.
These things never showed in EF2000/TAW because their terrain is, in direct comparison, extremely boring and feature-less.
Map
AC3 provides textures with overview maps of the levels. They are not nearly as sophisticated as TAW’s, but whatever! I was able to add them in no time.
Carrier landing
This afternoon, I found an aircraft carrier in one of the levels. It doesn’t render properly, but with some imagination it’s enough to hit it. I tried carrier landings for some time, and I even succeeded once! I also managed to take off again (with spinning up the engines while the tire brakes were still on). So the F-22 is officially carrier-capable …
Conclusion
This experiment showed a few places where the level API needed polishing, and it also lead to the discovery of a few bugs that would otherwise have been impossible to find (like all the places where the engine still calculates TFX units instead of meters). It showed me all the things I had mocked up long ago but never really bothered connecting with the rest. I will not pursue it with much energy, but I will keep it running until it becomes too costly to maintain.
Gotta take a few videos when I get that carrier render properly …
So I spent last week’s evenings writing an extension that imports the levels from Ace Combat 3: Electrosphere (AC3) into TFXplorer.
I haven’t pushed the extension to our repository (yet?) because the code is not really production-ready, but this experiment gave me some really interesting insights and was well worth it!
Starting
I wrote a new extension from scratch. This reminded me that the current workflow is a mess beyond words, but there is little chance to improve it until I finished my work on the sound/rendering API ¯\_(ツ)_/¯
Jumping through hoops
I was pretty quick at listing a new scenario on our scenario selection screen. But I had to do some work before the level would actually load: Define placeholders for rendering, physics, in-game maps, and so on. It felt like drag at the time, but it paid off later.
I left everything blank except the rendering part. I copied some code for loading AC3 data from other projects of mine, and alas I was able to draw their triangle data! AC3 terrain is tile-based just like EF2000/TAW’s, so I could let TFXplorer manage visibility for me and saturate its callbacks perfectly.
(The weird color is intentional – if you don’t define sky colors, TFXplorer will force the most annoying preset onto you, so you never forget to fix it.)
Adding textures took me some more time because of the weird quirks of the PlayStation GPU, and it was not really related to TFXplorer or its API. It all went pretty smooth!
Brightness
I had a level now and I was very proud, but it looked way too dark. This was due to the way the PlayStation GPU performed blending of textures and vertex colors.
Just hard-coding a different brightness would break the EF2000/TAW levels, so this was not an option. After all, I did this to figure out what my API was still missing! So I added a new brightness control to the renderer. This quickly broke rendering of HUD and text in a testament to TFXplorer’s insane rendering complexity, but I figured it out.
We would have needed a way to control brightness anyway to get a handle on day/night cycles. The fact that the stars are currently visible at day is a consequence of everything being drawn always in the same brightness. I did feel the urge to add a way of controlling white point, shutter time, and tone mapping; but this would have had me sidetracked for weeks, so I stopped.
AC3 has beautiful levels of varying brightness. Day, dusk, night and even indoor (more on that later). This showed another bug – temperature and humidity from the scenario not being honored! Compared to the EF2000/TAW graphics I normally see in TFXplorer, this is really something to look at. Getting the sky colors into the engine (readily provided by AC3) required a little rewiring of parameters, but went otherwise smoothly.
Physics
This was really nice to look at, but now I felt an itch. There’s these beautiful levels (40+ of them) with runways, highways, bridges, skyscrapers, mountains, canyons. But all I could do was look at them. Meh. I wanted to actually fly through the cities! I wanted to land on the bridges so badly!
So I filled my physics callbacks with a ray-triangle collision function I found on the internet and just iterated the same triangles I used for rendering. It worked remarkably well, and I would now crash into mountains and buildings instead of just passing through them. I could even land in the weirdest places!
There was a problem, though. My plane would explode with no apparent reason, and it was worst in the tunnel level. (Did I mention that Ace Combat is obsessed with tunnels? Every iteration has a tunnel level. AC3 even has a whole underground city level.) I ultimately tracked it down to a bug in TFXplorer’s handling of objects transitioning between terrain tiles.
These things never showed in EF2000/TAW because their terrain is, in direct comparison, extremely boring and feature-less.
Map
AC3 provides textures with overview maps of the levels. They are not nearly as sophisticated as TAW’s, but whatever! I was able to add them in no time.
Carrier landing
This afternoon, I found an aircraft carrier in one of the levels. It doesn’t render properly, but with some imagination it’s enough to hit it. I tried carrier landings for some time, and I even succeeded once! I also managed to take off again (with spinning up the engines while the tire brakes were still on). So the F-22 is officially carrier-capable …
Conclusion
This experiment showed a few places where the level API needed polishing, and it also lead to the discovery of a few bugs that would otherwise have been impossible to find (like all the places where the engine still calculates TFX units instead of meters). It showed me all the things I had mocked up long ago but never really bothered connecting with the rest. I will not pursue it with much energy, but I will keep it running until it becomes too costly to maintain.
Gotta take a few videos when I get that carrier render properly …
Re: Ace Combat levels
Wonderful!..IIRC that AC data was saved in VRML format, so you have a common renderer that can handle VRML and TFX's bytecode?
Re: Ace Combat levels
...and now I remember trying to take a tile from that AC data, and convert it to TFX's format.
https://community.combatsim.com/topic/2 ... nt=5195654
I didn't take it further, but that exercise gave me some small insight into the effort involved.
Those screenshots are stunning!
https://community.combatsim.com/topic/2 ... nt=5195654
I didn't take it further, but that exercise gave me some small insight into the effort involved.
Those screenshots are stunning!
Re: Ace Combat levels
Indeed! And I had completely forgotten your conversion exercise … it’s all back now, and I will answer a few open questions from that thread!
I did not render the VRML data here. I grabbed right into AC3’s game files (like we did with TAW) and read them from their native format.
I do, however, have a renderer that supports any kind of simple (textured and colored) triangle. You basically write the triangles to some kind of memory file and the engine will bring them to the screen. Very flexible approach that will also work well for VRML 🙂
Re: Ace Combat levels
Going underground
Some Ace Combat levels have underground structures. Not only is the Tunnel Vision level completely underground; Expo City famously has an underground airport. Here, underground does not only mean “below surface”, but actually “below sea level”.
The TFX games have no elements below MSL, so this uncovered another range of bugs related to negative coordinates. Most importantly, any object below MSL was immediately deleted as part of a clean-up pass: If an object or bullet falls through the ground – by numerical error or by gap in the level data, of which both AC3 and TAW have plenty – it will fall forever. Many such objects could saturate the CPU easily. So we clean up such lost objects by deleting anything below a certain minimal height.
The minimal height is now a central compile-time constant. I set it to -1024 m – this is easily enough for the lowest point on Earth’s surface (Dead Sea, -430 m) and in AC3 (-1000 m).
I won’t go deeper because air pressure grows exponentially the deeper you go, and funny things happen to jet engines and aerodynamics![Smile :)](./images/smilies/icon_e_smile.gif)
Anyway, with my next repo update we can
Some Ace Combat levels have underground structures. Not only is the Tunnel Vision level completely underground; Expo City famously has an underground airport. Here, underground does not only mean “below surface”, but actually “below sea level”.
The TFX games have no elements below MSL, so this uncovered another range of bugs related to negative coordinates. Most importantly, any object below MSL was immediately deleted as part of a clean-up pass: If an object or bullet falls through the ground – by numerical error or by gap in the level data, of which both AC3 and TAW have plenty – it will fall forever. Many such objects could saturate the CPU easily. So we clean up such lost objects by deleting anything below a certain minimal height.
The minimal height is now a central compile-time constant. I set it to -1024 m – this is easily enough for the lowest point on Earth’s surface (Dead Sea, -430 m) and in AC3 (-1000 m).
I won’t go deeper because air pressure grows exponentially the deeper you go, and funny things happen to jet engines and aerodynamics
![Smile :)](./images/smilies/icon_e_smile.gif)
Anyway, with my next repo update we can
- land on surfaces below MSL;
- shoot bullets below MSL;
- hit targets below MSL.
Re: Ace Combat levels
Looks great! Look forward to flying around the AC3 world without having 10 seconds to get get somewhere or destroy something. ![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
I already have AC7, so there's presumably also AC1,2,4,5 & 6.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
I already have AC7, so there's presumably also AC1,2,4,5 & 6.
Re: Ace Combat levels
Don’t forget AC0, which was arguably the best of them all. I missed it back then and only got if for my birthday this year. Haven’t played more than a few missions yet.
Re: Ace Combat levels
Introduction to Ace Combat 3’s General Data Layout
Place unpack_ac3 next to ACE.BPB and ACE.BPH and run it.
The extracted directories 5…65 contain missions. (As opposed to GUI data, airplane models, briefings, …) This is where I am interested in most. 5 and 65 are unused alpha/beta missions so it’s often best to ignore them. 6 is the first mission (Awakening) and they’re mostly legit until there’s beta stuff and odd fillers towards the end again.
Inside each mission directory (I think the game calls them packs internally) there is a number of files and sub-packs. Here is what I found out so far:
Currently, my tool can differentiate between 7 being a pack or a file in most cases, except for mission 12 One-Way Ticket (main pack 17). So don’t wonder why this file looks odd – the actual 7.dat starts a few bytes in and doesn’t go until the end.
Finding out if there is a flag for that would be a tremendous improvement so that I could remove quite a lot of workarounds from my code.
So, 7.dat (or 7/0.dat, for that matter) starts with this header:From the names AAA, BBB, Block13, … you can see that I understand almost nothing of the file. But the first four numbers are usually pretty low and the offsets are always ascending, with some sections having zero size in a few files.
The section denoted by wordsToObjects is an array of the following structure (length can be computed from the offset to the following section):As you can see, I know from type whether it’s a building or a ship or whatnot.
Then, I can use indexOrFF to look up in the other directories the 3d model to place. I don’t know what to do if this index is 0xFF (see what I wrote about the Bug Hunt mission and how I found out that these huge domes are animated – their indices are 0xFF for all but one dome!)
Lastly, x y z tell me where to place the model.
The coordinate system for placing objects is the following:
Things That Would Really Help Me
Positions of enemy aircraft and of player.
What I did so far: I searched the other sections of 7.dat of coordinates, but that wasn’t conclusive. There are some numbers that divide by 1000 but I couldn’t make sense of how to use them.
I watched AC3 gameplay videos and noted the altitude of the player spawning (the HUD shows feet). Then I looked for variations of this number: in feet, in meters ×16384, and so on. Also negative (because Y points underground!). Nothing found. May be in a different file?
The base altitude of the level.
This one is tricky. It seems like Namco hates positive Y coordinates, so whenever there is a tunnel entrance that goes a few meters below sea level, Namco shifts the coordinate origin of the terrain tiles so that no positive Y coordinates appear. E.g. the first mission Awakening has the (closed) doors to an underground airport in the center of the city, and these reach 256 meters down. So all coordinates in all tiles are shifted 256 meters up (or 1024 vertex units, for that matter). But now my altimeter shows the wrong altitude! It says 256 m when you’re flying sea level!
For some reason, AC3 knows how to compensate for this. But I don’t know how. It would be helpful to find that out so I can remove my workarounds/hacks. I don’t know if this is in 7.dat, in the terrain tile files, or in the sky file 0.dat, for that matter.
Sun position or daytime of the level
Now that I slowly introduce dynamic lighting into TFXplorer, I need the correct Sun/Moon position for AC3’s levels. Note that the game sometimes displays the Moon in place of the Sun, but never both, so there is likely one entry that is used for both.
I don’t know if this is in 7.dat, or in the unknown data of 0.dat, or somewhere else. I expect it to be either a vector (the PSX cannot use floating-point math, so usually three integers in range [-2048, +2047]) or an angle (unit unknown).
Place unpack_ac3 next to ACE.BPB and ACE.BPH and run it.
The extracted directories 5…65 contain missions. (As opposed to GUI data, airplane models, briefings, …) This is where I am interested in most. 5 and 65 are unused alpha/beta missions so it’s often best to ignore them. 6 is the first mission (Awakening) and they’re mostly legit until there’s beta stuff and odd fillers towards the end again.
Inside each mission directory (I think the game calls them packs internally) there is a number of files and sub-packs. Here is what I found out so far:
- 0.dat is a file with sky/sun colors (description here)
- 1.dat is a terrain tile map with 256×256 16-bit values (much like TAW’s tile maps). 0 means that there is no terrain at this point; values ≥512 have unknown meaning. All others are terrain tile indices into pack 2 after subtracting 1 from them.
- 2 is a pack with 3d models of terrain tiles. These are indexed by 1.dat as mentioned above.
- 3 is a pack with 3d models of objects that can rotate, e.g. planes and helicopters.
- 4 is a pack with 3d models of missiles/bombs.
- 5 is a pack with 3d models of objects that cannot rotate, like buildings and bridges.
- 6.dat ???
- 7.dat/7 is either the mission script or a pack that contains that script file. This is currently of most interest to me and details will follow.
- 8.dat ???
- 9 ???
- 10 ???
- 11 is a pack with TIM textures of terrain tiles and non-rotatable objects.
- 12 is a pack with TIMs of objects that can rotate.
- 13 is a pack with TIMs of missiles/bombs.
- 14 is a pack with TIMs of clouds and sun/moon.
- 15 is a pack with TIMs for the level’s overview map and in-game briefings.
- 16.dat is a file with sound samples in PSX SPU ADPCM format (container not yet fully decoded).
Currently, my tool can differentiate between 7 being a pack or a file in most cases, except for mission 12 One-Way Ticket (main pack 17). So don’t wonder why this file looks odd – the actual 7.dat starts a few bytes in and doesn’t go until the end.
Finding out if there is a flag for that would be a tremendous improvement so that I could remove quite a lot of workarounds from my code.
So, 7.dat (or 7/0.dat, for that matter) starts with this header:
Code: Select all
// Mission files define all objects and entities in a mission.
// • can be found at index [7] in a mission pack
struct MissionFile {
uint32_t numberOfAAA;
uint32_t numberOfBBB;
uint32_t numberOfCCC;
uint32_t numberOfDDD;
uint32_t wordsToAAA; // offset from the start of the file, in 4 B
uint32_t wordsToBBB; // offset from the start of the file, in 4 B
uint32_t wordsToCCC; // offset from the start of the file, in 4 B
uint32_t wordsToDDD; // offset from the start of the file, in 4 B
uint32_t wordsToBlock5; // offset from the start of the file, in 4 B
uint32_t wordsToBlock6; // offset from the start of the file, in 4 B
uint32_t wordsToBlock7; // offset from the start of the file, in 4 B
uint32_t wordsToBlock8; // offset from the start of the file, in 4 B
uint32_t wordsToObjects; // offset from the start of the file, in 4 B – buildings, ships, trains
uint32_t wordsToBlock10; // offset from the start of the file, in 4 B
uint32_t wordsToBlock11; // offset from the start of the file, in 4 B
uint32_t wordsToBlock12; // offset from the start of the file, in 4 B
uint32_t wordsToBlock13; // offset from the start of the file, in 4 B
};
The section denoted by wordsToObjects is an array of the following structure (length can be computed from the offset to the following section):
Code: Select all
// Types of objects in missions.
enum class MissionObjectType : uint8_t {
static_ = 0, // bridges, carrier decks, …
gndTgt = 1, // ground targets
ship = 2, // ships, submarines, …
airdrop = 3, // airdrop in “Enter Dision”
train = 4, // train in “One-Way Ticket”
sam = 5, // surface-to-air missiles in “Damage Control” (friendly ones?)
heli = 6, // can move a bit vertically and turn towards the player
debris = 7, // building debris in “The Orientation” after they collapsed with an animation
antlion = 8 // air-dropped Antlion tanks in “Reaching for Stars”
};
// Objects in mission files.
// • no AI; may move but only along simple, pre-defined paths
struct MissionObject {
uint8_t unknownA;
uint8_t unknownB;
uint8_t indexOrFF; // semantics depend on type
MissionObjectType type;
int32_t x; // meters × 16384
int32_t y; // meters × 16384
int32_t z; // meters × 16384
uint8_t unknownD[12];
uint8_t unknownE;
uint8_t unknownF;
uint8_t unknownG;
uint8_t unknownH;
uint8_t unknownI; // some kind of index?
uint8_t unknownJ; // some kind of index? “0xFF” if unused
uint8_t unknownK; // some kind of index?
uint8_t unknownL; // some kind of index? “0xFF” if unused
};
Then, I can use indexOrFF to look up in the other directories the 3d model to place. I don’t know what to do if this index is 0xFF (see what I wrote about the Bug Hunt mission and how I found out that these huge domes are animated – their indices are 0xFF for all but one dome!)
Lastly, x y z tell me where to place the model.
The coordinate system for placing objects is the following:
- coordinate origin is the center of the map
- Y is down towards ground; X/Z are North/East (I forgot which one exactly); surprisingly this is exactly what I picked for TFXplorer years ago
- coordinates are in 16384th part of a meter; terrain tiles have 512 m sidelength (in terrain meshes the vertex coordinates are usually in 25 cm)
- so every level with its 256×256 tiles is addressed via 32-bit integer ranging from -2^30 to +2^30, thus exactly filling the range of a 32-bit integer when computing offsets from the leftmost point to the rightmost and vice versa
- you will often find coordinates that are evenly divisable by 1000 or 10000; these are easy to identify in a hex editor and it seems like the designers really liked them
Things That Would Really Help Me
Positions of enemy aircraft and of player.
What I did so far: I searched the other sections of 7.dat of coordinates, but that wasn’t conclusive. There are some numbers that divide by 1000 but I couldn’t make sense of how to use them.
I watched AC3 gameplay videos and noted the altitude of the player spawning (the HUD shows feet). Then I looked for variations of this number: in feet, in meters ×16384, and so on. Also negative (because Y points underground!). Nothing found. May be in a different file?
The base altitude of the level.
This one is tricky. It seems like Namco hates positive Y coordinates, so whenever there is a tunnel entrance that goes a few meters below sea level, Namco shifts the coordinate origin of the terrain tiles so that no positive Y coordinates appear. E.g. the first mission Awakening has the (closed) doors to an underground airport in the center of the city, and these reach 256 meters down. So all coordinates in all tiles are shifted 256 meters up (or 1024 vertex units, for that matter). But now my altimeter shows the wrong altitude! It says 256 m when you’re flying sea level!
For some reason, AC3 knows how to compensate for this. But I don’t know how. It would be helpful to find that out so I can remove my workarounds/hacks. I don’t know if this is in 7.dat, in the terrain tile files, or in the sky file 0.dat, for that matter.
Sun position or daytime of the level
Now that I slowly introduce dynamic lighting into TFXplorer, I need the correct Sun/Moon position for AC3’s levels. Note that the game sometimes displays the Moon in place of the Sun, but never both, so there is likely one entry that is used for both.
I don’t know if this is in 7.dat, or in the unknown data of 0.dat, or somewhere else. I expect it to be either a vector (the PSX cannot use floating-point math, so usually three integers in range [-2048, +2047]) or an angle (unit unknown).
Re: Ace Combat levels
I'll just warm up with a few file checks on the files in some of the 7/ folders (there's a few with sub-directories, which I'm ignoring for now)
Anyway, I'd say the header (of 0.dat) contains another uint32_t after 'wordsToBlock13'
The number it contains can be odd, so unlikely to be a pointer.
pack6 404
pack7 568
pack8 505
pack9 996
pack10 4494
pack12 530
pack14 513
pack15 767
pack16 719
pack18 431
pack19 923
pack20 819
pack21 471
pack22 611
pack23 627
pack24 504
pack25 4257
pack26 740
pack27 647
pack28 658
pack29 433
pack30 889
pack31 625
pack32 722
pack33 877
pack34 1174
pack35 1355
pack36 838
pack37 373
pack38 327
pack39 237
pack40 1089
pack41 1208
pack42 930
pack44 106
pack45 900
pack46 632
pack47 141
pack48 1006
pack49 3422
pack50 1033
pack51 954
pack52 188
pack53 594
pack55 855
pack56 502
pack57 589
pack58 212
pack59 311
pack60 438
pack61 150
pack62 106
pack63 90
pack64 149
Anyway, I'd say the header (of 0.dat) contains another uint32_t after 'wordsToBlock13'
The number it contains can be odd, so unlikely to be a pointer.
pack6 404
pack7 568
pack8 505
pack9 996
pack10 4494
pack12 530
pack14 513
pack15 767
pack16 719
pack18 431
pack19 923
pack20 819
pack21 471
pack22 611
pack23 627
pack24 504
pack25 4257
pack26 740
pack27 647
pack28 658
pack29 433
pack30 889
pack31 625
pack32 722
pack33 877
pack34 1174
pack35 1355
pack36 838
pack37 373
pack38 327
pack39 237
pack40 1089
pack41 1208
pack42 930
pack44 106
pack45 900
pack46 632
pack47 141
pack48 1006
pack49 3422
pack50 1033
pack51 954
pack52 188
pack53 594
pack55 855
pack56 502
pack57 589
pack58 212
pack59 311
pack60 438
pack61 150
pack62 106
pack63 90
pack64 149
Re: Ace Combat levels
The offsets are stored in words, not bytes – i.e. 3 means 12 bytes. So there’s nothing against it being a pointer in principle; I’d rather determine this by checking if it’s always larger than the previous offset.
Regarding the time of day and sun/Moon position, the highest correlation I could find so far is one byte 65 bytes into the sky files (0.dat):
Code: Select all
byte +65 can have 11 values:
0:
18 A Canopy of Stars\0.dat
22 Target Acquisition\0.dat
23 Partners\0.dat
33 Casualties of War\0.dat
37 Archnemesis\0.dat
4 Paper Tiger\0.dat
43 The Prize\0.dat
45 Reality Distortion\0.dat
50 Resistance\0.dat
7 No Clearance\0.dat
1:
32 Geofront Attack\0.dat
47 Pursuit\0.dat
53 Sole Survivor\0.dat
8 Fragile Cargo\0.dat
2:
28 Claustrophobia\0.dat
3:
20 Soldier of Fortune\0.dat
29 Dilemma\0.dat
44 Utopian Dreams\0.dat
5 Broken Truce\0.dat
55 Tunnel Vision\0.dat
4:
6 Ghosts of the Past\0.dat
5:
35 The Orientation\0.dat
6:
1 Awakening\0.dat
10 Fates Intertwined\0.dat
11 Reaching for Stars\0.dat
12 One-Way Ticket\0.dat
14 Pawns in the Game\0.dat
15 Damage Control\0.dat
2 Bravado\0.dat
24 Tainted Peace\0.dat
25 Stratosphere\0.dat
26 Welcoming Committee\0.dat
27 Technology Transfer\0.dat
3 Enter Dision\0.dat
30 Betrayal\0.dat
31 Heart of the Serpent\0.dat
36 Liquidation\0.dat
38 Memory Error\0.dat
39 Electrosphere\0.dat
40 Power for Life\0.dat
41 Guardian Angel\0.dat
46 Counterrevolution\0.dat
51 Radio Silence\0.dat
52 Revenge\0.dat
56 outer space#0\0.dat
57 last enemy m3#0\0.dat
58 electrosphere#1 end-b\0.dat
9 Scylla and Charybdis\0.dat
7:
13 Bug Hunt\0.dat
16 Broken Wings\0.dat
17 Sphyrna\0.dat
19 ----\0.dat
21 Megafloat\0.dat
34 Geopelia\0.dat
48 Self Awareness\0.dat
49 Expo City Beta\0.dat
54 geopelia#1 end-a\0.dat
16:
42 Zero Gravity\0.dat
20:
60 Megafloat Beta\0.dat
22:
0 test map\0.dat
59 Expo City Alpha\0.dat
- 0 take place at night;
- 1 at night or undergroud;
- 7 during sunrise/sunset;
- 2/3/4 in fog/snow/heavy rain.
Also, while I could in theory derive the Sun/Moon elevation above horizon from it, it doesn’t tell me the compass direction of Sun/Moon.
Re: Ace Combat levels
Whoa, I need to get to grips with the terminology as I don't see the same values in the 65th byte of 0.dat.
If I open the file from the 42 folder which, according to that list is 'Zero Gravity', I'd expect 16...but it's not.
If I open the file from the 42 folder which, according to that list is 'Zero Gravity', I'd expect 16...but it's not.
Re: Ace Combat levels
42 is the mission number of Zero Gravity, but missions start at directory 5 in the data, so you must open 47/0.dat.
Edit: Even so, my designation differs from the official ones here. I will fix my dataset …
Edit: Even so, my designation differs from the official ones here. I will fix my dataset …
Re: Ace Combat levels
We should stick to this naming scheme: First the name of the directory in the game files, then the official mission title.The analysis then becomes
Code: Select all
5 Expo City Alpha (2)
6 M01 Awakening
7 M02 Bravado
8 M03 Enter Dision
9 M04 Paper Tiger
10 M05 Broken Truce
11 M06 Ghosts of the Past
12 M07 No Clearance
13 M08 Fragile Cargo
14 M09 Scylla and Charybdis
15 M10 Fates Intertwined
16 M11 Reaching for Stars
17 M12 One-Way Ticket
18 M13 Bug Hunt
19 M14 Pawns in the Game
20 M15 Damage Control
21 M16 Broken Wings
22 M17 Sphyrna
23 M18 A Canopy of Stars
24 Game Show
25 M19 Soldier of Fortune
26 M20 Megafloat
27 M21 Target Acquisition
28 M22 Partners
29 M23 Tainted Peace
30 M24 Stratosphere
31 M25 Welcoming Committee
32 M26 Technology Transfer
33 M27 Claustrophobia
34 M28 Dilemma
35 M29 Betrayal
36 M30 Heart of the Serpent
37 M31 Geofront Attack
38 M32 Casualties of War
39 M33 Geopelia
40 M34 The Orientation
41 M35 Liquidation
42 M36 Archnemesis
43 M37 Memory Error
44 M38 Electrosphere
45 M39 Power for Life
46 M40 Guardian Angel
47 M41 Zero Gravity
48 M42 The Prize
49 M43 Utopian Dreams
50 M44 Reality Distortion
51 M45 Counterrevolution
52 M46 Pursuit
53 M47 Self Awareness
54 Expo City Beta
55 M48 Resistance
56 M49 Radio Silence
57 M50 Revenge
58 M52 Sole Survivor
59 geopelia#1 end-a
60 M51 Tunnel Vision
61 outer space#0
62 last enemy m3#0
63 electrosphere#1 end-b
64 Expo City Alpha (1)
65 Megafloat Beta
Code: Select all
byte +65 can have 11 values:
0:
12 M07 No Clearance\0.dat
23 M18 A Canopy of Stars\0.dat
27 M21 Target Acquisition\0.dat
28 M22 Partners\0.dat
38 M32 Casualties of War\0.dat
42 M36 Archnemesis\0.dat
48 M42 The Prize\0.dat
50 M44 Reality Distortion\0.dat
55 M48 Resistance\0.dat
9 M04 Paper Tiger\0.dat
1:
13 M08 Fragile Cargo\0.dat
37 M31 Geofront Attack\0.dat
52 M46 Pursuit\0.dat
58 M52 Sole Survivor\0.dat
2:
33 M27 Claustrophobia\0.dat
3:
10 M05 Broken Truce\0.dat
25 M19 Soldier of Fortune\0.dat
34 M28 Dilemma\0.dat
49 M43 Utopian Dreams\0.dat
60 M51 Tunnel Vision\0.dat
4:
11 M06 Ghosts of the Past\0.dat
5:
40 M34 The Orientation\0.dat
6:
14 M09 Scylla and Charybdis\0.dat
15 M10 Fates Intertwined\0.dat
16 M11 Reaching for Stars\0.dat
17 M12 One-Way Ticket\0.dat
19 M14 Pawns in the Game\0.dat
20 M15 Damage Control\0.dat
29 M23 Tainted Peace\0.dat
30 M24 Stratosphere\0.dat
31 M25 Welcoming Committee\0.dat
32 M26 Technology Transfer\0.dat
35 M29 Betrayal\0.dat
36 M30 Heart of the Serpent\0.dat
41 M35 Liquidation\0.dat
43 M37 Memory Error\0.dat
44 M38 Electrosphere\0.dat
45 M39 Power for Life\0.dat
46 M40 Guardian Angel\0.dat
51 M45 Counterrevolution\0.dat
56 M49 Radio Silence\0.dat
57 M50 Revenge\0.dat
6 M01 Awakening\0.dat
61 outer space#0\0.dat
62 last enemy m3#0\0.dat
63 electrosphere#1 end-b\0.dat
7 M02 Bravado\0.dat
8 M03 Enter Dision\0.dat
7:
18 M13 Bug Hunt\0.dat
21 M16 Broken Wings\0.dat
22 M17 Sphyrna\0.dat
24 Game Show\0.dat
26 M20 Megafloat\0.dat
39 M33 Geopelia\0.dat
53 M47 Self Awareness\0.dat
54 Expo City Beta\0.dat
59 geopelia#1 end-a\0.dat
16:
47 M41 Zero Gravity\0.dat
20:
65 Megafloat Beta\0.dat
22:
5 Expo City Alpha (2)\0.dat
64 Expo City Alpha (1)\0.dat
Re: Ace Combat levels
Great, thanks!
I interpreted your statement "the highest correlation I could find so far is one byte 65 bytes into the sky files (0.dat):" as it being the 65th byte, but in fact it's the 66th byte (ie index 65) so I didn't see any correlation at all.
Now it works.![Smile :)](./images/smilies/icon_e_smile.gif)
I interpreted your statement "the highest correlation I could find so far is one byte 65 bytes into the sky files (0.dat):" as it being the 65th byte, but in fact it's the 66th byte (ie index 65) so I didn't see any correlation at all.
Now it works.
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: Ace Combat levels
… and that’s part of the mystery. I’m pretty sure these two values form one 16-bit value. Maybe we should collect all the 16-bit values and compare *those*.
Re: Ace Combat levels
The unknown stuff at the beginning of the sky file (0.dat) is mostly signed 16-bit integers. Very even numbers there like 28,000 and -24,600.
The values at +12 B from the beginning are especially suspicious: Three 16-bit integers with the middle one often being negative smells totally like an XYZ coordinate. If I just knew of what!
The values at +12 B from the beginning are especially suspicious: Three 16-bit integers with the middle one often being negative smells totally like an XYZ coordinate. If I just knew of what!
Re: Ace Combat levels
Note to self: The container format for Air Combat, Ace Combat 2, and Ace Combat 3 is now documented on https://web.archive.org/web/20220829221 ... offset.htm
It seems like this kind of format was used in a lot of games, and they call it dot1 due to the file extension .1 in some games.
It seems like this kind of format was used in a lot of games, and they call it dot1 due to the file extension .1 in some games.
Re: Ace Combat levels
Regarding "byte 65" in the sky 0.dat.
I think this is part of a set of 3 16bit integers, ie bytes 0x40/41, 0x42/43, 0x44/45
Here, we have the directory number, the 3 words and a couple of deltas between the values before the mission name.
No point in fancy formatting just yet...
EDIT: The next 6 bytes look like they should be considered as 3 related integers as well.
I think this is part of a set of 3 16bit integers, ie bytes 0x40/41, 0x42/43, 0x44/45
Here, we have the directory number, the 3 words and a couple of deltas between the values before the mission name.
No point in fancy formatting just yet...
Code: Select all
5 5734 5734 5734 0 0 Expo_City_Alpha_(2)
6 1761 1679 1597 -82 -82 Awakening
7 1761 1679 1597 -82 -82 Bravado
8 1761 1679 1597 -82 -82 Enter_Dision
9 245 286 245 -41 41 Paper_Tiger
10 819 819 819 0 0 Broken_Truce
11 1024 1024 1024 0 0 Ghosts_of_the_Past
12 245 286 245 -41 41 No_Clearance
13 286 286 245 -41 0 Fragile_Cargo
14 1761 1679 1597 -82 -82 Scylla_and_Charybdis
15 1761 1679 1597 -82 -82 Fates_Intertwined
16 1761 1679 1597 -82 -82 Reaching_for_Stars
17 1720 1679 1638 -41 -41 One-Way_Ticket
18 1843 1064 491 -573 -779 Bug_Hunt
19 1761 1679 1597 -82 -82 Pawns_in_the_Game
20 1761 1679 1597 -82 -82 Damage_Control
21 1843 1310 860 -450 -533 Broken_Wings
22 1925 1310 614 -696 -615 Sphyrna
23 245 286 245 -41 41 A_Canopy_of_Stars
24 1925 1310 614 -696 -615 Game_Show
25 819 819 819 0 0 Soldier_of_Fortune
26 1843 1310 860 -450 -533 Megafloat
27 245 286 245 -41 41 Target_Acquisition
28 204 204 204 0 0 Partners
29 1638 1638 1638 0 0 Tainted_Peace
30 1720 1679 1638 -41 -41 Stratosphere
31 1761 1679 1597 -82 -82 Welcoming_Committee
32 1761 1679 1597 -82 -82 Technology_Transfer
33 614 614 614 0 0 Claustrophobia
34 778 819 819 0 41 Dilemma
35 1761 1679 1597 -82 -82 Betrayal
36 1761 1679 1597 -82 -82 Heart_of_the_Serpent
37 409 655 573 -82 246 Geofront_Attack
38 163 204 204 0 41 Casualties_of_War
39 1843 1679 1597 -82 -164 Geopelia
40 1310 1269 1228 -41 -41 The_Orientation
41 1761 1638 1515 -123 -123 Liquidation
42 245 286 245 -41 41 Archnemesis
43 1761 1679 1597 -82 -82 Memory_Error
44 1761 1679 1597 -82 -82 Electrosphere
45 1720 1679 1638 -41 -41 Power_for_Life
46 1761 1679 1597 -82 -82 Guardian_Angel
47 4096 4055 4014 -41 -41 Zero_Gravity
48 245 286 245 -41 41 The_Prize
49 819 819 819 0 0 Utopian_Dreams
50 245 286 245 -41 41 Reality_Distortion
51 1761 1679 1597 -82 -82 Counterrevolution
52 409 655 573 -82 246 Pursuit
53 1843 1310 614 -696 -533 Self_Awareness
54 1843 1761 1679 -82 -82 Expo_City_Beta
55 245 286 286 0 41 Resistance
56 1761 1679 1597 -82 -82 Radio_Silence
57 1761 1638 1515 -123 -123 Revenge
58 409 655 573 -82 246 Sole_Survivor
59 1802 1679 1597 -82 -123 geopelia#1_end-a
60 901 1146 901 -245 245 Tunnel_Vision
61 1761 1679 1597 -82 -82 outer
62 1761 1679 1597 -82 -82 last_enemy_m3#0
63 1761 1679 1597 -82 -82 electrosphere#1_end-b
64 5734 5734 5734 0 0 Expo_City_Alpha_(1)
65 5242 5120 4956 -164 -122 Megafloat_Beta
Re: Ace Combat levels
Looking at the sky 0,dat files again today, and have formatted them in a way to help compare, but not seeing much pattern.
The files are identical for M31,M46 & M52 with that column of light.
M24 and M29 with that icy landscape are also identical, but not with M10 or M43.
M35 & M59 differ by a few bytes, but the missions look similar. I thought that the last part of each file may describe stars, but apparently not.
Anyway, I need to rearrange things to match up with the previously known info which I've ignored so far.
The files are identical for M31,M46 & M52 with that column of light.
M24 and M29 with that icy landscape are also identical, but not with M10 or M43.
M35 & M59 differ by a few bytes, but the missions look similar. I thought that the last part of each file may describe stars, but apparently not.
Anyway, I need to rearrange things to match up with the previously known info which I've ignored so far.
Re: Ace Combat levels
👍
I just wanted to throw in that there is a totally different approach that would likely yield results more quickly: Change the bytes, start the game with the modified file, and see what happens.
But this is likely harder than one would think due to the ULZ compression. I can’t be bothered to work out how to properly handle an emulator either ☹️
Maybe converting these numbers to 3D vectors before looking at them could help?
I just wanted to throw in that there is a totally different approach that would likely yield results more quickly: Change the bytes, start the game with the modified file, and see what happens.
But this is likely harder than one would think due to the ULZ compression. I can’t be bothered to work out how to properly handle an emulator either ☹️