116 Antworten in diesem Thema

[painofdungeoneternal]

pm kaedrin, he is allowing folks to have his source code. He probably will either support your module or explain how to do it. I have no idea why you need his source to use his code, usually end users can install his content as needed and it just works, and end users should be able to update it periodically as well without your help. ( assuming you use the standard event scripts )

He does not like it when people change his scripts, and end up botching everything and then don't support their changes. He ends up getting a lot of users coming to him for help and after way too much effort wasting his time, they reveal they are not using his scripts but something which is not even set up properly. This has been going on for a long time.

He basically is not letting those who were wasting his time get his source anymore, if you are not one of those people he emails the source as needed.

If you need his source files, you need to talk to kaedrin, not skywing. Just send him a PM.

[John McA]

Painofdungeoneternal,

if you need to know the details, the pack includes ncs files not nss files so I cannot see the scripts. I am using custom feats to cast about six spells and need to modify those spells so they work for those with zero caster levels. But since I was going to support the Kaedrin pack, users of that might get annoyed if my updates to broken standard scripts result in casting of broken spells. He already just kindly gave me the fix for darkvision which I have implemented separately. I didn't want to bother him with six other script requests. That was the only reason why I wanted someone to tell me how to use the advanced script compiler to decompile a single script. I have created about 10 large modules in NWN and NWN2 and am not in the habit of wasting people's time.

Anyway thanks for the lecture.

JM

[painofdungeoneternal]

Ok you don't want to pm him.

He SAID to pm him.

He has sent me those nss files, since i needed the same thing. He sends me a copy whenever he's got another version up. I will not however let others have those since he wanted to choose who gets them, nor is decompiling his ncs files a work around since he is offering to email them when needed.

He prefers to do this because it means he can review what you are doing and prevent wasting much more of his time via end users having borked versions of his content.

[dunahan_schwerterkueste_de]

I had thought to convert this compiler as an Android App. So I could compile my Scripts while I'm on my way home
So may I ask? Is the source code available and usable for this purpose?

Sorry for my bad english, it's been a long time since school XD

[SkywingvL]

Yes.

http://social.biowar...9/index/3116521 has a recent drop of it.

Bearbeitet von SkywingvL, 08 Januar 2013 - 04:19 .

[dunahan_schwerterkueste_de]

Thank you very much! I will take a look and leave a post, if I can't get through.

[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.

Bearbeitet von SkywingvL, 02 März 2013 - 07:32 .

[kevL]

zzip!

thanks Sky.


Say, I just realized I have all my base game scripted resources in my Override, but the #includes are strewn about in various subdirectories. So presently I'm using

-l

to load the base resources (which gets really taxing on my system when I compile my entire Override from a batchfile: load, unload, load, unload as it recurses subdirectories). I removed -l and tried out

-i path[;path...]

and that works great -- except I have ~6 very long path strings (that can also change at any time). So I'm wondering, is there a way to use -i path_to_dir

and then let the ASC search subdirectories for #includes?

[SkywingvL]

You can compile multiple scripts with the same NWNScriptCompiler.exe invocation, which will avoid loading/unloading things every time. Use -b to specify the output directory and then specify as many files/wildcard patterns for input as desired (not all need be in the same directory).

Subdirectories are searched if they are a part of a module directory itself that is being loaded, or part of the resource system initialized to match the game's resource loading strategy if -l is used. The -i include file directories option is handled more like your C compiler would, just a semicolon-delimited list of include directories to search without recursion. (It's also okay to use -i multiple times, the list appends, the same as -i path1;path2.)

[kevL]

SkywingvL wrote...

You can compile multiple scripts with the same NWNScriptCompiler.exe invocation, which will avoid loading/unloading things every time.

yes. I've been using *.nss as input for some time ... but without the -b switch, and it works great when compiling a single directory full of mixed files.

Use -b to specify the output directory and then specify as many files/wildcard patterns for input as desired (not all need be in the same directory).

But... using the -b switch it seems I have to list out the input files and what directories they're in(?) Because *.nss as input gives output files like "script.nss.ncs" ( yet correctly names the output as "script.ncs" when not using -b ) And this still leaves an issue, for me, of automatically recursing subdirectories

- just a note, unless i'm overlooking something else .... -b keeps appending ".nss.ncs" onto wildcarded scriptnames. :\\

- typical command line:
currentDir>f:\\asc -gl -b . -y *.nss

[SkywingvL]

No, -b isn't supposed to do that; this sounds like a bug. I'll try and look into that soon, as it is supposed to turn .nss into .ncs for the output extension.

[kevL]

sounds like my old habit coming back : in the '90s i could crash a computer just by doing, you know, regular stuff...

:|_~



edit, still working otherwise fine as ever, SvL

Bearbeitet von kevL, 03 März 2013 - 11:30 .

[SkywingvL]

Release 14 fixes this, if you download it from the usual link. The problem occurs only when using wildcards with -b.

[kevL]

test good.

ps. Don't laugh ->

for /r . %%1 in (.) do f:\\asc -aglo -i . -v1.69 -y "%%1\\*.nss"

- now that i look at it, I just have to expand -i to include the #includes ... (then -l can be taken out

[CromFr]

I made a package for sublime text to write and build NWScript using the advanced script compiler
https://github.com/C...verwinterScript

This package provides :
- Syntax Highlighting
- Auto completion for NWScript built-in constants
- Auto completion for NWScript built-in functions with their arguments
- Quick build with the AdvancedScriptCompiler (for Windows or Linux using wine)

Hope this might be useful
(Also, thanks Skywing for this awesome compiler !)

Bearbeitet von CromFr, 21 August 2013 - 10:16 .

[SkywingvL]

Release 15 posted. New NWNScriptCompiler.exe (standalone command line compiler executable) and NWNScriptCompiler.ndl (for toolset plugin users).

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.

[Dann-J]

Does this utility also decompile NCS files, if you don't have the NSS?

At the moment I'm using a version of nwnnsscomp that was modified for Star Wars: KotOR to not require a specific game installed on your machine (nwnnsscomp_st). It works if I copy the NWN2 version of nwscript.NSS into the same directory, although it decompiles to .pcode format that is difficult to make sense of (although at least you can see what functions are being called).

[Morbane]

don't think so Dann - when kevL sees ur post he'll confirm - he is an avid user (Skywing ain't 'round so much lately)

[kevL]

yes it has -d parameter. Disassemble the script (overrides -c Compile)

never tried it tho.

[Dann-J]

kevL wrote...

yes it has -d parameter. Disassemble the script (overrides -c Compile)

never tried it tho.

Well, it works - but the ASC also decompiles to pcode, rather than NSS.

[kevL]

hehe

I looked into decompiling once.. upon a time.. then figured my time would be better spent counting grains of sand on a beach in Maui -- with tweezers and a blindfold and a 500 lb. gorilla on rabies nearby.

[Morbane]

GM: You see a huge gorilla. It looks like it is on rabies.

Thief/Acrobat: Well I take downers; helps me stay steady. Perchance we can exchange dealer cell numbers?

GM: *sigh* 

Thief/Acrobat: I would LOVE to have a poison bite!! 

Bearbeitet von Morbane, 30 Januar 2014 - 02:31 .

[Morbane]

GM: The gorilla is ambling toward you, it has a bloody tweezers caught in its teeth.

Dwarf: Befriend the gorilla by pulling out the tweezers.

GM: ............

[SkywingvL]

I've re-released the version 15 release to fix an embarassing crash bug. Sorry about that!

DannJ: Yes, you can disassemble a script. As with nwnnsscomp, -d will give you a .pcode file that is (basically) an NWScript assembly language listing of the script. You need to tell the compiler how to load nwscript.nss for the script in order for this to work, so continue to use -l (or a path to nwscript.nss with -i). This is necessary for the static analysis package to function (producing the .ir and .ir-opt files as you'll see below).

In addition to the pcode output, you get two more files:

- A <script>.ir file, which is an "intermediate representation" of the script after running the NWScript binary through a static analysis package that is used by the NWScript accelerator to JIT the script to .NET code. The script's IR is sometimes easier to read than the raw NWScript assembly language listing, as the static analysis engine discovers functions, flattens the script stack out into variables, etc. Basically speaking, each "variable" here corresponds to a logical location on the NWScript stack.

- A <script>.ir-opt file, which is again an intermediate representation of the analyzed script, but after running the compiled script through an internal optimization pass to fold variables that were purely temporaries together into merged variables. This is often easier to read than the .ir file.


Here is an example that you might see for a function in NWScript:

struct Struct2 Function1()
{
struct Struct2 Variable;

Variable.Value = 0;

return Variable;
}

The NWScript assembly listing for this function might look something like so (i.e. the "pcode" output that you would get in the .pcode file):

00000037 02 03 RSADDI

00000039 04 03 00000000 CONSTI 00000000

0000003F 01 01 FFFFFFF8 0004 CPDOWNSP FFFFFFF8, 0004

00000047 1B 00 FFFFFFFC MOVSP FFFFFFFC

0000004D 03 01 FFFFFFFC 0004 CPTOPSP FFFFFFFC, 0004

00000055 01 01 FFFFFFF4 0004 CPDOWNSP FFFFFFF4, 0004

0000005D 1B 00 FFFFFFF8 MOVSP FFFFFFF8

00000063 1D 00 0000000C JMP off_0000006F

00000069 1B 00 FFFFFFFC MOVSP FFFFFFFC

0000006F 20 00 RETN


The .ir file listing for this function would be something like this (note that the disassembler can only give you a name for a function if you had a .ndb file as I did here):

Printing IR for function 0000002A (Function1)
label 0000002A:
0000002A: CREATE 097B40F0 ( temp int )
0000002A: INITIALIZE 097B40F0 ( temp int )
0000002C: CREATE 097ABFC0 ( temp SSA int )
0000002C: ASSIGN 097ABFC0 ( temp SSA int ), 097B4248 ( const int ) [0]
00000032: ASSIGN 097B40F0 ( temp int ), 097ABFC0 ( temp SSA int )
0000003A: DELETE 097ABFC0 ( temp SSA int )
00000040: CREATE 097B44B0 ( temp SSA int )
00000040: ASSIGN 097B44B0 ( temp SSA int ), 097B40F0 ( temp int )
00000048: ASSIGN 0979B7B0 ( retval int ), 097B44B0 ( temp SSA int )
00000050: DELETE 097B44B0 ( temp SSA int )
00000050: DELETE 097B40F0 ( temp int )
goto 00000062
label 00000062:
00000062: RETN

And the .ir-opt file listing for this same function would look like so:

Printing IR for function 0000002A (Function1)
label 0000002A:
0000002A: CREATE 097AEC20 ( temp int )
00000032: ASSIGN 097AEC20 ( temp int ), 097AED78 ( merged const int ) [0]
00000048: ASSIGN 0979AAF8 ( retval int ), 097AEC20 ( merged temp int )
00000050: DELETE 097AEC20 ( temp int )
goto 00000062
label 00000062:
00000062: RETN



If you really wanted something easier to read for a script, you could grab the NWScript Accelerator NWNX4 plugin, install it on a dedicated server instance with NWNX4 in use, set CodeGenOutputDirectory= to point to a writeable directory and run the script from that server instance. That would generate a managed code .DLL for the JIT'd-to-.NET script in the CodeGenOutputDirectory. You could run this through one of the .NET disassembly tools to see if it could produce a C# representation that's easier to read. (Or ILDasm if you prefer to read MSIL instead.)

But these are fairly esoteric use cases... unless you're working on the compiler (like I am), or the NWScript JIT system (like I am), you're probably not going to need that level of detail.

Given a .ndb file and the .ir-opt file, and some familarity with what's going on under the hood with how the NWScript instruction set works (and the IR for my script analysis library), you can usually get a fairly feel for what's going on, but it's not by any means for the faint of heart.

Bearbeitet von SkywingvL, 30 Januar 2014 - 05:53 .

[kevL]

GM: you see a 500 lb. gorilla ambling toward you ...


jk!