sELFiNDUCEDcOMA

It's a possibility that it is something to do with the issue, but if you are referring to the shadow-flag (byte) in the mesh node, then I already tried turning them off. However, I've found that the dirt-texture entries (both Int16) also affect whether shadows get rendered or not. I set them bot to zero but haven't gotten around to testing them yet -- it doesn't crash immediately, but something like 15-25 minutes into play. Again, could be part of the issue, but, I need to audit the edited model files to make sure that the changes made when converting to TSL haven't been stuffed up anywhere. It may also be a case that switching to a different model type will solve the issue -- as not all of them cast shadows. Hopefully it is something easy that doesn't require model mesh editing, as I'm not set up for that or have the time for it -- my modelling experience (especially for 3DSMax) is limited. Which could be the case if it is actually something to do with the scale controller which resizes the meshes to look right in the game. My feeling is that it could be this, as that is likely what the game is doing when it crashes. It's resizing the models based on read in mdx data that may have issues or it is just not expecting the models to needing to be scaled -- I'd have to check the vanilla models, but, I think they don't use this controller and its presence could be causing the issue.

Well, I thought I'd clarify some things. I've been working on my tool quite a bit, in that I wanted to get certain features done before I left it alone for I don't know how long. One of the things I wanted to do was support K1 models, which it hadn't up until that point. That was relatively easy. Then I wanted to support the conversion of K1 models to K2; that was a bit more involving considering the way the tool reads the models. I also had to write a feature that removed orphan controller header data that I think an old version of MDLOps would put into the model files. Having done this I put it to the test, in that I gained permission (quite some time ago) from Toasty Fresh to use his weapon work within my mod. My plan back then was to replace all the models and create new ones for all the uniques, never got a round to it. Since then Sithspecter released a weapon mod for TSL for all the ranged weapons that looks great -- haven't gotten around to using it myself as I wanted to keep my install primarily just to my own mod files for clarity. So, I focused on the melee weapons. I converted the models, got them working, and updated the textures so that each had their own variant to (more or less) match those found in TSL. I also created some new model variants to use in special cases from model variants that Toasty supplied. However, I also used some weapon models done by Oldflash who I also got permission years ago to use his work -- though, I think he has since stated that anyone can use his work. However, on playing a section of the game repeatedly -- the tomb -- I found that the game would crash when one of the NPCs would switch to a vibrosword. I've determined that it is the new models, however, haven't found what issue with them is causing this. It could be a model mesh setting that I set that doesn't need to be set, it could be a setting that isn't set that needs to be set, it could be the base model type I'm using for the weapon -- weapons can be any number of model types -- or it could be something to do with the conversion process that got stuffed up that I haven't catched yet. I'll give it some more work, however, I will likely remove the new models and textures for the release and just leave the new UI icons in place for weapons. When the game loads a model based on the UTI and finds the model variant is not present, it defaults to the first model variant for that weapon type. So, it won't look great in a few cases, however, the game will still be playable with the vanilla melee weapon models or with someone else's that replaces them. The main thing I would like to do, is complete the dxun tomb animated computer screens, for which I am still testing out colour schemes to use: It's the main thing I want to get done. I'd also like to do the Telos RZ grass texture, however, I currently have it as a simple transparent texture so, it won't look as great but it is still playable. I've simply run out of time on this, I really want to get some kind of release done as I don't know when or if I will ever return to this again. But I have devoted too much time to it already due to my stubbornness and puzzling interest in this game, considering the future of (and vision for) Star Wars based on the last film released by Disney. I can only think of this video series as to why TSL (over KotOR) as a story holds such interest for me, and why I wanted to tell my own story within it via a planet mod. My intent currently is to complete a few things and the try a few things for the sword models to see if I can get them to work without crashing the game. Then I need to playtest the start of the game to ensure that I don't have any testing stuff still appearing at the start. Once that is done, I will then compile a list of all the things this mod does (to the best of my recollection) and then zip up my mod files to release them. When I have more to post, I will.

Some miscellaneous stuff... [had to post this separate as I hit my max images per post limit]

So, an update... Realised that the Dxun jungle fixes were resulting in the affected model textures being rendered too bright, so, I fixed that: I completed the fix for the rest of the Dxun jungle areas, however, ran into a problem with the Dxun Tomb exterior: Decided to make some changes to the Telos Polar Academy -- making use of textures made and unused for the Tomb: Checked the Hand Sister appearance, all seems to be working correctly as far as I can tell.

So an update... I'm just about finished with what I planned for Dxun, I added a feature to my tool to fix the meshes so that the buggy fog isn't a problem for those who also want to use ReShade and can't use Shader Override. Basically the feature meant that hours of work took less than 30 minutes. For the most part. There's always the odd model or two that you need to go in and manually look at and change so that the game doesn't crash. I have 2 such models left for the Dxun Tomb exterior that I haven't gotten around to doing -- probably tonight just to have it finally out of the way. The real issue with Dxun is that all the rest of the textures need to be redone so as to capture the look again. It's surprising how much the original (working) fog covered up when it came to the textures. But that will have to wait. The big thing that bugged me with the Aspyr Steam update however, was not the fog but the sabers. Once I had a working tool that I could customise to my needs, I started looking at the issue to determine whether I could get them working without having to use a custom version of Shader Override (or the like). Turns out I could. Once that happened I started to focus on lightsabers. I don't have time or all the tools to update the models, however, I did start a texture mod for them a while back. I carried this further and completed a range of saber texture variants to use for certain colours: It's not perfect, rather quick texture jobs for me -- though editing and testing models is a real time sink. The original plan was to have unique models for each, gather models and got permission from the community for this years ago. Might still do it in the future, but, this is the quickest "fix" I could do with limited time. I also re-did all saber UI images, as I found they weren't clear as to the type of saber -- double, single, short -- and a few of the colours used for the blade colour just weren't clear: Finally I may redo some of the actual sabre blade colour effects based on how they are rendered now. My short-short list of things to do before I can release the mod: Double-check hand sister appearance and verify that it is all working and not causing bugs. Verify that the female (placeholder) variants for the armour changes I made are working -- can't recall if I test this or not. Finish the last Dxun Tomb texture -- the large animated computer screen that has become a chore to do. Telos restoration zone grass texture -- to go with the overhaul textures. Telos restoration zone shield (animated) The odd screwed up appearances for NPCs where I forced them to use a spec map for alpha when it needs to be used for transparency. I'm going to have to push back the release of the mod for a bit. I've run out of time and motivation. I have things to do by the 31st, and then some other things early Feb. And a lot of this work is just tedious due to how repetitive it is -- even with the tool I still do a lot of trial and error testing that is a drain of time and energy. So, I will look at this all again come next weekend to see when I can do the rest of the above.

Nope, last time I installed and played KotOR was around 2 years ago (if not longer) and it was the CD retail version. Never came across the issue before, but if it is just the characters, then it is an appearance.2da fix. If it is more than the characters, then it is a fix requiring something like a custom solution like Shader Override.

Not sure if it is newworthy or not -- as someone may have already done this -- but I do believe I have fixed the sabers so that they render properly in the Aspyr (Steam) version of the game... Have tested it out in another location within saber combat, looks fine so far.

We are in agreement on that one; especially as it's likely a quick fix on their end.

And that's why as a studio -- sorry "publisher" -- they only port other studio's games. An utter disregard for quality due to lack of understanding of what is important and why when it comes to a product meant to entertain people in exchange for money.

I was aware of *some* of that but not all of it. Recalled something about the rotations (quaternions) being compressed, wasn't aware they were compressing 3 floats (12 bytes) down to just 4 bytes. At the moment I don't need and really can't edit data like that. The .tmdl format is just a line by line account of each data element found in the .mdl file, in sequential order. The "compiler" reads this line by line and writes out the binary file. It doesn't error check byte index pointers and corrects them. Though I guess I could decompress the rotations so that I could then manually edit the data, probably best place to do that is in an actual modelling program. The .tmdl format was never meant for that; I had originally planned another file format for that which was a store of how the model data would have been stored in memory -- a more logical structure. That stuffs on hold, especially as this is heading into territory that I find usually takes me 3 to 6 times as long as someone who is interested in it to complete -- I'm not really a coder (software engineer) I'm a game designer who learned how to code (script) in engines that do all the hard stuff under the hood. If it solved the saber issue, I did have no issues dropping ReShade for it. I think instead what I will do is edit all the effected Dxun models so that those that like and use ReShade can keep doing so. Plus, the edited models shouldn't change the corrections made by Shader Override. I thought about writing a custom injector years ago for the game, I've also dabbled in some shader writing, however, what you really need is a graphics programmer. Someone who knows OpenGL quite well and how to analyse / inspect the game in order to find out what it is using so as to know what to override. I might know enough so as to get the two combined -- if they are easily combined and it doesn't mean effectively rewriting Shader Override within the ReShade code (if actually available) -- but not sure about the saber issue. And its really the saber issue that bugs me the most. How Aspyr thinks that what they have released as an update for TSL is acceptable, considering the game is set in Star Wars and is about a Jedi who beyond the use of the force, rely on a lightsabre... well that's just unprofessional in my opinion and makes it clear why they do the kind of work they do as a studio.

This won't work with Reshade, will it? -- I'm assuming as it is also a "opengl32.dll". How about the issue with the sabers not rendering properly, does it fix that as well?

Well, I worked on my tool some more to handle the NaN issue better along with a feature that spits out a list of all the textures used in the model, how many times and by what node types, and then turned back to fixing issues. There was this simple one to fix that came about due to the Dxun Tomb texturing... Fixed it... Then I looked at how Dxun was being rendered on my laptop, not sure if this is my laptop of the Steam version of the game, but, it is an eyesore to me that turns one of my favourite locations into a bit of a chore to play: Had a quick go at addressing the grey fogging issue and had very good results: So far I think it was worth the effort making the tool actually usable; at least for me.

So, though I've been sick of late I still worked on the mod, however, I took a break from the Dxun textures as the last animated texture for the tomb was taking a while... Originally I was focused on updating and cleaning out the effect plugins my imaging editing app uses until I switched to a long-term issue I had, and that had to do with the Telos station "skybox" and station sprawl. The issue was that the superstructure texture that I created (years ago) was not being rendered properly: The issue had to do with mesh settings. Since I was working on a tool and effectively had the converting of a binary model to a readable ASCII version that account for every single byte, I decided to make a quick tool that simplified the formatting to the bare minimum and save it out as a .tmdl file -- text file. Then it was a (relatively) simple matter of writing the part that parsed the file back into binary. With the original and processed .mdl files being exactly the same byte length. I made some changes to the mesh data, and thought I had solved the issue until I saw that what I had suspected would end up being the case, was the case: The issue I believe is that C#.Net when reading the bytes for floats will read a number it categorises as NaN -- not a number. Now, I don't know if it actually stores the value that it reads into the float object correctly or not, what I do know is that when it writes it out into a string (ASCII / text) it is NaN and not any number. Though you can safely parse this back into bytes for the binary file, it is clearly not the same value as was originally read. I tried a few things to do with storing it as a double -- floats are "singles" -- which is more precise, and using a custom class I found for writing out doubles precisely as strings. Wasn't a help. As I wanted an effectively tool to make my changes, I decided that I could simply read the float bytes, convert them to Base64 strings that are saved in the .tmdl file, and then parse these back into bytes. It worked: It's not the solution I wanted for the NaN float values, but for the time being it works, allowing me to change textures used in models with more ease and flexibility over hex editing, along with making meaningful quick changes to model data without having to import it into a modelling package, make my changes, export it and then compile it into a .mdl file and hope that everything comes out the other end fine. Oh, I also re-did the rain fx -- trust me it looks a lot better when not a static image of a screen:

So, some new screens of the interior of the tomb with some revised textures... I still have some textures to do with the computer terminals in the tomb. Once those are complete -- and maybe the odd texture like the outside rain -- I will be leaving the Dxun tomb where it is. Realistically, due to the original textures being used in all manner of ways -- think that low-resolution brown dirt texture ending up being used on metal walls, not at the correct scale with distorted UV mapping -- it is difficult to get decent results without extensive hex editing. Or by using the new tools to edit meshes. That I just don't have time for at the moment. If people are wondering, I am aiming to have a release up by the end of this week. Whilst I have some time available to me.

Thanks for the kind words about the work. Some screens of the outside of the tomb. FYI at this point I am only doing the Dxun tomb textures and not the rest of Dxun due to time constraints -- though I will likely do something about the rain fx. I started on the tomb as is uses some textures from other planets that I had changed and no longer fit the tomb; plus, the tomb interior was a real eyesore of rushed texturing.

Thanks! Something I started working on today, but need to stop as I have plans for tonight:

I figured out the issue with the HK and Mandalorian specular not working, it was an easy fix in that I forgot that the Steam version of the game actually stores workshop mod files in a completely different directory to the game itself. I was updating the appearance file but it was getting overridden by another. So, was playing some more and found another longstanding issue, that to do with the Telos station animated displays. They get used also in the HK factory/base, so, I got around to doing an animated texture for them: As this display is often found accompanied with other displays using an Ebon Hawk texture, I decided to redo this one again, making them green and devoid of the interlaced striping -- they are glossy / reflective displays now instead: I also did the other Ebon Hawk display textures, including a simple animated texture replacer for the galaxy map screen -- really didn't make any sense why this one was in full colour with all the rest effectively monochrome displays: I also did a few quick texture jobs for a couple of placeholder objects I spotted: Couldn't find the texture or model for this one though -- if anyone knows, please let me know, FYI can be found in the HK base: Not sure how well these screens represent the work. How the game is rendered on my laptop compared to my old dev rig, well, there is a marked difference between the two!

No it's an Nvidia, not the intel integrated junk. Dev rig also had an Nvidia and from what I can see it didn't have any issues. The big difference that I can tell is that one is CD retail, and the other is the updated Steam version.

Well, I thought I would carry on playing my game saved on this laptop, that way I could determine what other issues there might be. That is until I hit this bug I created in the Duxn Tomb that stopped progress: So I decided to download and install some tools so that I could fix the problem: I also changed the "Sith Master's" name and appearance. This was so as to add in a planned for Easter egg relating to the greater The Old Republic universe -- now the only Star Wars universe I consider canon. This lead me down a very dark path where I quickly did a tex for GoTo... ... and Hanharr -- albeit there isn't much I can do with a quick retex for the fur-ball: These both have updated profile pics too -- which I did a while back but didn't get around to doing the model textures until now. That leaves Visas, Mira and Disciple that I have yet to do -- all of which I probably would want to take more time with than the quick jobs I did for the two above. I also finished up quick placeholder textures for my Jal Shey (Jedi Armor) model replacer for male characters. An example: There not as good as the Sith bronze one that I did a while back, but, they're good enough to play with. I also reworked the textures for the female Jal Shey armor variants to match my original intent. There are also enough texture variants now for all equippable armour that uses these textures -- including Exar Kun armour, which is the bronze variant you've seen in the past. Found this issue with the HK unit textures that the Mandalorian soldiers also have: The diffuse texture transparency is actually being rendered transparent instead of being used for specularity. Checked the txi file and then played with appearance.2da settings. Still now fixed. Not sure if it has always been a problem that somehow I always managed to miss until now, or, this is something that got introduced with the updated Steam version of the game. If so, then I imagine that I would need to make changes to the model via mesh settings. That may take a while for me to get around to. Hopefully it is something really obvious that I missed, and is a quick fix. Another issue is the HandSIster variants. I implemented this last year I think, however, it wasn't setup on my laptop install -- the correct implemented solution was on my dev rig. Though I have all the working files, I tried a bunch of things so I'm not sure which exact files I need to use... This may need to be cut for now and looked at a later date. Oh, did I mention that I added holocrons to the game that you can actually use as the player..? Or how about a bunch of new weapons and items to collect..? No, well I just did

Well, based on the thread replies and the messages I received, I've decided that it is to be option 1: override folder zipped and released with a few quick fixes. Not quite sure when it will be as I first need to compile a list of all my changes along with what really needs to be addressed (done) before I can release it. With the latter it will likely be quick and dirty rather than actually finishing off work. Especially as I only have my project files and none of the specific modding tools setup on my laptop. Not sure if I will complete this mod or not; the various new tools would have made the difference 2 years ago, but they aren't as persuasive to me now. More than likely I would start a new project involving adding a new playable planet to the game. I'll post again when I get around to releasing the mod.

My thread isn't the place to be asking this. You should have messaged DarthParametric directly and/or asked for info via the General Kotor Modding forum. Usually those with the info reply in good time -- plus, it will be clearer and easier to find for everyone there. If they don't, well, there is nothing stopping them from not sharing said info when they were the ones who spent the time figuring it out and/or creating the tools and processes to achieve the results they have. But regardless, my thread isn't the place to ask that.

So, I've done a lot of work on this mod of mine. There's still a lot of work I intended to do, along with, a bunch of things I wanted to finish off before releasing. However, I haven't directly worked on this mod for some time now -- probably like more than a year ago. Most of my work was on a model import/export tool which I have since stopped all work on since learning of the new model tools in development. Since there release I haven't had a chance to use them, specifically, because they are dependent on installing and using 3DSMax. So, I'm uncertain what things are handled well and which things aren't or are not supported yet. However, that is kind of a moot point for me. I resigned from my job late 2017 and moved city. Primarily to work on an indie project of mine -- which keeps on getting delayed. Though I have funds to support myself for a while, my time and funds are best used in other capacities. Namely to secure (part-time) employ that will allow me to continue working on my indie (for commercial release) project. And though I'd like to perhaps do some additional work on this mod, it's just not a priority at the moment; plus beyond taking a copy of my dev files, I didn't take my (old) dev rig with me and my laptop is aging and running out of space as is -- I aim to replace it but I'm holding off as long as I can. As far as I see it I have 2 options: I zip my current mod files as they are in my override folder and release it as is -- maybe with a few quick fixes for things. I see whether modding folks want to help out with this mod -- or contribute existing work if that may be the case -- so that it can be released (hopefully) by the end of 2018. There is also a third option, and that is to do both of the above, however, I would only want to do so if I can release the mod as a proper TSLPatcher release with additional completed content so that on its own it is complete and robust. I suppose for me the truth of it is that I am far more focused on game programming these days and wish to focus on developing those skills and broadening my experience with areas like AI. Tool development was interesting but as I knew was the case, there are others here far more talented than myself and with far more available time and energy who could have achieved results sooner. Which is what happened. I guess what I'm saying is that for the mod to go forward, it would need to be the case of the second option, as working with the KOTOR2 engine is just not aligning with my interests and near-term goals. And if I am really honest, I don't think working on this mod really aligns with what I actually want to do in regards to creating a "mod" for the Knights of the Old Republic universe. Which my motivation for is diminished with the latest Star Wars film -- usually my motivation gets renewed, not the case this time. Anyway, I guess I wanted to see what people thought about this all before I made a final call.

Though I don't think it is the worst Star Wars movie ever -- if you do, you haven't seen The Star Wars Holiday Special or either of the Star Wars Ewok Adventure films. Though considering that Disney now holds the licence, you may yet see worse as they milk it for as much as they can. I am honestly baffled by people who claim that TLJ is actually a good film if not the best Star Wars film to date. They clearly do not understand what makes a good film, and I am speaking of structure. TLJ was a bloated hole-filled mess that failed to stick to what was set by way of vision, story, character and narrative style in TFA. It is meant to be a trilogy of films, not a collection of anthology. If you do not understand the importance of this, then why TLJ has so far gotten a user score of 4.9 on Metacritic and an audience score of 56% on Rotten Tomatoes, must be a complete mystery to you. And to be clear, neither one of those is a "good" score. My 6/10 is me saying it is watchable, but only if you paid next to nothing to see it. When a film gets such a difference between "professional" critic and average person scores, I take notice and usually go with the average person score. If I watch IX at all at the cinemas, it will be based upon how well the film has done after a week -- my mistake was not waiting longer. And I mean in the eyes of the average person not a critic who may have been paid or at least schmoozed at exclusive viewings to see the film in a better light. Regardless, I now have a big issue with Star Wars, and would struggle to see this new trilogy -- or any that Rian Johnson helms -- as being canon. And would approach any Star Wars film or TV series created by Disney much in the way I have treated Star Wars games made over the years. It is unlikely that all will be good or even great, but once in a while, there will be a standout worth playing (or watching). And I'll end up doing so like a year or two after everyone else has as the hype has no effect on me. And I hope this is the last I have to say about this rubbish film, as I can't believe I am still thinking about it 4 days after seeing it.

Wanted to resist as much as possible discussing this movie, but, couldn't fight it enough. Let me first say, I don't *hate* TLJ in it's entirety, but it is on the crap side of OK -- probably 6/10 from me. First off, Rogue One is a "Star Wars Story". Yes I liked it because it was different, but, that's not my point. My point is that it was intentionally branded a certain way so as to make it part of the same universe, and story, but, NOT part of the trilogies. Further, if you set up a trilogy of films a certain way as in TFA, then regardless if the other films are made by different directors, they have an obligation to stick to what was setup in the first film. Rian Johnson clearly wants to tell his OWN Star Wars trilogy and he decided he was going to sh*t on what JJA established in the first film. He clearly wants to make his own trilogy as he tried to not just do the second film of the trilogy but fit in enough content for the third as well into TLJ -- why it is such a mess of a film as it has too many narrative threads trying to be told. Which is why he was offered a trilogy of his own and JJA is going to finish off this one. That is unless it was simply a way of getting him off of these films once it dawned on them what he was doing -- killing JJA's vision of the trilogy along with what aspects of Star Wars that Lucas setup as canon. To list the things I hated... All the marvel one-liner self-referential humor that got old very quickly Snoke made out to be a powerful dark-side user yet easily bested by his apprentice; we still have no idea where this guy came from, who he actually is The very slow space chase that doesn't make much sense, even for Star Wars The whole casino world story thread that reminded me of the worst parts from The Phantom Menace Leia deciding she is actually going to use her force sensitivity finally to force pull herself out of the cold vacuum of space -- maybe plausible but was rather jarring Becoming what amounts to a Jedi Knight (if not Master) without any real training. Luke force projecting to battle Kylo -- I'm ok with how he was portray for the most part, a reluctant Master, but not happy about the battle and the way he died; would have been better if he died fighting Kylo in battle like Obi-Won did with Vader. The whole Rey goes into the dark-side anus on the Island and finds the mirror scene with what amounts to a voice over explanation of what's happening for the benefit of the audience -- I seem to recall something about: "show don't tell." We learn that Rey comes from nothing -- I'm ok with it but would have liked it handled better so that it had more gravitas. Rose The plush-toy penguin creatures -- I think Chewie should have finished what he started and eaten them... all! The Jedi book and tree burning... by Yoda of all Jedi Masters. Lastly, I can understand why Snoke was killed off in the second film, as they want to make it about Rey and Kylo. But he had so little time on screen and died in an idiotic way that doesn't fit with what I expect from the Star Wars universe. They should have had more time with him, so that we could get some idea of who he was. My opinion is that he was Darth Sidious' master (Darth Plagueis or not) until his apprentice killed him, or thought he had in that due to his power and knowledge of the dark-side he managed to survive, though horribly deformed. He abandons the Sith tradition -- why he lacks Sith eyes, as he is more a balanced force user -- and watches the rise of the Sith and their fall, from the shadows. He admires what his old apprentice had achieved, but, he thinks he can do better -- being "wise" and all. Then have him die in an unexpected way, namely, he gets taken out by the hyperspace suicide ship missile -- even there are reasons why this may not be plausible. It's something that even with all his power, he can't escape, and, I would have made it Leia the one who pilots the ship in order to get back at Snoke for taking her son away from him and twisting him into Kylo Ren. This happens near the end of the film, and sets up Kylo as the dark-side master leading into the third film. Luke can then die as well when he sacrifices himself to become a force spirit, leaving Rey THE LAST JEDI even though Luke will show up in the next film to guide her from the force. My two cents on it. Won't add anything more, as many of you have stated other good reasons why this movie was meh. I'm glad that I saw it at a regular cinema instead of wasting money on IMAX 3D. Will likely watch it again but once I can do so for free.

Maybe, or it just uses the predefined naming convention to find the correct mesh/bone/hook and then loads it into memory where the string name is lost as the data is now a memory object of a certain type that is referenced by whatever needs to reference it. That part is a moot point, as you shouldn't be creating your own names for things that have a set naming convention like "Rhand_g" otherwise the engine won't know what to do with it. Plus as I showed, there is no actual limit on how long these names can be. Now when specified as part of a model or mesh header, there is a limit of 32 characters (or 24 in some cases) -- actually it is always 32/24 characters in the model format as the remaining characters are filled with null characters. In engine this would vary as they would just use the first null reference to trim it down, however, if you look at the model format you'll see that the various nodes don't have associated names within the data. That's because it doesn't need them. It knows which is an animroot as it either has a pointer to it if a child, or, it is the first anim node that is loaded in. Things like super models are capped at 32 characters and are the model filenames that the engine needs to load in order to find the animations to use. Once it is loaded in it becomes another memory object referenced by other memory objects. It's a bit hard to be 100% as you'd need to decompile the KoTOR exe or have some kind of code debugger running -- forgotten the names for some of the types of tools available -- in order to verify what is going on. Not really inclined to see myself, as the answer is to simply stick to any predefined naming convention for things like bones, and, make sure to keep your other names as short as possible -- and definitely not make it go past 32 characters in length, or 24, for things like texture filenames used. EDIT: the real issue and thing to check is whether MDLops actually cares about the string lengths of certain things; my hazy recollection is that it actually doesn't, but, I could be wrong. As long as you stick to naming conventions and keep your model / mesh names to 32 characters, and textures, to 24 characters. I don't think the engine will likely have an issue.