DarthParametric

Playing through Onderon, a couple of a additions to the wish list come to mind. JCarter and I discussed these previously at points, namely the Mandalorian shuttle and the Basilisk War Droid. If you were going to remake the landing videos, might as well add those two to the list. That would be a good opportunity to switch out the in-game appearance of the shuttle, swapping the G-Wing for something else. And of course tackling the issue of the canonicity of the Basilisk's appearance (or lack thereof).

The forum has a large mod projects sub-forum. I'd suggest that if this project is to progress to anything significant, an early point of business would be creating a dedicated sub-forum for it. That seems like it would fall under your purview. Depending on how hands on you want to be, there are a myriad of managerial/organisational type things that you could do. Having been involved in an (ultimately failed) large mod project before, I know firsthand that these sorts of things live or die based on organisation. Trying to get a group of disparate modders to do anything collectively is like herding cats. It will quickly fall into a heap unless things are very clearly planned out. As an example, for myself as a potentially interested contributor, what I absolutely need is a clear outline of exactly what the project is doing, what has been done, and what yet remains to be done, and who is doing what. I need a list of tasks that are awaiting assignment that I can peruse, and if one takes my fancy I need very specific guidelines for what is required and by when. To use the Yavin station as an example, I would want specifics of size/dimensions, does it have to be fully constructed or do you only need a camera facing half, is it a high poly CG model or a low poly game model, does it need lightmapping UVs, do I need to create the textures, what's the timeline for completion, etc. Who do I talk to if I have questions/problems, how do I report my progress, what do I do with the final assets? And if I agree to undertake this task, then it needs to be made clear that this task has been assigned, so someone else isn't doubling up the same work. Someone, or possibly several someones, needs to implement and manage such a system.

Yes, I noticed. To be honest that's premature at this stage. At this point we need discussion and organisation. Randomly making stuff now is a waste of time, as chances are it could end up needing to be partially or wholly remade at a later date once all the requirements are known. And regardless, doing it via random request threads is not the way to go. That way lies madness. If you are keen to pitch in SH, I'd suggest there are far more useful contributions you could make in an administrative capacity.

It's basically just a giant lightsaber with a couple of flappy bits. I don't think recreating it would prove to be a significant challenge.

I assume you are a former Bioware Austin employee, from their Cartel Market art team?

They are placeables in both cases. For the Star Forge captives, the label in placeables.2da is, for some reason, "Dead Malak". The model name is PLC_EndCorps. There are three static body meshes, two of which hide under the floor at any one time. The animations switch between the bodies depending on the status of the captive. There are four textures used for the bodies. The "healthy" appearance uses PLC_EndPlA and PLC_EndPlC. The "drained" appearance uses PLC_EndPlB and PLC_EndPlD. I recall there being some discussion here at one point about the possibility of replacing those with something less terrible, but at the time we didn't have the model tools to handle it properly. The injured Republic soldiers in the kolto tanks in the Taris Upper City South medical facility are the generic placeable KolTank2.utp, "KoltoTank2_with_body". The model is PLC_KolTank2. The body uses textures pmbal01 and PMHC04. The breathing mask texture is shared with the tank itself, PLC_KolTank.

That's C9-T9, the unbeatable swoop racing droid on Nar Shaddaa. I figured he needed a more sporty paint job.

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