This project includes a NWN2 toolset plugin that adds an improved script compiler (based on Edward T. Smith's nwnsnsscomp) to the NWN2 toolset. The compiler is seamlessly integrated and automatically used when compiling scripts from the toolset. Features include better code generation, better warnings and error messages, and the ability to receive more than one compile error at once.
Additionally, an improved console script compiler (replacing nwnnsscomp) is also included, with various bugfixes and improvements over nwnnsscomp. In particular, NWN1 datafiles aren't required anymore for the console compiler, and nwscript.nss can be loaded from the game zip files. Various fixes are also made to ensure that scripts compiled with the console compiler are also compileable by the stock script compiler.
Release 6 posted. This release includes a number of new extensions available in the command line compiler, as well as improvements to how errors and diagnostics are reported for both the toolset compiler and command line compiler. --- Release 6: ---------- - The compiler now correctly issues an error diagnostic if a script program attempts to call a function that has been declared but never defined, instead of raising an internal compiler assertion. - The compiler provides support for 'default functions' in extensions mode, if -e is supplied on the compiler command line. A default function can have no body and if called, the compiler will automatically substitute a default implementation that throws the arguments away and returns the appropriate default value for any return value(s) as appropriate. This feature can be activated via a #pragma default_function(function-identifier) directive after a prototype for "function-identifier" is observed, but before the function is defined. If a default function is defined as normal, the script program's explicit definition is used as the function body instead of the default definition. - The compiler now supports automatic analysis and verification of scripts as a compilation post-step in order to check for various inconsistencies. Script analysis and verification can be enabled via the -a command line option at a modest (10-20%) cost to compile time on most scripts. - The compiler supports __FILE__, __LINE__, __COUNTER__, __FUNCTION__, __NSC_COMPILER_DATE__, and __NSC_COMPILER_TIME__ predefined macros. The macros work the same as their typical C counterparts (with the compiler macros reflecting the build time for the compiler itself). These macros are only enabled in extensions mode. - The compiler now supports #error and #warning to issue diagnostics to the programmer. These directives are only enabled in extensions mode. - The compiler now has limited #if/#elif/#ifdef/#ifndef/#else/#endif support. Only literal integers and macros can currently be tested; there is no support for expressions on preprocessor #ifs constructs. The preprocessor #if constructs are only enabled in extensions mode. - The compiler no longer generates bad code when optimizations are enabled, a global variable is initialized with a function call expression, and the global variable in question is never written to after assignment. - In compatibility mode, a warning is now issued if a script program contains a for statement with an initializer or increment block whose type is not an integer. - Compiler error and warning messages now have easily searchable identifiers associated with them (for example, NSC1001 or NSC6018).
Posted by FunkySwerve at on07/22/11
Very nice, and very well supported. :) Funky
Posted by Skywing at 2011-06-1920:26:03
Release 5 posted with some improvements to both the standalone and toolset compilers. If you are updating a toolset compiler install, be sure to copy over all of the toolset compiler plugin files. -- Release 5: ---------- - The compiler now issues a warning diagnostic if the user attempts to declare default arguments to an entry point symbol (main, StartingConditional). The script runtime always ignores the user's supplied default arguments, so it is misleading to declare defaults in the script. - The compiler warning diagnostic for non-default arguments following default arguments has been improved (i.e. specify which function and argument had the problem). - The standalone compiler was not properly loading KEY/BIF files if -1 was supplied on the command line for NWN1 compatible mode. This has been fixed. - IR disassembly was showing reversed operands for DIVFI instructions. This has been fixed. - User include directories were being prioritized after the resource system and not before. This has been fixed. User include directories are now the highest search priority for locating include files. - The compiler would generate an assertion failure if one attempted to compile a script whose entry point symbol was explicitly called within the script itself. This has been fixed. - The IR disassembler would reject as malformed (due to a mismatched stack pointer across control flows) a script program whose entry point symbol took parameters and was explicitly called within the script itself. This has been fixed. - The compiler now issues an error diagnostic should an identifier be used with multiple incompatible symbol types (i.e. as a variable and a structure, or other symbol type combinations). - The compiler now allows forward declaration of structures, but only if the structure in question is not embedded within another structure before it is fully declared. - The compiler now issues an error diagnostic should a structure be declared twice. - The compiler now longer issues an assertion failure in cases where a variable has the same name as an existing symbol, such as a function or structure. - The standalone compiler can now be directed to load a module from an arbitrary path with the -r option.
Posted by Morbane_Unhinged at on04/11/12
This gives nwscripting a whole new dimension - that advanced error trapping and enhancement within the toolset are virtually seamless - nary a second on compile time AND compatable with PowerBar which provides auto-parameters - the dynamic duo of nwscripting! BAM! POW! BAF! _________________________ |Morbane| Tintable Arcane Circles Tomb of Horrors PnP Conversion
Posted by Skywing at 2011-06-0102:52:51
Release 4 includes one additional comforance improvement that I forgot to mention in the initial announcement: - The compiler now issues a warning diagnostic in compatible mode (-v1.69 or below) if a script program exceeds 16384 global identifiers. This conforms with an internal limititation present in the stock compiler.
Posted by Skywing at 2011-06-0102:42:29
Release 4 posted with a number of core compiler improvements that improve conformance with bugs in the stock BioWare compiler in edge cases, as well as new compiler diagnostic warnings/errors for additional constructs that do not work correctly in NWScript (such as certain dangerous classes of global variable usage). This release updates both the standalone compiler and the toolset plugin. Changelog: Release 4: ---------- - In BioWare-compatible mode (enabled by default in the toolset plugin, and enabled with -v1.69 (or lower) in the standalone compiler), an error diagnostic is issued if a function with more than 32 arguments is declared, as such functions are not supported in the standard compiler. In extensions mode, a warning diagnostic is issued in this case. - The standalone compiler's support for batch mode (-b argument) did not support source file names that were wildcards correctly. This has been corrected. - The standalone compiler now supports supplying command line arguments via a response file using the @ResponseFile argument. Only one response file is permitted for the entire argument set, and the response file should be the last argument on the command line as response file arguments are currently always parsed after normal command line arguments. - STORE_STATE references generated before main (i.e. within #globals) no longer result in an uninitialized value being specified as the local variable store count to the OP_STORE_STATE instruction. - The compiler now issues a warning diagnostic should script code attempt to directly invoke an engine function taking an "action"-typed arguments from a global variable initializer expression. This case is not supported and will cause an error at script execution time in most instances. - The compiler now issues a warning diagnostic should script code attempt to invoke a function which makes references to global variables (anywhere within its call tree), from within a global variable initializer expression. This case is not supported and will cause an error at script execution time in most instances. - The compiler now issues a warning diagnostic in compatible mode (-v1.69 or below) if a script program has a function or global scope where the sum total of all non-constant global variables and all local variables within the current function (if not at global scope) exceed 1024. The stock/standard compiler cannot compile such scripts due to a bug. - The compiler now issues an error diagnostic if a local variable is declared with the "const" qualifier, instead of triggering an assertion failure. This construct causes a compile error with the stock compiler. - The error diagnostics for misuse of the "const" qualifier have been improved to provide more context information (i.e., specify which identifier had the problem).
Posted by Barry_The_Hatchet at on05/21/11
Brilliant. Thanks for sharing this. _________________________ Barry The Hatchet Custom Content [ BTH Vault Submissions] [ BTH Gallery] [ BTH Blog]
Posted by Skywing at 2011-05-1923:32:46
Release 3 posted with some improvements for both the standalone compiler and the toolset compiler plugin: Release 3: ---------- - The toolset compiler plugin now scrolls to the first compiler error or warning message in the verify window when compiling a script. - Compiler errors and warnings in the verify output window are now clickable when using the toolset compiler plugin. - Disassembly mode (-d) for the standalone compiler was not producing IR disassembly files (*.ir, *.ir-opt) properly. This has been fixed.
Posted by kevL's at on05/19/11
yer frying my brain, Skywing ;) I guess the answer is, Yes. Check your BSN PM for a link .. _________________________ All the world's a stage ... but so what.
Posted by Skywing at 2011-05-1912:12:25
If I run the same compile script you provided as a GUI script, it works as expected under the stock server. Do you have an example that doesn't involve running a parameterized (or with return value) script from console RunScript?
10 - A Masterpiece, Genuinely Groundbreaking 9 - Outstanding, a Must Have 8 - Excellent, Recommended to Anyone 7 - Very Good, Deserves a Look 6 - Good, Qualified Recommendation 5 - Fair, Solid yet Unremarkable 4 - Some Merit, Requires Improvements 3 - Poor Execution, Potential Unrealized 2 - Very Little Appeal 1 - Not Recommended to Anyone