Recommended Posts

I'm actually quite glad you took to making a distinction between the miners; especially considering how they would be wearing the Star Wars equivalent of a business suit in the most hazardous of environments.

 

Additionally, you're right. That jumpsuit model really is too often overlooked. I never considered it before, but it really does deserve more exposure. Also, yeah... I never considered that according to KOTOR, something designed to protect you from G-force was great at stopping weapon's fire too. :D

 

Trust me, there are others that appreciate detail work like this. I don't know about other people, but I've been itching forever to change the miner bodies into unique models (with varying levels of damage), but I was never able to find a way to do it. Heck, most of the things you're constantly fixing have been bugging me since I first got KOTOR 2 (8 years ago?!)

 

-

Lastly, Contrast work? You recolored the whole danged thing!

Share this post


Link to post
Share on other sites

Thanks, glad someone appreciates it. Wasn't sure anyone would care to be frank, as it is just the miner uniform -- and it is just simple "contrast" work apparently ;). But, I really do find it odd that this ugly jumpsuit is somehow classed as being armor...

Well, with that reskin, I might actually use it as an armor! Seriosly, that re-skin is really good. It reminds me of something, but I can't put my finger on it...

 

Wanna think about releasing that as a separate mod? :)

Share this post


Link to post
Share on other sites

@ Malkior

 

I'm sure you appreciate the amount of work that goes into these textures. It might be lost on others, as they've only done the odd texture of things, but not when you've attempted to update the textures of an entire area. Even what appears to be from a static poor screenshot to be a texture that hasn't changed a hell of a lot could have taken a lot of work to make look good, especially within the context of all the other textures; some demanding of more attention than others.

 

It's a bit of a shame with the armored flightsuit, in that it is probably one of the better armors to attempt to retexture in that the male and female version of the textures are pretty much identical. So, you don't end up having to do twice the work ;)

 

What makes things difficult is how painfully limited the scripting is; all have their idiosyncrasies that you need to overcome in order to get what you intend to work as best you can, but TSL makes it even more of a challenge. As far as I know, it is hard to do something as basic as having a script that is run throughout the mission. The best I could do was to spawn an invisible object that had an OnHeartbeat script attached, but, that will only get checked every 6 seconds and I'm unaware of anyway of increasing that rate.

 

Though, it didn't help that I had been sitting in front of the computer for several hours trying to get a solution that worked. Should have gotten some sleep instead as it then only took me half an hour to come up with something that did ;).

 

@ Fair Strides:

 

I dunno, I'm pretty good at getting myself sidetracked...

 

 

 

 

Having dawned on me recently that a better way to check the appearance of things like unique characters was to create a "disguise" item to equip, I decided to see how my Malak textures look in TSL having recently done a quick pass of them whilst replaying the game:

 

k2_00031.jpg

 

I knew would be the case, they don't look as they do in KOTOR as the two games go about rendering the game differently. I found that out when I threw in a bunch of my textures into the KOTOR override folder to find that the specular wasn't quite right along with the textures appearing more dark and dull.

 

After I tweaked the layers so as to get them to look in TSL as they do in KOTOR:

 

k2_00033.jpg

 

k2_00032.jpg

 

k2_00034.jpg

 

Though an interesting if quick distraction, it's still a bit of a time waste unless Malak appears later on in the game -- I know he does as his "Jedi" version, not sure as Darth Malak though.

 

 

 

 

If I can come up with an existing armor that I think it would work with, and I didn't have to do too much extra texture work... Maybe.

Share this post


Link to post
Share on other sites

Nice you eliminated the pajama look on Malak.

 

Looks like armor now.

 

That new minor uniform reminded me of Zaeed Massani from Mass Effect 2.

 

 

ME3_Zaeed_Citadel.png

Share this post


Link to post
Share on other sites

Oh, trust me, working with any textures from this game can become a huge time sink. I'm just now coming to grips with the fact that my previous techniques do so little for the textures that I was essentially wasting much of the three years it took me to make some of my earlier mods :0 

 

Nowadays my time is mostly spent/consumed when finding where a texture actually is, since the artists spread them so liberally throughout the level. I can be working half a day working on something only to find out that I was changing a completely different part of the level while the part I was trying to change was completely unaffected. (Of course then, it's a pretty simple step to just copy the layers from the first file to the next one, but it can still make testing difficult) and I have yet to find this ONE texture for the railing ... I've been at it all day... :coffee: and don't even get me started on UVW Mapping... :wallbash:

 

--------

 

I've also heard that it is possible to make something run continually during a level, but I couldn't tell you if I tried how it's done. 

--------

 

-In regards to your comment regarding Malak as a "disguise"

 

So with that Malak test you did, is it possible to replace any character without screwing up the Appearance.2da?

If so, there may be a way to make the Handmaiden mod actually work with TSLRCM (a mod where the handmaiden model is unique compared to the sister's rather than just the texture) I tried it myself with varying levels of Appearance.2da deviousness, and all I got where disturbing imagery of Kreia and even a random old man speaking with the handsister's voice. (since I assume that it was just replacing each as a "unique" character slot. Cool find regardless. (if I am talking about something completely different, then I may not have understood fully what you mean, and if this is the case, I apologize  :dizzy: )

Share this post


Link to post
Share on other sites

@Malkior:

 

What SIC was referring to was an item property called Disguise. It switched the appearance of the wearer to the line in appearance.2da marked by the Disguise effect.

 

@SIC:

 

It is possible to make a script run constantly, but it's effectiveness depends on the script's actions.

 

If you make the hearbeat script do nothing but launch another script, you're set. This would work:

 

 

Just repeat the DelayCommand until the 6 seconds are up. Have the executed script do what you want done.

Also, replace

Share this post


Link to post
Share on other sites

Anyway, this represents some of the last things to do with Peragus and that I've been working on for it. The other major thing to do is write the scripts and create the unique models in order to replace all those really bad looking dead corpse placeables with ones that look like the miners, as I have them now.

Nice, would save me the work of doing that, as I was planning to after TSLRCM was done XD.

I assume you are aware of VP's Peragus Mod that does exactly that with scripts though? Not to give yourself work for nothing.

 

The heartbeat is indeed per 6 seconds. And should be placed in the .are (IIRC) of a module, not attached to a placeable. And no, it's not possible to make that faster, it's done that way not to make the heartbeat a memory hog of unwise properties.

And scripting ain't all THAT bad. It can be bad... but it could be worse...

Share this post


Link to post
Share on other sites

 

The other major thing to do is write the scripts and create the unique models in order to replace all those really bad looking dead corpse placeables with ones that look like the miners, as I have them now.

This gets my attention, in particular. That will be very appreciated. One detail to be considered is what Malkior said regarding some corpse being not all the same. It makes sense to me that some of the dead miner should have blaster burns at some places and not every one of em' to get these wounds at the same place. This is something that was missing in VP's mod.

 

Also, will-it be possible for the exile to equip the miner protection gear, instead of the regular jumpsuit?

Edited by MrPhil

Share this post


Link to post
Share on other sites

You may be able to use ForceHeartbeat() to interrupt the six second delay between heartbeats if you combine it with DelayCommand, though the notes for the function say it only works with creatures. IIRC, stoffe used it in her Combat Simulation Arena, and was the one who first mentioned it to me.

Share this post


Link to post
Share on other sites

@ Milestails:

 

Wow... It's always a bit of a shock how much of a difference there is between TSL and more modern games graphically. Usually it takes a while to adjust when I start up on the textures again as the difference is massive, especially as there are no normal maps present for the most part. Seeing that pic hits it home again. 

 

@ Malkior:

 

Yeah, it's how Fair Strides says, its an item that is set to "disguise" and allows you to then change a character's appearance once it is equipped to pretty much anything in the Appearance.2DA file. Even a Gizka:

 

 

 

k2_00035.jpg

 

k2_00037.jpg

 

 

 

 

It's how in KOTOR you can get the armor that changes your appearance to that of a Sith Soldier so that you can get to the lower levels of Taris.

 

You might be able to use it to solve other problems, perhaps even use it to change the Handmaiden sisters to their correct appearance, however, it is still reliant upon the respective row within the 2DA file being correct and all -- models as well. Though, it seems that not all the appearance can be selected, at least not via KOTOR Tool in that it has a 255 (8bit) limit on things like the number of variations you can select from; for example, I found that I could not set a plot use icon beyond 255.

 

Not sure if that is a KOTOR Tool limitation or whether it is an engine limitation, but, as the 2DA file I believe has more than 255 rows... Then I suspect it can be gotten around with something like KGFF.

 

@ Hassat Hunter:

 

Don't think memory is really an issue -- my notebook has 4gb which I doubled to 8gb -- if anything, it would be processing and that really depends upon what you were doing with it and how the engine handles scripts. If the game engine's scripting system was optimized to work for hardware from 8 years ago, and has various limits in place. Then it would be an issue, otherwise, it ain't as most people are now playing the game on more modern hardware.

 

I also think that it was more than likely an unnecessary limitation to have in place back then as well, and at the very least, should of been 1 second intervals not 6. That would make it far more useful as the delay experienced is far shorter.

 

As a further example of the usefulness of what Fair Strides and Insidious are describing, having a script that is independent of any game objects that is checked every frame would actually be simpler and cleaner. I had an issue for when I was modding Fallout 3 in regards to applying fullscreen shaders depending upon whether an item was equipped or not -- for example, making night vision goggles that "enhanced" the screen. To control the effect, it required a script attached that had code for the OnEquip and OnUnequip blocks. It appeared to work fine when equipping and then unequipping the item, however, when you force equipped another item over this one things got screwed up -- the shader FX was removed but could never be applied again, unless you knew the precise steps of how. There was no OnForceUnequip to use, this was just something that it was not designed to handle and everything I tried failed, and looking at how others did it was no help as they were doing it along my way. No one had bothered to test their mods thoroughly, otherwise, they would have found the bug as I did.

 

The solution was straightforward, create a new quest that was always active and had a script attached that ran every frame. This script was simple, at the start it removed the shader effect if it was active, then, it checked to see if the item was equipped or not. If not it did nothing, if it was, it applied the shader. It didn't need to know whether the item had been equipped or not as the script wasn't directly triggered that way. It works every time and there is no performance impact as it's not doing something stupid like sorting through the contents of an overflowing container -- like the player's inventory.

 

In this case, how I went about achieving altering the holo-miner appearances is messy, not simple. In particular the holo-miners are created as needed and destroyed when not. So you can't have a script check OnEnter to search for and change the miners that way, which is even more simple and less chance of it impacting performance. And though I achieved it, there is one clear bug where a miner's appearance will change mid sentence and they will not be animated or say anything until the next line is said. By having a script that is continuously checking and then changing the miner's appearance as needed, virtually the moment they are created. Then this should not happen as it would be seamless to the player instead of mildly jarring.

 

That is if it will work without issue checking just about every game frame.

 

@ MrPhil:

 

Yeah, that's the plan, to have them multiple version and for them to not look the same. Not sure how well it will turn out as the body textures tend to only have the texturing for one side which then gets mirrored for the other side of the model. Makes it hard to get things more varied as bullet holes and such will get mirrored exactly on the other side. But, I have some ideas I just now have to make the time in creating all the assets for it...

Share this post


Link to post
Share on other sites

@ MrPhil:

 

The mining safety gear is equitable, the uniform no longer is.

 

@ Kainzorus:

 

Yes and no, as the result would be that every miner would be wearing it, including all the "admin / sec" officers.

Share this post


Link to post
Share on other sites

Don't think memory is really an issue -- my notebook has 4gb which I doubled to 8gb -- if anything, it would be processing and that really depends upon what you were doing with it and how the engine handles scripts. If the game engine's scripting system was optimized to work for hardware from 8 years ago, and has various limits in place. Then it would be an issue, otherwise, it ain't as most people are now playing the game on more modern hardware.

And still people have performance issues on M4-78. So no, modern hardware doesn't cancel it all out.

I also think that it was more than likely an unnecessary limitation to have in place back then as well, and at the very least, should of been 1 second intervals not 6. That would make it far more useful as the delay experienced is far shorter.

It is, very intentional, 6 seconds. 6 seconds is one "round" of combat. As thus, it's done after every round of combat.

Every second would be a major memory hog, especially since most of the time, you really don't need that heartbeat. There's a reason the random loot scripts delete the heartbeat after being seeded.

The game has memory leaks as it is, no point adding more to them for no good reason. For intermediary actions heartbeats aren't used anyway.

As a further example of the usefulness of what Fair Strides and Insidious are describing, having a script that is independent of any game objects that is checked every frame would actually be simpler and cleaner.

It's in-game. It's the HEARTBEAT in a .are file...

Though you really ought not to use it, since there are generally far better ways to handle whatever someone wants that doesn't put any additional strain on the game.

They're usually used for quest updates if you get a specific item.

In particular the holo-miners are created as needed and destroyed when not. So you can't have a script check OnEnter to search for and change the miners that way, which is even more simple and less chance of it impacting performance.

Solution; change .utc's. Done. ?

Share this post


Link to post
Share on other sites

The game has memory leaks as it is, no point adding more to them for no good reason. For intermediary actions heartbeats aren't used anyway.

It's in-game. It's the HEARTBEAT in a .are file...

Though you really ought not to use it, since there are generally far better ways to handle whatever someone wants that doesn't put any additional strain on the game.

They're usually used for quest updates if you get a specific item.

Solution; change .utc's. Done. ?

 

I'm steering clear of actually making changes to anything that I can't just plop into the Override folder -- the UTC files would overwrite every case of it throughout the game. Can't recollect all my reasons, as I really need to find coffee, but I think the gist of it was that I figured there would be far less mod conflicts that way as this mod won't necessarily care what you've done to those files as it will then endeavor to overwrite these regardless without overwriting absolutely everything a mod did -- just what was necessary.

 

Probably a waste of effort trying to do it that way as it's all (probably) largely covered by TSL Patcher anyways, but, I can be stubborn that way; plus, it's easier for me to track what I have and haven't changed this way if I don't have to remember I made changes elsewhere.

 

EDIT: it easy to forget that TSL is actually a turn-based game at its heart... why the 6 sec / round makes sense, even if it really doesn't  :no

Share this post


Link to post
Share on other sites

I don't want to speak too soon, as I haven't fully tested it yet, but, I do believe I have completely solved the Ebon Hawk black mesh problem for good:

 

 

 

 

The problem with the previous fix I posted up is that it relies on an edited VIS file, this one doesn't. What this means is that the black mesh doesn't just disappear once you enter an area, but is still visible before you enter it -- as seen in the below shots:

 

k2_00038.jpg

 

k2_00039.jpg

 

Rather, the black mesh is not visible at all anymore, and does not need an edited VIS file in order to achieve this -- which had another downside I didn't want to mention.

 

k2_00040.jpg

 

k2_00041.jpg

 

 

 

Share this post


Link to post
Share on other sites

Not exactly the game faults you're not using it's designated system.

It's somewhat the beauty of TSLRCM though, that since we change the .mod files ANYWAY, I can jam everything in there that I want changed with no regard to the override or other mods. Definitely makes things easy. .utc change? Stuff it in. .Git changes? Yup. .dlg? There you go.

 

Also in my custom mods I prefer to stuff stuff in the .mod files rather than override. Less chance for conflict. No extra work required to make them work in override (like the original Handmaiden mod had to had about 7 files just to rename so it was override friendly, all dropped). And yes, I do need to update them sometimes if TSLRCM gets patched, but I suppose a benefit of working on both is that I already know exactly what's changed and thus needs adapting.

 

As for keeping track, I just got all my modfiles nicely sorted in a seperate map. Most are pretty much the files you find in the patcher folder, few actually use the patcher to add to globalcat or dialog.tlk.

Of course, most are small anyway, just a few files, makes it easier too XD

 

EDIT:

Yes. That fix sounds good. Want to share how? Or top secret stuff? XD

Share this post


Link to post
Share on other sites

Not exactly the game faults you're not using it's designated system.

It's somewhat the beauty of TSLRCM though, that since we change the .mod files ANYWAY, I can jam everything in there that I want changed with no regard to the override or other mods. Definitely makes things easy. .utc change? Stuff it in. .Git changes? Yup. .dlg? There you go.

 

Also in my custom mods I prefer to stuff stuff in the .mod files rather than override. Less chance for conflict. No extra work required to make them work in override (like the original Handmaiden mod had to had about 7 files just to rename so it was override friendly, all dropped). And yes, I do need to update them sometimes if TSLRCM gets patched, but I suppose a benefit of working on both is that I already know exactly what's changed and thus needs adapting.

 

As for keeping track, I just got all my modfiles nicely sorted in a seperate map. Most are pretty much the files you find in the patcher folder, few actually use the patcher to add to globalcat or dialog.tlk.

Of course, most are small anyway, just a few files, makes it easier too XD

 

EDIT:

Yes. That fix sounds good. Want to share how? Or top secret stuff? XD

 

Yeah, not sure I have that kind of advantage, yet. So far it's only the miner appearance that's been an option of being handled via a .MOD file; so it's still early days on that front and I may decide that trying to do things via the override just doesn't warrant all the extra hassle as I figure just about no one else will bother making sure that their mod is compatible with mine. Making a mess of all my hard work. Plus, there are certain files that are going to cause issues regardless, like the Appearance.2DA file that by necessity has to have changes made to pretty much every single row.

 

I should just stick with making sure it is just compatible with mods like TSLRCM, and leave it to that. Not that I ever wanted to support every mod under the sun, as that is just impractical, just less hassle using it with others. Why I'm looking to recreate certain smaller mods by doing the same or similar with this one when I get the chance. Probably the best way to reduce compatibility issues if people can be persuaded to not use a bunch of mods that actually only make one small change to a .2DA file. But in the end, there are always going to be issues as there will always be people that have more than a hundred mods installed at once... Bit pointless when people go out of their way to ensure that there are as many mod conflicts as possible -- but of course, since yours was the last one they installed, it has to be YOUR mod that is causing all the issues :question: .

 

Anyway, I'll re-post my last post as I think it may have ended up being overlooked:

 

 

 

 

I don't want to speak too soon, as I haven't fully tested it yet, but, I do believe I have completely solved the Ebon Hawk black mesh problem for good:

 

The problem with the previous fix I posted up is that it relies on an edited VIS file, this one doesn't. What this means is that the black mesh doesn't just disappear once you enter an area, but is still visible before you enter it -- as seen in the below shots:

 

k2_00038.jpg

 

k2_00039.jpg

 

Rather, the black mesh is not visible at all anymore, and does not need an edited VIS file in order to achieve this -- which had another downside I didn't want to mention.

 

k2_00040.jpg

 

k2_00041.jpg

 

 

 

 

I think I'll keep the fix to myself (for now), but once the mod is released, it should be easy enough to dig out the answer. All I'll say as a teaser, is that when the issue was originally raised on this thread, well... It turns out I was even more correct than I thought I was  ;).

Share this post


Link to post
Share on other sites

Easiest should be to append the .2da changes with TSLPatcher, make it set the proper appearance in the .2da's, then stuff the result in the appropriate .mod file.

Best way to get the least mod conflicts...

Share this post


Link to post
Share on other sites

Well as I have finally gotten around to doing the last of the fixes and texture work for Coruscant, I thought I'd post up some screens for it.

 

Originally I wasn't going to do much beyond the skybox textures, not until I had a crack at Malacor as some of the textures are used here. But, it is a very small self-contained level that allows me to test some things out and still have it all completed within a short time-frame. And thought it is only seen briefly, it is still an important element to the game if undersold as it was.

 

 

 

Before pic, just the one as I think one is enough ;)

 

k2_00479.jpg

 

After pics...

 

k2_00089.jpg

 

All textures are now their own "COR_" version instead of being those for Malacor -- and from other areas. Though most likely not all of these textures are used with the other Malacor textures, I wanted to make sure that they were their own seperate version of the texture to make sure there are no conflicts, allowing me to be free in taking the Malacor textures in whatever direction I want to go with.

 

k2_00088.jpg

 

Skybox texture has different front, back, right and left versions rather than being the same one repeated:

 

k2_00087.jpg

 

You can now see various craft flying through the skies -- they were present before, just NOT rendered:

 

k2_00084.jpg

 

k2_00093.jpg

 

k2_00094.jpg

 

The obelisk in the centre of the room has been removed. Though I think logically based on "lore" their would actually be a holo-emitter; as the PC stabs something with their lightsabre, I decided to replace the generic looking obelisk with something a bit more appropriate. At first I was going to replace it with a new custom placeable, but decided that would be more work than necessary at this point. So, this is a combo custom floor texture and retextured standard placeable statue.

 

The words on the base read: "In the light there is shadow, within the shadow there is light."

 

k2_00086.jpg

 

The new marble floor texture I decided to radically depart from the original because it was pretty crap to begin with and based on what appears in the movies. The films are set around 5,000 years after the events in TSL and I figure the Jedi Temple has gone through at least some interior remodeling since then; why it looks the way it does in the films. So I thought that what you might actually see, is something far different and reflecting the "Jedi" of the time and their Je'daii order roots.

 

The marble black and white floor is based on the Je'daii order symbol, and it along with the statue and words is meant to reflect that begin as well as allude to themes within TSL. Essentially, the old Je'daii were about balance, the new Jedai focus only on the light side and shun the dark. The words on the stature reflect this old teaching as well as indicating something else, which is that no matter how "good" people or a society are, there is always the capacity of evil as well -- or put simply, arrogance and opulence as an outward display of an order's corruption.

 

k2_00097.jpg

 

Lastly a closeup of the inset Jedi Order symbol marble and gold / silver specular work:

 

k2_00096.jpg

 

 

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.