11 réponses à ce sujet

[Tarot Redhand]

At the expense of sounding like a complete novice, there's something I've been wondering for a while now. I've seen that there are at least 2 external script compilers on the vault. What I'd like to know is why would I want to use any of them? I can see that they might be useful for compiling include files, but do they have any other benefits? Do they have any flaws, i.e. not knowing all the functions/constants etc for 1.69? Finally what would I do with the output, where would I put it?

Thanks in advance for any replies.

TR

[ent.devil]

 There are some differences between the in-built compiler used in the toolset and the command-line versions. As far as I am aware both on the vault support 1.69 fine but I have only tried one (the one I use definately does).

I know for certain there more nested levels of include files that can be used and from previous posts I believe the optimisation is somewhat better. Not sure if it is a requirement if using PRC/CEP because I don't, I'm sure someone can confirm that.

If you combine this and the erf utility to pack and unpack the module contents the resulting .mod file is typically 200k smaller than when it is built and saved using the GUI (nwnnsscomp and erf.linux). Now that could be just the packing being more efficient.

The output of the compilation produces .ncs files as normal and as mentioned above if you use the this and a shell or cmd script to create a more robust build environment using version control and building on Linux without using Wine which lets the scripters play around without worry about altering an area content by mistake.

Something like a combination of these:

unpack - ../utils/erf.linux -x ../modules/some_module.mod
compile - ../utils/nwnnsscomp -cgo /usr/local/nwn `ls *.nss|egrep -v "_i0_|_inc_"`
pack - ../utils/erf.linux -c ../modules/some_module.mod *

Does that 200k have any real world effect? Guess it depends on the size of the module.


usage output from one of the nwnnsscomp versions:

Usage:nwnnsscomp [-cdegoqx] [-t#] [-v#] nwndir infile
nwndir - directory where NWN is installed.
infile - name of the input file.
-c - Compile the script (default)
-d - Decompile the script (can't be used with -c)
-e - Enable non-Bioware extensions
-g - Don't produce ndb debug file
-i - Add Search Path
-o - Optimize the compiled source
-q - Silence most messages
-x - Extract script from NWN data files
-vx.xx - Set the version of the compiler
-t1 - Perform a compilation test with BIF scripts
-t2 - Perform a compilation test with the given module
-t3 - Optimization space saving report with the given module
-t4 - Perform a compilation test with the given file or files


To complete the build environment I have the all of the syntax highlighting and tab completion strings extracted from the nwscript.nss file for use with vim if anyone wants them.

Modifié par ent.devil, 20 décembre 2010 - 08:21 .

[FunkySwerve]

To answer your question about 'why use them', it's because they're more powerful - at least, the PRC one I use is. You can find it here (and yes, it's 1.69-compatible):
Click Me
It can handle more declarations, handles circular includes, catches some errors that the bioware compiler does not, and can be configured to compile groups of scripts that share a prefix with relative ease. There are no real downsides, in my book, if you have even passing familiarity with DOS prompt. Here's our PRC compiler (nwnnsscomp) batch file, which handles the groups of scripts and incomplete script names:

@ECHO OFF
set mask="%1*.nss"
CD C:\\NeverwinterNights\\NWN\\MODULES\\TEMP0
..\\..\\NWNNSSCOMP.EXE -cego %mask%
CD ..\\..
PAUSE

It assumes you have the nwnnsscomp.exe with the .bat file in your installation path (default C:/NeverwinterNights/NWN), and that the script you want to compile is in a module open in the toolset in that installation (it looks for the scripts in the temp0 folder the toolset creates when it opens a mod).

typing 'compile' in DOS promp in that folder compiles every script in the module, while typing a partial will compile every script beginning with those letters - great for scriptsets.

Funky

[Tarot Redhand]

Thanks for the replies. I'll check out the PRC one. One thing I don't understand is why you use '\\\\' in your batch file instead of '\\'.



TR

[FunkySwerve]

Acaos wrote that, not I, but the point is to go up 2 dirs for the command, from temp0 to the nwn folder. I'm not particularly familiar with DoS or I could probably give you a more enlightened reply.



Funky

[Tarot Redhand]

It's OK. I just opened up this thread to check out your reply and found that this site had doubled the number of backslahes that I had typed. Cest la vie.



TR

[FunkySwerve]

Oh, dur, apologies, I didn't even look at the script. Yes, this site has several endearing qualities that way. It's refusal to capitalize 'class' in code being another.



Funky

[FunkySwerve]

I was just reminded of another nice feature of the PRC compiler when coding something as a favor: the vanilla compiler only allows you to use ints in for loops, preventing some very nice (and faster compiling) functionality. This, for example, will not compile with the vanilla compiler:

for (oObject = GetFirstObjectInArea(oArea);GetIsObjectValid(oObject);oObject = GetNextObjectInArea(oArea) {
//do stuff
}

We use this kind of for loop in so many places in HG I'd completely forgotten you couldn't without the PRC compiler. I can make for leaner, much easier-to-read code.



Funky

[Tarot Redhand]

Interesting. That's like VB's collections. Definitely a useful feature. Are there any other things that the vanilla doesn't do that the PRC one does?



TR

[NorthWolf]

Oh, nice. Now I'm curious, too.

[FunkySwerve]

I'm sure there are. The only one that springs to mind at the moment is that the PRC detects some declaration mismatches that the bioware one misses. Compiling jasperre's ai will demonstrate this. This is what I was talking about when I said it catches some things the bioware compiler matches.



Funky

[meaglyn]

Sorry to resurrect a dead thread, but I was wondering where to find the Linux version of this compiler that supports 1.69. Ent.devil seems to have one. The only binary I could find does not support 1.69 (I don't remember now where I even found it) and has fewer arguments. The only source I could find claims not to have been changed since 2004 which would be before 1.69, I think.

Pointers anyone?

It'll be great to be able to actually compile scripts where I write most of them.