DarthParametric

The reason you need a separate mesh for glowing objects is that Odyssey's implementation of emissive is done in the trimesh. The whole mesh has to glow, so any bits you want to glow have to be split off into their own trimeshes. They can share a texture. Animated textures are flipbooks. In other words, the texture space is made up into an array of frames, which the game plays in sequence at your defined rate (specified via TXI). Here's an example I found from a quick Google search: You can see here in this 512x512 texture that it is an array of 16 frames. If you convert this into a 128x128 GIF, you get the following animation: It should become immediately apparent why you want to confine animated sections to their own separate texture that only comprises the absolutely necessary elements. Like a monitor screen in this instance. You do not want to be trying to turn 2K textures into flipbooks.

Then it would be flipped on the left monitor. The UVs are mirrored down the center of the mesh. You either have to flip one of the monitor UVs, or break them both out entirely, either to their own island or to a separate mesh (if you wanted to do glow and/or an animated texture).

I don't think there is any actual text in the original, Aurebesh or otherwise. It's way too small for that. It would be easy enough to flip the UVs of the righthand monitor to solve the mirroring issue ndix UR's texture has. Or if you wanted an animated screen you'd need to break the screen polys out into a separate mesh and use a different texture (seeing as animated textures are flipbooks), so you'd be re-UVing them in that instance anyway.

Here's a render of the model with ndix UR's sample texture.

It would probably be easier to just add the headband mesh directly to the Yoda body model. I model in quads for any custom meshes, which may look a little "cleaner" in WIP screenshots compared to the game's triangulated meshes, but it's debatable whether my actual topology is any good or not. If you are a student, you can get a free 3 year educational license simply by using a school email (be it secondary, university, etc.) to sign up on their site.

Archive it with 7-Zip, that should shrink it down to something manageable. You can attach it to a private message. Btw, if you wanted to you could edit the model to add those glowy buttons as separate meshes, so they can actually glow. The monitor screens as well.

Not that I can see, but its problem is largely the same, namely that it is only 256x256.

Make sure you unlink everything before doing your reset. Then link everything back up before exporting.

A lot of the bad TSL textures are just holdovers from K1. The hutt textures are all from K1 for example, although for some reason Obsidian chose to downres them from 512 to 256 for TSL (which is probably Vogga's problem). It could be they blew their memory budget. The original Xbox only had a paltry 64MB of shared RAM.

You need to offset the mesh, not the pivot. And do a Reset X-Forms afterwards.

Ah, I thought it was someone in the refugee slums on Nar Shaddaa in TSL. Both being in K1 makes life a lot easier. It's just a simple override. Open KOTOR Tool. The infected soldier should be: Kotor I -> RIMs -> Modules -> tar_m04aa_s.rim - Undercity (Taris) -> Blueprint, Character -> tar04_republicso.utc Double click the UTC to open it in the Creature Editor. Then simply change the appearance drop-down to one of the Republic soldier or officer appearance entries, like so: Click the Save button to save the UTC somewhere. Then put it in your K1 Override folder. Using djh269's directions, again in KOTOR Tool go to: Kotor I -> RIMs -> Modules -> manm26aa_s.rim - Ahto West (Manaan) -> Blueprint, Character -> man26_manmerc.utc As before, double click the UTC to open the Creature Editor and change the appearance drop-down as desired. Click save and put the UTC in your Override folder. TWO THINGS TO NOTE: Firstly, this will not work if you already have a save anywhere in the area containing the NPC. The appearance.2da reference is permanently stored in your save at that point, so a simple UTC override won't have any effect. You'll have to load a save prior to entering the area for the first time. Secondly, doing the same thing for TSL is more difficult, as Obsidian was extremely lazy and did not give their UTCs unique names. Thus, you have to make use of MOD files. If you are using TSLRCM, as is almost certainly the case, you have to inject your modified UTC into their pre-existing MOD. That's a story for another day.

Which one? Odis, the former Republic pilot? The only other one I can see is simply labelled as "Veteran{Man}. You'll have to be more specific. Need a module name (Ahto East, West, etc.) and preferably an NPC name.

I have to say I was extremely surprised about the decision when I saw the notification. Especially given Dark0ne's stance on other matters relating to respecting author rights, and the fact that Gamefront has already been archived. There was no need for Nexus to touch it.

https://web.archive.org/web/20151002081041/http://home.comcast.net/~cchargin/kotor/index.html

You need to use MDLOps 0.5 for sabers, not 0.6 or 0.7.

Check out BIFs -> scripts.bif -> Script, Source in KOTOR Tool.

So what script couldn't you get to decompile? Were you talking about k_ptat_raceone? That does fail to decompile using DeNCS or nwnnsscomp, but the NSS is included with the game files: //:: k_ptat_raceone /* The player has won the first of the races on Tatooine. */ //:: Created By: John Winski //:: Copyright (c) 2002 Bioware Corp. #include "k_inc_tat" int StartingConditional() { if (GetRaceCompleteGlobal() == 1) { return TRUE; } else { return FALSE; } }

I tried it on XP Pro x86, SP3. Crashed at the splash screen. Perhaps you can make some sort of debug version that can log what is going on?

If you are not using 0.7 then you absolutely must break every single edge at the boundaries of UV islands. The older MDLOps had a bug where it wouldn't calculate geometry verts and UV verts independently.

DeNCS hasn't been maintained for years, probably a decade. It came out of TSLRP. I don't think they ever provided the source.

And so it begins. You've taken your first step into a larger world. A world of pain. To fix your UV issues, you'll likely need to add breaks at UV island boundaries. 0.7 addressed some of the issues, but it's still finicky.

Zaalbar has a GoggleHook at least, although Hanharr has neither. You could always try adding them, assuming the models recompile. I'd say a more pertinent question is whether there is a hard-coded restriction.

It uses the nwscript.nss from the game override folder, although it seems it does come prebundled with existing copies. However, I tried it on an XP box without the games installed and it crashed at the splashscreen like you described, so I thought it might be because it couldn't find the games (it presumably wouldn't find the Steam versions because they use different registry strings and I think the program may be too old to have included them). But if you are using the CD versions then that rules that out.

Are you using Steam versions of the games by any chance? It seems it does a registry lookup when starting....

Hrm, it does require 4.0. I'm kind of surprised actually, I was expecting only 3/3.5, which is more common for programs of that vintage. XP does actually support 4.0, although that is the last version it does. 4.5 requires Vista and up. But that should be sufficient. Can't really think of much in the way of options. You could try uninstalling 4.0 and running the full offline installer - http://download.microsoft.com/download/9/5/A/95A9616B-7A37-4AF6-BC36-D6EA96C8DAAE/dotNetFx40_Full_x86_x64.exe By the way, somewhat off-topic, but I would seriously recommend migrating away from XP ASAP. You should not be exposing an XP box to the internet in this day and age, it is full of security holes.