DarthParametric

Modders
 View Profile  See their activity

  • Content Count

    4,607

  • Joined

  • Last visited

  • Days Won

    521

Everything posted by DarthParametric

  1. DarthParametric
    It's ok, if completely overhyped. It is the best thing to come out of the Disney Star Wars era by a large margin though, so I guess that shouldn't be too surprising. If you've ever seen Eddie Murphy's skit about a starving man in a desert being given a cracker, you know what to expect.
  2. DarthParametric
    Note that since Bioware's compiler (and nwnnsscomp too) pull in all globals listed in listed includes, the script doesn't actually need to make any use of RACE_DEFAULT. Simply being in the global list is enough to bork it. Which is why half the Tatooine and Manaan scripts don't decompile, despite none of them appearing to actually make use of it (not that I have seen anyway). Doing this: #include "k_inc_tat" void main() { } is enough to choke DeNCS.
  3. DarthParametric
    Nope, still fails. I'd already hex edited it to replace that, as with all other Tatooine/Manaan module scripts. There are a number that still fail to decompile for unknown (to me anyway) reasons.
  4. DarthParametric
    You can start a new game if you want, although that's a bit extreme for a simple Bowcaster. If you have a burning need to add it to a store inventory rather than simply directly to your own via KSE, like I said you can either edit the save file or use a script to add it.
  5. DarthParametric
    You don't need to do this. The G vs G1 was merely Bioware's internal reference for differentiating items added in the Yavin DLC. Whatever you call it, the UTI filename (ResRef) should match the TemplateResRef field. Ideally for items you should also keep the Tag the same, although that is primarily for scripting purposes. This is the real problem. It doesn't matter. All three inventories are added to your save on the very first visit to Yavin. The only way to add it in a later save is either via script, or editing the save.
  6. DarthParametric
    No, that one still doesn't decompile.
  7. DarthParametric
    Indeed, but better late than never. Hopefully most/all of the remaining ones will be able to be decompiled eventually as well.
  8. DarthParametric
    Thanks to AmanoJyaku's input, there's now a hacky workaround for decompiling most of the problematic Tatooine and Manaan scripts. Some still won't decompile, but these should be all of the relevant ones that fail specifically due to one of the globals in the Tatooine/Manaan includes. Tatooine_Swoop_Registration_(tat_m17ae)_Scripts_Using_Include.7z Manaan_Ahto_East_(manm26ab)_Scripts_Using_Include.7z
  9. DarthParametric
    Depends on how exactly the BarkString function works. Since, results-wise, it performs exactly the same as calling a DLG with a single node, it's probably just passing the StrRef to the engine's conversation system in the same manner as when it parses a DLG.
  10. DarthParametric
    What happens if you call it as a BarkString? I assume the same thing, which would presumably mean it only works in a DLG.
  11. DarthParametric
    GetScriptParameter is a TSL function. Salk is talking about K1.
  12. DarthParametric
    Add new lines to the TLK that are just the <CUSTOMxx> identifiers. Then use GetStringByStrRef(nStrRef) to pull the value as a string. You can use GetStringLeft/GetStringRight and StringToInt if you need to break it up into its mins/secs/milliseconds components.
  13. DarthParametric
    Your UTI appears to lack a file extension. Add .uti to the end.
  14. DarthParametric
    Per some discussion we were having about this in the Mod Development channel of the /r/kotor Discord, is it actually nwnnsscomp that is choking? I'm kind of hazy on how exactly it works, but my assumption is that DeNCS calls nwnnsscomp to decompile the NCS into bytecode, it then converts that into a script, then it calls nwnnsscomp to compile and decompile that and compares that bytecode back to the original's. I would be interested to know what DeNCS would do if you could feed it the bytecode from ncsdis, since that apparently is able to generate it from that script. But the recompiling step would be a roadblock. Edit: Hrm, trying nwnnsscomp directly it seems not to be the case. It can apparently produce bytecode for those scripts just fine: 00000C67 02 05 RSADDS 00000C69 04 03 00007E21 CONSTI 00007E21 00000C6F 05 00 00EF 01 ACTION GetStringByStrRef(00EF), 01 00000C74 01 01 FFFFFFF8 0004 CPDOWNSP FFFFFFF8, 0004 00000C7C 1B 00 FFFFFFFC MOVSP FFFFFFFC So I guess it really is all down to DeNCS. Did you get a chance to have a look at that third set of non-decompiling scripts btw? Going through some of the Tatooine modules I also found some new ones that still fail after hex editing them to remove the GetStringByStrRef from the include (although I gather a couple of them could just be recursion): Additional_04.7z
  15. DarthParametric
    Both games are chock full of bad lightmapping. K1CP & K2CP have addressed some of the worst of it, but not all.
  16. DarthParametric
    They tried to use a (blank) string instead of an int? Or a string and an int.
  17. DarthParametric
    In Dorak's little quiz, I was always more of the "bash the door down" type of guy rather than one of those "pick the lock" or "knock" losers.
  18. DarthParametric
    I can confirm that your appraisal was correct. At least with the two files I have tried so far. If I hex edit them and replace 03 00 00 7E 21 05 00 00 EF 01 with 05 00 0E 44 45 43 4F 4D 50 5F 52 45 50 4C 41 43 45 (effectively replacing string RACE_DEFAULT = GetStringByStrRef(32289); with string TEST_REPLACE = "DECOMP_REPLACE";) then DeNCS decompiles them. Many thanks, this will open up a lot of previously closed doors.
  19. DarthParametric
    Here's the source if that helps. I removed an include function to see if that was it and it still fails to decompile. Also tried not declaring GetUserDefinedEventNumber() as an int and just popping it directly in the switch, but again still fails. Although the ncsdis error has now changed to Unbalanced stack in block fork merge @000001AB: 1 != 4 void main() { switch (GetUserDefinedEventNumber()) { case 50: object oTrask = GetPartyMemberByIndex(1); object oPC = GetFirstPC(); location lTraskSp = Location(Vector(16.34,20.5,-1.27), 180.0); DelayCommand(0.25, AssignCommand(oTrask, ActionDoCommand(SetFacingPoint(GetPosition(oPC))))); DelayCommand(0.6, AssignCommand(oTrask, ActionStartConversation(oPC, "", FALSE, CONVERSATION_TYPE_CINEMATIC, TRUE))); SetGlobalFadeIn(0.9, 0.5); break; } } Apologies AmanoJyaku for derailing your thread. I appreciate you confirming my suspicions regarding the problem being something to do with the includes by the way. It's nice to have that mystery finally resolved. cp_end_trasksp_d.7z
  20. DarthParametric
    I went through some of K1CP's own scripts and found a few that won't decompile. Running them through ncsdis, cp_end_trasksp_d produces a message I haven't seen before - "WARNING: Script analysis failed Because: Unbalanced stack in block fork merge @00000464: 2 != 5". It looks like cp_tar_brejikatk is recursion, but that one is actually just a renamed vanilla file. Non-decompile_additional.7z
  21. DarthParametric
    Presumably not coincidentally, both the Tatooine and Manaan module includes contain the following in their constants list: string RACE_DEFAULT = GetStringByStrRef(32289); And, as discussed previously, we know Bioware's compiler pulled in all constants from any listed includes, regardless of whether they were required or not. @JCarter426 also determined that the KOTOR nwnnsscomp also does this, despite the original NWN version being fixed to prevent that.
  22. DarthParametric
    Sure. Here's another short one from the very same conversation: Non-decompiling_same_convo.7z And here are some other ones that we came across developing K1CP v1.8. Mostly module OnEnters and OnHeartbeats that have a bit more going on, but also some smaller trigger scripts and the like. Mostly from Tatooine, but there are also a couple of Manaan ones: Other_non-decompiling.7z
  23. DarthParametric
    Once your work is far enough along and you have a spare moment @AmanoJyaku, I'm curious if you can finally resolve the problem I mentioned above regarding DeNCS choking on decompiling some scripts that doesn't seem related to recursion (or at least ncsdis doesn't report it). I just found another one (attached if you are curious) as I was poking through various things, again from Tatooine which seems to be heavily affected by the issue, so it reminded me. I'm extremely curious to know the whys and wherefores. Non-decompilable_script.7z
  24. DarthParametric
    @jc2 Try editing appearance.2da and changing the 2nd and 3rd Selkath rows (259, 260) to the F modeltype, as per @ebmar's suggestion above.
  25. DarthParametric
    This archived thread from LucasForums should cover your needs. Some direct tool links: ERF/RIM editor for JE - https://web.archive.org/web/20150424042602/http://www.starwarsknights.com/forumdl/ERFRIMEdit036a.7z DLG editor for JE - https://web.archive.org/web/20151106043010/http://www.starwarsknights.com/forumdl/jedlgeditor_230a2.rar TLK editor for JE - https://web.archive.org/web/20151106043008/http://www.starwarsknights.com/forumdl/TalkEd v1.1.1a.7z TXB2TGA (texture converter) - https://web.archive.org/web/20151106043024/http://www.starwarsknights.com/forumdl/Txb2Tga.7z Save editor for JE - https://web.archive.org/web/20150324074631/http://www.starwarsknights.com/forumdl/jse_06.zip Save extractor for JE - https://web.archive.org/web/20151106043245/http://www.starwarsknights.com/forumdl/sac_utils.zip Find Resources for JE - https://web.archive.org/web/20151106043021/http://www.starwarsknights.com/forumdl/JEFindRes03.7z 2DAs can be converted with Convert2DA, as per KOTOR. GFFs can be modified with K-GFF, as per KOTOR. Scripts can be compiled with the KOTOR version of nwnnsscomp with JE's nwscript.nss (I don't know about decompiling, DeNCS might work on some).