bead-v

As soon as it's approved I expected MDLedit to take a little longer before it's approved, I didn't take this time gap into account.

File Name: MDLedit File Submitter: bead-v File Submitted: 08 Oct 2017 File Category: Modding Tools MDLedit is a (de)compiler for KOTOR and KOTOR2 model files. Which version should I download? There are two packages on the download page. They differ in whether the program uses Visual Styles or not. The difference is purely visual, they are completely equivalent in terms of functionality. The version in the mdledit_v0.0.0xp.zip package will work on Windows XP or newer as well as on MacOS through Wine, but it will look like crap. The version in the mdledit_v0.0.0.zip package will look better, but will only work on Windows Vista and up. How do I set it up? Open the .zip archive, extract the .exe and run it. If you want MDLedit to keep track of your option between sessions, create a blank mdledit.ini file in the same folder as your .exe. How do I use it? The program comes with a help documentation window accessible from the About menu, read that to learn how to use it. If something is not mentioned there please let me know in the relevant thread (link to be added) and I will explain the functionality and add the explanation to the help window for the next version. MDLedit was designed to be used with KOTORmax and the new version of KotORBlender by ndix UR. Using the ascii model files that it produces with NWmax will cause data to be ignored in the best case and a crash in the worst. The program crashed/froze/reported a weird error! Describe your issue in the relevant thread and I will look into it. Attaching a .zip archive with the files that MDLedit was processing when the problem appeared is also very welcome. Thanks A big thank you goes out to ndix UR, without whom MDLedit would have maybe half the functionality it has now. I would also like to thank the testers, who also made a lot of great suggestions that made MDLedit that much better: – DarthParametric – JCarter426 – Quanon – VarsityPuppet – FairStrides The program was built on the knowledge about the MDL format, which is the result of the work of many modders, including CChargin, Magnusll, JdNoa, ndix UR, DarthSapiens, VarsityPuppet, FairStrides, and others! Thank you for your efforts! Lastly I'd like to thank the KOTOR modding community, which makes taking the time to make such a tool worth it. Click here to download this file

http://deadlystream.com/forum/topic/5540-character-stat-guide/

Amazing... as always Is the golden one intended to be B4-D4?

Agreed. A small change, but blends in perfectly and just looks awesome!

That should work like you described. Though maybe writing ActionDoCommand(ActionPlayAnimation()) will help if it's not working. I vaguely remember something about some Action...() function not really behaving like an action function, it may be this one but I'm really not sure. If it is this one then ActionDoCommand() should fix it.

ebo_m12aa has an OnEnter script in both the .are and the .ifo, make sure you take both into account.

Apparently, it returns 0 if the global doesn't exist (I also tested in TSL, same thing). The reason why you get so many is because the onEnter script runs that many times. The onEnter script runs for several objects; for this reason, most onEnter area scripts have something like this somewhere in the beginning: if(GetEnteringObject() != GetFirstPC()) return; This'll ensure that anything that comes after this will only run once. The script in question enclosed a portion of the script into if(GetIsPC(oEntering)){ ... } for that reason, but not the part that spawns the creatures – that part was relying on a global to make sure it only runs once. But if the global doesn't exist it can't be set to true, so the check came out as true every time the script fired.

That sounds awesome! Sounds like you'll be making a lot of new scenes if you want to pack that development into the factory. I approve Does he know about the HK-50s though, or does HK-47 have to tell him?

An alternative would be an alliance against the HK-50s. HK-47 could convice HK-48 that they're the real enemy for both of them I like that you're paying attention to HK-48's personality and its interaction with HK-47. I think this could turn out really well if done properly! HK-48 could be like a prototype that ended up completely missing the point of HK-47. Like they were trying to recreate HK-47 but failed to get some of the details right. Now HK-47 already describes how the HK-50s missed the point, I imagine the flaws with HK-48 could be way bigger and more noticable, in a comical way if at all possible. Something to make HK-47 roll his eyes, but not feel threatened at all, unlike with the HK-50s. He could be really silent and literal, maybe because he was made too droid-like without a personality, he could be religiously focused on a very specific meaningless goal, or you could just make him a little stupid Just throwing ideas around, maybe one of them will help you out Another way they could have missed the mark would be with his voice – a nice ingame explanation for why it's not voice-acted by the same actor.

It could be part of the area model. But you can't solve this the same way with the current version of MDLOps and NWmax, because they don't handle area models well. You could use MDLOps to find the emitters and then hex edit the binary models. Though you can't remove them that way, only change them. But if it isn't all the emitters causing trouble then you should be able to change them in a way that solves your problem. What else apart from smoke isn't working for you? Sparks? Fire? Alternatively, you could also try replacing the smoke texture, maybe that could work? It'd instantly apply everywhere, so you wouldn't need to hunt down every instance of smoke in the game.

The *hook dummy nodes can only be identified by their names, which suggest the engine reads them. Also, the animroot is specified as a string, so the engine needs to compare it to the node names to find the right one.

Definitely. As sELFiNDUCEDcOMA mentioned, the format itself doesn't have a limit for them, but we don't know anything about the engine. A lot of the time the mdl format allows for 32byte strings, but you should actually keep them under 16bytes in those cases, because other game files are limited to 16byte strings. I think that holds for the filenames inside the .bifs too. So to keep it simple, I'd advise everyone to keep their strings under 16 characters in all cases if they want to be safe. (ignoring texture0 and texture1 in the mdl, which are 12bytes – those are unused and we don't know how to use them or if they even work)

Puts us over 8-bit, right? So it's 16-bit or greater, which is indeed at least 65,000.

Not even the slightest chance I'd find the time to do this right now, sorry.

You'd have to keep the general structure for it to work, but I'm sure you could do a lot if you spent enough time with it. Here's what FairStrides has done before:

Agreed, the ground texture doesn't fit, and the pillar is problematic. I also don't like how obvious it makes the texture patterns. If I redid the camera myself I'd probably go for a completely different, more close-up approach. But moving the camera slightly, lowering it's starting position and raising the pitch should fix the bigger issues.

Tried in windowed mode?

An onEnter script can also be specified in the module.ifo – ebo_m40ad has, under Mod_OnModLoad, the script k_pebn_pophawk that spawns the NPCs.

Good ideas there, SH! bead likes!

Are there any VOs of G0-T0's in the files where they forgot to apply the filter?

It wasn't good enough for me, so I made this. But once the new modeling tools are out, the best way to create them will probably just be with max/blender. I could also update ACDC to export MDLs directly, since I have the knowledge now, but unfortunately I won't be able to find the time for that anytime soon.