WCP Pascal Error

Jason_Ryock

Vice Admiral
Getting a general error with WCP Pascal, it seems to happen whenever I try to declare and use any kind of a global variable.

For example, the generic spawn routine that declares and calls several variables doesn't work in my code at all, I get the same error: CFlagList::CFlagIndex No Index Found for CRC (Random String) the Random String always corresponds to the CRC of the Global Variable in the mission file (Checked by compiling and editing, and looking at the result).

Here's the code in question, I copied it straight from the UE6 source code, I'm only going to post the relevent portions to save reading time:

var bugsalive;

function M_Nav1;
begin
Nav_ActivateSelf;
SF_AutopilotDisable;
NAV_SetEjectSequence(ES_SAR_pickup);
AI_Waitseconds(1);
bugsalive:=2;
NAV_Createship(2, 108, 0, @M_Bug, @M_BugCount, 1000, 100, 0);
NAV_Createship(2, 109, 0, @M_Bug, @M_BugCount, 1000, 0, 0);
until (bugsalive=0) do
AI_WaitSeconds(1);
end;

function M_Bug;
begin
SF_SetObjectFlag (OF_Alignment, ALIGN_Alien);
SF_ActivateSelf(0);
while(1) do begin
AI_Waitseconds(1);
end;
end;

function M_BugCount;
begin
bugsalive:=bugsalive- 1;
end;


Tweaking the code, I've come to the conclusion that it has no problem updating the variable to 2 in the nav code, but it doesn't seem to like checking the code to make sure the bugs aren't dead yet.

Removing that line, generates the same error message when a ship is killed, and the mission tries to rewrite the variable again.

Any help? I've been stuck on this for two days. I've even tried running and compiling old mission code I've written that I KNOW works, and anything that uses or declares variables (spawn routines, for example) spits out the same error. I just did a clean install of WCSO this morning, with the only additional files some extra ships (that aren't used in this mission) and the High Res patch.
 

Quarto

Unknown Enemy
Delete your savegame and try again - the reason you get this bug is because the game writes CRC values into the autosave when you start up a mission - and it only does so the first time. So, when you added another variable into the mission after playing it, it didn't get added, and the game crashed when you referred to it.
 

Jason_Ryock

Vice Admiral
Actually, that didn't clear it up. I deleted all the files out of the "save" folder, and just to be safe, all the files out of the "history" folder as well.

Did I miss something somewhere? Would creating a new pilot eliminate this error?
 

Eder

Mr. Standoff
You need to delete the replay and autosave files in the WCP/SO folder as well the save and history folders. And yep, starting a new pilot eliminates the error.
 

Jason_Ryock

Vice Admiral
Fantastic. Worked as promised, thanks for the help guys.

If I add more variables, I will need to do the same, yes?
 

Quarto

Unknown Enemy
Yes - anything that has a CRC value will require you to do that. This includes variables, but also declared objects of any kind - ships, navpoints, etc. Spawned ships, on the other hand, don't require it, because they don't exist until spawned. Also, constants don't require it, because they don't actually exist.
 

Jason_Ryock

Vice Admiral
Would these rules still apply if you were writing to a SIM file? Or would it then be irrelevent? I'm not sure how the sim files work with the save game.


EDIT:
Is it better to use the Spawn Routine, or just cleaner (Code wise)? I noticied the UE Missions tend to use the NAV CREATE SHIP command alot, but seem to recall being encouraged to always use the spawn routine.
 

Quarto

Unknown Enemy
No, sim missions do not save anything, so you don't need to do that.

The spawn routine actually calls on the NAV_CreateShip function, it just makes it easier to use. So, it's easier to use the spawn routine, though not necessarily better.
 

Jason_Ryock

Vice Admiral
I've got a new problem now. I'm using several custom ships on my mission, and I'm having trouble forcing them to spawn. The game keeps asking for "fatal.iff". I assumed this was a problem with a single ship, but it now appears to be not so isolated: I'm getting the error anytime I try to spawn a custom ship.

Any help? I've already appended them onto the end of ships.pas file. Is there somewhere else they need to go to spawn correctly?

EDIT: They don't seem to be working with the NavCreateShip command (which as mentioned before is what is used when spawning ships!).
 

Quarto

Unknown Enemy
You can't append ships at the end of ship.iff - the game is restricted, by code, to those 57 entries. And even of those 57 entries, at least the last two are hardcoded not to work. So, the only way you can introduce new (spawnable) ships is to replace existing entries. The same, incidentally, is the case for cdlayout.iff, missile.iff and bullet.iff.
 

Jason_Ryock

Vice Admiral
EDIT:

Nevermind! I figured it out via UE Source Code. I had to recompile ships.iff with my ships swapped for the ships I wanted them swapped in in the ships.pas file I was compiling with my mission.

They all spawn proper now.
 

Jason_Ryock

Vice Admiral
Only two more questions tonight, and these can't be answered via the source code for UE (At least one of them can't, the other I've just got no clue where to look).

1) As it is impossible for the Standoff source code to ever be released, can you tell me (in vague vague terms) how you managed to force the WCSO/P missions to write to an SQL database? Was this done via some complicated hack, or did you just make use of Pascal's native coding functions?

2) How the heck did you make the game load your own .tre files? I downloaded UE and Standoff and poured through their EXE's with a hex editor to find a clue, but in the end I just couldn't. Is this done somewhere else in the game files? This can probably be found somewhere in the UE source (I know because I know UE uses it's own .tre files) but I can't for the life of me figure out where.

EDIT:
2) Okay, I think I see it. You have the unknownenemy.pas file use this line:

#AddPathConstant("uesrc", "d:\wcppas\ue\");

This add's UE.tre to the game as a constant, so you can use it to search. The game then calls for a search:

#AddToSearchPath("$uesrc$");

And this forces it to search in UE.tre. Is that correct? The game treats the .TRE files like a subdirectory? In fact, this whole file seems to be spelling out where the various files are for the UE mod, so that the game can find them. These seems very handy when you want your 'mod' to run on top of SO or UE or Standoff without interfering with the other files.

But still, the EXE must call this file at some point, right? Because as far as I can tell, the EXE is the only unique file to each mod, it has to specify the series, so it must also specify where to look for the data...or the file that does...right?
 

Eder

Mr. Standoff
Which TREs to load is something determined by a .cfg file - a text file with a bunch of parameters - which the game checks thanks to a DLL patch by HCl, I believe. You can specify which TREs to load all the time, and which to load for specific resolutions only. More info on this, including the source to Standoff's and UE's DLL patches, are found at HCl's site. I'm pretty sure UE had no other .cfg files (Standoff uses this kind of file for configuring numerous patches apart from the TRE-loader) so it should be easy to find it.

So, at least some of these DLL patches (and some EXE editing, to make sure your savegames use different folders than SO's, and such) are a requirement in order to have a mod that can coexist with original SO or other mods, instead of just replacing files.

You should also check Killerwave's site (http://killerwave.solsector.net) for some important tutorials not covered elsewhere, including EXE editing.

The "add path" things in WCPPas are just to make sure the code finds all the external references it needs in order to compile that particular file... it points to where the resources themselves are - not to the TRE that contains the final, compiled versions of them. So, "uesrc" just points to the folder where Quarto or whoever it was had all their files.
 

Jason_Ryock

Vice Admiral
Which TREs to load is something determined by a .cfg file - a text file with a bunch of parameters - which the game checks thanks to a DLL patch by HCl, I believe. You can specify which TREs to load all the time, and which to load for specific resolutions only. More info on this, including the source to Standoff's and UE's DLL patches, are found at HCl's site. I'm pretty sure UE had no other .cfg files (Standoff uses this kind of file for configuring numerous patches apart from the TRE-loader) so it should be easy to find it.
Yes, I found an excellent almost tutorial on HCL's site covering the basics of creating and loading a DLL File to hack the exe. I was under the (wrong) impression that there were no tutorials on his site, only source code. However, he explains in depth exactly how he created the DLL file to load it's own tre files and the process to do the same thing for anyone else.

I made sure to look over the Hex Editing tutorial several times, because I believed that's where my answers were (I still have the tutorial open in another window even as I'm writing this). This tutorial has been most excellant for helping me change some basic factors related to the game.

You should also check Killerwave's site (http://killerwave.solsector.net) for some important tutorials not covered elsewhere, including EXE editing.
I made sure to look over the Hex Editing tutorial several times, because I believed that's where my answers were (I still have the tutorial open in another window even as I'm writing this). This tutorial has been most excellant for helping me change some basic factors related to the game.

The "add path" things in WCPPas are just to make sure the code finds all the external references it needs in order to compile that particular file... it points to where the resources themselves are - not to the TRE that contains the final, compiled versions of them. So, "uesrc" just points to the folder where Quarto or whoever it was had all their files.
That IS a pity. I rather wished it had been that simple. However, it appears I'm going to need to edit and recompile a DLL File to make a standalone mod.

Thank you very much for your answers! This is something I've been puzzling over for quite a few days now!

EDIT: ...was the Standoff Scoreboard implemented in the same manor? A DLL hijacking the EXE to temporarily upload the scores?
 

Quarto

Unknown Enemy
1) As it is impossible for the Standoff source code to ever be released, can you tell me (in vague vague terms) how you managed to force the WCSO/P missions to write to an SQL database? Was this done via some complicated hack, or did you just make use of Pascal's native coding functions?
Uh...

...Do what to a what database? It sounds like something you got figured out all wrong - not only do I not know what you're talking about, I don't even have any ideas as to what you could be talking about, I'm afraid.
 

Jason_Ryock

Vice Admiral
Uh...

...Do what to a what database? It sounds like something you got figured out all wrong - not only do I not know what you're talking about, I don't even have any ideas as to what you could be talking about, I'm afraid.
I was under the impression that the Standoff missions were writing to an SQL database on the CIC server to store the scores on the scoreboard. But that's more of just a guess, though an educated one.

EDIT: Going to look at the Standoff DLL Source for a bit to see if I can figure this part out.
 

Quarto

Unknown Enemy
Oh, right, the scoreboard. Yeah, I have no idea how that works, but for all I know, it could indeed be SQL.

That is done through a DLL patch, but it's definitely not something you'll find in the DLL source code on HCl's page - that one was released a long time ago, and the DLL has been expanded a great deal since then.
 

Jason_Ryock

Vice Admiral
That is done through a DLL patch, but it's definitely not something you'll find in the DLL source code on HCl's page - that one was released a long time ago, and the DLL has been expanded a great deal since then.
I didn't think so, but I was hoping all the same. I'm vastly curious about that, there are some really neat things you could do with it - like a fully interactive campaign, where not just your scores, but the scores of everyone else affect the outcome of the mission.

Anyway, I think I have all the information I need now to make a completely stand alone mod, the UE DLL Source files should be more then enough, I think. I've certainly nailed down the mission code, I can generally compile several missions (some of them a bit complex) without any errors.

I finally got briefings working - I don't know what was wrong with them before, but I haven't had a problem with them since. I already know how to set up comms, and change splash screens.

The only thing that really leaves me left to work on is room editing (Which, between tutorials and the UE Source shouldn't be much of a problem). There's quite an abundance of SO ships available (just from the CIC site, but from other sites as well - no worries, I plan to leave the UE and Standoff ships well enough alone, you made them so beautiful I could never do them justice.

I think that racks up everything but movies - and I have a feeling that can be done fairly easily (ALA Secret Ops) now that I understand how to write functioning code in Pascal.

Thank you a thousand times over for the UE source code - I said it before and I'll say it again, that Code is taken me places I never though I could go with.
 
Top