JCarter426

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.

You may want to stretch it beyond the edges of your texture to be safe. If you can load the PSD version, you can also fiddle with the opacity of the bars. Given that I did it so quickly, I may not have been thorough with regards to accuracy. I did load up one of the game loadscreens and drew the new layers to match it, but I was eyeballing it. If I end up doing loadscreens in the future, I'll take a second look at it. Also, for future reference, to make the bars I first filled in some horizontal lines in black with the selection marque and the paint bucket. A single line was 4 pixels high in the original size, so 8 pixels for the doubled size that I did. I duplicated and moved that over and over to create the venetian blind effect - one line of black, then negative space of the same size, then another line, and so on. Once they filled the screen, I merged all the line layers and applied a blur effect. After that I reduced the opacity to 50%. The exact steps will vary depending on the software you use, but that's the basic design philosophy.

So it was compiling a valid model (which it definitely would if you used the wrong source as the "original") but the issue was its failure to realize hey, this object is the same as that one over there, and it should animate as that one does... that totally makes sense. I haven't done much compiling since before the latest MDLOps release, so I wasn't sure how it handled things differently, but that sounds like a good solution to me - try the cleaner method of loading the supermodel, and resort to the arcane rituals if that fails.

I will do you one better...

File Name: JC's Loadscreen Template for K2 File Submitter: JCarter426 File Submitted: 25 Mar 2018 File Category: Modder's Resources This is a template for the K2 style loadscreens. Included are a PNG overlay which you can place directly over your loadscreen background, as well as the PSD source. Note that the aspect ratio is 1:1, so the image will be stretched depending the display resolution. That's how the game's original loadscreens are. Click here to download this file

I don't believe there's an established date for it, but I believe you're right regarding the reason for that date being mentioned in the mod. It would fit with the timeline if we assume the L'Xing/Gu-vandi incident was incited by Revan via an HK unit.

Nah, that's what I mean - renaming files for compiling. It wasn't always necessarily the supermodel with MDLOps, though. A head, for example, would require another head as the original, or else the lips wouldn't move. MDLEdit on the other hand specifically wants the supermodel, not renamed.

The basic functionality is the same - load ASCII, save as binary or load binary, save as ASCII. There are some things MDLEdit can do on its own without conversion that might warrant tutorials. Anything you could do by hex editing before, and a ton of stuff you couldn't. But the biggest difference between MDLEdit and the old MDLOps rituals would be the files you need when you compile a binary model. For any character models, MDLOps required a binary model in order to copy data from it. There were some parts of the model we knew what they did, but didn't understand how they worked, so MDLOps couldn't write it correctly because nobody knew how to tell it. (I say "we" but hell if I know what any of it is). So instead it looked for a model that was already compiled so it could copy the hex values from it directly. This is also essentially how HeadFixer works - it inserts missing data onto the model that MDLOps failed to. So when MDLOps loaded an ASCII model, it needed a binary model of the same name. If it couldn't find one it would say it failed to load the "original model" (i.e. the one it wanted to copy data from) and then freeze. Often the case was if you werere editing a model, you'd keep the original binary model in the same place and put the new ASCII there and recompile, but this was not always the case. You could have any model serve as the "original" so long as it served that purpose, and you could get different results from using different models in this manner. It was a bit dodgy. The important thing was it needed a binary model named exactly the same as your ASCII or else it would freeze up in such cases. MDLEdit doesn't want that, however. Instead, MDLEdit wants your model's supermodel (aka parent). I'm guessing it's for more or less the same reason, just a different process. In short : MDLOps - a binary model to serve as the "original model", one similar to whatever you're compiling MDLEdit - the binary supermodel that your model is using

They very well could've planned a colony for the sake of planning a colony and not because of the civil war. However, by the time of the game, they are in no condition to start a colony due to the civil war. The planet was abandoned, so apart from that being a reference to other events mentioned in the game, it doesn't really have a connection to where the droids or Sith came from.

I'm not positive and more testing may be needed, but that was my initial impression. I added in up to line 580 or so and tested the last one with dummy items. Initially, the game crashed on launching the upgrade screen. After a couple instances of that, it stopped crashing and would display the new crystal, but I couldn't select it. I tried like 255 and this time I could select the new crystal and assemble the lightsaber. Then it completely destroyed the lightsaber. That's the sort of thing I would expect if it were generating nonexistent UTI items, but I think I had them set correctly. Also in this case, the preview would display a model of the lightsaber crystal rather than a lightsaber. Finally, I tested line 127 and that performed as expected. So my tentative conclusion is it only supports 128 lines. I should test it some more, but it was such a shocking, disappointing discovery that I haven't wanted to take a second look yet... I'll have to muster up the courage. By the way, I've confirmed you can put anything into upcrystals.2da and it'll recognize it as a valid crystal item. So that's not an issue, at least. It's 255, but yes, that's right. I've already planned around that, and have room to spare. That's the problem. I did want most of these to be in the upgrade system. The new exotic types (lightsaber pike, crossguard, etc) would not be upgradeable, due to either requiring new base item types or not making sense when applied to the upgrade system (imagine putting a longsaber crystal in a short lightsaber). So those are fine handled through the new console, as you say. The regular hilts, though, the ones that only apply aesthetic changes, I had intended to be upgradeable. The console would create the hilt item and merge it with a crystal to create a new crystal item, but the rest would be handled through the existing upgrade system. And it seems the number of those possible is severely limited.

Hmm, I'd say the ones that have been the biggest pain are player armors C and H in both games and I in K2 (PFBCM/PMBCM, PFBHM/PMBHM, and PFBIM/PMBIM), and maybe the commoner clothing too (N_CommF/N_CommM). That's mostly down to how versatile the models are. There are loads of robe mods of course, while armors C and H and the clothing are useful for new NPC designs. I can also recall some models with rather bad mapping, like PFBMM and the Twin Suns body model. In general, the male textures are of higher quality than the female textures. This was especially so on the Republic armor, which is one I already sorted. For that, I tweaked the male model to bring it more in line with the body shape of the female model, while retaining the male texture mapping. I tried to do the same for PFBCM, with underwhelming results. The best option would be entirely new maps, which would also get rid of the mirroring issues, but that's beyond my skills. So there's my wish list if you ever want to take a look.