14 Antworten in diesem Thema

[Nasu no Yoichi]

Is there an nwscript.nss file (or equivalent) for DAO available, as there is for NWN? I'd like to try porting the decompiler portion of nwnnsscomp.exe, and starting out with the definitions of all the constants would make my life way easier.

[DarthParametric]

Yes. Open <install dir>\packages\core\data\scripts.erf which contains script.ldf and cscript.ldf. I gather script.ldf is the one you are after.

[Nasu no Yoichi]

Thanks heaps. I think I actually want both of them, by the looks of it. In other good news, DA2 has equivalent files in the equivalent location, too =)

[DarthGizka]

script.ldf is the one you want. cscript.ldf is for the client scripting engine.

The format used by nwnsscomp is different from the one used in DAO's script.ldf.

I converted the information in the extant DAO script.ldf versions to the nwnsscomp format when I farted around with that program to learn more about the object file format. See nwscript.nss for DAO in my pastebin. I couldn't prevent the wrapping, so you may have to fix it up a bit.

[Nasu no Yoichi]

script.ldf is the one you want. cscript.ldf is for the client scripting engine.

So I have discovered.
 

The format used by nwnsscomp is different from the one used in DAO's script.ldf.

Yes, I know nwnnsscomp/script.ldf from NWN uses the function declaration order instead of assigning the opcode to the declaration. Which is kind of disgusting. I've ended up parsing DAO's script.ldf instead of mangling it into NWN's format. The latter would have been quicker to get working but not as clean and lots of nwnnsscomp needed rewriting or refactoring anyway IMO.
 

I converted the information in the extant DAO script.ldf versions to the nwnsscomp format when I farted around with that program to learn more about the object file format. See nwscript.nss for DAO in my pastebin. I couldn't prevent the wrapping, so you may have to fix it up a bit.

Oh, thanks. Really good to have those undocumented actions

I have some scripts disassembling (bytecode.ncs -> instructions.pcode) properly now but need to run more tests. And there's a few instructions I haven't got quite right yet.
Writing a proper decompiler (instructions.pcode -> source.nss) is going to be the tricky part

[DarthGizka]

There's source code out there for various versions of nwnsscomp, and lots of useful code in the SourceForge repositories for Aurora-related libraries.

Decompiling stuff is right down my alley. In first approximation it would be useful to have a tool that makes the information contained in byte code files human-readable/human-understandable in some form (even if not recompilable). Recoding smaller portions of code manually should be no problem at all then, but bulk processing is a different thing. Hence in second approximation we could use a two-way disassembler/assembler, because this makes it easy to achieve 100% correctness and automatic verifiability. A full decompiler would certainly be a very rewarding project but as far as bang/buck ratios go we do have a couple swarms of other fish to fry - what with DA:I coming up and all.

[Sunjammer]

Will there be any benefit for DAI? It is a totally different engine and presumably had its own scripting language. Is there any reason to think they have tacked the archaic nwscript virtual machine into the Frostbyte engine?

[DarthGizka]

The scripting layer sits atop the raw engine, and it is intertwined with other parts of the Bioware/EA infrastructure. So the idea of NWScript making a reapparance in DA:I may not be so outlandish after all.

However, my point was that tackling DA:I - whatever scripting system it may use - will drain resources from DA:O and DA2 efforts. A while later, people might even drift back to DA:O/DA2 and start new projects there. For now I just don't see it.

[MerAnne]

..... A full decompiler would certainly be a very rewarding project but as far as bang/buck ratios go we do have a couple swarms of other fish to fry - what with DA:I coming up and all.

 

Since DA:I won't have a toolset (Bioware has said this many times - or put the vague possibility of having a toolset into the far distant and vague future), the only 'fish to fry' that I can see is for some to spend time playing DA:I rather than modding DAO/DA2.  I'm sure that there will be a few who will be capable of writing mods for  DA:I - other than appearance mods - but I don't see writing mods for DA:I being something that most people who write mods for DAO will do.

[DarthGizka]

The raw mechanics of DA:I modding are bound to be trickier than for DA:O but the same was already true for DA2. Also, there are already many tools out there for Frostbyte games, and lots of experience of modding such games without any support by the game developer.

 

Also, there's mods and mods... Big mods need lots of authoring support to be practical, and their authors tend to pick a particular platform (NWN, DAO) based on how suitable it is for realising their project. Such mods might never appear for DA:I but mods which are really just that - modifications - are bound to appear in a matter of hours or days from now. Convenience/vanity items, little helpers, bug fixes. And the wherewithal for arcane studies.

[Sunjammer]

... it is intertwined with other parts of the Bioware/EA infrastructure ...

I'm intrigued to know what these are: do you have some examples?

[Nasu no Yoichi]

Hence in second approximation we could use a two-way disassembler/assembler, because this makes it easy to achieve 100% correctness and automatic verifiability.

That's my aim for now - AFAIK you can't guaranteed binary comptibility between original bytecode and fully decompiled and then recompiled bytecode, and disasembling/reassembling is a much easier task anyway.
 

A full decompiler would certainly be a very rewarding project but as far as bang/buck ratios go we do have a couple swarms of other fish to fry - what with DA:I coming up and all.

Between playing DA:I and inevitable ad-hoc bugfixing I don't doubt many people will have their attention focused on DA:I for a while.
 

The raw mechanics of DA:I modding are bound to be trickier than for DA:O but the same was already true for DA2. Also, there are already many tools out there for Frostbyte games, and lots of experience of modding such games without any support by the game developer.

I hear Frostbyte 3 in particular is supposed to be very challenging to work with. Should be interesting to see how it goes.

[DarthGizka]

I'm intrigued to know what these are: do you have some examples?

 
Well, there are the obvious traces that you can see in the toolset. The toolset itself is a giant plug in search of a network socket. In the actual game scripts you see a logging infrastructure and telemetry (sending stuff to Georg's server, if I recall correctly). The client scripts are for QA, obviously. They also tap into the infrastructure.
 
Most of the client script functionality and a good part of the game script functionality relating to the inhouse phase are disabled in the shipped game, or suppressed via conditional compilation. Hence I wouldn't have found more than rudiments and stubs in the binaries, if I were the disassembling type.
 
Scripting and the M2DA system form a thin layer atop the raw engine, yet they contain 100% of the actual game. Conceptually and asymptotically you could switch the engine beneath that layer, convert the assets, and play the same game on the new engine. Much like you can fit different engines into one and the same car. Conversely, you can build lots of different cars based on a single engine and basic frame (see EA's drive for unifying/standardising system components like engines).
 
If I were of a spelunking persuasion then I might have undertaken long wanderings in the dark bowels of the mountain. But one's mind would have been on other things during such excursions, noting strange rock formations and curious strata in passing but not recording them in expedition journals.
 
In a few hours we will have hard facts before us in any case, which rather takes the wind out of speculation about hypothetical fact-finding missions and reading the tea leaves of scarce, contradictory evidence on the 'net. Speaking of things to come: in the coming months we could use pub where we can exchange hypotheses more freely, without having to couch everything in politically correct terms...

 

P.S. re speculation: I heard that Frostbyte has a mature production system/pipeline with one-click installation. I.e. you click their phone number and then guys in dark suits come and work for a couple of weeks to cobble it all together...

[Sunjammer]

Unfortunately I'm not seeing anything in what you said that indicates that the nwscript virtual machine interacts with anything other than the game engine and that engine is not being used anymore.

[Nasu no Yoichi]

A few hours for some, maybe. Down under I have to wait until the 21st...

Unfortunately I'm not seeing anything in what you said that indicates that the nwscript virtual machine interacts with anything other than the game engine and that engine is not being used anymore.

The way I interpreted DarthGizka's claim is that the NWScript system is somewhat abstracted from the game engine itself and obviously there has been a ton of asset production by non-programmers (at Bioware for the last X years) aimed at sitting on top of the NWS system, so it is possible ("not so outlandish") that BioWare have kept and or updated the NWScript system in some form, running on top of Frostbyte3. I don't know enough about Frostbyte3 to comment further on the quality or likelihood of doing that.

Speaking of things to come: in the coming months we could use pub where we can exchange hypotheses more freely, without having to couch everything in politically correct terms...

Indeed, indeed.

P.S. re speculation: I heard that Frostbyte has a mature production system/pipeline with one-click installation. I.e. you click their phone number and then guys in dark suits come and work for a couple of weeks to cobble it all together...

Kekeke.