I'm preparing to do a release of NWNTools. I fixed some outstanding bugs reported against the compiler and updated it to work for HotU. Also, there's the new python wrapper.
Could someone with HotU installed please test the compiler and confirm that it works ok for HotU specific commands?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-05-16
I compiled and ran it last night, and it appears to work fine. I compiled "x2_s0_grmagweap.nss", which is a standard HotU spell script, that includes the special HotU itempropery commands. It also links to several default include files.
Interestingly enough I noticed a bug in the BW default x2_inc_switches.nss, it apparently declares a function with a the type "int" when it is prototyped as "void", fixing it lets the compile finish. ;)
One question though, can wildcard support be added like in the windows version? Typing:
nwnnsscomp <gamedir> *
...will expand the "*" to the full file name "blabla.nss", where nwnnsscomp expects only "blabla", ie. without the file-ending. Obviously, this means that it is not possible to process more than one file at a time, without a wrapper script.
Also, the built-in help needs to be looked at, since running:
nwnnsscomp <gamedir> -x x2_s0_grmagweap
or any variation to the above named file that I tried failed. It always thought "x2_s0_grmagweap" was an "infile". Am I calling it incorrectly?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the better for many files support is to use makefile, as with any compiler.
> nwnnsscomp <gamedir> *
>...will expand the "*" to the full file name "blabla.nss", where nwnnsscomp
> expects only "blabla", ie. without the file-ending. Obviously, this means
> that it is not possible to process more than one file at a time, without a wrapper script.
I don't understand what you mean, nwnsscomp accepts files ending with .nss on my install...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-05-17
> I think the better for many files support is to use makefile, as with any compiler.
While it's possible to use Makefile, I don't think it fits with how people (at least I) work with nwnnsscomp, work is much more fluid and it's not the same project based approach as with things I generally compile with gcc. If you look at http://www.torlack.com/index.html?topics=nwnnsscomp_readme you will see that the windows version of nwnnsscomp offers a built-in wildcards support which simplifies usage a lot. I understand this might not be something sumpfork priorities, but I still wanted to mention it.
> I don't understand what you mean, nwnsscomp accepts files ending with .nss on my install...
I mean this (working in a directory inside my NWN dir):
-------------------------
% nwnnsscomp ../ nw_s0_daze.nss
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Errors occurred in compiling "nw_s0_daze.nss"
%
% nwnnsscomp ../ nw_s0_daze
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Compiling: nw_s0_daze.nss
%
% old_nwnnsscomp ../ nw_s0_daze.nss
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Error: Unable to open input file "nw_s0_daze.nss"
%
% old_nwnnsscomp ../ nw_s0_daze
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Compiling: nw_s0_daze.nss
%
-------------------------
I had to remove the spellhooking lines from the spell script, because otherwise, the old nwnnsscomp couldn't handle the script.
Is this just happening to me? The old nwnnsscomp was the binary version downloaded from here, the newer one was compiled by myself locally.
Hmm, noticed the error message is slightly different but even so, it still fails.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just did a release as I wanted to get this out the door before the next neveredit release (and so people can run neveredit from source).
I can definitely implement wildcarding for UNIXes at some point - maybe even file a feature request to remind me.
The error message above has changed because I now collect all errors and exit with an return of 1 (should make use in Makefiles more pleasant). And yes, I will remove the necessity to not have the '.nss' on the command line sometime.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No need to add 'wildcard' support inside the software on UNIX. The UNIX shell does wildcard expansion itself before the software even sees it, so the software won't see '*', it'll see 'file1.nss file2.nss file3.nss ...'.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-06-15
That's true erydan, the problem is that the compiler only accepts file names without the file ending. Which is where it differs from most other unix applications. :/
If you supply the file name "file1.nss", the compiler will fail to compile the file.
That's what I was trying to show in my posts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since when has this been the case? did anyone change nwnnsscomp? it supported having the extension in since even before OpenKnights got a hold of it (in fact, my copy here is used inside makefiles just like your pointed out).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi folks,
maybe I can shed some light on this issue. The problem is with how nwnnsscomp assumes 'basename' works - namely that it returns a pointer to inside the string it gets passed. This is a crashing bug on the Mac, because basename returns a pointer to other memory, and I fixed it some time ago.
I missed the fact that in removing the extension of filename.nss, nwnnsscomp also relies on this fact about basename - this time not in a crashing manner. As a result, the extension never gets cut off if you have a basename implementation that returns new memory.
I'll fix this right away.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Needed a minor fix in order to compile on Linux/x86 (const char* vs char* thingy)... fixed it and commited to CVS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-06-17
Thanks! That fixes the filename problem.
Now, the only Windows/"common unix" feature I miss is proper multi-file support.
Running "nwnnsscomp gamedir *.nss" will only ever compile the first script it finds, and stop after that. (yes, I know this is where Makefiles come into the picture, but it would still be a nice thing to have ;)
Oh, and I just noticed this:
------
% nwnnsscomp gamedir scriptfolder/*
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Errors occurred in compiling "scriptfolder/add_damage.nss"
------
It seems as if it thinks the whole "scriptfolder/add_damage.nss" is a file name. Or maybe I'm just doing something weird.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Er it DOES compile all files specified... at least here it does:
fguimond @ salamander src $ nwnnsscomp ~/nwn *.nss
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Compiling: explore.nss
Compiling: dl_autils.nss
fguimond @ salamander src $
As for failing when you specify a full path, could it be that the script you are attempting includes other scripts which aren't present in the current directory? (since nwnnsscomp doesn't have a -I switch like gcc, it only checks the current directory for includes if I remember right)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-06-17
Oh... *cough* quite right. Compiling several files at once DOES work.
The culprit was my poorly written shell-script that I called in place of the binary, that adds a few things I wanted. (it was chopping off all but the first filename) My mistake.
Regarding the "nwnnsscomp gamedir scripts/*" issue, I don't think it's related to include files, since i just tested it with three clean scripts that all contained:
--------
void main()
{
}
--------
They should compile fine (no includes or anything that should break), but it still fails as shown in my previous post. And just to confirm, this is without using any of my clunky shell-scripts. ;)
Does it work for you?
I also noticed that nwnnsscomp doesn't seem to handle some directory names like shown here:
% nwnnsscomp gamedir /full/path/with\ spaces/in\ it/scripts/*"
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Errors occurred in compiling "/full/path/with"
%
See how it breaks? (obviously I altered the real path, but I think the message is clear still)
This is a very minor issue, but I think it might be related to the previous error. Since it suggests nwnnsscomp doesn't handle paths as you would expect.
Again, pretty minor, and sumpfork probably has more important things to worry about for now. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, the breaking it up with the spaces is probably due to your shell script again, if you run directly nwnnsscomp keeps the path intact even with spaces.
As for the other issue at hand, I verified the source, turns out nwnnsscomp is dumping the path part and only keeping the basename, so no matter what path you type, it looks in the current dir for the files. :/
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-06-18
*sigh* Yes. At least one of us knows his stuff. :(
The shell script, even though I thought I cleaned it up, was the responsible party for the broken path.
But at least it wasn't the cause of the other problem (since I wasn't using it when testing that...).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-08-09
I have found a problem with the post incrementor and decrementor of a global variable. The offset to the variable is calculated incorrectly.
The following code near line 1550 in NscCodeGenerator fixes the problem (original code commented out:
Explanation for the problem: The original code always incremented the nElementOffset by one but that is only correct for a local variable. A local variable adds the CPDOWNSP before the increment/decrement which adjusts the SP. A global variable adds the CPDOWNBP which does not change the SP. A simple script that increments a global will show the problem when compared to clcompile in NWNExplorer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
<sigh> - there's a bad interpretation of 'ASAP' if I ever heard one. Sorry, a year later. You folks gotta poke me when I drop the ball like this! Alan just pointed out this is still not fixed. I'm committing the patch to CVS right now. Let me know if there are problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm preparing to do a release of NWNTools. I fixed some outstanding bugs reported against the compiler and updated it to work for HotU. Also, there's the new python wrapper.
Could someone with HotU installed please test the compiler and confirm that it works ok for HotU specific commands?
Thanks.
I compiled and ran it last night, and it appears to work fine. I compiled "x2_s0_grmagweap.nss", which is a standard HotU spell script, that includes the special HotU itempropery commands. It also links to several default include files.
Interestingly enough I noticed a bug in the BW default x2_inc_switches.nss, it apparently declares a function with a the type "int" when it is prototyped as "void", fixing it lets the compile finish. ;)
One question though, can wildcard support be added like in the windows version? Typing:
nwnnsscomp <gamedir> *
...will expand the "*" to the full file name "blabla.nss", where nwnnsscomp expects only "blabla", ie. without the file-ending. Obviously, this means that it is not possible to process more than one file at a time, without a wrapper script.
Also, the built-in help needs to be looked at, since running:
nwnnsscomp <gamedir> -x x2_s0_grmagweap
or any variation to the above named file that I tried failed. It always thought "x2_s0_grmagweap" was an "infile". Am I calling it incorrectly?
I think the better for many files support is to use makefile, as with any compiler.
> nwnnsscomp <gamedir> *
>...will expand the "*" to the full file name "blabla.nss", where nwnnsscomp
> expects only "blabla", ie. without the file-ending. Obviously, this means
> that it is not possible to process more than one file at a time, without a wrapper script.
I don't understand what you mean, nwnsscomp accepts files ending with .nss on my install...
> I think the better for many files support is to use makefile, as with any compiler.
While it's possible to use Makefile, I don't think it fits with how people (at least I) work with nwnnsscomp, work is much more fluid and it's not the same project based approach as with things I generally compile with gcc. If you look at http://www.torlack.com/index.html?topics=nwnnsscomp_readme you will see that the windows version of nwnnsscomp offers a built-in wildcards support which simplifies usage a lot. I understand this might not be something sumpfork priorities, but I still wanted to mention it.
> I don't understand what you mean, nwnsscomp accepts files ending with .nss on my install...
I mean this (working in a directory inside my NWN dir):
-------------------------
% nwnnsscomp ../ nw_s0_daze.nss
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Errors occurred in compiling "nw_s0_daze.nss"
%
% nwnnsscomp ../ nw_s0_daze
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Compiling: nw_s0_daze.nss
%
% old_nwnnsscomp ../ nw_s0_daze.nss
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Error: Unable to open input file "nw_s0_daze.nss"
%
% old_nwnnsscomp ../ nw_s0_daze
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Compiling: nw_s0_daze.nss
%
-------------------------
I had to remove the spellhooking lines from the spell script, because otherwise, the old nwnnsscomp couldn't handle the script.
Is this just happening to me? The old nwnnsscomp was the binary version downloaded from here, the newer one was compiled by myself locally.
Hmm, noticed the error message is slightly different but even so, it still fails.
I just did a release as I wanted to get this out the door before the next neveredit release (and so people can run neveredit from source).
I can definitely implement wildcarding for UNIXes at some point - maybe even file a feature request to remind me.
The error message above has changed because I now collect all errors and exit with an return of 1 (should make use in Makefiles more pleasant). And yes, I will remove the necessity to not have the '.nss' on the command line sometime.
No need to add 'wildcard' support inside the software on UNIX. The UNIX shell does wildcard expansion itself before the software even sees it, so the software won't see '*', it'll see 'file1.nss file2.nss file3.nss ...'.
That's true erydan, the problem is that the compiler only accepts file names without the file ending. Which is where it differs from most other unix applications. :/
If you supply the file name "file1.nss", the compiler will fail to compile the file.
That's what I was trying to show in my posts.
Since when has this been the case? did anyone change nwnnsscomp? it supported having the extension in since even before OpenKnights got a hold of it (in fact, my copy here is used inside makefiles just like your pointed out).
Hi folks,
maybe I can shed some light on this issue. The problem is with how nwnnsscomp assumes 'basename' works - namely that it returns a pointer to inside the string it gets passed. This is a crashing bug on the Mac, because basename returns a pointer to other memory, and I fixed it some time ago.
I missed the fact that in removing the extension of filename.nss, nwnnsscomp also relies on this fact about basename - this time not in a crashing manner. As a result, the extension never gets cut off if you have a basename implementation that returns new memory.
I'll fix this right away.
Quick fix checked into CVS for this issue. Confirmed on Mac so far.
Needed a minor fix in order to compile on Linux/x86 (const char* vs char* thingy)... fixed it and commited to CVS.
Thanks! That fixes the filename problem.
Now, the only Windows/"common unix" feature I miss is proper multi-file support.
Running "nwnnsscomp gamedir *.nss" will only ever compile the first script it finds, and stop after that. (yes, I know this is where Makefiles come into the picture, but it would still be a nice thing to have ;)
Oh, and I just noticed this:
------
% nwnnsscomp gamedir scriptfolder/*
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Errors occurred in compiling "scriptfolder/add_damage.nss"
------
It seems as if it thinks the whole "scriptfolder/add_damage.nss" is a file name. Or maybe I'm just doing something weird.
Er it DOES compile all files specified... at least here it does:
fguimond @ salamander src $ nwnnsscomp ~/nwn *.nss
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Compiling: explore.nss
Compiling: dl_autils.nss
fguimond @ salamander src $
As for failing when you specify a full path, could it be that the script you are attempting includes other scripts which aren't present in the current directory? (since nwnnsscomp doesn't have a -I switch like gcc, it only checks the current directory for includes if I remember right)
Oh... *cough* quite right. Compiling several files at once DOES work.
The culprit was my poorly written shell-script that I called in place of the binary, that adds a few things I wanted. (it was chopping off all but the first filename) My mistake.
Regarding the "nwnnsscomp gamedir scripts/*" issue, I don't think it's related to include files, since i just tested it with three clean scripts that all contained:
--------
void main()
{
}
--------
They should compile fine (no includes or anything that should break), but it still fails as shown in my previous post. And just to confirm, this is without using any of my clunky shell-scripts. ;)
Does it work for you?
I also noticed that nwnnsscomp doesn't seem to handle some directory names like shown here:
% nwnnsscomp gamedir /full/path/with\ spaces/in\ it/scripts/*"
NeverWinter Nights Script Compiler/Decompiler
Copyright 2002-2003, Edward T. Smith
Copyright 2003, The Open Knights Consortium
Errors occurred in compiling "/full/path/with"
%
See how it breaks? (obviously I altered the real path, but I think the message is clear still)
This is a very minor issue, but I think it might be related to the previous error. Since it suggests nwnnsscomp doesn't handle paths as you would expect.
Again, pretty minor, and sumpfork probably has more important things to worry about for now. :)
First, the breaking it up with the spaces is probably due to your shell script again, if you run directly nwnnsscomp keeps the path intact even with spaces.
As for the other issue at hand, I verified the source, turns out nwnnsscomp is dumping the path part and only keeping the basename, so no matter what path you type, it looks in the current dir for the files. :/
*sigh* Yes. At least one of us knows his stuff. :(
The shell script, even though I thought I cleaned it up, was the responsible party for the broken path.
But at least it wasn't the cause of the other problem (since I wasn't using it when testing that...).
I have found a problem with the post incrementor and decrementor of a global variable. The offset to the variable is calculated incorrectly.
The following code near line 1550 in NscCodeGenerator fixes the problem (original code commented out:
if ((ulFlags & NscSymFlag_PostIncrement) != 0)
CodeINC (fSP ? NscCode_INCISP : NscCode_INCIBP, nOffset - nElementOffset + (fSP ? 1 : 0));
// TK CodeINC (fSP ? NscCode_INCISP : NscCode_INCIBP, nOffset - nElementOffset + 1);
else if ((ulFlags & NscSymFlag_PostDecrement) != 0)
CodeINC (fSP ? NscCode_DECISP : NscCode_DECIBP, nOffset - nElementOffset + (fSP ? 1 : 0));
// TK CodeINC (fSP ? NscCode_INCISP : NscCode_INCIBP, nOffset - nElementOffset + 1);
return true;
Explanation for the problem: The original code always incremented the nElementOffset by one but that is only correct for a local variable. A local variable adds the CPDOWNSP before the increment/decrement which adjusts the SP. A global variable adds the CPDOWNBP which does not change the SP. A simple script that increments a global will show the problem when compared to clcompile in NWNExplorer.
Thanks! I'll have a look at this ASAP.
Sumpfork
<sigh> - there's a bad interpretation of 'ASAP' if I ever heard one. Sorry, a year later. You folks gotta poke me when I drop the ball like this! Alan just pointed out this is still not fixed. I'm committing the patch to CVS right now. Let me know if there are problems.