NWNTX : remove compiler plug-in?

[Legacy_Proleric]

               

I started using NWNTX as a wrapper for the toolset, because it gives major performance benefits.


Areas load at least 4 times faster, conversations load and resources delete instantly, even the dreaded Faction Editor build runs much faster.


Just wondering, though - is it possible to run NWNTX without the compiler plug-in? I don't really need it.


Postscript - in brief, the answer is "yes" unless hitting issues with the Bioware compiler mentioned below.

               
               

               
            

[Legacy_Proleric]

               

So far, removing the three files with "compiler" in the name seems to work, giving all the performance improvements, plus the vanilla Bioware compiler.

 

If anyone knows of a good reason not to do this, please advise!

               
               

               
            

[Legacy_Grymlorde]

               

So far, removing the three files with "compiler" in the name seems to work, giving all the performance improvements, plus the vanilla Bioware compiler.

 

If anyone knows of a good reason not to do this, please advise!

 

Are you unhappy with the NWNTX compiler? I recently switched to NWNTX and found similar performance gains and haven't had any issues with the compiler so far. . . but now I'm wondering what I should beware of.

               
               

               
            

[Legacy_henesua]

               

the compiler is the primary reason for using nwntx. its awesome.

               
               

               
            

[Legacy_Proleric]

               No, I've found no bugs in the compiler, but no advantage, either.


NWN-TX seems to work fine without it.


My policy is "if it ain't bust, don't fix it". Also, I'm too lazy to learn the new set of error messages, which seem no less cryptic than the vanilla compiler.
               
               

               
            

[Baaleos]

               

But the vanilla compiler is bust .. . .

That was the motivation behind the nwntx compiler being created.

The new compiler also gives more detailed messages, describing the reason for compile time errors in more detail.

 

The vanilla compiler has difficulty in spotting certain compile time faults and has limited memory space when it comes to include files.

For a small uncomplicated PW Server, vanilla will be fine, but you will not be able to get any advanced / impressive systems developed within the PW that uses include files with hundreds of methods and consts.

 

My own PW Server was fine with Shayans subrace engine,

but then I started writing my own Vampire Bloodline system - which integrated with shayans engine, then I found that the compiler could not handle the combined include files of my bloodline system and Shayans (at the same time)

 

7 Years later, I have a Bloodline System, a Post-Level 40 System, a rift system, an afterlife and alternative dimension system, a God/Deity System, Forum Integration and Integration with .Net WebServices for E-mails and other complex external systems.

None of those systems could be compiled by vanilla compiler without getting an IDENTIFIER LIST FULL error.

               
               

               
            

[Legacy_meaglyn]

               

This is not completely true.  While it is true the vanilla compiler has a limit on the number of symbols it can handle in a compilation unit (it's 8192 but most are used up by nwscript.nss itself, leaving 1800 or so), this can be dealt with by good code design and the use of ExecuteScript instead of direct function calls. You do not need to have all your scripts include everything and you can break things up and limit the excessive use of constants.

 

You can create any cool system you want using the vanilla compiler, you just have to design it well. And/or be willing to rework the includes as needed. It takes a little discipline but otherwise is not really much of a problem.  That said, I did add code to my out of tree compiler to report the number of symbols and optionally list them to make it easy to see when I've messed up and written something that won't compile with vanilla. Without that it would be very frustrating to debug...

               
               

               
            

[Baaleos]

               

This is not completely true.  While it is true the vanilla compiler has a limit on the number of symbols it can handle in a compilation unit (it's 8192 but most are used up by nwscript.nss itself, leaving 1800 or so), this can be dealt with by good code design and the use of ExecuteScript instead of direct function calls. You do not need to have all your scripts include everything and you can break things up and limit the excessive use of constants.

 

While decoupling and shrinking large god methods into smaller methods is ideal - its not always possible.

It is also very impractical when trying to work with a subrace engine which is already very mature and has alot of linkages already.

So yes - I agree that ExecuteScript is a good work around.

However that work around can adversely affect the design of your code.

 

Eg: If you need to get variables to the calling script, you will then have to export them as local vars so the calling script can get visibility of them.

 

My advice is that people use the nwntx compiler, and then just plan their code properly - avoiding god methods and adhering to good design principles.

Using ExecuteScript should be used when intended, not as a work around for a limitation of the compiler.

There can be instances where you just need to use quite alot of include files.

I personally find it reassuring that I will never hit any limit on include files - because I use the nwntx compiler.

 

Its almost like saying:

​The compiler doesn't allow me to use the number 5, so I pass in 2 and 3 and then add them up, to get 5 - to achieve the same result as using 5 in a functional compiler.

​(Highly exaggerated example.)

 

 

 

It should be noted that large include files do not bloat your ncs files.

When compiling - your ncs files take only the pieces of code that are relevant to them.

So at runtime - there is no difference between using vanilla or nwntx - other than the fact that nwntx compiler can give you more freedom for framework design.

               
               

               
            

[Legacy_Proleric]

               

But the vanilla compiler is bust .. . .

...None of those systems could be compiled by vanilla compiler without getting an IDENTIFIER LIST FULL error.

 

Interesting.

 

I've never encounted that in SP, but it's worth knowing that I could implement the new compiler if I ever hit that barrier.

 

Until that happens, though, I don't really have an incentive (unlike the toolset performance issues, which are a compelling reason to adopt NWNTX right now).

 

As a more general observation, while we are very fortunate as a community in having a wealth of excellent tools and add-ons, it's not always easy to discover key reasons for using them.

               
               

               
            

[Baaleos]

               

That being said - I think the spirit of nwn was to make it as mod-able as possible.

So the developers were key in making it as easy to mod too.

Eg: Providing the community with symbols - which led to the creation of nwnx plugins.

 

nwntx though - hats off to Virusman, who saw the problem faced by individuals who were not familiar with the advanced compiler, and was able to integrate the advanced compiler into the nwn toolset GUI.

 

Now using the advanced compiler is as easy as using the vanilla compiler.

               
               

               
            

[Legacy_meaglyn]

               

Using ExecuteScript can be done with a wrapper which handles the arguments when there are a many. You can also often reduce the number of arguments needed by drawing the line in a different place. You can then have an include that only does that for your subsystem (or subsubsystem,,,). It also allows you to use a subset of your code more easily.  It leads to a more modular code design.


I'm not trying to give you a hard time friend but you were claiming that all these cool things like the stuff you have in your PW can't be done with the vanilla compiler. And I disagree.  You said none of those systems could be compiled with the vanilla compiler. I have no doubt that is true as they are written. I suspect they could be rewritten to work with the vanilla compiler if you wanted them to. I don't particularly care which compiler you use, though. Just don't make claims that things as cool as yours can't be done with the base compiler...

 

As to using the nwntx compiler in the toolset... I have never had that work when using it through wine, which I have to do to run it on Linux. So It's not quite as easy as all that  '>

Also, what's with the white on white text (in your earlier post)?  Makes it really hard to read in the dark theme '>

               
               

               
            

[Baaleos]

               

I did not mean to imply that they cannot be developed in vanilla compiler.

I do however mean to imply that the vanilla compiler cannot handle them in their finished state.

 

As stated - this is a technical limitation of the compiler and I see no need to redesign a functional system in my PW to accommodate what I perceive as a bug in Biowares compiler.

If something is broken and you have a fix for it - why not fix it. Opposed to allowing the broken tool to contaminate your product by influencing its design.

 

 

White on White text? I don't see any? (not being sarcastic, I don't recall putting any white text in)

               
               

               
            

[Legacy_Failed.Bard]

               

Having an option in nwntx to select the compiler used, since there are a few different ones out nowadays, would be the ideal, I think.


The advanced compilers, like the one in nwntx, do allow things that the vanilla ones don't, especially in for loops.  Having the option to use those for objects, effects, and floats in addition to the int type the vanilla compiler allows, is a nice option when coding.

               
               

               
            

[Legacy_meaglyn]

               

White on White text? I don't see any? (not being sarcastic, I don't recall putting any white text in)

 

It's on a white background.  The default foreground color on the dark theme is a very light grey, almost white.  So when the text has a white background I have to select it to see it. This was in your first response quoting me - and including the part you quoted. I don't know if maybe you cut and pasted some of it? Some of the text does not have a white background. Maybe a forum bug...

 

As to the compiler... Fair enough. I put some (admittedly only a few at this point) of my systems on the vault and I make it a rule that those are compilable on vanilla (i.e. the tools I know everyone has). I suppose it would be different for code that you were the only one who ever needs to compile it.

 

Cheers.

               
               

               
            

[Legacy_virusman]

               

Yeah, just delete or move nwntx_*.dll files for plugins you don't want to use. Some people prefer to disable Optimizations plugin, as it has some limitations (you should restart the toolset before loading another module, or it'll use the resource cache from the previous module and that may crash or corrupt the module very quickly).

The advanced compiler was developed by Skywing and is very stable. It also compiles 2-3 times faster and produces more optimized bytecode.

 

Having an option in nwntx to select the compiler used, since there are a few different ones out nowadays, would be the ideal, I think.


The advanced compilers, like the one in nwntx, do allow things that the vanilla ones don't, especially in for loops.  Having the option to use those for objects, effects, and floats in addition to the int type the vanilla compiler allows, is a nice option when coding.

I haven't seen other compilers available as libraries, but NWNTX is open source, so you can link it to any other compiler with the same API, or, even better, compile your own compiler DLL with the same exports to replace the one that comes with NWNTX.