81 réponses à ce sujet

[SkywingvL]

You can use the toolset plugin module (NWNScriptCompilerDll.ndl) with virusman's NWNTX for NWN1 as well.

The standalone compiler (NWNScriptCompiler.exe) can be used with NWN1 or NWN2 (or other games using NWScript).

[Dark_Ansem]

thank you. would any module done with it require the NWNTX extension to be played?

[virusman]

No

[Sherincall]

Wonderful stuff! #define is awesome, I even use it as typedef.

Would it be possible to add another optional layer of code processing to the compiler, either before or after macro expansion.. I want to add syntax support for a few things (for example, arrays). I could run that program before the compiler for every script, but then I won't be able to use it in NWNTX.

A simple ini option to specify the program to parse the script before the compiler would do wonders, and then just send the script as stdin and get the result as stdout of that program.. Or if it's easier, specify an interface and load the parsers from a dynamic library.

One more question.. Does the new #include work like in C/C++, or does it add only the symbols that were used. What about multiple definition? Do we need include guards?

Thanks again, for this great toy..

[SkywingvL]

Release 13 posted. New NWNScriptCompiler.exe and NWNScriptCompilerDll.ndl (toolset plugin compiler core DLL). Download link on the first post in the thread.

Release 13:
-----------

- Added -j option to standalone compiler to show where an include file was
really picked up from (useful for debugging include priority ordering
problems).

- The compiler now correctly disambiguates between struct tag symbols and other
symbols (improved language conformance with the BioWare compiler).

- Added support for recognizing the GOG.com NWN2 edition installation path.

[Dark_Ansem]

thanks!

[SkywingvL]

Sherincall wrote...

Wonderful stuff! #define is awesome, I even use it as typedef.

Would it be possible to add another optional layer of code processing to the compiler, either before or after macro expansion.. I want to add syntax support for a few things (for example, arrays). I could run that program before the compiler for every script, but then I won't be able to use it in NWNTX.

A simple ini option to specify the program to parse the script before the compiler would do wonders, and then just send the script as stdin and get the result as stdout of that program.. Or if it's easier, specify an interface and load the parsers from a dynamic library.

One more question.. Does the new #include work like in C/C++, or does it add only the symbols that were used. What about multiple definition? Do we need include guards?

Thanks again, for this great toy..

Sorry, I hadn't seen this question before.

It would conceivably be possible to define some interface to allow preparsing of the source text if desired.  Drop me a PM if you're interested in this, with more details on what you're looking for.  Language extensions are probably best handled by extending the compiler itself though, particularly if they pertain to parsing more complicated than the preprocessor's very basic functionality.

Include is the same as the pre-existing #include already supported by the standard compiler (and earlier ASC versions); this functionality has not changed.  The way #includes work in NWScript is:

- If this is the first time that the include filename has been observed for this compilation unit, include the source text.
- Otherwise, ignore the #include directive (e.g. if the directive was specified twice).

This isn't as flexible as C-style includes.

[Shadooow]

I am using the latest SkywingvL's version and now when Im running win7 I got serious issue with compiling scripts.

Newly compiled scripts are names "*.nss.ncs" does anyone know solution for this? Running as administrator neither XP compatibility helped.

[Shadooow]

ShaDoOoW wrote...

I am using the latest SkywingvL's version and now when Im running win7 I got serious issue with compiling scripts.

Newly compiled scripts are names "*.nss.ncs" does anyone know solution for this? Running as administrator neither XP compatibility helped.

turns out its not win7 error, does this as well on my XPs too

also recently installed virtual XPs on my 7s and I cannot run it there, no matter whether i specify the path with -n or not it always throw the SSC1085 error unable to open include file 'standard_nwn_library_file', I copied nwn into standard path and added registry informations but nothing helps, I can run it on my brother's computer with XP fine but not on virtual.

Version: 1.0.0.2.4
batch file:

cd scripts
..\\nwnnsscomp.exe -g -o -e -l -1 -i ../includes -b ../scripts_compiled/ *.nss
pause

Anyway, Im very disappointed with this compiler. If it wasnt be one little bug in the original Torlacks I would never used this one. There are no extra features I would needed, only dozens options for NWN2 issues. First what annoyed me on this one was the need to specify numerous new options to normally run it for NWN1 while the original compiler didnt needed them. I understand the original compiler didnt worked for NWN2 but yours isnt backwards compatible with NWN1. I tried very hard to understand these choices, and keep using it but I always get soon kicked by some bug, missing functionality or incompatibility.

All I need is a Torlack's with the fix for the duplicate global/local structure names.

Does anyone have an older working version of this tool maybe? Author seems to be gone now.

EDIT: added image to the unable to open include file error:

Modifié par ShaDoOoW, 05 septembre 2013 - 03:30 .

[painofdungeoneternal]

You might want to try the toolset plugin virusman did, this would mean you don't have to figure out the command line options.
http://www.nwnx.org/...491b1daad57f58b

[FunkySwerve]

I use Skywing's without any diffculty - it absolutely kicks butt. Here's the compile.bat we use, located in my install directly in the NWN folder:

@ECHO OFF
set mask="%1*.nss"
CD C:\\NeverwinterNights\\NWN\\MODULES\\TEMP0
..\\..\\NWNScriptCompiler -1cegloq -r . %mask% 
CD ..\\..
PAUSE

Makes it very easy to compile code in sets of like prefixes. I'm running Win 7 64 bit. For example, this:

compile fky_

compiles all scripts beginning with fky_, while

compile

compiles everything in the temp0 folder.

Of course, I haven't updated it in over a year, so my version may be somewhat different, but I'd be very suprised if the same params don't still work.

Funky

Modifié par FunkySwerve, 05 septembre 2013 - 07:17 .

[Shadooow]

FunkySwerve wrote...
Makes it very easy to compile code in sets of like prefixes. I'm running Win 7 64 bit. For example, this:

compile fky_

compiles all scripts beginning with fky_, while

compile

compiles everything in the temp0 folder.

Of course, I haven't updated it in over a year, so my version may be somewhat different, but I'd be very suprised if the same params don't still work.

Funky

Feature to specify input files has the Torlack/PRC compiler too.
Nobody has a version 1.0.0.2.3 ?

[henesua]

I am using NWNTX (latest version) and today upgraded the .ndl for the script compiler to th latest from skywing

Compiles now result in
Access Violation at address 2A022DA9 in module 'NWNScriptCompilerDll.ndl'.  Read of address 00000000.

If it matters I am using the toolset in VMWare Player. The toolset extender was working fine in this environment until I changed the ndl.

I changed the ndl back to the one distributed in VMan's NWNTX, and no longer get the error.

Modifié par henesua, 14 septembre 2013 - 06:21 .

[Via Con Diablos]

Skywing or Funky: I'm overriding some function names in nwscript, and and when I run funky's batch file, I get tons of errors like the following
nwscript.nss(5793): Error: NSC1045: Variable "sLanguage" defined multiple times
in the same scope (previous definition at nwscript.nss(5793))

which makes sense if it's loading the base version as well.

Is there any way to avoid this, other than compiling chunks of files at a time?

[Via Con Diablos]

I guess I can add -y to just pass on and look for errors after, but it would be nice if files in the module properly overrode the base ones (or maybe I'm just missing the obvious way to do so)

[SkywingvL]

Release 15 of the Advanced Script Compiler posted.  New NWNScriptCompiler.exe (standalone command line compiler executable) and NWNScriptCompiler.ndl (for NWNTX users).

Download link here.

Release 15:
-----------
- Added -k option to standalone compiler to generate a pseudo-preprocessed
  version of script source text, annotated with originating line numbers and
  file names (useful for diagnosing problems with conflicting #includes).
- Fixed internal compiler assertion when printing out the error diagnostic
  for a duplicate default: block in a switch statement.
- The compiler was not previously issuing an error diagnostic if a duplicate
  case select value was supplied within a switch statement (longstanding bug
  dating back to nwnnsscomp).  This has been rectified with new error
  diagnostic NSC1089: Case value '<integer>' already used.  Previously, code
  for duplicate case blocks would be generated silently.

[Zeke]

I'm trying to compile nw_c2_default9.nss and nw_c2_default4.nss and they give the following warnings:

x0_i0_anims.nss(1261): Warning: NSC6023: Function "AnimActionPlayRandomGreeting" argument "nHDiff" default value does not match the initializer value for a previous declaration.  The first declaration value will be used.

x0_i0_anims.nss(1261): Warning: NSC6023: Function "AnimActionPlayRandomGreeting" argument "nHDiff" default value does not match the initializer value for a previous declaration.  The first declaration value will be used.

x2_inc_switches.nss(596): Warning: NSC6023: Function "SetExecutedScriptReturnValue" argument "nValue" default value does not match the initializer value for a previous declaration.  The first declaration value will be used.

x0_i0_anims.nss(1261): Warning: NSC6023: Function "AnimActionPlayRandomGreeting" argument "nHDiff" default value does not match the initializer value for a previous declaration.  The first declaration value will be used.

x0_i0_anims.nss(1261): Warning: NSC6023: Function "AnimActionPlayRandomGreeting" argument "nHDiff" default value does not match the initializer value for a previous declaration.  The first declaration value will be used.

x0_i0_anims.nss(1261): Warning: NSC6023: Function "AnimActionPlayRandomGreeting" argument "nHDiff" default value does not match the initializer value for a previous declaration.  The first declaration value will be used.

I'm using the following command:

"path-to\NWNScriptCompiler.exe" -1cegloq -i "path-to\NWN Project\nss" -n "path-to\Neverwinter Nights" -y -b "path-to\NWN Project\nss" "path-to\NWN Project\nss\*.nss"

Is this normal behaviour?

[Shadooow]

yes this is normal, these vanilla includes have minor bugs in them

 

you can either fix it yourself, or since you get this warning install my community patch which fixes this and much, much more

[Zeke]

yes this is normal, these vanilla includes have minor bugs in them

 

you can either fix it yourself, or since you get this warning install my community patch which fixes this and much, much more

 

Ah, thank you! I'm calmer now.

 

Does the patch has any known module and CEP incompatibilities?

[Shadooow]

Ah, thank you! I'm more calm now.

 

Does the patch has any known module and CEP incompatibilities?

its compatible in everything in a way that if there is any file conflict it uses the version from hak/module to avoid conflict. on the other hand that means that you wont get all promised fixes in every modules but thats how it always worked with official patches.

 

check FAQ

[Zeke]

Great! Thank you very much. I'm using your patch to implement changes to the original files.

 

Is someone using the compiler with *.nss files in an external directory (not in temp0)?

 

For rebuilding everything I use sublime. Using this command:

["C:\\Program Files (x86)\\NWNScriptCompiler\\NWNScriptCompiler.exe","-1cegloq", "-i", "${file_path}", "-n", "E:\\Games\\Neverwinter Nights","-y", "-b", "${file_path}", "*.nss", "&", "move", "/y", "*.ncs", "E:\\Games\\Neverwinter Nights\\modules\\temp0", "&", "xcopy", "*.nss", "/r", "/y", "E:\\Games\\Neverwinter Nights\\modules\\temp0"]

In other words:

1) Compile everything

2) move the *.ncs files in temp0

3) xcopy the *nss files in temp0

 

I don't like this approach because it copies and moves even when there is a compile error and it takes time to copy and move everything. Is there a better approach to this?

[Shadooow]

yes i use it externally for my patch project

 

 

cd scripts
..\nwnnsscomp.exe -g -o -i ../includes *.nss ../scripts_compiled/
pause

this simple batch file compiles all nss files in scripts directory

[Zeke]

Do you then copy manually the compiled scripts from /scripts_compiled  to temp0?

 

I'm having some problems. I can't seem to be able to specify where to output the compiled *.ncs files. It always outputs them in the same directory where the *.nss files are located.

[leo_x]

Don't recall how the earlier versions work.  But in the lastest Skywing versions you can specify -b <output directory> and all ncs files will be placed there.  Taking a gander at your Sublime script that might be why they're always in the current directory.

[Shadooow]

Do you then copy manually the compiled scripts from /scripts_compiled  to temp0?

 

I'm having some problems. I can't seem to be able to specify where to output the compiled *.ncs files. It always outputs them in the same directory where the *.nss files are located.

thats not how im using it, but yes im cutting the files from scripts_compiled and putting them into other folder after