sELFiNDUCEDcOMA

Have you considered making your 3D scene files available as a modder's resource. I ask in that these new cockpit textures generally only work for the vanilla version of the game, not, modded ones. There are a number of world texture replacers released or in the works, if those modders want to create their own versions, they would have to do something similar to yourself or try another technique. Having something that is already set up and just needs textures/materials changed, would be a big help. Just a thought.

I hate to point this out, but, how is this a mod exactly? Or put another way, how does this belong in the WIP thread where people post their mod work.. Shouldn't this be in the general thread? ReShade is an injector, not a mod for the game but rather a general purpose tool that can be used for any game. if you want to post up how-tos, then I don't see how it belongs in this thread. Perhaps the moderators disagree, but, I felt the need to post this comment as I don't see it being relevant to this part of the forum as I don't see it as an actual mod.

It's not that much for the moment. Got sick of the back and forth with MDLOps and other tools and decided to start making a replacement. So far all it does is read in the mdl model file and spit out text telling me what each byte essentially is; it accounts for EVERY byte, and the text conversion follows the file structure exactly. Both of which MDLOps doesn't do. It's written in OOP C#.net, not Perl using binary regular expressions -- which I can't find any good info for freely via the web. The idea is that when I have mapped and accounted for every byte of the mdl & mdx files, that I will then model the required data structures in memory and write/read it out as an xml marked-up file. The editor will have some kind of editable xml data view tree, so that I can easily edit things like texture file names and other values rather than opening up the saved xml file via something like Notepad++. When that all works, I'm going to then look into importing and exporting mesh/model data as either obj or fbx model files. Which means that you can edit models in whatever model program you like as long as it can open and save such files -- most can. There would be no need for NVMax scripts, which is part of the pipeline problem with editing model files.

I dunno, it is your model and texture, and I tend to think that those that do good work should do what they feel is best for their work. But, I think is is missing the "dark" from the dark-side. I know that the "transitions" are really bad as found in the vanilla game, but, they were in the right spirit. I would actually darken the hair, and shadowing to areas of the skin along with making it look more pale, sickly. Then the eyes need to look like they are glowing, burning with contained hate. The full dark-side transition would have some fine purple veins as well. Having said that though, I think I can see where you are going with the bleaching of the hair. Kind of like Ash from the Army of Darkness look. Which might be more applicable come to think of it. As in you darken the hair over all but pick an area or two to streak with white -- as long as it mirrors well. But as I said, I feel it is really the call of the artist/modder. If you are confident with the way you are heading with it, you should stick with it . EDIT: Here is an (old) example I did for a character head, which like yours, will be limited in that I could not make use of specularity:

Yeah, I was thinking that earlier, that perhaps 2048x might be the better option for some heads. From the comparisons it looks like it definitely, would be interested in seeing a comparison of an existing UV mapped and textured head at 1k and then 2k followed by 4k. See if there really is a big difference even between 1k and 2k, as I gather you've UV mapped it quite specific to the model, so as to get a more or less uniform pixel-density across the whole head. If I recall correctly, the Twi'lek heads aren't like that at all, so you might be able to just use 1k as 2k is pointless. Anyway, regardless, definitely seems like 2k is a valid option if the model is UV'd to make use of it.

Thanks for noticing! Well not any work to really show, or, at least not directly...

Yeah but I my point is that you won't see that extra "pixel density" in-game. I've got no issue with people using larger sizes for their work and then scaling down, but I do with people using these in mods and insinuating that you are going to get 4k detail from them. Like it's somehow better than another mod that uses 1024x1024 knowing that the renderer won't really make use of anything more. Anyway, you set it up as you like. Especially as it's a new model and not some rework of a pre UV mapped head.

Nice work with the head modeling, even if it's getting all chewed up and spat out in-game .

I'm at a bit of a loss. How does creating 4k textures actually translate into 4k textures in-game..? Sure, the new steam update means that the game can support 4k resolution, however, that does not mean that the game's renderer can make use of 4k textures. Likely they will be down-sampled to something it can use, or, simply get lost in some other way. Meaning the end result isn't going to look all that much different if you simply used a texture that was 1024x1024. EDIT: it's like the support of widescreen displays via the new steam update; sure, you can use widescreen resolutions, however, all the UI elements get stretched out. It's not a "complete" fix for the problem, just a patch of sorts. I don't have any 4k displays, so, perhaps there is some big difference that is lost on me. Anyway, like the head model. Nice to see some new and really interesting work.

That's not what I meant. You have an OnEnter script that is made up of include calls, you can comment them in and out and switch load orders prior to compiling it and placing it into you override. Pretty simple really, even if this is something a mod author may end up doing as the average user has no clue when it comes to scripts. Basically creating a range of script variants supporting different mods. Ah, so as to have a LOAD ORDER that can be tweaked by other modders so as to make it more compatibility with other mods. The OnEnter is nothing more than a container that calls other scripts, one that is exposed so as to make modding those modules easier without having to actually modify the modules themselves. If there is an issue, all you have to do is remove the OnEnter script in the Override and it reverts back to the original state TSLRCM safe version. And more "runs" ain't your problem or even other modders' problem, it is the users who try and use this to have 100 mods running at once. Which may not be the case unless they are comfortable with modifying and compiling scripts. Yes, well it does happen and when it does people expect the mods to be checked for compatibility issues. Not everyone bothers -- because it was once off work or they just don't have the time/interest to do so-- which can lead to some mods not being used anymore due to being perceived as potentially resulting in bugs. From my point of view, this becomes less relevant if OnEnter injecting is used. That's why you have an OnEnter script that is doing nothing more than calling other scripts; some can be called prior to the original, some after. Plus, I didn't say it was a cure all. Sure, OnEnter injecting isn't going to be a solution for every specific problem. But where it works... Does anyone have an active download link for DeNCS..?

Hey all, sorry for the (long) delay in reply; after a short break I started work again and it tends to be demanding for the first few weeks. Whenever I had the time I tended to be too tired to remember or motivated to write this. Sounds good to me. Well, at the moment I have the following folder structure: As you can see it's already a long list along with not really having much of a naming convention or standards in way of what goes where. I can imagine that if I keep it as is and other modders use their own folder structure, that quite a bit of conflicts would arise. It's pretty simple really, you either replace the OnEnter script for the module to point at something like: OE_PER202, probably found in an "OnEnter" subfolder -- for ease of modification. The last line of the script would have an include for the original OnEnter script if the module had one. An alternative -- depending if the uncompiled scripts are available -- is to edit the original OnEnter script to have an include for the new OE_PER202 script. Regardless, the script can be easily found within the new "OnEnter" subfolder and modified by modders or those using mods. Users should be able to resolve some conflicts by simply modifying the load order for the included scripts -- EDIT: via a script editor / compiler. To be frank, I use an SSD drive so I don't notice any real "performance" issues to do with scripts, but I can see how scripts loading a lot of things will cause lag. I didn't think you would agree with this, and to be frank once again, I don't expect you to do this at all. However, I will comment regardless: If users have power in that they can edit the new OnEnter script -- EDIT: via a script editor / compiler if the uncompiled version is packaged with the mod -- and modify load orders or even comment things out for debugging; well, I don't see how that is shifting "incompatibility" (or problem) from one file to another. Another option is that modders can provide multiple versions of this script to support compatibility for various mods. I think we have a different view of what the OnEnter scripts would do and how they work. The original OnEnter script would still get called rather than being replaced. And if you are simply using it to add various things based on an initial check to see whether it is necessary, then I don't see how there is the conflict you are suggesting. My understanding and use of the OnEnter script is that they are called once and run once on entering the module, rather than this being a script that is called every so often by the game. Further, when a script is included, it is essentially run before the next included script is loaded and run. It's procedural not concurrent -- though, I could be assuming here. I really don't agree, and think it is quite easy to take that point of view when your mod is TSLRCM and you don't have to make it compatible with any other mod, rather, every other mod has to make their's compatible with yours upon every single release. OnEnter injection gets around this to a degree, in that I don't have to update anything other than the scripts if I even have to do that at all. Any issues OnEnter injection has, is more to do with bad scripting and a lack of conventions for scripts and the usage of this type of script IMO, and I doubt that I won't make use of it in the future as it makes my life easier at the very least. Yeah, hex-editing along with up-scaling is the usual way to go; don't believe that the modifying of UV maps and the use of the Replacer function works that well if at all. Don't recall it doing so.

Thought I'd give this a bump by asking whether anything was new with this and what you still had "to do." Nice to see another tool that supports another 3D modelling package; especially as Blender is widely used for modding and indie games. Plus, really nice to see a tool use something other than Perl .

Amen to that!

I think the skybox looks great; not sure I'll ever bother to make my own version. The graininess may have a lot more to do with the renderer, it may be more obvious out of game as seen via a screenshot over in-game. Though, you may consider simply downsizing a version of it, then up-scaling it back up to the original size, then overlaying it via the first in PS and playing with transparency and blend modes. Might be a bit quicker than trying to replace certain textures you've used... Just a thought. Regardless, I think most people -- apart from the odd whiner -- would be really happy with that.

Might this not be something best moved or recreated as a tutorial found within the tutorial section of the forums..?

Just thought I'd mention that you are limited to how many levels (branches) there are to your override folder. From my experience, you can have a sub-folder, but, you can't have a sub-folder within that one. At least that is my experience from using them to organize my mod project work. In way of standards for these folders, I would suggest that for base-game shared files that they go into the main override folder. For those specific to certain modules, they go into module subfolders. I would also suggest that if you are creating new assets, that if they are for a specific module, they go there, if they are "generic" and used across the game like weapon models / textures, then they go into a new subfolder for weapons, however, prefixed with an identifier for your mod. Alternatively for the last, you simply have a Weapons folder for all weapon file assets -- you'd do the same for armor, characters, etc. I have a similar structure for my own mod WIP, mostly to make it easier for me to work with the assets and to separate mine from TSLRCM. However, if you want to ensure "compatibility" then you have this folder structure by default in use with TSLRCM. You would create the various folders even if you end up putting nothing in it -- so that other modders, would make use of them instead of creating their own with some idiotic naming convention . If this is the old NWN command prompt tool, I recall it did an ok job of it. But as long as it is doing a good job of converting TGA to (proper) DDS, then I think by default those that reskin should be using it; primarily for things like environment textures, as DDS will support mipmapping. May not be worth the trouble of any extra tweaking for one-offs or characters -- depends on the end quality, though. The issue with scripts is due to the OnEnter script injection process. It's problematic, if others use it as well, however, probably the better way to get "compatibility" with TSLRCM. I think TSLRCM could actually do a better job of supporting compatibility with other mods. For example, by making it easier for others to OnEnter inject their scripts and not interfere with TSLRCM. Basically, you set up a script call to another script that does nothing other than include other scripts. You set this up for every module, even if they don't have an OnEnter script for the module -- you create one in such cases. Then if anyone wants to inject anything, they add their script include to this script for the module, and then add the script to the Override folder. Some good points, however, not sure I entirely agree; especially where you should be putting certain files instead of the override. It's easy to make these rules if you've never worked on a large mod that deals with all sorts of models, textures and scripts -- among other things. This might make it easier for people to use a bunch of mods together -- kind of doubt it -- at the cost of making the modder's task far more difficult. But, that is just my opinion. I agree. Can't remark on poly limits, as it really depends upon the model, however, it's clear that some folks need to spend more time learning the basics of low-poly modeling and UV mapping. But hey, from my experience, most mod users tend to not to even notice the difference. Very much agree. And I'm agreeing from a point of view regarding texture mods in general -- not just for KotOR / TSL. Having said that, in the right context, 2048x2048 isn't a bad choice. However, 4096x4096 -- or worse, larger than this -- for these games is utterly pointless due to the engine... I'm going to suggest something different here: Heads: 1024x1024 Weaps: 256x256 -- or 512x512 for new weaps; yes, there is a difference if you know what you're doing Armors: 1024x1024 Items/Head-gear: 256x256 -- or possibly 512x512 for new models. Inventory pics: 128x128 Creature: 1024x1024 Skybox: 2048x2048 Environ: 512x512 -- 1024x1024 for special cases It really depends upon the skill of the modder when it comes to texturing for some of these. For example heads, you may be better off with 512x if you don't have advanced skills and can't make use of specularity properly. However, even so, you will find that there is a noticeable difference between a head using a (decent) texture resized from 1024x down to 512x. The same is the case for "armor" or any body texture, like those for aliens / robots. I might suggest higher for the skybox, however, either the renderer fails to display the extra detail or the textures are down-sampled as there is a size cap for these. Largest I can get to work, is 2048x and yes, there is a noticeable difference between it and 1024x. Environment textures are funny, in that if you compared it to the minimum size for later games, then you might argue that 1024x is the best option. If you can get DDS to work correctly, this might be the best option, however, I find that the main issue with environment textures it that they are used all over the place at scales they weren't meant to be used at. The better option here is better model tools so that you can switch textures or reset the scale of those that are used for certain parts of the mesh. However, so far I have stuck with 512x as there are a lot of environment textures and there would likely be negligible improvement in way of the environment by using anything larger. You are better off hex editing environment models to replace textures used at horrible scales with something else instead. Anyway, that's my opinion on "best practice."

You really should consider moving away from Perl, even if it is to something like Python. You would at least be able to do "3D" stuff that way I'd imagine; but honestly, you should take a good look at C#. Even if it is just playing around in Unity with it's version of C#. Anyway, I say it as any "future" TSL modding will be reliant on better 3D tools -- exporting and viewing of. EDIT: didn't you get C# source code for one of the model viewers floating around? That's interesting. You would need to do it will the full version as it will require specialised tools, like an importer/exporter for Unity -- that would require engine source-code assess. Would have been a problem to do with the free version, but now you should be able to score a pro license for cheap / free. Big shake-up with game dev middleware due to Epic making Unreal 4 pretty much free to develop with -- still royalties required for anything commercial. For those who don't venture that far beyond KoTOR/TSL modding

Hmmm... Probably not Though, seeing that some of you have discovered ReShade, I thought I might share some screens of it using MasterEffect: That's from a while ago, since then I've been busy creating my own custom selection of shaders from MasterEffect and SweetFX; along with some new stuff. SweetFX in particular people have issues getting to work with OpenGL and 32bit games, resulting in a black screen. So far what I have ported to my version works accept for SMAA -- but, I think I've an idea of what's going wrong The screens don't show everything, as I found that FXAA had almost nil positive effect and bloom was a little too much in combination with HDR -- especially without other corrective effects still to be ported. EDIT: forgot to add that I brightened the screenshots as things look darker out of game; may affect things like contrasting details however.

Thanks. Too bad the male Twi'lek voice is so the opposite of that; hands down, the worst voice to visual representation paring for the series IMO. Every time one of the male Twi'leks in the game starts waffling on in that impotent and verging on aging-senility sumo-wrestler voice... I click as fast as I can .

What the hell, a quick run through for a Sith skin variant for Twi'lek males... This one helps show off the Sith dark-side stained teeth:

Spent some time doing the other male Twi'lek textures... Orange skin -- originally Komad for K1: Purple skin -- originally Xor from K1: Red skin -- originally Zhar from K1: And the older male Twi'lek textures... Yellow skin: Aqua(ish) skin: Lavender(ish) skin: That last one is actually based on one of the original textures in the game but I've decided to replace with the aqua skin instead; leaving this one as an alternative. I kind of like the tail coloring on the tails of the others, kind of like a change in appearance that happens with age. The lavender-grey to me seems like I could re-work it to create a Sith appearance instead.

Final tests with the updated green tex again, albeit with some tweaks to make it more vibrant along with the other variants I've done... And this last one should show more clearly the bump-specular effect to the textures...

Decided to do the alt textures for the (young-ish) male Twi'leks: First is the blue... Next is the orange... Finally is the green again, albeit with some tweaks to make it more vibrant along with the others... And this last one should show more clearly the bump-specular effect to the textures...

As far as I can tell these don't work: isdiffusebumpmap 1 isspecularbumpmap 1 Only isbumpmap will work without throwing an error on load; you can use these with isbumpmap, however, that does not mean that they work only that the engine will ignore them if they don't work. As far as I can tell, they do nothing when used in conjunction with isbumpmap. As far as bumpyshinytexture, it seems to work the same as envmaptexture when used in conjunction with bumpmaptexture. And bumpmapscaling does work, how I'm not sure as it doesn't seem to work the same as I would expect from regular bump/height maps -- seems to make the effect wider than heigher. I haven't used specularcolor but I suspect it will and will work along the lines I suspect. Yeah, I think that what you can achieve with this will be limited as this seems to be more of a bumpy reflections implementation of bump mapping and not really normal mapping as you would expect it from modern games. Mainly good for things that are (hard and) reflective, with limited use for organic things -- especially as it only works with models that have existing bump map textures.

My current attempt. It's hard to see the bump/specular out of game with the screens, that's due to going for something more natural rather than strong.