Premium Member
  • Content Count

  • Joined

  • Last visited

  • Days Won


bead-v last won the day on November 16

bead-v had the most liked content!

Community Reputation

209 Jedi Grand Master


Profile Information

  • Gender
  • Location

Recent Profile Visitors

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

  1. All this would require is dialog editing. Since you seem to have a pretty clear idea about what you want, why not edit the dialog yourself? You do need to know where to find the right dialog, which can sometimes be a little tricky for a beginner, but then you can ask here (the above part is in k_hbas_dialog.dlg). Once you have the file, editing it is simple. Then just drop the file into your override folder.
  2. I'm guessing your talking about the state of affairs after importing with KOTORmax? Anyway, the animations aren't hardcoded, you can add additional keyframes that exceed the 16600 as you say. It's max that has the limitation of just one timeline, KOTORmax therefore loads the animations onto it in sequence. It has an animation editor through which you can keep track of which keyframes belong to which animations. You can simply add a new animation and assign the keyframes you want to it. Although, using the new animations in the game is a different story. I think in K2 it should suffice to list it in animations.2da and then it's possible to call it via script. But I'm not sure it's as simple in K1. You may delete the animations in the animation editor if you want. This means they won't be exported from KOTORmax. Once the model is exported, first you need to compile it back to binary. After that you either place it in the override folder or you put it in a .mod file (which represents a module). Modders generally never edit .bif, .rim and .erf files, we leave those as a source of the original files. For just a character model, you'll be fine putting it in the override folder. Also note that K2 will recognize files in the subfolders of the override folder, while K1 won't. Not sure what you mean with the training dummy.
  3. 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.
  4. 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.
  5. With anything, as long as the files are named correctly!
  6. 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.
  7. 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.
  8. 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!
  9. Thanks for reporting that, it wasn't using the .ini file. Fixed now.
  10. 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:
  11. 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.
  12. 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.
  13. Considering how weird animations are in kotor sometimes, this is perfect! I'm fine with it as-is