Short update:
No new release yet, but I am just working on some awesome stuff.
Well, developers will find it awesome.
I do, at least.
As some of you might have found out on their own through the years, working on fan projects may become tedious.
At first it's all exciting and new and you learn so much new stuff and you have so many great ideas.
But then, even fan projects consist of daily routine. (just 17 more ships to work on, only 5 scenarios to write, etc...)
It's more or less the same with programming.
To be precise, converting binary files from their binary form to something usable and displayable is amazing at first:
"Wow, look at all those dialogs, with all branches! And here, you see that 'Spirit' string? That's the gal from the game. And it's her name, right inside my application. Directly from the game files! And there ..."
I think you got it.
But after mapping file 1, you map file 2 and then file 3.
And it's all the same. Different content, but same algorithm.
Once you can read all the files, you're not done. Oh no, sir.
You have to be able to generate such binary files as well.
You want your campaign not only to be visible on some sleazy website, you want to play it (you know which site I'm talking about).
So every single binary file which has been read, now has to be written.
So all the same conditions, loops, variables and constants again.
Just the other way around. Going out instead of coming in. For every single file.
And that's exactly why I have come up with something different.
I'm currently working on a mapping library, which allows me (and you, but so far it's all about me) to define properties and offsets in a mapping file.
Some reader algorithm then uses the offsets defined in that mapping file and fills it into some shiny new object inside my application.
The mapping file for the savegames looks like this:
Code:
class=test.Wc1Savegame
size=828
property=name,offset=0,length=16
property=occupied,offset=17
property=scoreboardEntries[],mapping=savegame_scoreboard_entry,offset=18,times=8
property=bronzeStars,offset=364
property=silverStars,offset=365
property=goldStars,offset=366
property=goldenSun,offset=367
property=mission,offset=381
property=series,offset=382
property=pilotStatus[],offset=392,times=8
property=ace1,offset=408
property=ace2,offset=409
property=ace3,offset=410
property=ace4,offset=411
property=day,offset=412
property=promotion,offset=420
property=victory,offset=424
property=campaign,offset=426
That scoreboardEntry property itself has a submapping, which is defined in another file:
Code:
class=test.Wc1SavegameScoreboardEntry
size=38
property=name,offset=0,length=14
property=callsign,offset=14,length=14
property=unknown1,offset=28
property=rank,offset=30
property=sorties,offset=32
property=kills,offset=34
property=unknown2,offset=36
Look, ma! No code! It's all declarative!
The programmatical approach took about 80 lines of code. The declarative took about 20. And: the mapping file can also be used by the writer, which would be another 80 lines of code in Java.
The "class" in the first line defines the Java class I'm actually working with in my project.
Every property in the mapping file exists as property in that Java class.
Some loops and some ifs take care of transporting the bytes into the object. And back again.
And, it already works (find the code
here, if you're so inclined).
Problem still is, that I have not yet been able to identify every single bit.
So the mapping library still lacks the possibility to conveniently handle "unknown" data (eg fill it with zeroes, fill in some pre-defined bytes, etc).
The game already shows the titles of the savegames in the barracks, but loading one crashes the game.
But the concept works and I'm sure this will help the project to stay alive in the long term.
Less tedious tasks means more time for the awesome stuff.
So much for that (not so) short update.
.