bead-v

Premium Member
  • Content Count

    525
  • Joined

  • Last visited

  • Days Won

    15

bead-v last won the day on October 1 2018

bead-v had the most liked content!

Community Reputation

192 Jedi Grand Master

5 Followers

About bead-v

  • Rank
    Evil Malachor Overlord

Profile Information

  • Gender
    Male
  • Location
    Slovenia

Recent Profile Visitors

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

  1. bead-v

    Doorhooks and Path Files?

    I think so too. As for the path files, I long time ago I made a program for editing PTH files. It used the ingame maps for reference and the data in the .are to get the coords right, but that never worked 100% for some reason I never figured out. But editing the .pths themselves was ok. I used it mainly for K2 though, I know I must have tested K1 too, but I don't remember how that went. It's another thing I could possibly integrate into kmax.... hmm... So what gets you stuck?
  2. The scale wizard was meant for exactly this purpose apparently. I don't have the time to get into this properly, but I did make a quickfix which should make it usable. Hopefully that helps you out, @ebmar. You put these into "gmax\scripts\KOTORmax\kotormax_scripts", overwrite the old ones and reload gmax. The script will probably encounter problems if there are more objects with the same name in the selection. kotormax_scale_fix_20190121.zip
  3. bead-v

    Apeiron

    Did they take down the letter? Does anyone have a screenshot?
  4. You can change it from a looping to a fireforget animation in dialoganimations.2da. But this means the animation will freeze after it plays until the end of the node. The mouth still moves but if the node is a bit longer, it looks kind of weird. Up to you to decide which option is worse
  5. bead-v

    MDLedit

    Hey ebmar! Please try the latest version attached to this post. Hopefully it'll work then.
  6. 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.
  7. 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.
  8. 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!
  9. 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. k_hen_heartbt01-DialogOrientationFix.zip
  10. 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.
  11. 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.
  12. 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.
  13. 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?
  14. 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.
  15. From your wording it sounds like recompiling such a vanilla model would break it. Have you encountered anything like that?