bead-v

Fixed

Newbies picking up giant projects, it never works out (statistically, no offense meant). I'd suggest you set your goals lower and do some smaller mods first, and then ask yourself again if you're willing to do it when you have more experience. I also doubt one person alone could do it without getting overwhelmed.

I've been preparing a known issues list, because I want to get an official MDLedit update out as soon as possible. Posting it here in case there is something I missed. 1. MDLedit is not capable of processing some very large models (eg. the K1 DS endgame scene area models). I may be able to solve this in the future. 2. When converting area models from K1 to K2, some models lack an aabb node in the MDL. Without the aabb node, the model will not be displayed in the game (unless the VIS file is missing, but this shouldn't be the solution). In this case, first decompile the model to ASCII, then edit the file with a text editor and add the following lines in an appropriate place: node aabb NEW_AABB parent BASE_NAME endnode 3. There have been reports of smoothing not working properly if the model was converted with the batch convert function. I haven't been able to reproduce the issue so far and would be grateful if I could receive all the relevant files to examine them if it happens to you. 4. In some area models, the aabb mesh isn't properly modeled to be used for the creation of the walkmesh, which causes the compilation to fail. If that happens you have two options. You can either inspect the aabb mesh and delete all the offending faces or you can enable the 'Export WOK file' option in MDLedit, then use that mesh to replace the aabb mesh, just make sure it has all the right options afterwards. In the future, I will add an option for the WOK file to be handeled separately, so this issue won't arise anymore. 5. Smoothing will sometimes not work across boundaries where the UV is mapped in different directions. This requires an update to the vertex normal calculation and will hopefully be solved in the future.

With anything, as long as the files are named correctly!

Okay, so here's what should work: 1. Open the K2 soundset.2da 2. Add the entries for the PC soundsets at the bottom of the table. These are the entries in the K1 soundset.2da, for reference: 3. Save the modified soundset.2da to your K2 override folder. 4. Open KSE and change the soundset for your PC on your last saved game. 5. The soundset files need to go into the SWKOTOR2/StreamSounds folder and need to be named correctly according to the .2da file. Take the files for other characters as reference.

The problem is that there is so little content left in the files, most importantly very little character VO's. So that meant having to use other means to drive the story, using new characters or droids/aliens/computers, and other means (eg. camera recordings with no sound). Another problem is that there are many possible scenarios (some characters may be dead, etc.), and many of these weren't ever really fleshed out. That's because it often wasn't clear if it was possible to achieve what was necessary for what we wanted. We also wanted to include a new area, which IIRC we could never get working correctly because the tools weren't able to handle it at the time. We really went for quality and paid attention to every detail, but that meant that there was a lot that was either very hard to achieve or not possible at the time. Because of the new tools, many things would be easier now, but a lot would still be very hard and it would take a LOT of work if your goal is the sense of closure and completeness that we wanted to give to K2's ending (as opposed to just a buffed up ending that still feels incomplete). And I guess this is the answer to your question. It wasn't just restoring/adding content, it was doing it in such a way that it feels complete. MVI was different from TSLRCM in that this wasn't part of TSLRCM's goals. I personally don't have anywhere near the time to pick up even projects way smaller than this. Maybe someday someone will, who knows.

Sorry, I didn't see your post before... It's true, it's not immediately obvious the way I wrote it, I had to think a bit to remember what I wanted to say. So: VP = BaseHitPoints * (PlayerLevel * vpmult(autobalance.2da) - 1)(only if mult > 0) + HitDie(classes.2da)/Levelup + CON * Level Here you have several references to levels: 1. PlayerLevel: "All values depend on the player level, which is determined from experience. This means that if you have enough experience for level 33, the game will consider that level even if you haven't levelled up yet." 2. Level: "Level = Level(Class I) + Level(Class II) + (PlayerLevel * levelmult(autobalance.2da) - 1) (only if mult > 0)" 3. Levelup: "At levelup, you gain: 6-12 points depending on your class" So, the base is BaseHitPoints (which is multiplied by (PlayerLevel * vpmult(autobalance.2da) - 1) if the vpmult is > 0). To that value, you add some amount for every level up (ie. it's not retroactive, if you get a character at lvl 6, they will not get the bonus for the levels up to 6, they will only get it added once you level them up [I haven't checked this recently, but I think that's what is meant, and if I wrote it down I must have checked it back then]), the exact amount that's added depends on the HitDie column in classes.2da. Then at the end, you add the CON modifier * Level (as it is defined above). Force points work the same way, the only difference is that there is no autobalance scaling of the base value (there is scaling of the attribute modifier however, because of Level). As for the LEVELUP for Skill, that's the points you assign to skills when you level up your characters. As you probably know, the amount of points you can assign depends on your class as well as your INT modifier. Again, only player controlled characters get this part, since non-playable characters don't level up. [I just realized, I haven't checked or at least don't remember having checked what happens if you change the PC to another party member. Is the PC's level still used as PlayerLevel for autobalance (which is more likely I think) or is it the party member's? But if it's the PC's, then the party members that you get at higher levels have quite a disadvantage against the enemies compared to the PC and the party members you get at lower levels.] Hope this helped clear things up!

Thanks for reporting that, it wasn't using the .ini file. Fixed now. mdledit_v1.0.104b.zip

I found some time to look at the reported issues with mdledit. I'm sorry it has taken such a long time to arrive. This issue... ...and this one are fixed. This one I couldn't reproduce, my Handmaiden has correct smoothing in either case. Your result puzzles me, because both operations use the same routines, there should be no difference. The problem here was the WOK (it hanged while calculating Adjacent Faces, Edges and Perimeters). Why it happens: mdledit_v1.0.103b.zip

Well, when you press the process button, you expect the values you entered to be applied, right? If the position and rotation controllers were not linear, then it would just do nothing. I had to look at the code to figure out that this was the requirement. So now when you press the button, you get a message about which controllers are supported and will be affected, and then you're asked if you want to continue.

The problem with it is that it only works with linear_position and linear_rotation controllers. I also enabled it for bezier_position now, which is the default kotormax uses. However, in some of my tests I experienced some unwanted side-effects (wobbly movement). I'm sending an edited script in the attachment. It supports bezier_position controllers, but the main addition is feedback messages telling the user which controllers are supported and what is going on. You put this script into your "gmax_or_3dsmax_folder/scripts/kotormax/kotormax_scripts" and overwrite the existing one. kx_masskeytweak.zip

Considering how weird animations are in kotor sometimes, this is perfect! I'm fine with it as-is

I see... then I wonder if it would work making Dodonna move in the previous shot already, but you've probably considered this as well and found the best solution And thank you for the list of changes, didn't catch all of them before! Kudos!

Good work DP! The only thing I like better in the vanilla version is the camera angle when Vandar steps forward. Yours is very close up, so it actually confused me on where exactly he's standing (I forgot how the scene plays out). The way it jumps from a right side to the left side right afterwards was also a bit abrupt, I would suggest a broader view from the same side. But other than that it's perfect!

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?

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

Did they take down the letter? Does anyone have a screenshot?

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

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

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.

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.

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!

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

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.

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.