195 réponses à ce sujet

[MrZork]

Thanks, guys. I just downloaded the updated toolset and am liking the improved performance. Very nice.

[ShadowM]

In the old compiler I get IDENTIFIER LIST FULL on one of my scripts, I know add a lot of includes and I can fix it, but in the new compiler I do not get this error can the new one handle more? So I do not have to worry? I pretty much work with your new setup exclusively now.

[FunkySwerve]

The new one can handle FAR more identifiers. That's actually one of the main reasons people would use it, or the PRC (Torlack) compiler, instead of the bioware compiler.

Funky

[ShadowM]

Great, that what I was hoping. Thank you for the info.

[SkywingvL]

There is no hard limit other than available memory. Performance may decrease based on the complexity of the scripts being compiled, however, so it's still worth spending a little bit of effort to reduce spurious includes.

If compatibility mode is enabled, then a warning is issued if you exceed one of the various identifier or scope limits intrinsic to the standard compiler.

The (basic) #ifdef support might help with better organizing your includes.

[virusman]

NWNTX with updated Optimizations plugin (fixed access violation in certain cases). The compiler DLL has also been updated.
http://data.virusman...-full-1.0.4.rar

There is a known issue with 2DA caching: if you open a module with one set of haks, then open another module with another set of haks, Toolset will use cached 2DAs from the first module.
So if you're using this plugin, restart the Toolset before opening another module.

Modifié par virusman, 27 novembre 2011 - 07:52 .

[Shadooow]

new version wants msvcp100.dll which is not included in the package, I tried to download it from those dll-webs, but it threw some errors, could you provide correct link?

btw: would be possible to allow set value greater than 50 into item charges field? I suspect it can handle 255, the 50 is only toolset limitation.

Modifié par ShaDoOoW, 28 novembre 2011 - 05:53 .

[virusman]

I've uploaded the updated package with msvcp100.dll included. The link is the same.

[FunkySwerve]

This is officially the best thing since sliced bread. I began testing it by reworking all of our mod's areas to fire a unified, general onenter event, with variables for certain things. This wasn't easily done with moneo, since it involved opening and reading a great number of unique onenter scripts, as well as areas and area property boxes.

It has saved me literally dozens of hours already, by my estimation, over just the short period I've been testing. MUST HAVE.

Very nice work.

Funky

[SkywingvL]

New Advanced Script Compiler (and compiler DLL, usable with the NWNTX plugin) posted. The note about the "toolset compiler plugin" below only applies to NWN2, not NWNTX for NWN1.

Release 8:
----------

- Fixed warning message NSC6019 sometimes showing an incorrect count for the
standard compiler's internal identifier limit.

- IR disassembly output (.ir and .ir-opt files in NWNScriptCompiler -d mode)
now includes the literal values of constant variables in the disassembly
text.

- The compiler no longer generates a second NSC6018 (unsupported pragma
directive ignored) for each line causing the warning to appear.

- Added support for enabling full extensions mode in the toolset compiler,
which requires the NWScript Accelerator plugin to be used server-side for
parameterized scripts to function.

- New warning NSC6021 issued in compatibility mode when a nested assigment
  where the RHS expression being assigned is itself an assignment, e.g.
  "a = b = c;", is encountered.  This does not parse properly in the
  standard compiler.

Modifié par SkywingvL, 09 décembre 2011 - 10:09 .

[virusman]

Another fix for the Optimizations plugin:
http://data.virusman...-full-1.0.5.rar

[Silvercloudjes]

I'm havin an issue where in the standard bioware toolset I can see Custom monsters with their appearances, but when i click on the same custom monster in the nwntx it will show an empty field in the appearance box and the creature appears invisible. Any ideas or is this normal?

[wyldhunt1]

While we wait for someone who may have a proper answer, I do have one idea...
Go to your NWN\\logs folder (Not logs.0). Open the nwntx_optimizations.txt file and do a text search for appearances. See if it has any error messages. Mine doesn't cache appearances.2da and I've never had an issue (And appearances is nowhere in that log file). I assume your appearances.2da is cached and something odd is happening.
Is it only happening with certain custom appearances, all custom appearances, or every appearance in the toolset? If it's only a few, I'd be curious which line numbers they were in the appearances.2da. If they are the bottom rows, it may be that nwntx has some max line number or something that it can handle...

Anyway, I know almost nothing about nwntx. If you can give more of that kind of info, it may help Virusman though.

[virusman]

Silvercloudjes wrote...

I'm havin an issue where in the standard bioware toolset I can see Custom monsters with their appearances, but when i click on the same custom monster in the nwntx it will show an empty field in the appearance box and the creature appears invisible. Any ideas or is this normal?

This is exactly the issue that was fixed in 1.0.5. Please check if you're running the latest version.

[wyldhunt1]

Or.... Virusman could already be several steps ahead of us.
I've never heard of a more efficient virus in a santa hat. Not ever.

btw: Thanks for all the cool toys you've given us Virusman and SkywingvL. Very appreciated.

Modifié par wyldhunt1, 14 décembre 2011 - 01:13 .

[OldTimeRadio]

wyldhunt1 wrote...
btw: Thanks for all the cool toys you've given us Virusman and SkywingvL. Very appreciated.

Hear! Hear!  Much appreciated work.

[henesua]

Yes, I am playing with this modified toolset too.

I am curious if the changes have only been to the compiler. It seems that the toolset is a little quicker, more responsive as well. Am I imagining that?

[edit]
Another question: Must this modified toolset always be started from the loader? Or is that only on first launch?
The reason I ask is that the loader won't run from my start menu, and I prefer to launch all my programs from there.

Modifié par henesua, 01 janvier 2012 - 12:44 .

[virusman]

Yes, NWNTX Optimizations plugin makes it more responsive.
Toolset has to be started from the loader. You can edit the Toolset shortcut to point to the loader.

[henesua]

Thanks. And again thank you for putting this together. I appreciate your work. Its a great help for me.

[wyldhunt1]

Never mind. Dumb moment.

Modifié par wyldhunt1, 07 janvier 2012 - 10:04 .

[Borden Haelven]

Is it me or have you wonderful peeps finally sorted out the "Takes ages to delete objects" problem? I've just deleted an item I got wrong and it went in a flash instead of locking up the toolset for ages. Woot!!! You've speeded up deleting scripts as well. Love you peeps.

Modifié par Borden Haelven, 21 janvier 2012 - 06:24 .

[FunkySwerve]

Heads up. I'm using a slightly older version of Skywing's compiler, but I had another of our devs check on the compiler he downloaded with the latest version of NWTX yesterday, and the problem is still there. It seems the compiler doesn't notice if implementation and declaration differ in default values. This declaration and implementation yeild no compiler errors:

fky_loot_inc (78): string GetRandomResrefLootBeyondUltraRare(int nRaceBkSlots=1, int nCraftBkSlots=7);
fky_loot_inc (2717): string GetRandomResrefLootBeyondUltraRare(int nRaceBkSlots=1, int nCraftBkSlots=2) {

And again, thanks for your work on this incredible tool.

Funky

[SkywingvL]

I will look into adding a warning about this.

However, because the standard compiler is silent about this sort of construct, there are standard scripts that will trigger the warning.

The observed behavior will be that the first declaration observed takes precedence in terms of the default values assigned.

Modifié par SkywingvL, 21 janvier 2012 - 09:15 .

[FunkySwerve]

SkywingvL wrote...

I will look into adding a warning about this.

However, because the standard compiler is silent about this sort of construct, there are standard scripts that will trigger the warning.

The observed behavior will be that the first declaration observed takes precedence in terms of the default values assigned.

Thank you very much. We'd guessed as much about the declaration, based on the behavior of C and C++ compilers, but it's good to know for sure.

[Edit] I mis-read/spoke. We'd guessed, based on the behavior of the other compilers, that the implementation, rather than the declaration, was defaulted to, but it sounds like that isn't the case.

Thanks again,
Funky

Modifié par FunkySwerve, 21 janvier 2012 - 09:26 .

[henesua]

For the record I have noticed that declarations and implementations of functions can differ in other ways as well, and not generate compile errors.