TSL Textures Remastered

[Squall Lionhart 81]

Option 1 feels like the right path, especially with everything you've got going on. I wish the best of luck!

[Vriff 21]

Your's is one of the best texture mods I've seen. I know it's late, but I do hope you consider option 2 later, as well. 

[sELFiNDUCEDcOMA 98]

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:

 

 

 

 

Oops! 

 

 

 

 

 

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:

 

 

 

 

HINT: the light behind the model is actually appearing through the model.

 

 

 

 

 

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 

[DarthParametric 3,782]

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.

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

[sELFiNDUCEDcOMA 98]

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.

[DarthParametric 3,782]

The Aspyr version doesn't alter appearance.2da, so it's not that at least.

[sELFiNDUCEDcOMA 98]

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:

 

 

 

 

 

 

And yes it is animated, won't tell you what the Aurebesh says

 

 

 

 

 

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:

 

 

 

 

 

The Aurebesh simply says: Standby.. Calculating

 

 

 

 

I also did a few quick texture jobs for a couple of placeholder objects I spotted:

 

 

 

 

Glossy metallic crates -- best I could do quickly, but better than the vanilla version:

 

 

This tex used for these tables and chairs -- again best I could do quickly but still better to the vanilla IMO:

 

 

There was one other crate tex that I forgot to take a screen of.

 

 

 

 

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!

[VarsityPuppet 1,085]

Just marvelous, work! The screens look phenomenal

[Kexikus 995]

Those look amazing. Great work!

[sELFiNDUCEDcOMA 98]

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:

 

 

 

 

 

 

 

 

 

[N-DReW25 1,336]

Thanks!

 

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

 

 

 

 

 

 

 

 

 

THAT is absolutely stunning.

[Vriff 21]

i LoVe YoUr WoRk

[Mephiles550 227]

Amazing, reminds me of the old Star Wars comics before the prequel trilogy. They loved scenery like this. 

[sELFiNDUCEDcOMA 98]

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.

 

 

 

 

A screen of it seen in the distance. I also replaced the freighter texture with one I had already done for Nar Shaddaa:

 

 

At the start of the ramp:

 

 

The textures used are actually variants used inside the tomb, these ones have more grime / green stuff on them due to the weather of Dxun.

 

 

A screen with characters to put things in perspective:

 

 

Screens of the entrance leading into the tomb:

 

 

 

This one I took when I realised I could do something about the door not looking the way it was intended:

 

 

 

 

[sELFiNDUCEDcOMA 98]

So, some new screens of the interior of the tomb with some revised textures...

 

 

 

 

This is the door out of the tomb -- the way you came in:

 

 

First crossroads / junction you find below. FYI I changed the gold / bronze texture as I found the "stained with age" version worked less well in all contexts, resulting in a very visible and annoying pattern.

 

 

One of the corridors that branches off to a control / computer terminal -- unfortunately the lighting in the level largely provides a red tinge to things, making the gold appear very orange at times:

 

 

I guess you would call this the main hall in the center of it with the large doors leading to the tomb itself:

 

 

Close up of the doors themselves:

 

 

The ramp leading down to the tomb / ritual space:

 

 

Do you have a pool of mucky Dxun water, or do you have a pool filled with blood when conducting a Sith ritual? I think the answer is obvious:

 

 

Some bros play-fighting to provide some context by way of characters. I think I will be reworking the black marble texture some. Unfortunately quite often textures that work within one area or use, end up looking really bad due to that texture being used in inappropriate ways by today's standards.

 

 

 

 

 

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.

[sELFiNDUCEDcOMA 98]

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

 

 

 

 

This atrocity of a texture is the only one left I have to do; oddly enough the right part ( a separate texture) is actually flipped, making it even more of a hassle to work with.

 

 

 

 

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:

 

 

 

 

You can see that it is being rendered transparent below:

 

 

 

 

 

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:

 

 

 

 

No more stuffed up rotations on the shuttles!

 

 

So now all the modules (areas) in the game this was an issue has been fixed -- view from Exchange module:

 

 

 

 

 

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:

 

 

 

 

 

 

 

[sELFiNDUCEDcOMA 98]

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

 

 

 

 

The inner walls of the entrance are black marble, not at all fitting...

 

 

 

 

 

Fixed it...

 

 

 

 

It's just now using a differently names version of the original texture until I can get around to doing the rest of the textures...

 

 

 

 

 

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.

[DarthParametric 3,782]

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

[sELFiNDUCEDcOMA 98]

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? 

[DarthParametric 3,782]

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).

[ndix UR 218]

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.

[sELFiNDUCEDcOMA 98]

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.

[DarthParametric 3,782]

if actually available

 

https://github.com/crosire/reshade

 

How Aspyr thinks

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.

[sELFiNDUCEDcOMA 98]

 

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.

[VarsityPuppet 1,085]

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 don't think it's necessarily disregard for quality due to a lack of understanding, more likely due a lack of time and resources. Still, I agree lightsabers are the important part of a Star Wars game, and seems like that was a bad thing to overlook