Fair Strides

To do this, you will need both the new entry in appearance.2da that you already know about as well as a new entry in heads.2da. You will need to enter the value of the new row in heads.2da into the "normalhead" and "backuphead" columns in the new entry in appearance.2da. In heads.2da, you can enter the same model name (which is in a column labelled either "model" or "label" or "head", I think) and then change the names in the various texture columns. For specifics on the various parts of the appearance.2da and heads.2da, I recommend the .2da reference guide in the tutorials section.

1. Static cameras have Quaternion orientations just like everything except for doors and IIRC placeables. 2. Static cameras (don't know about Animated, but I assume no) are oriented 90 degrees counter-clockwise from what you'd expect. This is why you had to enter the numbers for 90 degrees to get a 180-degree facing. I learned a bit about this in college math, but I honestly cannot recall the reason for this rotation... 3. Animated cameras, and indeed all models, use Quaternions; the tools do the conversion for you so you don't have to bother with them (trust me, they're ugly and annoying).

Most of the DLG Editors probably don't treat Unicode properly, I imagine. One that could potentially work is using TLKEd (found in the TSLPatcher download in the Modding Tools section of Downloads) to edit the dialog.tlk and dialogf.tlk file. For that to work, you'd need to go into the DLG files, add each of their lines one-by-one into the dialog.tlk file, and then update the entries/replies in the dialog.tlk file to point to the entry in the dialog.tlk file. That would also make future translations/corrections easier if need be.

@Sith Holocron: You know... I was going to do that mod. Then I saw a new mod released called "Train the Handmaiden", so I had assumed it did the Force Power training... Oops.

@VarsityPuppet: Oh, is this a race? I'd better hurry up and re-install my programming stuff if I want to get back to work...

Sir, I must inform you that you are posting in the download thread of a restoration mod for the KotOR game and not on the game's store page or another place where Steam is likely to see your message. That being said, I can understand your anger and being upset, as it clearly shows a passion for the games and the dedication to put the time in to attempt to make them work. I would also recommend that you go to GOG.com and look up their copy of KotOR 1 (and 2). These are basically pre-patched (I believe...) versions of the game that are copies of what you'd find as a 4-CD copy from an old game store.

PorygonZRocks: I'm not sure if you know of me or not, but that knowledge would only help in giving you confidence in my offer. I have access to most of the file formats the KotOR games use and I recently just finished converting TSLPatcher from Pascal to Perl so I have the entire source code in two different langauges and can answer questions. Had I even known this project existed (it likely got buried in all of the holiday and Episode 8 stuff), I would have been able to help out much sooner. Things like the .mod, .erf, and .sav files are all in the ERF format, while the .rim files are in the RIM format; both are similar, but have their tricks for writing the files. Also, with writing RIM files, you will never be able to get a 1:1 byte-to-byte ratio between the original game files and edited files... :| I can be contacted on here via PM, on Discord (User name FairStrides, ID# 2148), or on Skype (though I'm rarely on that nowadays). @peedeeboy: I realize that you guys are already past the fun of writing .2da files (yeah, the pointers part was fun, avoiding a 1:1 ratio and doing it the way Bioware did it), but I felt the need to correct you in that KotOR Tool does not do a 1:1 Pointer-to-Data ratio. It still uses a single pointer for each unique piece of data, with duplicate data being referenced by the original pointer.

...The view behind you and the view in your sunglasses don't match. Glasses look like you're standing in the road and taking a picture while a car's approaching at full speed.

As of 1-17-18, Snigaroo informed me that the download was broken and directing you to an error page here on DS. So he sent me the copy he'd already downloaded and I have re-attached it to the original post, as a .7z file that you will need to unpack using WinRAR, WinZip, or preferably 7zip.

Ndix_UR: I had completely forgotten about this. I fixed this bug in ERFEdit, but forgot that TSLPatcher uses a copy of this library. In either case, I'm mostly done translating TSLPatcher to Perl, where I don't even bother with the check on the filename's contents.

As far as starting the game of pazaak during a dialog, you want to have a blank Entry line after the Player reply or NPC response to starting a game. For that blank Entry, you'll want to put "a_playpazaak" (without the quotes) in the Script that fires #1" slot. This script uses TSL's Script Parameter slots in the DLG file. In DLG Editor, the slots for this script have the following use: P1 - Which row from "pazaakdecks.2da" will be used to form the opponent's side deck. P2 - The wager amount P3 - Whether or not to play the tutorial P4 - The delay (in seconds) before starting the game String Param - The name, minus the extension, of the script to run after the game is over. This is typically used to set a global variable or whatever and then start either the original dialogue or a new one. There is a function called "GetLastPazaakResult();" that needs to be used before you reload the save, since the result isn't saved. I'm assuming you'll have the dialog file itself figured out. The actual scripts you would use could be as follows: Script to run after the game is over: Script to check if the Player won the game: If that last one doesn't work, then you'll need to edit the script that runs after the game is over to include the following BEFORE you start the conversation: SetGlobalBoolean("G_Paz_JustPlayed", GetLastPazaakResult()); And instead of the script above that checks if you won, you'd use the "c_glob_bool_set" (minus the quotes) script as the conditional script. You'd enter "G_Paz_JustPlayed" (minus the quotes) as the String Param for that script.

@Qui-Gon Glenn: I believe the person is asking if they can copy-paste their fully-modded folders from the KotOR 2 installation on GoG into the TSLRCM workshop folder on Steam. They're asking if mods act differently (in-game) on Steam compared to GoG. And if that's the case, the only issues you could conceivably have would be Steam verifying and re-downloading the TSLRCM files, and potentially issues with the game's audio (voices, music, sound effects, .etc) due to the formatting.

Read the very end of Milestail's last post (which is the second post above yours).

If you wanted to either send me the scripts or tell me where to find them (and their names), I could change that so that it actually does depend on the power you use (which makes a hell of a lot more sense to me...)...

Might try changing "ActionJumpToLocation" to "ActionForceJumpToLocation". Otherwise, just change the coordinates in the module.ifo file. Also, are you using the coordinates I posted above, or are you using 200 as the X? If so, I don't think that's a valid coordinate (as far as the walkmesh is concerned), so you might try the 244.

Nope! The GetPartyMemberByIndex function works off of the current party you're walking around with. It starts at 0 (the character the player is controlling) and goes up to 2. When it hits 3, the object doesn't exist and the while section is done. Also, you'll want to correct my typo... Inside the while block, I have: iIndex++; oTarget = GetPartyMemberByindex(iIndex); You'll want to change that to this: iIndex++; oTarget = GetPartyMemberByIndex(iIndex);

void main() { if ((GetIsPC(GetEnteringObject()) == 1)) { location lJump = Location(Vector(244.0, 55.1, 8.99), 0.0); int iIndex = 0; object oTarget = GetPartyMemberByIndex(iIndex); while(GetIsObjectValid(oTarget) == 1) { AssignCommand(oTarget, ActionJumpToLocation(lJump)); iIndex++; oTarget = GetPartyMemberByindex(iIndex); } AssignCommand(GetFirstPC(), ActionStartConversation(GetObjectByTag("DarthMalak"), "scene_06", 0, 0, 1, "", "", "", "", "", "")); PlayRoomAnimation("StuntRoom40d", 1); } }

Loading up the level's files, I believe the issue is the fact that the module's spawn-in point is right in the middle of the room. If you want to move them back behind the door, you have two options: 1. Open the "module.ifo" file in K-GFF and set the "Mod_Entry_X", "Mod_Entry_Y", and "Mod_Entry_Z" fields to 244.0, 55.1, and 8.99. 2. Modify the script to move the PCs to those coordinates using "AssignCommand(, ActionJumpToLocation(Location(Vector(244.0, 55.1, 8.99), 0.0)));"

@DarthParametric: What module is that one again? I can load it up and check it out (the module with the Leviathan).

@Pepoluan: As it turns out, I'm rebuilding the TSLPatcher in a different language (from Delphi Pascal to Perl) due to some annoying issues with it. Most of your list I've already been implementing. I can probably allow a "modinstall.ini" in the same folder as the .exe, with a sub-folder called "moss". The "modlist.ini" would then have a list of installs to run back-to-back, with paths to the .ini files to run and the name of the Info file. The paths would be relative to the mods folder.

@Kreia: You're evil for showing the food and not sharing! @Deadman: Nice! Given the mixed opinions I've been trying to avoid hearing, I was expecting a crying face...

As far as I am aware, the only thing that would happen is that the wrist launcher's texture wouldn't change. I can retrieve my old files and test, though.

Oh, I really dig the shine and effect work you've done on it. I kept it to a separate texture all by itself, but I should be able to re-rig your texture like that. Though, I might need a copy of the UV template for just the wrist launcher to make mine match up.