DarthParametric

Modders
  • Content Count

    4,666
  • Joined

  • Last visited

  • Days Won

    531

Everything posted by DarthParametric

  1. 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.
  2. 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.
  3. 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
  4. 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
  5. 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.
  6. 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
  7. 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
  8. @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.
  9. 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).
  10. 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.
  11. 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.
  12. 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.
  13. Pretty good likeness, but it seems like some extra subdivision wouldn't go astray.
  14. 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.
  15. 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.
  16. 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
  17. 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
  18. 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.
  19. Probably not an unsafe assumption, even if it is not the case in this specific example. Perhaps @DrMcCoy could shed some further light.
  20. As when any such debates arise in game development - add a toggle for it!
  21. I'm assuming these are all the debug functions? PrintString, AurPostString and the like? I was playing with those only yesterday and noticed that despite removing if (!ShipBuild()) checks, they still didn't appear to function. I assume they gutted them from the retail release altogether? While they are unnecessary for the code to run, I would argue they should remain in any decompiled scripts since, in the absence of commented source for the module scripts, the debug functions are the only thing remaining that can indicate developer intent. Additionally, the user can manually change them to SendMessageToPC for their own debugging purposes if needed.
  22. Anticipation building for the announcement of the winners in 2021.
  23. Deleting geometry is actually ok. It's only adding new geometry that destroys the weights. This was something I was going to come back and add after re-reading what Malkior said. Namely that you could select the appropriate block of polys around the neck region all weighted 1 to torsoUpr_g, then duplicate the mesh, on the original delete the selected polys, on the duplicate invert and delete everything else. Now on the split out neck piece you can add new geometry with impunity, as long as you don't reposition/alter the bottom ring of verts that mate to the rest of the body. Reskinning it manually once modelling is complete is trivial, since all the verts will be weighted 100% to one bone.