JCarter426

Ah, that makes sense. Also, I made a typo before. bumpshinytexture replaces envmap, not bumpmaptexture.

No problem. It's good to have a resource like this. Use an alpha channel as normal. Black will be translucent, white will be opaque. However, all the dark parts of the texture will still be translucent due to the blending mode, since it is additive and black is adding 0. There's no way to get around that unless you use punchthrough or two different textures. By the way, here's what happens when the game is missing the TXI:

Additive is equivalent to "add" or "linear dodge" mode - the color is added to whatever is underneath it. Punchthrough is equivalent to "normal" mode, I think. In the game, punchthrough is generally used when only transparency is needed, when there really is supposed to be nothing there (grass, leaves, grates, hair, etc) while additive is used for any translucent texture (such as windows) because it brightens the background and makes it easier to see. You might be wondering why punchthrough is even there when we have alpha channels that can handle transparency. That's because the game is crazy and won't render anything behind another object even if its texture is transparent from the alpha channel, unless a blending mode is applied. This increases the intensity of the bump map. If you have part of the bump map that is higher than the base texture, bumpmapscaling 2 will double the height, bumpmapscaling 3 will triple it, and so on. At least, that's my guess. I noticed a subtle but possibly not imaginary difference when I tried it. This is for use with a bump map on a texture that uses an environment map. If you're using cm_baremetal on a metal texture, for example, you'll want to use bumpshinytexture instead of bumpmaptexture. I believe there's more to it than that. This is an assumption based on how I've seen it work in other games, but I believe decal will make the texture render on top of anything that it's flush with. A burn decal on a wall, for example, will always render on top of the wall texture, rather than the Z-fighting nonsense you'd usually get. This just tells the game the texture is a bump map. This is an optimization thing. A mipmap has multiple copies of the texture in different sizes and the game renders the smaller ones from far away, only rendering the real size when you're close up. I'm not entirely sure how it works with KOTOR since KOTOR also has different texture packs, and I've only seen the mipmap parameter on certain textures. But it's not really a concern to us, thanks to modern hardware.

Doors, placeables, creatures, waypoints, and anything else that's spawned. Static cameras are the only game objects that do use them. That would be a no. That's all that matters, right? You don't have to mess with that stuff in 3ds Max or even AniCam. You do have to if you want to place any camera in a GIT file. Sounds like it's doubling everything you enter? That doesn't make sense... at all...

Oh, that does make sense. That's a strange way to go about it, but I can see why they would do that. You could still do it all in the same dialogue without requiring a new trigger, but it might end up being more work so it might not be worth it. Static cameras: a ) are required to be placed in a module's GIT file, which means they can't be placed after you've entered the module and make for a compatibility nightmare b ) use the obscure quaternion rotation system c ) are restricted to a single module d ) can't be animated Animated cameras: a ) can be animated but don't have to be animated b ) use intuitive XYZ values for rotation c ) are contained in a model file that can be named whatever and used wherever (though difference in module layout is obviously still an issue) There is one and only one thing static cameras can do that animated cameras can't: You can change cameras in the middle of a dialogue node with SetDialogPlaceableCamera. Unless I had to do that, I wouldn't ever use them. I hadn't ever considered a circumstance like the Xor encounter, though. That's a unique case because it can pop up in different areas, as you said.

There are approximately zero reasons to use those, but ok. Well, you're right - it does look like you want 180°. I've attached an animated camera that confirms this, though it's not going to tell you anything you don't already know. I don't know what to say other than that BioWare wasn't at all consistent with orientation. 90° being south is typical of some other modules, such as m01aa. It's probably just a quirk of that area. Though it is weird that only the static cameras would be incorrect, that wouldn't be the most shocking oddity with this game. Camera Rotation Test (m17ab).zip

First, what sort of cameras? Static ones in the GIT file? Second, the orientation in the game isn't consistent. Some modules have 0° as north, some don't. So you might just be in one of those modules.

I'm guessing the game renders it and attaches it to the camera if the flags in the ARE are set... otherwise it doesn't. I don't recall any script functions that would turn it on or off, and I also don't recall needing any specific OnEnter script for it to work. I've known weather to work in 231, 301, 506, 601, and 605. So it would be hard coded if anything. I know The Witcher has randomly-generated weather, and I believe this already supported by the engine and not anything they specifically cooked up for The Witcher. So whatever it is, it does seem to be something that can be triggered on and off... although I don't know if it works in KOTOR. Each room in the ARE has a flag to allow weather, though I don't know how this works. I remember assisting someone in editing this before without any luck - rain would show up everywhere or nowhere. The game definitely doesn't have this problem for modules that are already set up for rain, however.

The rain does use particles, but I'm not sure if you can edit them. As far as I can tell, the weather system is generated from an emitter that follows the camera, a 10 meter cube or something like that. Presumably the game uses some sort of model for this, but you'd have to figure out what it is. It's easy enough to create rain with the fountain emitter, though, and it's even possible to have rain (or snow or whatever) in the first game.

Well, no, there's no such file. That's just an instance of the waypoint template sw_waypoint001.utw with a custom tag. As for the script that spawns the party members, that's k_pebn_pophawk.ncs.

This should work (attached). Ministry.zip

Oh, my mistake. I assumed it was using an event fired from heartbeat but it's actually his perception event (1002) which... should not be failing. Unless you went into stealth or something. It might be something wrong with the general AI. The other one being used here is the damage event (1006) which makes him surrender. But you said that's working. Still, you could bypass the problem with heartbeat like I was saying before. If you copy the whole 1002 tree to 1001 and put in a condition that the henchmen are dead, then it should fire that when his heartbeat event fires in the event that the other one doesn't.

Are you sure the global is being properly set to 1? I've heard of that being a problem before. I'm assuming that's meant to happen when all the henchmen die and Xor's health is below a certain amount. If it's not that, then I would guess the problem is in his heartbeat script rather than anything there, since the user defined script only ever fires from that. You could probably ignore the problem entirely and simply fire the dialogue from his heartbeat script, too.

I started translating some of my ideas into code. This script is essentially a copy of the script for the dark side taint in the Tomb of Freedon Nadd: I've set it up so it can be applied to the player or the Disciple, or both. It grants a Force power based on a certain progression tree. If by any chance the character has all the powers it'll give them 10 bonus Force points instead. I've also drawn up a light side version: I've picked light side powers that I think correspond to the dark ones in the original script. Finally, these two scripts will check what power is supposed to be given without actually giving it: These will let the game say "here's what power you're going to get" in the dialogue file before it gives it to you. I think that should cover the rewards for generic holocrons the Disciple doesn't have anything to say about. I've yet to look at the ones he does say about in detail, though I imagine the player would find at least one generic one before getting any of the special ones. Holocron_Quest_Source_Scripts_v1.zip

It's possible to get rid of swoop minigame altogether and convert the tracks to regular modules. This would let you run around in them and take whatever pictures you want, though you would lose the swoop bike (which could be composited back on) and possibly all the other minigame items like the mines and accelerator pads. I believe I already have done that for each swoop track, though I'll have to dig through my files to make sure I can package it into something that can be installed easily. So let me know if you want to try that method.

Oh, so you're not doing any 2DA editing. Huh, this is... strange. I would think 154, 853, 907, and 950 might be in trouble too, but they actually do have custom loadscreens. Just not 205. There's a line for it, but it has 204's data. Maybe it was a typo. Progress looks good, in any case.

Yeah, I'd say the back for the reasons you mentioned. It also makes it seem more like the ship is going somewhere if we can see out the window.

Nah, 154 is the cutscene of him meditating on the bridge when the Harbinger arrives at Peragus. That is correct. EDIT: Whoops, I did... not read that properly. It's the cutscene with Admiral Onasi speaking to the player. After the battle. I suppose that would work. Hmm, I'd go for the overhead shot. It's the first time we see evil Kreia, so I'd avoid revealing her in the loadscreen.

There are modules that are missing loadscreens, or don't have unique ones, like 001EBO and 004EBO, which you've done. Some others that come to mind are 205TEL and 950COR. As far as mods, go, it would also be nice to have custom loadscreens for modules that replace prerendered cutscenes, like Sion's introduction, Visas' introduction, the Nihilus and Tobin scene, and Kreia's fall... but that depends on whether they were given unique modules and I don't recall if they all are. Sion's is 154HAR and I believe Kreia's is 907MAL, but I think the others are both 853NIH. There's also the Telos shuttle, if that was given its own module.

Yup, all source scripts are included. I know for sure because, given that five years had passed, I had to track them down to make sure all scripts were fixed and everything was included in the mod. I hope it helps! Even I forget how some of this stuff works, and I wrote them...

File Name: JC's Toolbox for K1 File Submitter: JCarter426 File Submitted: 01 Apr 2018 File Category: Mods K1R Compatible: No JC's Toolbox is a collection of items I created to perform various tasks while working in the game. Some I created out of necessity, others were by request, and a few were just for fun. If you're a fellow modder, think of these as developer tools. They can do handy things like add or remove party members, let you change party members whenever you want, open and close doors, play animations, delete objects, clone objects, adjust your alignment, warp, teleport through broken walkmeshes, and much, much more. And for the rest of you, if you were paying attention you might have noticed many of those functions are of a cheating nature. If you just want to mess around with the game, do stuff you can't normally do, you can find something useful here. Like make everyone in the game dance. Click here to download this file

I thought I’d start one of these blog things. I’ll be using them to announce... things. First up is the release of a mod that’s five years late. Veterans of the LucasForums era may remember a mod for Star Wars: Knights of the Old Republic II – The Sith Lords called “JC’s Toolbox”. It added what I called “a collection of items for developers, filmmakers, and cheaters of all kinds”. It let you do things like open and close doors, get free items and XP, teleport, spawn characters, and play animations, and it granted full control over the party system so you could add or remove party members wherever and whenever. I initially sought out these functions while making videos with the game, and also found them to come in handy with mod development. Before I made the Toolbox, I relied on a few different mods - the Whereami Armband, Call of Aid, Teleporter 2000, and the Wrist Console - to perform these functions. Most of these mods performed their function through armband items; you could equip the armband on your player character, and then it would fire the mod’s script when activated. The Wrist Console was a little different, using Mira’s wrist launcher as a template instead. But they all gave you an item that, instead of creating an energy shield, would fire a custom script to teleport you or spawn characters or whatever. I even made my own edits to a couple of these mods, adding more features like animations and unused camera modes that were left over from Neverwinter Nights. I used these for years before deciding to learn how to make a proper armband myself instead of hacking someone else’s. In the process, I also learned that armbands and wrist launchers weren’t even necessary: there’s an unused item type called “Plot Usable Item” that functions like an armband, but the function is available so long as the item is in your inventory. You don’t have to equip it at all. I believe this was used for the sonic device on the water suit in the first game, the one that lets you kill sharks. It still functions in KOTOR II, and since you don’t need to equip it to use it, I could access more than two of them at a time. The entire party could access them, too. That was much more convenient than the previous setup. So I decided to rebuild not only my mod hacks, but also many of the original functions of those mods, to give myself a set of Plot Usable Items to replace all the old tools. With accessibility being a non-issue, I decided to make several tools, each with a limited scope. My hack of Call of Aid had gotten particularly crowded, so I wanted to avoid that. Each new tool would specialize in a specific area, such as spawning characters, playing animations, or managing the party system. And I overdid it. The initial release of JC’s Toolbox contained eighteen usable items. I ended up making the actual Toolbox item just to be able to fire the other seventeen from the same place. According to my records, I released the K2 version of my Toolbox in December 2012, and over the following year I made a couple updates to that. I didn’t release a K1 version. There was a good reason for that. A bunch of my scripts wouldn’t work. It took me five years to figure out why. I was never compiling scripts for K1. It’s rather embarrassing, but that’s that’s the truth of it. I compile my scripts through a batch file, and I have a different one for each game. When I first set up the K1 compiler in 2009, I neglected to edit the file to change the game number. On top of that, I wasn’t aware of some significant differences in scripting for each game. I knew Obsidian added many functions, but I didn’t realize they had changed a few of them too - common functions like ActionStartConversation, DestroyObject, and CreateItemOnObject. Several functions have been altered to pass more parameters in K2. For example, when creating an item in K2, you can specify whether the player will be alerted through the GUI or whether the creation will be hidden. I first learned how to script in K2, and you could say I developed some bad habits and wrote all my K1 scripts under the assumption that they worked the same as they did in K2. And because both my compilers were set to compile for K2, I was never told otherwise. No error messages, no scripts that wouldn’t compile, nothing. The compiler was reading K2 scripts and writing K2 scripts, so as far as it was concerned, nothing was wrong. For nine years, I was writing scripts for the wrong game. For the most part, these scripts did work. I’m amazed how much of it did work. Even though the scripts were compiled for the wrong game, even with the differences in those functions, they did run. After all, I wouldn’t have gone so long without noticing the problem if the scripts didn’t work. I’m only now realizing how many oddities I encountered can be blamed on this mix-up. Up to a point, my scripts would run properly. Even if my script was compiled for the wrong game, most of the functions are the same, so it was happy. Then it would reach one of these functions that Obsidian had changed. It would get to an extra parameter that didn’t belong in K1. That’s where the trouble began. With CreateItemOnObject, the parameters are the item name, the object to receive the item, the number of items to create, and then whether to hide this process or not. In K1, the script was happy to put in the item, and the object, and the amount, but when it got to that last bit, it couldn’t take it anymore. The function wasn’t coded to allow a fourth parameter. So it would execute the first three parameters, and then it would get stuck. That meant it would actually create the item, as I intended. But the rest of the script wouldn’t run. Not just the rest of that function, but the rest of the entire script. That’s how these bugs would play out. My script would run up to a point, and then mysteriously stop running. It all makes sense to me now, but understand that for years and years, I didn’t have any reason to assume there was a connection between these oddities, or that they could all be blamed on such a simple mistake. As far as I was aware, they were isolated incidents beyond my control. I thought that was just the way things were, and developed some workarounds, like executing CreateItemOnObject in a separate script, that let me do things the wrong way for nine years. And even doing things the wrong way, I still managed to achieve most of what I wanted. But these bugs crippled the Toolbox for K1. I started working on it shortly after the initial release of the K2 version, but certain scripts just would not behave. I released a few betas of the K1 version that lacked the misbehaving features, but I held off on an official release until I could get them to work. I could never figure that out. I only realized my compiling issue recently, by happenstance, and from there I was able to unravel the whole mess. It was all because of a stupid mistake that was Past JC’s fault. Now, JC’s Toolbox for K1 is ready for release. It’s a collection of items for developers, filmmakers, and cheaters of all kinds. It lets you do things like open and close doors, get free items and XP, teleport, spawn characters, and play animations, and it grants full control over the party system so you can add or remove party members wherever and whenever. It’s five years late, but it works. And it was programmed for the right game.

I've thought about this before and I think it's a mod that's possible and worth doing, but it comes with some complications. First, the holocrons referenced in the Disciple's dialogue would be difficult to implement. Many of them would grant Force powers that are already learned through some other means, very late in the game, including Force Enlightenment and some prestige class abilities. Do you get something else if you already learned an ability with a holocron? Or does the holocron merely give you early access? What you already have the ability before finding the holocron? Do you get a different holocron? And would a version of the quest be available without the Disciple, either for male player characters or before you recruit him? There's a lot to decide here. Second, it's not really clear how the final holocron mission would play out. Some dialogue suggests the Disciple didn't know the Exile was meant to be his master so many years ago, while the other dialogue has him give the Exile's holocron to her because he knew, and he knew all along in the original release of the game as well, of course. Likewise, some dialogue seems to have him find the holocron by happenstance during the quest, while other dialogue has him take the Exile to the final holocron after all the others have been found. Perhaps both were possible, depending on things such as the order in which the holocrons were found, how much influence the player has with the Disciple, and when the Disciple is trained as a Jedi. Some coherent series of events would need to be realized. Third, any attempt at this mod would require editing the Disciple's global dialogue file, placing holocron items in numerous different locations throughout the game, and adding new journal entries and/or global variables. Naturally, compatibility with other mods would be a concern. Finally, it would be nice if it were possible for new planet mods to add holocrons to the quest. That would be another compatibility challenge, but it's something I would appreciate. If, for example, someone wanted to add a Sith holocron to M4-78, that should be possible. Or if a new Coruscant mod were to be made, as has been discussed, it would make sense for it to come with a holocron or two. I wouldn't make a holocron mod that didn't allow for that, and that's the main reason I've yet to attempt one. I think rather than a standalone mod, the holocron quest should be made as a sort of mod resource. I would include a system that could be edited to include any number of additional holocrons. Of course, the Disciple only has a few lines of dialogue, and therefore could not elaborate on the specifics of each one, but perhaps he could have something generic to say for the others. For the holocrons beyond the scope of the original plan, the items could randomly give you light or dark side points, or an ability you don't have, or some similar bonus, like what you when you access the dark side mist in the Tomb of Freedon Nadd. To account for a variable number of possible holocrons, the mod would have a sort of "next holocron" script to determine which one you find, much like learning the lightsaber forms. That would generate either the next holocron that has specific dialogue attached to it or one of the generic holocrons, depending on circumstances. Those are just some rough ideas for it, anyway. It's not like I've written code for it or anything. I'm busy with a few other projects at the moment, but I might lay out the core structure of what I've mentioned if I get some free time. I'm willing to offer assistance if anyone else wants to attempt it, also. But I wouldn't undertake such an endeavor lightly. This is almost as complicated as a planet mod.

The particle system doesn't care one whit about your TXIs. The data is on the model, as you suspected: The grid size determines how many animation frames there are and how they're organized. The one in your image is 2x2. It's the same way it would be in a TXI. If you just want to improve the texture resolution, then you don't need to do anything except keep your resolution a power of 2 and portion the frames the same way. All the game knows to do is halve it. If you want to add more animation frames, however, then you would need to edit the model. All this data is in on the OdysseyEmitter modifier.