AmanoJyaku

Did you try modifying k_inc_man.nss? int QUEEDLE_TIME = 3012; int CASSANDRA_TIME = 2702; int JAX_TIME = 2548; int CHAMP_TIME = 2348;

Are you trying to record the times in a journal entry, and then retrieve them later?

Got it to work. There is no GetCustomToken because you don't need it: //SetToken.nss void main() { SetCustomToken(2000, "Hi, I'm token 2000!"); } The DLG file: Line 1 - "I am ugly." //Execute SetToken.ncs here, just as an example Line 2 - "Yes, you are very ugly." Line 3 - "I knew it. <CUSTOM2000>" The printed text: NPC - "I am ugly." //SetToken.ncs fires and sets 2000 PC - "Yes, you are very ugly." NPC - "I knew it. Hi, I'm token 2000!"

Need. More. Coffee.

I think you use the following to set up a token: Then, you use the following to retrieve a token: tl;dr GetScriptParameter(int)

It's because you're trying to add the item using an existing game. Start a new game. tl;dr KOTOR loads UT* files and saves them in the save files. Your save file doesn't have a_robe_45.uti, so it's acting weird.

One file has RSADDI in the _start() function, which I don't think is legal. But, most files seem OK at first glance. Will have to investigate some more as this is beyond the capabilities of the current analyzer.

Yep, the problem is the script is compiled so that StartCreditSequence(int) is told to accept two arguments, despite being defined as accepting one. DeNCS is failing to decompile, because the code doesn't match the function definition. It doesn't know what to do. Crappy coding. Given the fact that I've only just now seen a function call used to initialize a global, my guess is DeNCS was never written with that in mind. It's taking me forever to write my compiler/decompiler because I'm accounting for this and more. And, I still expect the finished product to have issues. 🤣

Not off-topic at all!!! My guess is because the compiled script is wrong. Look at what it does: //Simplified code void main() { StartCreditSequence(); SetGlobalBoolean(); SetGlobalFadeOut(); } So, what's wrong? The very first function: // 518: StartCreditSequence void StartCreditSequence( int bTransparentBackground ); It takes one parameter, an integer. However, look at the byte code: 04 05 0000 //CONSTS - Place Constant String Onto the Stack, 0 characters 04 03 00000000 //CONSTI - Place Constant Integer Onto the Stack, value of 0 05 00 0206 02 //ACTION - Call an Engine Routine, 0x0206 [518, or StartCreditSequence(int)], with two arguments Can you see what's wrong here? Off-Topic: Sometimes the code blocks have colored code. Then, it goes white. Why???

"Closed doors" *AmanoJyaKreia, Dark Lord of the Script, mentors DarthParametric and boosts their security skill*

Not derailed at all. This is exactly what I will encounter when I get far enough. May actually be easier to troubleshoot than the parser and lexer I'm writing. 🤣

Shouldn't matter. The game doesn't have a problem with this, it's the decompilers that do. Guess it's a good idea to create a new one, after all.

Veeeery interesting. I'm seeing the same thing in all files, so I hope it's the culprit. Basically, every NCS file I've worked on uses global variables initialized from constants. However, the files you've given me all include a global that's initialized from an engine routine! I'm wondering if DeNCS is choking on that. 0x00000c67 RSADDS 0x00000c69 CONSTI 32289 0x00000c6f ACTION 239 1 0x00000c74 CPDOWNSP -8 4 0x00000c7c MOVSP -4 // 239: Get a string from the talk table using nStrRef. string GetStringByStrRef(int nStrRef);

Interesting. It's definitely not recursion. There are only four functions: 1) _start() 2) _global() 3) main() 4) sub1() The main() function only calls sub1() once, and sub1() never calls a user-defined function. So, only an engine routine could recur. More interestingly, the file is very short and very simple. I suspect I know what the problem is, because I see something in the code I've never seen anywhere else. But, I would like to withhold assumptions until I can analyze another file that doesn't decompile. Can you supply another?

Have you looked at these mods? KOTOR 1 - https://deadlystream.com/files/category/6-mods/ KOTOR 2- https://deadlystream.com/files/category/5-mods/ If these mods aren't good enough, you will need to make your own. https://deadlystream.com/forum/25-tutorials/

Let's start over. Why are you trying to spawn NPCs? Are you trying to get XP? Are you trying to get items and equipment? Are you creating a mod? What, exactly, are you trying to do?

https://deadlystream.com/forum/25-tutorials/ Start here, then tell us where you're having trouble.

This? It extracts just fine. Download it again. Use Windows FCIV to make sure your download isn't corrupt. The checksum should be: MD5 df9877f621bd82db2b43ec4230f9394e SHA-1 2c9063151dc5175513cfc15d3b31724b9e308e26

Ooooooooooooh!!! There are issues in almost all of the tools on that site. I'm sure it's the case for NWNSSCOMP, as well, although I haven't used it myself. Don't need to, either, seeing as how the scripts you gave me are compiled incorrectly. I'm particularly concerned about this: Modified? Modified how? Where's the source? Was this reverse engineered? Etc... Given that this was worked on by three different people/groups, my guess is someone screwed up while making updates. Ah, well... All the more reason to produce a new compiler. Edit: So, I just read Torlak's old site. Here's the full description of NWNSSCOMP and it's potential problems. tl;dr, there most likely are bugs in NWNSSCOMP:

Scripts 1-5 have unreachable code (remember, I'm ignoring dead/unused code for now). Script 6 is fine, all basic blocks are reachable. How did you compile this? *triggered*

Unreachable code, by definition, should have no effect on script execution. Analysis of unreachable code is simply to facilitate analysis of reachable code.For example: 0xNNNNNNNN CPTOPSP -4 4 0xNNNNNNNN CONSTI N 0xNNNNNNNN EQUALII 0xNNNNNNNN JNZ 0xNNNNNNNN Is analyzed to see if it is a switch case label. Every case label I've seen fits this pattern, and for all but the first case label the above code is the entirety of a basic block. However, the first case label has instructions prior to CPTOPSP. It's necessary to see if such code is unreachable, and therefore part of a separate basic block, or actually a functional part of the first case's basic block. And, that's assuming it's actually a switch! It could just be an if (false) {} statement, but we have to analyze the flow to find out! I won't rule out optimizations, but I doubt they exist. They would be meaningless since NWScript isn't meant for high-performance. We aren't using NWScript to create databases, calculate protein folds, or process bank transactions. Slow code won't be noticeable, but such optimizations are error-prone and require a lot of development effort that clearly would have been better spent elsewhere.

My apologies. As with all things STEM, terminology must be accurate. I am learning compiler design in order to create this compiler/decompiler, so I am still unfamiliar with communicating this topic effectively. "Dead code" has two meanings, one more accurate than the other: Instructions that compute a value that is never used Unreachable code The red blocks do not represent "instructions that compute a value that is never used". They may fit the first definition, but I am not looking for that in these diagrams. The red blocks are "unreachable code"; they never get called, which is why they aren't preceded by another green block. Only the function entry point (the very first block in a function/subroutine) should be without a preceding block. The image above has 10 functions/subroutines, each represented by a box filled with one or more colored blocks. (Accuracy alert!!! Functions and subroutines are similar, but not identical. The difference only matters to academics and compiler designers, but this entire post is about pedantry...) Thus, there should only be 10 blocks that aren't preceded by another green block: the function entry points. If a block is in red, that's because no other block explicitly jumps to it or implicitly proceeds to it. These blocks are therefore useless, and could be removed if they serve no other purpose. x86/x86-64 uses the NOP op code to allow for instruction padding to improve memory alignment, and resulting access times. To my knowledge, such a technique has no effect in the NWScript runtime. If I am correct, then the code could be stripped. My concern is that perhaps there IS a reason for these blocks, or that the existing script compilers are riddled with bugs... Finally, these blocks are not the result of debug code. One of the switch statements in the diagram has a debug function under a case label in its source. switch(nPlanet) { case PLANET_PERAGUS: { AurPostString("ERROR: We should not be able to travel back to peragus.",0,10,5.0); } break; //Other case statements removed } The compiled case label: case 8: 0x00000ffb CPTOPSP -4 4 0x00001003 CONSTI 8 //PLANET_PERAGUS defined as 8 in nwscript.nss 0x00001009 EQUALII 0x0000100b JNZ 0x000010dd The target block in the compiled file: case 8 block 0x000010dd 0x000010dd CONSTF 0.000000 0x000010e3 CONSTI 10 0x000010e9 CONSTI 0 0x000010ef CONSTS ERROR: We should not be able to travel back to peragus. 0x0000112a ACTION 582 4 //Engine functions are zero-indexed, AurPostString() is #582, and it takes 4 parameters 0x0000112f JMP 0x0000158e Case label 8 jumps to the Case 8 block, and calls the debug function. No unreachable code here!