sELFiNDUCEDcOMA

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.

Great find!

It seems that the Steam version generally doesn't support cubemap based surfaces; almost all modded textures that are shiny in the original Kotor look transparent in Steam version, which is also one of the reasons why I cant get myself into modding these games again.

 

Do you know by chance how to fix those in Steam?

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.

Still, I agree lightsabers are the important part of a Star Wars game, and seems like that was a bad thing to overlook

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

 

https://github.com/crosire/reshade

 

 

They think the same as any other commercial entity. They don't do squat unless they are getting paid to do so. There's no financial incentive for them to bother with additional patches.

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.

Just in case you aren't aware, your NaN issue stems from the fact that (most of the) rotations are compressed quaternions which aren't valid floating point formatted numbers (they are 3 floats occupying 4 bytes via a certain math/bitmasking algorithm, which is why treating them as doubles doesn't really help, both float/double have actual internal data structure (separation of value & mantissa, etc)). I decode and use them internally as unsigned ints (just 4 bytes, no funny business) but of course an array/buffer of bytes exported as hex will work fine too. If you were trying to decompress them for any reason, like if you wanted to be able to alter them in a meaningful way, you'd want them as uints so you could do the necessary bitwise logic on them (the required shifts don't line up at byte boundaries).

 

The IEEE754 float32 type specifies a particular value for NaN, so when you read the NaN back in to recompile your model you wind up with a very different, defined, constant value for those rotations.

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.

No, it won't work with Reshade, or any other OpenGL override. The source for both is available though, so merging is always a possibility for those of the code monkey persuasion.

 

It doesn't address the saber issue, no, but possibly it could if you knew which shader/s to edit (and how to edit them).

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.

If you are using the Aspyr version of the game, that's the problem. Amongst many other bugs they introduced, they screwed up the fog. This is what you want:

 

https://github.com/HappyFunTimes01/ShaderOverride

 

See here for more info - http://deadlystream.com/forum/topic/5345-fog-and-speed-blur-fix-for-the-2016-tsl-patch

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.

Just marvelous, work! The screens look phenomenal

Those look amazing. Great work!

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!

Probably more likely due to you playing on a laptop. Integrated graphics?

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.

What format can the game use?

 

I have been working on several texture updates and only seem to have found the .txi commads "islightmap 1" and "isbumpmap 1" to have any effect on rendering.

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:

1. 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.
2. 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...

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.

The *hook dummy nodes can only be identified by their names, which suggest the engine reads them. Also, the animroot is specified as a string, so the engine needs to compare it to the node names to find the right one.

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.

Actually, I don't think that the engine would bother loading the model mesh / node names. That's for people to understand what each are, the engine doesn't need it.

More than likely these are just ignored and aren't loaded. Can't say for sure, but, as people tend to write game engines to be optimized and memory efficient... That would have been even more so the case when trying to get a PC game to run on an Xbox.

Your mesh names are possibly too long. I'm unsure what the maximum the MDL format can cope with is, but I would suggest capping them to 15 characters.

 

 

Well, it doesn't appear to care itself. The names array is a bunch of strings that are separated by null characters. They can be as long as you like when stored in the model format. Whether MDLops has an issue or the engine itself... not sure, but, I'm a guy who grew up with MS Dos. I tend to establish some kind of succinct naming convention and then I stick to it.

I would suggest sticking to the max length found for other string values in the format, that being a max of 32 characters. In some odd cases it appears to be capped at 24 in the model, however, I suspect if the engine has any max cap on strings (names / labels) then it would be sticking to that which is found in the model format: 32. If you want to use less, it won't hurt none as long as you can still read the label and understand what it is.

Now whether MDLops itself has a set cap... You'll have to ask someone who cares to look at the Perl junk.

EDIT: to help illustrate...

There is an index for each name array pointer, there is actually no cap in the model itself. Any cap is in engine or the original tool -- or any mod tool -- that exports into the MDL and MDX files that the game engine reads.

Hmmmm.... blind superhero....

 

Yep, was thinking of Dare Devil having seen the Defenders recently. Though, probably more of an ornamental crest to it and less horns