ACC.exe is about to implode on me

[Jimmy]

It would appear that in developing my Jukebox's library, I've constructed a string array too large for ACC to handle. This array stores all the MIDIs to be used in-game by the playlist randomizer. There are 342 MIDIs in the WAD, and the lumpname, track title and track author for each one need to be defined and stored in the array. So, currently it is [342][3] entries in size, which is apparently so big that it's interfering with the local scripts in MAP00 of the mod. In fact, the array is too big to post here.

Basically, the array is so massive, that the local scripts in MAP00 aren't getting parsed. So I've had to place a dummy script in MAP00, at the top of the file, so that ACC ignores it, and skips to the scripts afterwards to make sure all the relevant ones get parsed.

Adding just three more entries to this array causes ACC to ignore the first two scripts defined in MAP00's BEHAVIOR, meaning that in order to keep updating my jukebox with more songs, I'd presumably have to keep attaching more dummy scripts to the top of MAP00's script file.

Kate informs me that it could be a "static buffer overflow" - that the array in the j-jukebox.wad library is causing ACC to ignore the scripts in the actual map. Is there any way around this? And while I think of it, what's the current stance on ACC++?

(Separating the jukebox array into three separate ones is certainly an option, but would require an OBSCENE amount of reworking... )

[VGA]

Well, there is obviously a 1Kb limit somewhere (1024 bytes, 342*3 = 1026) hehe

[Jimmy]

This is slightly unrelated, but there's a massive issue right now that's bothered me a couple of times now and I can't fathom for the life of me why it is happening.

In a couple of my mods' libraries now, #defines and #libdefines just haven't been brought over to the local scripts that use them. Not even the ones in zdefs.acs like TRUE and FALSE, meaning that I have to resort to using 0 and 1 instead. This has just come up unexpectedly, so I must have updated something semi-recently which is causing my scripts to catastrophically fail to compile unless I get rid of every define I use in them.

It's particularly bad when I want to use simple defines from zdefs.acs like TRUE and FALSE in #defines and #libdefines of my own. But no, it seems I have to use numerical values instead.

This is driving me positively doo-lally, but not in a good way. What could be going on here?

-------

EDIT: This issue first cropped up when I was writing my dialogue box script system. I had to resort to using numerical values in place of TRUE/FALSE and the other defines that come in zdefs, which was a massive pain and completely unnecessary, but now it's reared its ugly head in my Jukebox. I was trying, just trying, to optimize my library by moving the massive array into a separate file within the script library. I set up the library as it should be, and took "#libdefine MAX_JUKEBOX 345" from the original file (JUKEBOX) into the new one (ARRAY). The new one, ARRAY, compiled successfully. Then I added "#import array.acs" to the original, JUKEBOX, which also compiled successfully. Then I went to MAP00's scripts, added "#import array.acs" to it, and hit Compile. Oh dear.

This is what I got:

Code: Select all

Line 125 in file "\acc\svn\jukebox.acs" ...
\acc\svn\jukebox.acs:125: Syntax error in constant expression.
> int JukeBoxCheck[MAX_JUKEBOX]
>                            ^
\acc\svn\jukebox.acs:125: Arrays cannot have a dimension of zero.
> int JukeBoxCheck[MAX_JUKEBOX]; 
>                              ^
\acc\svn\jukebox.acs:125: Missing ']'.
> int JukeBoxCheck[MAX_JUKEBOX]; 
>                              ^

Bloody fuck. I'm at my wit's end. This should not happen under any circumstances. This not what a compiler should ever do. The only conclusion I can draw is that the universe hates me.

Help on this dumbfounding issue will be rewarded with a gold-plated unicorn with laser-beam eyes. I'm serious.

[FDARI]

I haven't grasped your complete description, but I have run into a few variants of inclusion-and-import issues before.

Problem (import): Apparent compiler bug, (last) libdefine not necessarily parsed when compiling the script that references the library.
Workaround: Add a final libdefine #LIBDEFINE LIBNAMEDUMMY 0
Result: Preceding libdefines work

Problem (include): Multiple definitions of name.
Typical cause: Including multiple files that are or include "zcommon.acs" or another shared code file
My favoured solution: String all "include"-scripts on a chain.
01SCRIPTHEADER.ACS (includes zcommon.acs and adds some stuff)
02SCRIPTSECTION.ACS (includes 01SCRIPTHEADER.ACS and adds some stuff)
03ANDSOON.ACS (includes 02...)