Fair Strides

I'm positive I could help knock the rust off of those old gears. I'd even be willing to do a fair share of the work on the mod.

Well it's been a little while, hasn't it? Mostly my fault, though. Been busy with school and working on the Toolset mostly, plus there's the usual fun with DnD every week. I'm wanting to do another stream or two soon (I figure probably another US-and-then-EU session). I'm debating on continuing with the scripting because it's occurred to me that going anywhere from here requires and understanding of at the last the basic components of the game and the tools, so I might do a stream just on those subjects... I'm also not going to be able to do a Saturday or Sunday stream due to the schedule. At the very least, I can probably do a session on a Thursday night (bear in mind, I'm PST UTC - 8) and then another on the following Friday morning. What do you guys think? Should I go over the basics or keep going with the scripting? And what do you think about your schedules versus my availability? Also, if anyone ever wants to go into a particular aspect, they are always free to make the suggestion and I'll do my best to get around to it.

That was the case for the appearance.2da, which the game's files references by the row number. Your issue with that file was that you inserted the row above the last row instead of entering some bogus info in the very bottom row and then pasting your row over that one. Yes, the KT 2DA editor is clunky that way... However, the scripting functions that interact with the global values specifically take the value of the name column. The game uses that and doesn't care what order the rows are in. Also, you say that you plan on having five "tiers" of dialog that can be accessed one at a time. I take it the player can't ask about previous tiers? If so, you'd be better off using a global number instead of a boolean. This way, you can increase the global number by 1 when the new tier is ready to be accessed and you're only using one global variable instead of five or however many you'd end up doing. As an example: Tier 1 DLG: int StartingConditional() { // If the variable is 0 (default), this'll be the first time. // You can always adjust this by change the < 1 to < 2, which // would allow you to set the variable to 1 after you talk to // Shanilla the first time. if(GetGlobalNumber("<name of variable, without the < > >") < 1) { return TRUE; } return FALSE; } and then at the end of that branch of dialog, you could update the global number: void main() { // Set it to 1 if you originally had it at 0, otherwise set it to 2. SetGlobalNumber("<name of variable, without the < > >", 1); } Oh, and you can disable the color-coding if you set the code type to XML when in the code window.

Custom booleans won't affect compatibility, unless you somehow make the same global variable (remember, there are booleans and numerics) with the same case-sensitive name. As to what you're asking, can you do a little doodle or something to illustrate it? Is just something as simple as "If B and C are replies to A, how can I make B appear but not C?" or something more complex?

Looking up that global boolean, you need "kas_ChuundarDead" not "KAS_CHUUNDARDEAD". I don't know if I mentioned it or even got to it in the stream, but it is case-sensitive.

Seeing you link to the mediafire made me wonder and double-check something: was there a particular reason this never got uploaded to DS? I forget if you might have mentioned something in the LF thread or not.

Sorry for the delay. When I'm at home, 90% of the time I don't do anything modding-related because I can't actually run the games on my laptop. And I'm sorry I didn't get around to answering this, but Kexikus is correct. The only thing is that this only works the one time, unless you use the script "k_act_talkfalse" to reset the whole thing, but I think that's a K2 script (which you could remake in K1). When I originally read your post, I had thought you were asking about the concept and how to apply it to your own global variables. That would be the right function, but I've never seen that syntax (format) used before. Try modifying it to remove the " == TRUE" part. The GetGlobalBoolean function itself returns a 1 or a 0 (TRUE or FALSE), so the " == TRUE" could be interfering.

If you want to give me a few days, I can get back to my modding computer and do a write-up on weapon sounds and how the game uses them.

"Screw the rules" is never a polite phrase on a site that has rules, at least not if you want to rely on the rules yourself in the future... And we can't speak for someone who isn't here, much less presume how they'd feel about their content. As far as making an effort, Seikan knows of a way to contact him and can always have someone act as the middle-man to do so. He hasn't done this yet, so one could say the attempt hasn't been made/executed yet. @Seikan: I don't mean that in a negative way. Purely looking at it objectively/semantically.

Incidentally, it's also in cHaInZ.2da's archive. http://www.jumpstationz.com/ModsArchive/Sciamano/

Also, in the first or third tab of KotOR Tool's options menu, there is an option at the bottom that sets whether to use the .2da files from the BIFs or from the Override folder. This is turned off by default, meaning KotOR Tool will ignore any .2da files in the Override folder.

And a quick tip for you, QGG, before you test the installer: In the appearance.2da row entry in ChangeEdit (the | is the separator between the columns): 2DAMEMORY1 | RowIndex And in the relevant .uti/.utc file: "Appearance_Type" (without quotes) in the path/field box (should be the top box of the lower section in the editing section for the file) and 2DAMEMORY1 in the Value box below that.

CreateObject(OBJECT_TYPE_PLACEABLE, " marks>", Location(Vector(x, y, z), directional facing));

DP and DeadMan are correct. For one thing, there's a separate type of mesh/model component specifically for the saber blades themselves (which I would assume is what makes them flicker/have the trailing effect) and then there's the animation. The blades themselves are made up of 4-8 planes (single and short vs double) and use a Scale animation. During the Power-on and flourish animations, the scale is set to 1, giving the planes their size. When the power-down animation is played, the scale is set to 0. Other model components could also be scaled, but the main thing is that we don't know that particular piece of the model animation format. There's 8 pieces to any one segment of an animation and the last 3 pieces are unique to the animation type itself. We could possibly hard-code the values for a lightsaber-only compilation, but I'd need to see if that would actually make them work correctly.

@SH: To be fair, he said he got them from DS and they're no longer on DS, so I'd be inclined to ask if they were Xedii's/XarWarz's mods that he had us remove.

Generally if there's an update for a mod, it'd be a good idea to install that update. Also, you said that you're using a version of the mod from an altogether unknown (to me) source, so I'd DL the Deadlystream version. As to your issue with the installer, the solution is listed in the support thread for the mod, but it basically boils down to replacing all of the / with \ in the changes.ini files before running the TSL Patcher. Or vice versa, the \ with /.

Does this occur without the mod?

The reason for the crash is a difference in the .mdl and .mdx format between the two games.

Just for the record, the following baseitem classes in K1 have an evil texture column: Underwear and in K2: Underwear Basic Clothing Jedi Robe Dancer's Outfit Jedi Knight/Master Robe

Oh... I see what you mean. Yeah, that's my bad, I was thinking of something else. Yeah, you'd just edit the one model and that should be all. You'd just need to recompile multiple ones if you were splicing a custom one in the list at any point before the end of the list.

If you did it after "s_female03", when all of the character models reference "s_female02" or "s_female03", your custom one wouldn't be tied in any way to the models. Hence the need to set "s_female03" as the super model of your custom one and then re-compile every model (or hex-edit) so that your custom one was the new super model. Alternatively, the best way would probably be to splice your custom one (assuming you'd really need to keep it separate from the other animations) in between "s_female01" and "s_female02", that way you'd just need to set the super model in "s_female02" and re-compile (assuming you'd set the super model of your custom one to "s_female01"). Though the big assumption here is that the breathing animation isn't in "s_female02" or "s_female03"...

And assuming you did this between "s_female02" and "s_female03", you'd still need to-recompile your model and the "s_female03" model. Or if you did it after "s_female03", you'd still need to re-compile EVERY character model at that point. Also, I believe there are some models (I can't recall if they're body or head models) that use "s_female02" and don't go the last step for "s_female03"'s animations...

Yeah, if the animation named "default" (assuming that's the breathing animation) was in "s_female02", you'd only need to re-compile it and "s_female03".

@SuperSzym: No, the breathing animation is in one of the "super models" from which all of the NPC models (that are humans or humanoids) inherit there animations. Same thing with most of the heads, but the heads don't really breathe. So one would need to find whichever super model (either "s_male01", "s_male02", "s_female01", "s_female02", or "s_female03", in that order from first to last in inheritance), decompile it, edit what would probably just be called the "default" animation on the model, recompile it, and then re-compile any of the super models that come after it, with their files being in the same folder as this re-compiled one. Each of these super models has some of the animations, and they chain together through the field in the .mdl file that sets what super model the model references. "s_male01"->no super model "s_male02"->"s_male01" "s_female01"->"s_male02" "s_female02"->"s_female01" "s_female03"->"s_female02" The animations from the super models aren't actually imported when the model is compiled. The game will simply look in the model itself for an animation and then if it can't find it, it starts backtracking through the list of inheritance to try to find it.

*grins* Naturally, I feel compelled to say yes. To figure out the texture for a specific armor, you need three things: 1. The row of the armor in baseitems.2da. 2. The row in appearance.2da. 3. The Texture Variation entry in the armor's .uti file. In baseitems.2da, a row has two columns of note: itemclass and bodyvar. The itemclass entry is the "root" of the texture name for the item's icon. For example, the Combat Suit in K1 is Armor Class 4 in baseitems.2da. The itemclass entry for that row is "a_Class4". The icon file's name is generated like so: "i" + + "_0" + . Using the Combat Suit as an example again, the Texture Variation is "1", so this would be treated as "01" by the game. Combining the itemclass for the Armor Class 4 row in baseitems.2da, we finally get a name of "ia_class4_001" for the icon texture. The bodyvar entry indicates which "model*" and "tex*" columns of the appearance.2da row to use. Since the body var is "C", the Armor Class 4 items use the "modelc" and "texc" columns. For the typical row in appearance.2da the modelc column would be "PFBC*" for females and "PMBC*" for males (where the * is "S", "M", or "L" depending on class in K1); similarly, the texc column would be "PFBC" for females and "PMBC" for males. So looking at the Combat Suit's Texture Variation of 1, the game would again see it as "01" and this is added right onto the texc entry. For females, the Combat Suit would use "PFBC01" and for males it'd be "PMBC01". For other items that aren't armor, the process is the same, except you would use the Model Variation field from the .uti file.