JCarter426

Just that with MDLEdit, you have to change the game before importing - basically it does all the work when reading the model. So you should load the binary model in the original game and convert to ASCII, then change the game, then load the ASCII, then convert back to binary.

I just made a cube map with a different color on each side, then applied it to a cube and looked at how each face changed relative to the viewing angle. That picture looks consistent with my testing. I think you've got it flipped around in your head. Your building and the cube map have opposite texture wrapping. If it helps, imagine the cube map is being wrapped onto the skybox rather than the building. The map is then drawn on each part of the building that's facing that part of the skybox. If you mapped the cube map onto a cube, then you would indeed get two faces swapped, similar to how you get a left/right flip with a reflection in a mirror.

I got a lot of problems with you people. Now you're gonna hear about it. I'm trying something new again, though I've been thinking of doing it for a while. I noticed the site update changed the way it manages updates to mods. I think the new way makes more sense than the old way, but it does mean it's easier for updates to go unnoticed to anyone who isn't specifically following the mod page for that. So I figured I'd do a sort of mod roundup every so often to shout into the void about what I've been up to. Updates The primary point of this format - new updates to old mods that you might've missed. Supermodel Fix for K2 - Added some fixes for dual saber animations. And apparently I broke TSLRCM's lean animations at some point, so I fixed those too. Slave Bastila - I spent a good part of the summer putting out fires for this mod. Then after I thought it was done, there was some more weird stuff that wasn't even my fault. Nobody's reported anything for a couple months so I think it's safe now. Handmaiden Sisters - This was the first mod I submitted to Deadly Stream, though it wasn't the first mod I made, not by far. So it didn't have much sentimental value and I neglected it. It had been out of date for a while. I ended up redoing it from scratch for the update. Korriban: Back in Black - By request, there are new options for Uthar and Yuthura. And also a fix for a weird bug with a guy on Manaan. New Mods Some fine additions to your collection. Vision Enhancement - Makes the player stop going to bed wearing armor and teleporting to the Ebon Hawk in their sleep. Fashion Line I: Cloaked Jedi Robes for K1 - Ports those K2 robes with cloaks to K1. Possibly the #1 request since Deadly Stream started accepting ported mods, if we aren't counting "hey why don't you port the entire game" as one mod. Force Knock - Adds a Force power to replace the need for the Security Use skill. Modding Tools & Resources Stuff of no interest to non-modders but of potential non-zero interest to modders. Cloaked Jedi Robes & Supermodel Port for K1 - Mod resource version of what makes the Cloaked Robes and Slave Bastila work. Odyssey++ - User-defined languages for Notepad++. Suggests stuff as you type. Makes scripting for KOTOR easier. Something Completely Different In this section I'll post something recent that I didn't make but I think is cool and deserving of attention. This time, without a doubt, it's the CSLU Toolkit revival by @Jenko. The CSLU Toolkit is what KOTOR mods have always used to generate lip files because that's what was available back in 2005 when JdNoa made her LipSynchEditor. It was a convenient, free resource... at the time. Recently, it's been impossible to get a hold of the software. The CSLU server has been offline for over a year, meaning nobody could install the Toolkit. Even if they had the installer, it wouldn't work without the server available to confirm the license. I remember problem-solving this when the server first went offline. I even sent over my registry files, hoping we could get a new installation to recognize my license - just so we'd have the option of transferring a totally legitimate installation to a new machine when the time came. But nothing worked. It was oddly secure for freeware. Ultimately, it took him single-handedly pestering the staff at Oregon Health & Science University, getting his emails sent down a chain of several people in the hopes that it would finally reach somebody who actually worked on the thing. And it did. It was a Festivus miracle.

Should be simple enough to test, let's see... In descending order: bottom / top / left / right / front / back With directions relative to a player facing north. At least for what I tested.

Usually you shouldn't use KOTOR Tool's inventory editor. It's buggy. If you open the file with K-GFF, you can edit the fields directly.

For the textures, you need to replace all the files in the TexturePacks folder. Though I believe you will still get some hangups with the GUI on account of name changes. All I can suggest is you do that first, then eyeball what is still wrong and continue from there. A module includes the following files: all the contents of the .rim and _s.rim files (these can be extracted with ERFEdit) the module's layout (.lyt) file (located in layouts.bif) the module's visibility (.vis) file (located in lightmaps.bif) the map (located in swpc_tex_gui.erf) the loadscreen (also located in the _gui.erf) the area models (.mdl, .mdx, & .wok, located in models.bif) the lightmaps (located in lightmaps.bif) If you are porting the whole texture archive, that should take care of the map and loadscreen already. The models must be converted because the games use slightly different formats. My usual procedure for this is to extract everything, convert the binary MDL/MDX to ASCII, then load the ASCII files and convert those back to binary. This isn't foolproof, though, as you can see here . I've put my area porting endeavors on hold until the next update to MDLEdit (plus I've got other projects anyway). Everything else can be archived in a new .mod with ERFEdit and then placed in the modules folder.You can put modelsand textures in there too, but they are often used for more than one area, so it's not as practical. Like I said in the first post, ultimately I would like to explore a way to create new archives for the games rather than shunting everything into Override. We've had some progress, but there's still more work to be done.

That issue doesn't sound like something caused by my mod - it only changes the models, not the items, so the robes will either work or or they won't. It sounds more like an issue with either your baseitems.2da file or the robe .uti files, so I would suggest investigating any mods you may be using that edit those.

Yeah, capital letters in Aurebesh get mirrored in some appearances, although in others they don't. I believe K2 leaves them all lowercase. Those are facing the standard way now, anyway.

View File JC's Force Knock for K2 This mod adds the Force power Knock, which can open locks as if you had used the Security skill on them. You earn the same amount of XP using this power as you would using Security, as well. It is a universal power and costs 10 Force points to activate. When used, Knock unlocks the nearest door or container, provided there is an eligible lock within 5 meters. It cannot open a lock with a DC greater than 50, or one that requires a special keycard. In other words, it cannot unlock anything you could not otherwise unlock with Security in regular gameplay. You can acquire Knock whenever you level up a Jedi character. It will then appear with your other friendly Force powers (such as Heal and Speed). Submitter JCarter426 Submitted 12/18/2018 Category Mods TSLRCM Compatible Yes  

Firstly, I would recommend my Odyssey ++ user-defined languages. They auto-suggest things and add markup, makes things easier. NWScript will list all the functions but your best bet for learning how they work would be to look through what source scripts are available in scripts.bif. The NWN Lexicon is another good resource, though much of what's there doesn't work in KOTOR. And any resource on any C-like language will help. This should help get you started too: void main() { // Delay for lightning flashes // First, generate a random number between 0.1 and 10.0 seconds: float fRandom = ( IntToFloat(Random(100)) + 1 ) * 0.1; // Extra time always added on top of the random roll: float fExtra = 5.0; // Final delay: float fDelay = fRandom + fExtra; // Lightning animation will be randomly determined // Animation numbers correspond to the ANIMATION_ROOM_SCRIPTLOOP constants string sRoom = "whatever"; int nAnim = Random(20) + 1; // Thunder sound will be randomly determined string sSound; int nSoundRoll = Random(2) + 1; switch(nSoundRoll) { case 1: sSound = "as_wt_thundercl1"; break; case 2: sSound = "as_wt_thundercl2"; break; default: sSound = ""; break; } // Do stuff DelayCommand(fDelay, PlayRoomAnimation(sRoom, nAnim)); DelayCommand(fDelay, PlaySound(sSound)); } It will randomly play an animation and thunder sound. This will utilize all 20 possible room animations if you want to use them all, but you can reduce it by changing the 20 to however many you want. You can also add more thunder sound possibilities by adding more cases before the default case. You can also change the values for the random delay; it's currently set to a delay of between 5 and 15 seconds.

It's a similar issue, except rather than relating to the model hierarchy, it's it's the order in which the sabers are drawn. A newer saber's hilt will always render on top of any older saber's blade. In the screenshot above, you equipped the yellow saber more recently. If you were to keep the yellow saber and replace the blue saber with something else, then the yellow saber would always render behind the new one. My guess is that the intent was to ensure a saber's blade doesn't render on top of its hilt when it clips through it, but there's a side effect of it applying from object to object as well.

By all means. Sounds like the problem is you're renaming the supermodels. All the S_Male and S_Female files should keep the names they already have.

I'm not sure what you mean. The robes are originally from KOTOR 2. The P_ models are the robe models. PMBIL is the large male variant, used for players starting with the soldier class. The other ones are different gender/size combinations. The S_ models are the supermodels. They contain all the animations in the game for the player character. The mod replaces the supermodels with the KOTOR 2 rig, which has additional bones that allow the cloaks to animate.

Nah, that was just for converting it. I use dd for Windows on Windows with a batch script.

Huh, it appears to be. I think I always edited out that glitch at the beginning and thought nothing out of it. Looks like this script works: @echo off for %%F in (*.wav) do dd if=%%~nF.wav of=%%~nF_out.wav bs=1 skip=470 pause

The files in StreamSounds are just raw audio files. I don't recall there being the same sort of header trickery like there is elsewhere. In Audacity, you can import them with File > Import > Raw Data at a sample rate of 22050 Hz. Should be a similar procedure in other programs.

Oh, that makes more sense than what I was thinking. And it's obvious considering what the textures look like, but it's been a while since I did look at them. So you could get some interesting results by adjusting the probabilities too. Like in the example above, two of the tiles have some pink flowers, and I would guess they're given lower probabilities than the other two.