Premium Member
  • Content Count

  • Joined

  • Last visited

  • Days Won


bead-v last won the day on October 1

bead-v had the most liked content!

Community Reputation

185 Jedi Grand Master


About bead-v

  • Rank
    Evil Malachor Overlord

Profile Information

  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. bead-v


    Hey ebmar! Please try the latest version attached to this post. Hopefully it'll work then.
  2. bead-v

    DLG Editor

    Naah, you can't break anything. It should be fine, I think. It only fires once per dialog... but the best way to find out is to test it.
  3. bead-v

    DLG Editor

    Yeah, GetLastSpeaker() works in a weird way that's not obvious to me from a few tests. In any case, I don't think it can be used in this way. And even if it could, there's no way of checking whether this an actual speaking node or just a cutscene node, so you'd likely get partymembers turning weird directions during cutscenes. You'd also want a few more checks in there, like Solo mode, distance, etc... But I'd say with the functions we have at our disposal, this isn't doable at a decent level.
  4. bead-v

    DLG Editor

    So that's a bit different, because it clears the action if the party member happens to be in Solo mode, not in dialog as in our case. But the reason why that part of the code's commented out is because that's probably the old code for the script before it was all moved to k_ai_master and run from there. Fingers crossed!
  5. bead-v

    DLG Editor

    You could do it for the main onDialog script, but that wouldn't eliminate all the cases. Whenever the dialog is fired from any other script, you'd need to either edit the dialog to add the ClearAllActions() script as suggested above or edit the script that fires it. EDIT: But here's another thing that seems to work. I modified the party member heartbeat script to do this: if(GetIsConversationActive() && GetCurrentAction() == ACTION_FOLLOWLEADER) ClearAllActions(); The heartbeat script only fires every 4s or so, so it may not always work immediately, but it is a pretty general solution.
  6. Another piece of information, discovered as a result of Salk's question. When outside of dialog, party members follow the PC and reorient on them at any time. When you enter dialog in K1 this behavior persists, and causes them to reorient on the PC whenever they speak, ignoring the Speaker/Listener functionality. Calling ClearAllActions() on the party member will remove this behavior. This issue will also not arise in Solo mode, because in that case the party members are not following and reorienting on the PC.
  7. bead-v

    DLG Editor

    Ah, I see what you mean. In any case, this doesn't seem like an issue with the Speaker/Listener functionality, but an issue with the party members trying to reorient on the PC even during dialog. If you turn on solo mode for example, the issue goes away. I also removed the function that makes the PC move, but that made no difference. I'm gonna do some more tests, because it seems like sometimes it does work. However, you could probably use the solo mode trick to fix the issue. You'd make two scripts: a_disablesolo: void main(){ SetLocalBoolean(GetArea(OBJECT_SELF), 10, GetSoloMode()); SetSoloMode(TRUE); } a_reenablesolo: void main(){ SetSoloMode(GetLocalBoolean(GetArea(OBJECT_SELF), 10)); } Then you'd just need to add these two scripts to all the dialogs where it happens. And just a disclaimer, I'm not 100% sure this would work, but it could. EDIT: Well, I checked the script that fires the banter dialog, and all it seems to do is ClearAllActions() on all the party members. I checked that with the Matale cutscene and it worked. So you can package this up as a script like this: a_clearactparty: void main(){ int n = 0; for(n = 0; n < 3; n++){ AssignCommand(GetPartyMemberByIndex(n), ClearAllActions()); } } And just make sure it fires somewhere in the dialog before the lines with the party members.
  8. bead-v

    DLG Editor

    How this whole Speaker/Listener business works isn't simple, I once did extensive testing and wrote a guide about it. A lot depends on the exact syntax of how the conversation was started in the script. This was for TSL only though, K1 may be and probably is a little different. If you give me a specific example I may be able to tell you why it's not working.
  9. The question then is why the fogged out skybox in 852nih13 rendered when it wasn't under the a-dummy (everything else was though). There was no walkmesh and ignorefog was enabled... Well, what else did you change when it started working?
  10. I checked our conversation about that issue, there's indeed a lot of bizzare stuff happening, but I'm pretty sure it all has to do with the setup of the models and not the tools themselves. Unfortunately, all the .zips with the model files are inaccessible and it seems that since the site update we can't download previous versions of mods anymore, so I barely have anything to look at. I guess I'll just try to describe what was going on... Kexikus added the model 851nih53 to 851nih for his Backdrop Improvement mod. At first that had ignorefog off, so telos appeared completely fogged out. He originally disabled fog for the entire module to fix it. Then for v1, he hex-edited (I assume) his 851nih53 to ignore fog. Now the issue was gone so fog could be turned on for the entire module again. BUT, now the flames in 851nih02 dissappeared. Apparently this was caused by enabling fog for the module and disabling it for 851nih53. It was then discovered that if the walkmesh in 851nih53 was deleted, the flames would show, but now 851nih53 wouldn't show. We now know that this is because the game doesn't render area models without a walkmesh if the .vis file is available. So it seems that if it has to render 851nih53, in some way that breaks the flames in 851nih02. This the structure of the model: It was discovered that if the plane* nodes were deleted or moved under 851nih53a, the flames would show as well as the model. But apparently, moving those planes under the 851nih53a dummy caused (or at least, didn't fix) the smoke VFX in Visas' room to disappear. DP then deleted the walkmesh and moved everything under the 'a' dummy like so: This then fixed all the issues. Apparently, under some circumstances, an area model is STILL rendered even though it doesn't have a walkmesh. @JCarter426 😮 Then there were some more problems in the other ravager module. This time something was up with the lighting. There were two area models added, 852nih13 with some ravager geometry and the reused 851nih53. The issue was fixed by applying the dummy solution to 852nih13. On the first try we forgot to move the skydome itself under the dummy, which though it caused the skydome to show, made it fogged up, and that's even though ignorefog was enabled! This is all even more bizzare than I remember. I guess the first step in solving this would be to figure out why 851nih53 renders without a walkmesh.
  11. From your wording it sounds like recompiling such a vanilla model would break it. Have you encountered anything like that?
  12. bead-v

    KOTORmax bug reporting thread

    All extra_data does is add in a few bytes that the game doesn't use, just for the sake of byte-for-byte comparison in mdledit. So really all that you're doing is deleting the keys. Now the question is whether the keys are there in max, or whether kotormax somehow puts them there during export.
  13. bead-v

    MDLedit bug reporting thread

    Okay, so there is space in the MDL for two more bones beyond 16. However, because we never found more than 16 bones (didn't look hard enough, as it seems), we assumed that was just padding (an otherwise common situation in the MDL). Anyway, I checked Vandar's model, and the first part of the padding corresonds to the index it's supposed to have, so at least that one is still a bone index and not padding. If that is the case, I'm thinking the last one must also be a bone index. It's possible that it didn't work before because mdledit was configured to only put 16 indices in there and ignore the rest. Maybe with the attached version of mdledit, 18 bones will work. I'll look into this some other time. What I meant was that mdledit would automatically add an empty aabb node. If you want to fix the issue, you just need to add a mesh in kotormax, make it a descendant of the OdysseyBase and apply the OdysseyWalkmesh modifier with the Type set to Aabb. Mdledit crashes when compiling aabb nodes without geometry, so the mesh should have at least one face. This is already fixed and when it's released, you'll be able to add an empty aabb node via the ascii simply as: node aabb NEW_AABB parent BASE_NAME endnode
  14. bead-v

    MOD:Movie-Style Holograms for End Game Cutscenes

    Yes, normally I'd agree with you, but controllers are stored in the model by number, and some controllers share numbers: nr 88 = birthrate (emitter) = radius (light) nr 96 = combinetime (emitter) = shadowradius (light) nr 100 = drag (emitter) = verticaldisplacement (light) = selfillumcolor (mesh) nr 132 = p2p_bezier3 (emitter) = alpha (mesh) nr 140 = randvel (emitter) = multiplier (light) The tools can only know which controller it is if the type of the node is also present in the model. We could agree to only turn meshes into dummies, and make mdledit default to mesh (and light?) controllers, but there's no guarantee... The tools can't know if what they're outputting is correct. I find that problematic.
  15. bead-v

    MOD:Movie-Style Holograms for End Game Cutscenes

    Well, that explains it then! EDIT: Actually, @DarthParametric, I have another question. TOR_Hat for example is a dummy in this model. But it has animation nodes with alphakeys. Mdledit will ignore those, because it gets the type of the geometry node, which returns 'dummy', not 'trimesh/skin', so it refuses because dummies don't have alpha controllers. I've never seen this situation in vanilla files. If this is valid, then I may need to change the logic for mdledit.