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.
- The pcode dump mode now works again for the standalone compiler.
- The compiler now allows compiled scripts to be up to 64MB, versus up to the
old limit of 512K. It is strongly recommended that scripts be kept under
512K compiled size for both compile-time and runtime performance reasons.
- The compiler now provides a proper compile time error (NSC1036) if a script
exceeded the maximum compiled script size. Previously, the compiler asserted
in this condition.
Release 11:
-----------
- In compatibility mode, the compiler will now terminate an unterminated
comment block at the end of an include file. This improves compatibility
with certain ill-formed third party scripts. In compiler version 1.70 or
higher, the fixup is not performed.
Posted by Morbane_Unhinged at 2012-04-11 01:41:02 Voted 10.00 on 04/11/12
I love the ASC! So great to have all the features.
(The spammer before this voted - finally they at least participate) _________________________ |Morbane|
Posted by onitsuka tiger shoe at 2012-03-06 06:33:31 Voted 10.00 on 03/06/12
I believe youve made some truly interesting points. Very few people would really consider this how you just did. Im really impressed that theres a lot relating to this subject thats been uncovered and also you made it happen very well, with the much class. Doozy you, guy! Excellent stuff here. _________________________ Asics Mexico 66 Asics Mexico 66 cheapairmax90uk nike tn pas cher cheap nike air max 90 onitsuka tiger shoes
Release 7 posted. This release includes fixes and improvements for the standalone and toolset compiler versions.
---
Changelog:
Release 7:
----------
- Script programs that contain duplicate definitions for a function, and which
supply empty bodies for such duplicate definitions now correctly trigger a
function redefinition error (NSC1062). Previously, these were incorrectly
permitted (the standard compiler does not permit such constructs).
- Error and warning diagnostic messages that relate to duplicate identifier
definitions now contain a source location pointer to the first definition of
the conflicting identifier.
- Fixed a bug where the command line compiler did not report the number of
errors across all scripts correctly in some circumstances. The error
message listing the total error count was showing an incorrect error count.
Posted by kamal at 2011-10-29 07:38:34 Voted 10.00 on 10/29/11
Yay for usable errors. Does what it says. _________________________ Shadow Thief: Crimmor and Path of Evil blog Link
Posted by GrinningFool at 2011-09-17 13:55:20 Voted 10.00 on 09/17/11
Excellent work _________________________ The Grinning Fool The World of Khalidine, a unique RP PW.
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 2011-07-22 14:58:57 Voted 10.00 on 07/22/11
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 2011-06-01 04:47:37 Voted 10.00 on 04/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|
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.
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 2011-05-21 23:02:41 Voted 9.75 on 05/21/11
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?
Posted by kevL's at 2011-05-18 15:27:31 Voted 10.00 on 05/19/11
yep (note to others, the default compiler returns 'unsuccessful' on a *cough perfectly good script)
i should point out, though, that it doesn't seem confined to the console RunScript - it first popped up fer me in bad code I had been running 'successfully' for half a year (without so much as a peep, then i recompiled with the ACS and bang, so thanks too!) _________________________ All the world's a stage ... but so what.
kevL: The fact that this crashes is a bug in the game server. However, it's not something that I would consider an issue with the script compiler (it's luck that this works at all with the toolset script compiler).
The root cause of the issue here is that the console RunScript command does not support scripts that take parameters or return values (i.e. it must be a "void main()" script). Any other scripts called via the console RunScript command may corrupt the internal state of the script VM.
Please link me the .nss, .ncs. and .ndb files for the problematic script, including all dependencies, and I'll take a look. (Don't build with -g for this as I will need the .ndb file. This won't impact the .ncs file output at all.)
Also, please link me the nwn2_errorlog.txt (or nwn2_servererrorlog.txt) from your game installation directory in Program Files. You may need to click 'ompatibility files' to see the error log in vista/win7.
Posted by kevL's at 2011-05-17 04:13:38 Voted 10.00 on 05/19/11
( clarifications )
"specified in the code itself" should read "specified in the function itself"
iBonusHP = nBonusHP, sry. _________________________ All the world's a stage ... but so what.
Posted by kevL's at 2011-05-16 19:55:36 Voted 10.00 on 05/19/11
oh, my command line:
-glo -v1.69 _________________________ All the world's a stage ... but so what.
Posted by kevL's at 2011-05-16 19:50:19 Voted 10.00 on 05/19/11
note the commented line. If uncommented, the default compiler compiles the script and runs it from the console fine (if iBonusHP != 0, else unsuccessful); the ASC compiles the code (no errors) but *if nBonusHP is zero* (at the console) my game crashes to desktop with a Windows error message.
ps. If iBonusHP is specified in the code itself, the ASC script behaves the same as the default compiler script (no crash, only unsuccessful if iBonusHP = 0). Have not tried other Effects, only passing a variable into EffectBonusHitpoints() then turning it into a SupernaturalEffect().
Personally I don't mind the operation as it is, causing me to tighten my code with a check for nBonusHP == 0
but .. have not tried this in the TS, only with the stand-alone ASC. _________________________ All the world's a stage ... but so what.
Release 2 posted. This includes the fix for the issue when compiling scripts with the same name as a built-in script in the game zip files.
Changelog:
Release 2:
----------
- Fixed a stability issue with GUI and conditional script detection in the
toolset compiler plugin. This does not impact the standalone compiler.
- Fixed a resource prioritization issue with the toolset compiler plugin that
might result in resource files from the game data zips taking priority over
in-module files (for example, overridden scripts with the same name in the
module might not be used as expected in lieu of the in-zip versions). This
does not impact the standalone compiler.
Lunamaria, Psionic-Entity: I believe that I have a fix for this issue (where sometimes .zip resources might be used instead of resources from the module if both had the same name). Drop me a line on IRC at #nwn2cr/irc.nwn2source.net so that we can verify the fix addresses your issue, and I'll release it after that point.
This issue only impacts the toolset plugin and not the standalone compiler as it relates to how the compiler is plugged in to the toolset's resource system.
Ran this on scripts just before a stage, and it completely borked a few scripts that the standard nwn2 compiler runs just fine. (I've since tried adding and removing the plugin, the script compiles correctly during a one-off with the standard compiler, but instead creates a miniscule empty script with the advanced one, that does not fire ingame)
The script is a modified nw_c2_default7 that's been customized for our server, which may have something to do with it.
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
Site
at 2012-05-24 23:08:09
at 2011-10-29 07:38:34
at 2011-07-22 14:58:57
