Hellcat cockpit in the WC2 style

I hope I'm not sidetracking the people doing the important ship and mission editing when I point out these obscure engine features.

However, this hasn't stopped me from learning how to edit these hotspots. They're defined in OPTIONS.V00 (which also contains the graphics). I'm afraid I'm not very familiar with how to describe low-level editing like this, so please let me know if I should be using any particular formatting conventions.

Within OPTIONS.V00 you'll find 6 uses of the text "FORM", followed by 4 bytes (looks like the length of the following structure), followed by "HOTRSTRC", some more bytes, then "FORM" again, 4 more bytes (length again), and "HTXTSYMB". The 6 such blocks, in order:

1. Non-Concordia menu (starts at 8A5E hex)
   
2. Non-Concordia save/load (starts at D012 hex)
   
3. Concordia menu (starts at 141CA hex)
   
4. Concordia save/load (starts at 1877E hex)
   
5. Planet menu (starts at 2087C hex)
   
6. Planet save/load (starts at 26FA6 hex)

Let's look at the first "FORM" (Non-Concordia menu), starting at 8A5E.

The "HOTRSTRC" at 8A66 defines the hotspot areas - both clickable and (for "View storyline" and "Fly mission"), the location where the replacement graphics appear. The first 4 bytes seem to be another length. I'm not sure what the next two bytes do, but they have the same value (0A and 00) in every "HOTRSTRC". After that, there are 4 of 10 bytes, defining the 4 hotspots in this screen. These are 5 little-endian words, in order:

1. Left edge
2. Top edge
3. Right edge (inclusive, so the 51-pixel-wide "Fly mission" graphic goes from 131 (hex 8300) to 182 (hex B600).
4. Bottom edge (inclusive again)
5. Index

What does that "Index" do? These are numbers from 1 to 4, defining:

1. The index in the following "HTXTSYMB" list where the hotspot text comes from.
   
2. The graphic replacement used, where one exists.
3. The actual place the game takes you. (1 = Fly mission, 2 = View storyline, 3 = Save/Load, 4 = Exit to DOS).

There are 10 bytes (00 00 00 00 3F 01 C7 00 00 00) for every single HOTRSTRC resource. I can't work out what these do. I've changed them all to 00 or FF without obvious effect.

Note that this means that hot spot areas may not be defined in the same order as the associated text. In this case, they turned out to be, in order, 4 (Exit), 3 (Save/Load), 2 (View storyline) and 1 (Fly mission). Torment your friends! Swap the 04 at 8A7C with the 03 at 8A86, and the airlock will act as Save/Load while the panel next to the bunk will exit. The popup text will give the game away, but you can fix that too...

Amazingly, it's possible to add index 5, and associated text, and it will display correctly when you mouse over it. However, clicking on it does nothing - which is an improvement on my predicted result, where I fully expected the game to crash. Hotspots with index 0 cause severe lag when moused over and do nothing when clicked.

Putting it all together, here are hotspots moved to the screen corners, with modified text.


Some limitations:

1. The game redraws a special background slice in the space where the "subtitle" text appears. This means that you can't have custom door graphics appearing in that part of the screen - see what happened when I put the "storyline" hotspot there. It would be logical if the 10 unknown bytes define this area's placement, but they don't appear to do so.
2. The top-left corner of the replacement graphic has to be the top-left corner of the hotspot. You can't, say, have the room lights turn red when the mission briefing door is open.
   
3. My custom text invovled shortening the other text. Changing the length of the "HTXTSYMB" resource would involve changing multiple length definitions throughout this file. I'm assuming that someone has existing documentation on how to insert data into these files and update all the lengths and offsets?

What can we do with this?

1. If the tools for swapping out graphics can be applied to OPTIONS.V00 without damaging its non-graphic resources, we can swap in a whole new carrier interior, with its own layout.
   
2. At a minimum, we can replace the 3 hotspot screens offered by WC2. Hopefully the campaign or mission files have a byte somewhere which selects one for each mission.
3. It's just possible that we can add a 4th or further screen and resources to OPTIONS.V00, and select it from the campaign or mission as before. Imagine having each "Fly mission" hotspot be the fighter for that mission sitting on the flight deck, for example. (No, I don't see a way to allow fighter selection through hotspots. Sorry.)

Was this worthwhile? Probably not. There's really no point messing with the interiors to show a new carrier until we can confidently edit the missions and ships to have us flying off a new carrier. Still, it's here for when the time comes.

Final observation: why does the "Fly mission" door appear to lead to the debriefing room on the Tiger's Claw? No room in WC2 looks like that...

 

Great, thanks! Looking forward to it

On my side, i managed to finish my script in order to handle stats, and managed to implement Q's stats on the Hellcat. It has a nice feel to it (although i'll play a bit more tomorrow and compare it with a few other ships in some scenarios). The guns are closer to each other than on most other WCA ships, since they are nose mounted, so it does give it a bit of a "shotgun effect", as anything that gets near your line of sight is likely to get damaged by all bolts. This was more difficult to happen in a ship like the Sabre, for instance, which had the guns further apart.

Then again, neutrons and mass drivers are shorter range guns, so you might need to get a bit closer than usual. But, if they're outside the range of your guns, you can always switch to missiles.

Anyway, I need to tweak the cockpit just a bit. It turns out, the cockpit does not have the icon for the Neutron Gun, so once I changed the gun type, it stopped appearing. I need to include an icon for it (either reuse the icon from another gun, or grab it from the Crossbow, although it is a bit on the wide side)

Other than that: engines. Made some progress on this. I suspect i'm going to have to go back to the 3D model and compute 2D projections from the 3D coordinates of the engines. At this point, i'm fairly sure that the game needs 2D engine coordinates for each of the image angles, but I'm currently working on a script for testing this theory.

Also, the chunk i'm looking at because of the engine exhausts might be related to the symmetry issue we've been discussing, so i'll be sure to be on the lookout for something suspicious. I'll compare with the other more "unusual" ships and see if a pattern emerges.

Dondragmer: no sidetracking at all, that's some nice information, thanks! The format you describe seems to be standard EA IFF format, which is widely used in the more recent WC games (WC3, WC4, WCP), but apparently also used a bit in WC2. The best approach may be to "decompile" the IFF file to text, change it, and reassemble it.

If you do any more research on this, please do let us know!

The current tool should be able to swap out the graphics from options.v00, so that's a possibility.

 

I always was impressed by the way that the exhausts in WC1 and WC2 displayed independently - so yes, it's hardly surprising if it's fiddly to get them positioned right.

Looking at some specifications on IFF, you're quite right, and it's the same format used SERIES.S??, CAMPAIGN.S?? and GAMEFLOW.S??.

If I understand the specification, a file that uses IFF for its outermost wrapper should start with a 4-byte chunk identifier, and every other chunk identifier should also be 4 bytes. The WC2 files start with a scatter of other data, with FORM identifiers scattered through them. Is the outer wrapper still the format used by the VGA files?

Where a FORM appears, it is followed by a 4-byte big-endian length, and often inner layers of data in IFF-style format as well. Chunks the aren't FORM or SYMB have 8-byte chunk identifiers, which is not consistent with the Amiga version of IFF but easy enough to spot.

Also, the 4-byte chunk lengths are big-endian (conforming to the Amiga IFF specification), some of the other numbers are little-endian. Genius!

Just browsing with a hex editor, I can't see any sign of IFF chunks in the Academy files. Two interesting files that are in WCA are "HOTRECT.PAK" (presumably the coordinates for hotspot rectangles in the interface) and "DISPLAY.PAK" (just because it's so huge). However, there is no obvious text in either file. I seem to recall previous discussion about how WC1 compressed some of its files, and the first step towards editing that was to "unpack" MODULE.000. For people familiar with existing Wing Commander compression algorithms, are these "PAK" files using anything familiar?

 

Unlike the later games, the FORM data is wrapped inside a VGA container, yes. The instance (in WC2) where I encountered FORM data was on animation sequences (ex. JAZZRESC.V00), where there's a FORM PAL CMAP defining a new palette at points of the animation.

(this is actually very interesting, since it is not so different from WC3 FMV in that regard, it also changes palettes at keyframes).

Yep, the data is compressed with a form of LZW.

I'm attaching to this thread both files in uncompressed form. HOTRECT.PAK does seem like it could have some sort of coordinates, although it doesn't follow the IFF format. DISPLAY.PAK has sprites for the rotating objects in the Simulator console.

Hope it helps!

As an aside, I managed to fix the missing cockpit neutron gun, so i'm continuing to document the engine data. Hopefully i'll be able to make some more progress this weekend.

 

That's actually a very interesting idea. If polygon-based 3D did not take off the way it did, I wonder if other approaches would have been considered. For example, imagine WC1 with terrain support. A hybrid sprite / voxel engine (essentially expanding the WC1 engine with a voxel component) could have been very interesting, with sprites being used for fighters / capships as usual and voxels being used for terrain (not unlike Commanche Maximum Overkill). I'm guessing of course, but i think it could have worked very well!

Anyway, research on the engine data is continuing. I think i managed to locate the exhaust coordinates in there, but there's still a lot of unknowns that I need to solve befor I am able to generate a new chunk. I suspect it will still take me a few days to figure things out.

In the meantime, however, since the Hellcat already has stats, i thought it would be fun to upload what I have so far, so you could take the ship for a ride and see how it feels in WCA. Just keep in mind that the engine exhaust placement is not final, and still has to be adjusted. As for the VDU guns, i ended up changing the gun icons to the WC2 mass driver icon, for both the MD and Neutron guns. The Neutron gun icon of the crossbow was just too wide. Plus, this helped "unclutter" the cockpit area a bit. I think the end result is good!



You can download it at the link below, comments and suggestions are welcome!

http://hcl.solsector.net/HellcatWCA.zip

(edit: at this time, the Hellcat replaces the Wraith, so back-up your files so you can get the Wraith back when you're done)

 

I'm a little late seeing this, and nothing constructive to add - but just wanted to say this is absolutely freaking fantastic. One of the most interesting and potentially exciting updates of the year. I love seeing ships from different Wing Commander ages flying alongside each other, and the job you've done on this Hellcat is good enough to make it slot into WC2 seamlessly. I cannot stop looking at that cockpit.

It really is as good a job as Origin could do had the Hellcat been introduced in WC2.

Will be watching this post like a hawk. Superb.

Well done, the both of you!

 

Still wow!

Please continue the technical discussions, they are so interesting. I love reading about byte orders and so on, it's fascinating!

Quarto: I love your insights regarding Game Design. I think, it's true, that something was lost during the change to 3D. When I am looking at Rayman Legends or other 2D-titles, I can't imagine how good 2D-titles could have looked by now, if more developers had stayed on that path.

 

Indeed, we need some side and rear views for the cockpit! That's something we discussed a while back but I think we kind of forgot about. Hopefully, Howie will be able to come up with some amazing art for those views, i'm really looking forward to that!

I think i have the engine chunk more or less figured out by now. To summarize, the game has a number of engine sprites, coded at representing different angles... and for each ship angle, the chunk needs to define which engine bitmap to use, coordinates, a scale factor and a rotation factor for the engine bitmap. So this really means the game has to calculate very little (i sort of expected the game to calculate a few things, which flame sprite to use based on the ship angle for instance, but even that is encoded in the ship file). This approach makes sense though, given the available computing power in 1993: pre-compute as much as you can and keep the game logic simple and fast.

Good stuff! This means i'll need to go back to the WC4 IFF file, get the 3D coordinates for each engine, and do the necessary calculations. I'll try to play with the data a bit in the following days after work hours!

 

It looks nice and flies quite well. I like the loadout and stats you went with--it's got just a touch more weapon power, shields, and armor than the Rapier while being just a little slower (speed in between the Rapier and the Sabre). Giving it only short-range guns and thus forcing it to get in close (and expose itself to enemy bomber turrets and the neutron guns on Grikaths and Sathras, which makes the added bit of shields and armor feel necessary) keeps it from feeling overpowered compared to the Rapier and Sabre.

 

Funny you should mention Comanche Maximum Overkill. Apart from the voxel terrain, it did the multi-part bitmaps trick. It's most obviously used to have moving rotors on the helicopters, including the two counter-rotating rotors on the Kamov Ka-50 "Werewolf".


The tanks and missile launchers also share a base while placing different rotating turrets on top. No doubt the generic base infuriated some afficionadoes of tracked military hardware, but it was good use of storage by a game that originally shipped on floppy disks.


(Actually, these pictures are from Werewolf vs Comanche / Comanche 2.0. It is very similar to Maximum Overkill, although the reflection effects and ability to fly the Werewolf are new. The tanks and missile launchers do not helpfully spin their turrets like this; for the screenshots, I swapped the helicopter fuselage/rotor graphics with the tank base/turret graphics.)

 

Just flew a mission, very nice! It didnt seem too strong due to the limited gun energy and short range of the guns. Question: those are the standard neutron guns, not the turret neutron guns, right?

 

Hey that's awesome! I could definitely imagine Wing Commander sub-components implemented like that in a fake-3d engine. And the more I think about it, the more I'm convinced that a voxel-based terrain would have worked very well in a WC2-like engine.

Glad you liked it! Yes, those are the standard neutron guns, not the turret ones.

(As an aside, going back to the topic of full-angled vs half-angled ships: I initially suspected that the same chunk that contains the engine data might contain some kind of information related to the number of sprites the ship has... but that doesn't seem to be the case. So, I'll probably expand my search to a few unknown bytes on the stats chunk and even the EXE itself, to try and figure how the game can tell that a ship is supposed to have 37 sprites or more...)

 

Just a quick follow-up on this: after experimenting a bit, it turns out there's a byte on the stats chunks that seems to have a direct influence on how the angles are interpreted. This is good, as it means this functionality is most likely not hardcoded into the EXE as special cases for a couple objects

This makes sense: ships have usually 41 chunks, with the first 37 being image angles and the 39th being always the stats. When they have less angles, the header defines sprites up to number 37 as being zero-length (case of the Human Starbase). For Ayer's Rock, sprite angles resume at number 42, behaving more or less as an "extension" of the more usual format.

Very interesting!

I still haven't quite figured out how the game determines how many rx / ry angles the ship has, as both Ayer's Rock and the Human Starbase share the same flag... so, i'm guessing there should be a few more bytes on the stats chunk defining this. With some luck, that will be the case, and we can start working on asymmetrical ships

On the engine encoding front: i have adapted a few scripts for handling WC2 ship engines, so I am starting my encoding experiments. Hopefully i'll have more news on this soon!

 

You've received plenty of compliments already, but allow me to add to the chorus. This is fantastic work! Looking forward to seeing other ships being added.

 

Hi all, I have an original WCA install (not from GOG), and I also have the mod installed that added the Kamekh and Fralthra to the game. I have taken the two posted files and installed them, and oddly seen absolutely no effect on the game. The Wraith is not replaced and still works fine. Any thoughts on why that might be?
Running in dosbox 0.74.

Thanks in advance.

 

Make sure you unzip the files into the Gamedat folder, that should do it.