DarthParametric

Modders
  • Content Count

    4,568
  • Joined

  • Last visited

  • Days Won

    514

Everything posted by DarthParametric

  1. 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
  2. Both games are chock full of bad lightmapping. K1CP & K2CP have addressed some of the worst of it, but not all.
  3. They tried to use a (blank) string instead of an int? Or a string and an int.
  4. 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.
  5. 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.
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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
  11. @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.
  12. 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).
  13. Hrm. I'm not sure that I have the specific mesh I encountered the problem with any more. I know it was a Nautolan head that I ran through Turbosmooth. But the version I dug out of my crap pile is only around 8K tris/4K verts (if it were a single mesh - it's actually split out to about half a dozen). It does seem that was only a single iteration though. I think the mush version must have been 2 iterations as kind of a "let's see what happens" experiment. But running the source low poly through that still only comes out to ~32K tris/16K verts. Maybe it was actually ye olde MDLOps choking on it.
  14. You keep the meshes separate. That was the entire point of splitting them. The original mesh (sans neck? I gather this is your collar thing?) can be left as-is. The new mesh you can just collapse the stack and do whatever you need to do to it to get the results you desire. You can add a new skin modifier later once any modelling is done.
  15. Single skinned meshes up around 10K polys tend to turn to mush, presumably due to some upper limit for weights in the model format or something (@bead-v would know more). Shadow casting meshes above around 2Kish polys cause crashes. It's mostly the hair that's the problem, and that should be able to be completely separate static mesh, so you shouldn't have too many hard limits.
  16. Pretty good likeness, but it seems like some extra subdivision wouldn't go astray.
  17. Not for KOTOR work, no. Instances are duplicates that inherit the properties of the parent (and also vice-versa in Max's implementation). It's an extremely useful tool for rendering, since it uses far less memory than unique copies. In this case you need to select Copy. That will make a unique object that you can edit freely without affecting the original.
  18. You can also use doors as well. Either via script, if you want it to remain permanently closed, or the door itself can act as a transition trigger simply by passing through it. The K1 Dantooine Enclave module (danm13) is a good reference, since it has one of each. The transition to the Ebon Hawk uses a trigger, the transition to the Courtyard uses a door. Edit: Ah, I see you have updated your post. Your proposed transition would need to use a trigger.
  19. The Autodesk solution (or recommended action anyway) is, from an elevated command prompt in the GMax directory run: regsvr32 /u MAXComponents.dll Then: regsvr32 MAXComponents.dll
  20. Looking at the model, looks like the smoothing group assignment is pretty ropey. Try this and see whether it is better or worse. Edit: The N_TatComW_F head also has a Joker smile baked into the texture, which is a bit disconcerting. I tried an AI upscale of the textures and painted out the extended mouth corners on that one. Edit 2: Based on some further feedback from @ebmar, I made additional adjustments to the UVs and texture for N_TatComW_F. K1_Commoner_Female_Head_Fixes_Revised.7z
  21. That's why you hit that handy "never show me this message again" checkbox. Max is very sensitive about out of order stack changes, even though they rarely have any actual consequence.
  22. Probably not an unsafe assumption, even if it is not the case in this specific example. Perhaps @DrMcCoy could shed some further light.
  23. As when any such debates arise in game development - add a toggle for it!