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.

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.

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

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

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.

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

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

@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.

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).

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.

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.

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.

Pretty good likeness, but it seems like some extra subdivision wouldn't go astray.

Probably not ideal. In which case you might as well go the whole hog and use the maskless male/female models used in the revelation scene. But you are going to get a ton of clipping with either. And wearing the DS robes for the LS ending is an odd choice regardless. You'd be better off sticking to the J models.