Castle Paradox

[Rinku]

when working on giant turtle today, i came across a strange bug. when i ran the game after importing some new scripts, i got a "could not unlump 32634.asx (or some number -- below the 32767 limit). i'm not 100% sure the extension was .asx, but it was something similar to that.

has anyone come across this bug before, and could explain what causes script unlumping problems, and offer tips on how to fix it?
_________________
Tower Defense Game

[rpgspotKahn]

Probably a problem with a variable overflow or something...
Isn't the limit on an integer 32767 or something?

I think the same error occured in Shadowiii's game. 7th Day. Which he had to upload like 3 or 4 times... trying to fix it.
_________________

2nd Edition out now!

[Soule X]

I think there's probably a bunch of things that cause overflows, but my trouble with them seems to always be the fault of loops.

In particular if you have a for loop starting at a number lower than its ending at and increasing by one, that can cause an overflow.

Example:

for ( i, 12, 5, 1)

Also, if there's a never-ending loop or maybe a loop that runs a whole bunch of times you might need a wait command in there.

I don't know if these cause overflows 100 percent of the time, but they're often the cause of my overflows. Hope you figure it out.

[Aethereal]

This isn't an overflow problem...it failed to completely open something. Anyway, I checked the FAQ and found this:

[Uncommon]

That's happened to me before, but it was in conjunction with an overflow error, so, unless that's what's going on, I couldn't really tell you how to fix it, especially without a look at the scripts.

Rinku, have you tried the F10 key? That might give you a little more insight into what's going on.

[Bob the Hamster]

The Failed to unlump 32634.hsx means that some other running script attempted to open a script with ID number 32634, and no script with that ID number exists.

Compile your script with -d and then post hs_debug.txt, and then search for the number you saw. If it is a real autonumber script, you will find its name, and then we can try to figure out how the import process is losing it.

If there is no such script ID number at all, then that probably means a bug (not a bug in your script, but a bug in the plotscript interpreter) has caused the interpreter to mistake some piece of data as a script ID number.

An overflow could cause an error like this, but ONLY if you saw an overflow error message first and then tried to continue anyway.

[Mr B]

I got this (not the same number, obviously) whilst working on PB2.

In my case, it happened because I had accidentally deleted the entire script. I still had the script declaration at the top of the file, though, so the interpreter passed it by.

You probably already know about this, but if you open (your compiled script).hs in notepad, you'll see a list of the script names with some numbers under them. Some of the numbers are for the default values passed to the scripts, and one of the numbers is the script ID #. Just look for script ID #32634 and see what script is associated with it, and that should jump ya' right to the problem area. At least, that's what it did for me.

Good luck!

[Rinku]

sorry for the delay in reply. shortly after i posted this message i managed to fix the problem by changing the plotscript in question to a non-autonumber, and recompiling. perhaps the bug is that particular autonumbers sometimes get lost? anyway, thanks for the responses regardless.

i have another question, though -- is it possible to split up a game's plotscripts into seperate .hs files, and import each, rather than having to re-compile all of a game's scripts at once? i doubt it, but c/c++ allows it. i ask because the number of lines in one particular game is like 10,000 or something, and bound to go much higher, and if i can avoid the 3 or so minute compile time by having scripts which i don't change that often moved to a seperate .hs it'd be worth it.
_________________
Tower Defense Game

[TMC]

I could modify HSimport to import several .hs files at once, but this would require you to be able to compile different bits of your script into different .hs files in the first place.

This *could* be done with a third party program (assuming that it still uses HSpeak to compile but spilts the hs file), but this would be tricky because you can't just split the file in two and compile each bit, HSpeak assigns each autonumber script a number depending on how many autonumber scripts it has already compiled. So any multi-scripts-importer would have to renumber every script during importation, and go through every script and change all references to any autonumber scripts.
Also, if you wanted to reference a script in one of the other file(s), you would need to make up a bogus 'define script' and give it an empty script in the same file, and other such things. Error detection would also be devilish.

In short, I couldn't do it without much hassle, and it would require a large rewrite of HSpeak and the importing routines of custom, which methinks James would like to avoid, to help just 2% of OHR users : P. My advice is compile the scripts on a faster machine- on my 1.5GHz, wanderp.hss (3600 total lines including includes) compiles in just over a second.
_________________
"It is so great it is insanely great."