DarthParametric

Perhaps you could hack a console to get a binary load lifter in there to carry the locker back to the sub.

My feeling is that the Ebon Hawk models are probably mostly ok, they primarily need some new textures. Looking at the Peragus and Korriban videos, the CG model doesn't look significantly more detailed. That said, it's certainly feasible to touch the old girl up a bit, add in some extra geometry where necessary. That's probably getting ahead of things though. I would think the logical place to start would be producing a spreadsheet of exactly what is needed for each shot in terms of assets, determining what already exists in the game content that can be used as-is, what can be used but needs some TLC, and what needs to be scratchbuilt. Then you can start soliciting for volunteers to tackle the various bits. It would presumably be wise to make use of some sort of tracking/project management system. And something like a GIT or SVN repository would be useful for sharing/storing the assets.

I'm not sure if this is a bug, or user-error. I tweaked the astromech animations to suit my model: clean up some clipping, add in a probe arm door, and animate the rear wheel. Testing it in game it seems like certain animations are stuck on their last frame when finished, rather than returning to the default. For example, using security to open a cylinder, when complete the probe arm will remain extended rather than retracting. Similarly, after combat the gun will remain popped up rather than returning to flush with the head. Do any potential causes spring to mind? A casual comparison of the animation section of the ASCIIs for my model and the vanilla don't reveal anything obvious. Edit: If I load the vanilla animations back onto my model, they seem to function correctly. So presumably that means some error on my part. Edit 2: OK, disregard. Seems like a couple of animations have bad keys at the end, causing the poses to blend into the subsequent animation. Entirely user-error. Edit 3: Maybe not. Comparing the animations in question to the original again, they actually seem the same. I did notice that my model had the "compress quaternions" option turned off, unlike the vanilla model, but when I enabled that and recompiled, that seemed to screw up the animations even more, seemingly reversing things. For example, unlocking a crate, rather than rocking back and extending the probe downwards, with compressed quats he leans forwards and the probe points up in the air (like he is giving the finger - must be going through a rebellious phase). The end result is still the same, with the probe remaining extended after the animation finishes, it's just rotated 180 degrees now. Edit 4: Reloading a fresh version of just that one container unlocking animation from the vanilla model and adding in some extra keyframes for the probe door, it still results in the probe arm hanging out at the end. It's kind of like that saber animation issue where the blade stays extended. Edit 5: OK, the problem was user-error indeed. It seems the problem was missing keys for the default state for certain parts. So presumably the model had no return state for things like the probe arm, so it just got stuck in the last used pose until it was repositioned by another animation. Adding some keys for neutral states to the other animations appears to have sorted the problem. I guess there is nothing more to see here.

Is that the bloke hiding in the locker?

I was just talking about the landing/take-off vids.....

I just watched the TSL landing/takeoff videos again, and wow the quality really is terrible. We must be to the point now where it's time to re-render all those as some sort of large group project. But in terms of the skybox, it's very orange.

One option may be to re-bake the level's shadow maps if you think the lighting is wrong.

Hrm, the last one looks a little too blue to me. I think the middle one is closer to where it needs to be, personally.

No. The T7 version is the default. The vanilla-style head with blue stripes is an optional alternative. With all the other stuff on my plate, I don't have plans for any further variants at the moment. I still have to sort out the protocol droids so I can get the first round of testing done over Xmas. Then after those two are released, it's on to the war and assassin droids. Once all the base versions of the mods are out, I may come back to it at some point in the future as part of a revision/update, but no promises. Of course there's nothing stopping someone else from releasing different texture variants. Edit: Now the testing can commence.

Soon™: With that many lights, I could probably start my own disco cantina.

You have two options. The quick way is via scripting, to spawn the object when the PC enters the module. This is best used for testing. Typically you hijack the on-enter script for the module to have it fire your script first, before passing on the original on-enter script. You can read some info about that here - https://web.archive.org/web/20151203123041/http://www.lucasforums.com/showthread.php?mode=hybrid&t=143536 - as well as plenty on DS, such as - http://deadlystream.com/forum/topic/3894-module-npc-and-object-placement/ - if you use the search function/Google. The second option is what would be considered the "proper" way to do it for the finalised version of a mod that is to be publicly released. Namely, adding your content to the module itself via a MOD file and editing the module's GIT to add in your placeable spawn data. The downside of this approach is it only works if you haven't previously entered the module, hence why this is better left for release versions and using scripting for testing.

There appears to be an issue when processing a series of textures one after the other. After the 3rd or 4th texture, the program shows a red "compression failed" message. It's not a problem with the texture, as after closing the program and restarting it, the texture is processed with no issue. I got the error twice whilst converting a batch of 14 textures.

It should be g_w_hldoblstr004.uti in LEV_M40AD_s.rim.

Can't recall one. I'd guess it is unlikely given you'd have to remodel the entire back. If you remove the backpack you are left with a giant hole, seeing as those would be wasted polys.

View File K1 Main Menu Widescreen Fix This is a companion to my TSL Main Menu Model Fix for Widescreen mod. In a similar manner, it adjusts the model file for K1's main menu so that it properly fills the full screen width of widescreen aspect ratios (i.e. 16:9, 16:10). It is designed to be used in conjunction with ndix UR’s KotOR High Resolution Menus mod (as pictured). Because the original vanilla background texture is very low resolution, it looks pretty terrible when scaled up to fullscreen at 1080 (or above). I created a new, higher resolution background texture that approximates the same look. As of v1.1, an optional replacement logo is provided. This is a TOR-style version of the logo, created by GOG. Two versions are provided, one of which is offset in order to better align using the current version of ndix UR's GUI mod. A centered version is also provided in the even that the GUI mod is updated. Note that I have only tested this at 1080. I have no idea how the image may be positioned at different resolutions. Obviously this mod will not be compatible with any other mod that also alters/replaces the menu model. As mentioned, it is intended to be used with ndix UR’s UI mod, and serves no real purpose without that mod. N.B.: This is NOT a widescreen mod! This is just an addition for when you are already using a widescreen mod like UniWS. Installation Instructions Extract the archive, copy the MDL, MDX, and TGA files, and paste them into your Override folder. If you also wish to use the upscaled vanilla logo or the TOR-style logo, copy the appropriate version to your Override folder as well. Acknowledgements Thanks to @bead-v for MDLEdit and KOTORMax that made editing and compiling the menu model possible. Thanks to @ndix UR for testing the mod and various discussions pertaining to its development, as well as all the behind-the-scenes work in getting the new mod tools off the ground. Thanks to @JCarter426 for helping out with filtering via waifu2x to clean up some of the aliasing Submitter DarthParametric Submitted 12/05/2017 Category Mods K1R Compatible Yes  

Not mods per se, but bead-v and ndix UR need special recognition for their work on MDLEdit, KOTORMax, and TGA2TPC. A lot of future mods will only be possible thanks to their work on these tools. =========== KotOR High Resolution Menus by ndix UR - http://deadlystream.com/forum/topic/5790-downloadkotor-high-resolution-menus/

Before installing, open changes.ini found in the tslpatchdata folder in a text editor. Delete the following lines (lines 169-192): [p_carth001.utc] !Destination=Modules\003EBO.mod Appearance_Type=2DAMEMORY3 [p_carth002.utc] !Destination=Modules\003EBO.mod Appearance_Type=2DAMEMORY3 [n_carth001.utc] !Destination=Modules\151HAR.mod Appearance_Type=2DAMEMORY3 [201_carth.utc] !Destination=Modules\201TEL.mod Appearance_Type=2DAMEMORY3 [carth.utc] !Destination=Modules\205TEL.mod Appearance_Type=2DAMEMORY3 [221_carth.utc] !Destination=Modules\221TEL.mod Appearance_Type=2DAMEMORY3 [222_carth.utc] !Destination=Modules\222TEL.mod Appearance_Type=2DAMEMORY3 [carth_holo.utc] !Destination=Modules\602DAN.mod Appearance_Type=2DAMEMORY3 You may also need to change the [GFFList] near the top of the file to: [GFFList] File0=n_repoff001.utc File1=rep_gen.utc File2=rep_gen.utc File3=rep_gen.utc That will still keep the 2DA entries and models, so if you wanted to you could change the Silveredge appearance to use the Carth head I added with the admiral's cap. I figured that was probably the case. I'll remove that one.

Hrm, I looked at his UTC on both Citadel Station and the Harbinger and I was sure they pointed to an officer appearance. I'll have to check if there are additional UTCs. Edit: OK, looking in 151HAR, n_repoff001.utc points to appearance Republic_Soldier_Mal_Old_Black which uses N_RepSold. So yeah, that is just the generic soldier appearance. It should be considered a bug in TSLRCM, seeing as all his other appearances use the officer body. It should be reported to the TSLRCM crew as such. Yeah KTool relies on the registry for the game's location. Steam uses keys it doesn't know about. I posted just the other day about how to fix it - http://deadlystream.com/forum/topic/5852-lack-of-head-skins/?p=60954 Be aware however that if you are using the Workshop then KTool won't see that content. It only sees what is in the primary game folder. The comments say it no longer works. ======================================== Edit: I've had a look at the Admiralty mod's contents and I have to say I'm unsure why it's as complex as it is. It edits scripts and dialogues, adding in new UTCs. I would have thought simply editing the original UTCs to point to the new appearance rows would be sufficient, at least for TSLRCM. I've never used it myself. Did it add in cut content for Carth before TSLRCM was around? Here are all the UTCs I could find in TSLRCM: The two Carth ones I highlighted I am unsure about. I assume that the Dantooine one must be Admiral Onasi, but the one on the Ebon Hawk I am wondering if it may be something else. It seems to be the logical starting point is creating new appearances and then editing these UTCs to point to those. The problem is testing, seeing as you need a save before having entered that module, which more or less means playing a full game. ======================================== Edit 2: Seeing as Jinger gave permission to use the mod assets with attribution, I figured I'd have a crack at making a revised version of it. I actually ended up just making new models, seeing as the original used full body models. I went with separate heads to make reusing the bodies for other purposes easier, and because Jinger swapped out the original Saul legs with Carth's, while I kept Saul's but modified the texture. I also lopped off the bit of their heads underneath the hats, as I noticed that Jinger didn't do that and it looks pretty weird on Carth in hologram form. Like I said, testing is difficult, so I have only been able to test on the Harbinger so far, but that seems to be working at least: If you want to test it, here's an initial version (you'll probably need to start a new game): It's designed to only work with TSLRCM, so if you are using the Steam Workshop you'll need to install it over TSLRCM's Workshop folder, which should be \steamapps\workshop\content\208580\485537937 for the English version. If you also use M4-78, I gather you'll have to install it over that instead, but I don't use that so I haven't tested it. Edit 3: File updated: Edit 4: I just realised the the Cede portion (beyond the Harbinger at least) would be broken in the file I posted because of TSLPatcher's inability to deal with editing multiple instances of UTCs with the same filename. This now at least partially explains why Jinger's original mod was more complex than I expected.

Looking at his UTC, he uses the generic Republic_Officer_Mal_Old_Black appearance, which uses the model N_RepOff. So he should already be in the officer's uniform. The Admiralty mod is just an edit of the Saul Karath model/texture to make it match Admiral Dodonna's model/texture (both of which remain in TSL's files). The easiest thing to do would be to replace the male officer model with the Admiralty mod's model, and the female officer with the Dodonna model. That would require minimal effort. The better option would be to create unique appearance rows for with those models for Cede and anyone else you want to change and then edit their UTCs to point to that (of course that is basically remaking the Admiralty mod, or at least the compatibility patch, so I assume you don't want to go down that route).

Reverse image search is your friend. It's the Final Touch mod by oldflash: https://www.nexusmods.com/kotor2/mods/429

You'd have to extract, convert, and load the models into a 3D package. That's not something that can be covered with a quick explanation. You'll have to go look at some of the mod tutorials that cover that. KOTORTool will individually convert TPCs to TGAs. Someone (maybe tk102?) made a commandline batch converter, although I can't find a link for it at the moment. However there is also a commandline converter as part of the Xoreos Tools: https://github.com/xoreos/xoreos-tools/releases/download/v0.0.4/xoreos-tools-0.0.4-win64.zip https://github.com/xoreos/xoreos-tools/releases for other versions. You can use a batch file to mass convert TPCs. Put the TPCs in the same directory as the tools, then extract the BAT from this Zip: Batch_Convert_TPC.zip into the same folder. Double click the BAT file and it should convert all the TPC files it finds. The batch command, for those interested: @echo off for %%F in (*.tpc) do xoreostex2tga --tpc %%~nF.tpc %%~nF.tga pause

I assume you mean C:\Program Files (x86)\. In that case download and extract the attached Zip, then double click on the extracted REG file, clicking on Yes when asked. KOTOR_Original_Registry_Keys.zip