Wc1 editing and new missions

Nearly finished the new interface screen. Looks a lot neater, ordered and manages to fit a lot of relevant info on the screen at once.
Done 50% of the pseudo code for the re-code and know how I'm going to handle most of the data.
I'm feeling that this should go pretty smoothly (as an experienced coder, I should know better than that).

Then it's on to the briefings/debriefings and finally (if doable) the campaign file.

I'm moderately excited!
 
That's more than moderately exciting. I can foresee the creation of campaigns bring created post WC1 and pre WC2 if this gets off the ground. :)

Looking forward to seeing future releases!

How about between-mission bar conversations? Are you looking at being able to edit those as well?
 
Yep, those should be pretty easy.
The ones that are baking my noodle a little at the moment are the debriefings, as there is a lot of conditional branching in them.
Coding took a weeks hiatus, as I spent a week away with my fiancee.
The Pseudo code is looking nice, but for once in my coding life I want to make 100% sure this works on paper, before I code anything at all.
 
Well, well. I go away for a while to do mortgages, weddings and all that pesky life stuff and I come back to find that this made the CIC front page!
Cor blimey, eh guv?

Well that being the case,I should say something about the project. It is and has been on hold for all of the reasons mentioned above. As I have said before, I need a block of time with no other creative or social distractions. That's the bad news.
The good news is that me and the missus-to-be should be completing on our mortgage at the end of May (or therabouts). What that means is that by going from living with 6 mates (not to mention numerous regular drop-ins) to just the other half, who spends much of her time marking and lesson planning, I will be actually have this time!

So I'm not going to make any bold statements at this time, I'm just saying that movement is hopefully imminent (after a brain frying stag weekend in Amsterdam!).

What I have done is complete the project code plan and make some new screens...

The new main screen...

newscreen.jpg


Much more ordered and it uses space much better, allowing me to have more info on screen at once.
The ship slots are in one column on the right. The main screen will hold visuals like the nav map and the briefing screens.
The big gap on the right will hold specific control layouts for editing campaigns, navs, ship data and briefings. An example of this is the screen below...

sidescreen.jpg


So there you go. Not much, but something.
I apologise for the lack of progress. I'm a little embarrassed at how long this is taking. The teenage coder in me is shaking his head.
 
I haven't looked into that, but I would assume that the WC2 files work in a similar way, so that could be something to look at once this is done.
 
WC2 works pretty similarly, though not identically - so, it shouldn't take too much work (especially since you can always look at the source code for HCl's editors to compare them).

One interesting detail - in WC2, you can only have 16 ships, compared to WC1's 32 ships. Isn't it amazing to think that some of the most extraordinarily difficult missions in the series were done in a game that could never the player up against more than 14 enemies, and usually no more than 10? No wonder that when we dragged the afterburner fuel values across from WC2 to Standoff, everyone complained about not having enough fuel :p.
 
To be fair, a Sartha with three particle cannons is more intimidating than a ship that can only turn left.
 
Flashpoint said:
Nearly finished the new interface screen. Looks a lot neater, ordered and manages to fit a lot of relevant info on the screen at once.
Done 50% of the pseudo code for the re-code and know how I'm going to handle most of the data.
I'm feeling that this should go pretty smoothly (as an experienced coder, I should know better than that).

Then it's on to the briefings/debriefings and finally (if doable) the campaign file.

I'm moderately excited!
Click to expand...

hi, Norton tells me wce1.exe is a virus.. may you give me the MD5 to verify its integrity?
I would use the editor to check carefully the enemy ships on each mission and then fix some errors in wcpedia...
 
Sad that there seems to be no public progress for some time...

Would it be possible to release the (pseudo)-code to the public, so maybe another wingnut could pick it up... ?
 
The project stalled for a few reasons.
First was the rewrite of the code. The main program started out simply as an exploratory poke at the MODULE.000 file, to see what I could find and see if an editor was possible. It grew as I tacked stuff on and ended up with the interim release that is available on here. There were numerous problems with the code, due to the way I had coded it, not least the fact that it references the loaded file directly on each screen, rather than pulling all of the data into variables to be accessed at any time (for example, when you look at a nav map, it gets the data then and then has to release that data when you go to the next screen. Same for the ships). The reason this is unworkable in the long run, is due to the way the data is used by the game.
For example, all navpoints on any map are relative to the position of the Tigers Claw. That is position 0,0,0 (x,y,z) NOT the top left of the map, as might be suspected. It turns out that the nav maps in game are done adhoc by the game itself. If I change the position of a nav in the data, the game compensates automatically.

That's pretty neat, but it goes further. Nav 1 is relative to the TC (Tigers Claw), then any ships tied to that nav are positioned relative to that nav. It then goes even deeper. The wing leader of any ships at a nav are relative to that nav and their wingmen are relative to the wingleader.
This was a problem I knew I was going to fix and it all came to a head when putting the asteroid and minefields into the maps. I realised I no longer had the info on size or density available. That's when I started the rewrite.

That's when I hit the biggest block and one I have yet to overcome (though I haven't really devoted much time to it for a while now).
I realised that if I am going to build new missions with this, I need to know how the module.000 file specifies what a significant ship is. What I mean by that is if your mission is to save an Exeter, I regard that as a significant ship and that ship must be flagged in some way by the module.000 file and referenced by the game.
This is a riddle I have been unable to solve. Without an answer to this the whole project is doomed to fail.

I'm currently learning Python for a few projects at work, so maybe that will end up being a better language as I have heard it is good for this type of work. I'd love to have another crack at this but I would not hold your breath.

That said, if anyone knows anything about the missing piece of the puzzle (along with the brief/debrief branching code), it'd help a lot if they could show me where I'm going wrong, or at least where to look.
 
Thanks for the deep insights.

As already mentioned in another thread, I have started to work on creating an editor myself.
I plan to display unknown bytes along the known ones and also to make them editable.
This way, it might be easier to discover new information by trial and error.
Especially for those, who are afraid (or unaware) of hacking resource files via some hex editor.
 
Okay, one of the biggest challenges you will face if you want to make new missions is the briefings.
When WC1 came out the size of files was very important, they needed to be as small as possible. The upshot of this is that there is no spare space between lines of briefing dialogue.
For example, if in one part of the briefing a character just says 'Yes, Sir', you only have that much space to play with if you want to change the text. You also only have a small amount of the phonetic text directly afterwards. There is also little space between each briefing in the file. This is problematic when you want to put in a line longer than 'Yes Sir', into the middle of a briefing or have a longer briefing than there was to begin with.

There is a potential way around this though. ZomegaZ did a way better job of decoding those files than I did. It seems that the file is made up of tables and blocks, whose position within the file is referenced in the table.
For example...

Table 1 (main file table)
Character chat----------location within the file
Mission briefing--------location within the file
Mission debriefing-----location within the file

Table 2 (Character chat)
Enyo 1------------------location
Enyo 2------------------location
etc.

(This is not a strict example, just to give you an idea)

So in theory it is possible to put in what you like and have an editor keep track of where the new briefing starts. The issue here though is that if you're editing a mission in the middle of a campaign and it is longer than the original briefing, you would have to get your editor to move the data that follows onwards, to create space and adjust all of those mission locations in the parent table.
It would be much easier to do this if you were writing a whole new campaign.
Another consideration is that I believe that each has data in the first few bytes that specifies its total size. I don't know what might happen if the file size changed and not that data.
 
Yes, you are completely right about that. The same goes for the conversations in the bar.

I think by adjusting the offset information in the resource files, it should be able to create dialogs with any length.

My editor does not directly work with the resource files. Instead, I read all information into a dedicated object model.
When done editing, the object model is written transformed to a native resource file, recalculating all the necessary offsets and stuff.

While I am convinced that this works, I still have to figure out, how to correctly fill the gaps of unknown bytes...
 
You must log in or register to reply here.
Back
Top