JCarter426

M478_Staff
  • Content Count

    1,505
  • Joined

  • Last visited

  • Days Won

    126

Everything posted by JCarter426

  1. Merchant markup is set by the script that opens the store, not in the store file. This is how, for example, Suvam is able to give you a discount after you beat him at pazaak, but the items in his store remain the same. // 378: Open oStore for oPC. void OpenStore(object oStore, object oPC, int nBonusMarkUp=0, int nBonusMarkDown=0); I believe the last two are percentage increases/decreases, the first for the merchant's inventory and the second for anything they buy from the player. One would have to locate the scripts for each merchant, decompile them, adjust the values, and recompile. It's not difficult - assuming the scripts will decompile properly - but tracking them all down would be a bit of work.
  2. That's because Hanharr is a Wookiee. Alien dialogue in K2 doesn't work like the other dialogue, or like the alien dialogue in K1. The VO_ResRef entry is meaningless, much like how player lines in K1 have them. Aliens in K2 have a set of VO defined in alienvo.2da. The audio played is determined by three parts: the alien race (Wookiee, Duros, Sensor Ball, etc), the emotion (comment, question, seductive, etc), and the take number (1, 2, or 3). The Record No VO Override flag will tell the game to use alien VO when it's set to 1, or at least that's what I think judging by the look of it. It's been a while since I messed with this. The AlienRaceNode flag points to a line number in alienvo.2da to establish the race and which files to use. The Emotion list is what lets you add variety and in part determine how long the node is since many are split up into short/medium/long. Note though that DLGEditor lists all emotions that exist, not just ones available to that race. No VO set actually has files for every emotion. Finally, the game picks one of three takes for that emotion to use, I believe randomly. The lip files are named the same as the the VO files, though they may not work in certain modules due to the lips being missing, so you might have to extract them. This also means it's possible that some VO lines don't have any lip files on account of never actually being used in the game, though I'm not certain of that. Also, in your screenshot, there's something wrong with the dialogue. It looks like all the alien VO data has been stripped from it. On Hanharr's line, No Record VO Override should be 1, AlienRaceNode should be 12, and Emotion should be Question_Medium. Did you by any chance edit the file in KOTOR Tool? It doesn't support K2 dialogues, and might break them.
  3. It doesn't matter. The game won't read it because it won't know what it does. I've tried it before, though I don't remember if it crashes or just doesn't read the new information. If you want try it, go ahead.
  4. It's not a row, it's a column. It's not possible to add new columns to KOTOR 2DA files and have the game recognize them. I understand that it is possible for NWN, and that makes me sad.
  5. Yes, but those wouldn't be universal scripts used by the whole party (or worse, every NPC). They would be random scripts just to add the item in the game, like editing Bandon's OnDeath to give a specific UTI rather than dropping the one he does. That's your typical mod compatibility issue, and most mods don't edit the same things.
  6. Yeah, the heartbeat script is the only compatibility issue. If you don't use it, you're fine. But in that case, though, you are still limited to the one item: one character issue. So you couldn't, for example, give Bandon's armor a custom model and have it wearable by the whole party. You'd have to pick a character and restrict it to them, or have multiple Bandon armor items, one for each character. Unfortunately the only way to add support with everything for everybody is the heartbeat script (or a similar script) and it's a mess to deal with. Though it's ironic, because editing it is so bad for mod compatibility, nobody edits it anymore. Kreia's Assorted Robes is the only mod I recall that does it and that I still see people using today. Agreed.
  7. I could, and for the most part I have, though I never finished debugging it to stop creating duplicate items. But it all does work, no maybes about it. The K1 version already accounts for gender and player class, and I have separate code I tested in K2 that duplicates the head, though I never united the two because I never decided how to deal with the clone NPC spawning as I mentioned before. Like I said, what I actually wanted to do with it wasn't what I judged to be worth the effort at the time. If there really were a use for it I'd be willing to take a look at the code again, but I don't exactly see people lining up with new player models that are just waiting to be put into the game. Actually, the way I set it up is somewhat simplified. I intended to release it for general use at the time, so I accounted for people who don't know much scripting. If you wanted to add an item with that functionality to my system, all you would have to do is name your UTI files in a specific way and put the needed disguise effects on them. Though just that part alone requires knowledge of disguise items, new appearance lines, and how to use tokens in TSL Patcher, so it still isn't that simple.
  8. Yeah, that's true. People would still have to make models for such mods and set up all the items and follow my notes so it all works properly. If I finished my scripts and released them, that wouldn't change the amount of people with all the required knowledge and skills to do anything with them. Perhaps I haven't been clear enough on what my code would actually do, however. The situation now is that when you equip a clothing item, it does one of two things: a) assign a body slot and point to the model in that column of the character's appearance.2da line, or b) apply a disguise effect that points to a specific line of appearance.2da and use the cell from that line instead. For option a we are limited to the available body slots in appearance.2da (9 for K1, 14 for K2). We can't add more. For option b we're limited in that any character who equips the item gets the same disguise. So female characters still look like male Sith when they equip the uniform. Heads are tied to it the same way, so if you want to add a new appearance row for Bastila, anybody who equips the item will have to look like Bastila. The only provision to get around this, currently, is to restrict who can equip the item. In K2, there are provisions to restrict the item to specific characters (e.g. Atton's jacket, Mira's jacket, Handmaiden's robes, player's armband) while in K1 you can get the same effect if you restrict it to a feat only one character has (e.g. Battle Meditation for Bastila). That's doable right now, and several mods have done this. This does mean, however, that only that character can equip it. You need a different disguise item for each character. It's that final issue that my code would eliminate, if completed. In my above video, Carth and the female player are equipping the same Sith armor item. The script applies either the male or female disguise variant depending on what it detects as their gender. If this were extended to account for body size and heads, then it would effectively function as if you added new body variation. Every character could equip the item and their body would change based on their gender and phenotype but their head would remain the same. But even if I smoothed out all the bugs, it wouldn't be a flawless experience. There would be a delay, a fade to black or some more ridiculous solution, and there's the feedback issue (in K1 only) that I mentioned. It could be done, but it would never be perfect, and it would be a lot of work for a simple armor mod.
  9. Even if it didn't mess with it, I don't think it could be applied quick enough to hide the character. I haven't tested it but I'm assuming there would be a brief lag between the character being spawned and the invisibility effect being applied through their OnSpawn or whatever. I also don't remember if there's a true invisibility effect or if we're limited to the distortiony cloak effect that doesn't even work on all video cards or if frame buffer effects are turned off. Mind you, the visibility is going to be brief regardless. 1 or 2 seconds, max. I'm just being fussy about that.
  10. TXI files alone won't work for K2. Changes to the model are required, like I did with my Shader Fixes. I included the same N_Mandalorian.mdl/mdx files in my Minor Fixes so if you want to just include the files in your mod you're free to do so (see that mod for details). Though, by the look of it, you've already made changes to the model so you may be better off correcting it yourself. In that case, all you have to do is make sure your texture file is applied on the model before exporting it. The game reads the TXI data from the texture on the model, not necessarily the texture it's using. Or you could edit the envmap entry in appearance.2da to use the shader you want, which is kind of a hack method but also works.
  11. Not where there isn't a walkmesh, no. They'd be spawned to the nearest walkmesh, which would make them visible to the player in many modules - especially given how K1 likes its single-room modules.
  12. Yeah, that would be an eventual possibility if the thing were finished. But just getting a gender change was buggy enough on its own.... I've tested the head thing in K2 separately but I don't have a handy video showing it because I never implemented it into the K1 code. That's more complicated because to accurately copy the player's head, including any modded heads, you have to use the DuplicateHeadAppearance() function and that specifically requires two spawned characters. That's what's used in the revelation flashback to copy the player's head onto the stunt model. This clone has to be spawned somewhere and I never figured out a good solution for the where. I still think the best solution would be a hidden utility room, if it didn't require editing every bloody area in the game to work. I've made a mental note that if I ever get into video game development, to include such rooms just in case. I've seen them in other games, and even KOTOR uses them sometimes, but there's no standardization here. The next best option would be to spawn them wherever (such as the player's location) but have the game fade to black during the whole process, which would probably only amount to a second or two anyway.
  13. I remembered I had an old save from my testing, so I recorded what my work in progress was a couple years ago: As you can see in the video, though, I never finished debugging. The script started adding duplicate items to my inventory. Actually, I remember that started happening after I fixed another bug.... Anyway, it's not in any releasable shape, but you can see proof of concept at least. It's just a ridiculous and buggy proof of concept, which is why I never finished it. An easier option, I think, would be to eliminate some of the armor models to free up the slots. Keep different models for light, medium, and heavy armors but eliminate the other half and you free up three body slots. Then you could use those for such things as Republic armor or Darth Bandon's armor or whatever you want. Somebody could do a poll to see what armor models people want kept or eliminated maybe.
  14. As the Dark Lord says, for K1 we're limited to the 9 body types in the game, all of which are already used for the player character. To be specific: A - Underwear B - Clothing C - Light Armor (Class 4) D - Light Armor (Class 5) E - Medium Armor (Class 6) F - Medium Armor (Class 7) G - Heavy Armor (Class 😎 H - Heavy Armor (Class 9) I - Jedi Robe J - Revan Armor Additionally, K2 has: J unused (there's no Revan armor item in the game) K unused L - Dancer Outfit (unused for male characters) M - Zeison Sha N - Jedi Master Robe You can change what models those slots use, and you can change which items use which slots, and you can create new item types and configure them to use whichever slot (including underwear) but you're locked with using one of the existing slots and any changes will affect all models in that slot. In K2, you can use the J and K slots for whatever you want, and in fact I released a mod that uses them for Republic armor and uniforms a long time ago. In K1, you're not so lucky. You could replace one of the models with the Republic soldier armor if you did new textures for every other item that uses the same model, or configure them to use a different model. I thought about doing that once, and I think I even made textures, though it was so long ago that I assume they were awful. There is a method of circumventing this, for either game. A really convoluted method that requires editing some core files that would be a nightmare for mod compatibility. But it would work. I wrote and tested some code for it a couple years ago and got a proof of concept going, but ultimately decided it was too convoluted to be worth doing. It would work something like this: You equip a dummy item. This doesn't have the appearance you actually want, just whatever placeholder you choose (perhaps clothing or underwear). It will only be visible for a few seconds. The player and party heartbeat script (k_hen_heartbt01) constantly checks what item the character is wearing. When it detects that the character is wearing the dummy item, it fires some new code that will ultimately give us the look we want. First, the script removes the dummy item from the character's inventory. Second, the script spawns a clone of the character elsewhere in the game. The main problem here is that due to the way the script functions work, the character must be spawned in the game world, even though we don't want to see this character. To get around this, one option would be to spawn them in an unseen utility room... but you would have to add such a utility room to every area in the game. Or maybe you could live with fading to black for a few seconds. Third, the script detects the character's size and gender in order to equip them with an item that matches their body type. The new item will be a disguise item, pointing to a new line in appearance.2da. Each body type would require a different line and item pointing to that line. This appearance is a placeholder - it won't have the correct head. Fourth, the script copies the head from the clone NPC to the player, thus restoring the player's original head. Finally, the script destroys the clone NPC. The heartbeat script also checks if the player has unequipped the disguise item in order to destroy it and replace it with the original dummy item. I've tested most of this - I had scripts to swap out the items working in K1, though it was a bit of a buggy experience. For example, part of the GUI would have to be disabled in game options or else you'd get a feedback note every time the item was changed. I only tested changing the gender in K1 and not the body size or head. I had it replace the Sith trooper disguise with a female version for female PCs. I did test the head thing in K2, and I believe I wrote code for the body size that could be enabled if needed. But I gave up working on it because it's just too ridiculous. I could be convinced to reconsider if there was enough of a demand for it, and maybe we could work out a compatibility solution for the heartbeat script, but at the time the stuff I specifically wanted to do with it - female versions of the Sith trooper, Sand Person, and Mandalorian disguises - was so minor compared to the amount of effort required to make it function, and it would never function perfectly, so I gave up. I think you'd be better off porting all of K1 to K2. That way you get the extra K, L, M, and N body slots and you can do whatever you want with them. Or just replace one of the nine in K1. I'd rather have different outfits like the Republic armor, Sith armor, dancer outfit, and so on rather than several slightly different looking armors that I'm only putting on for the stats, anyway.
  15. Oh, a lady droid. Interesting. Doesn't the one on Nar Shaddaa that's bad at pazaak have a female voice already?
  16. Yes, that's right, and the order in which the models are loaded would matter as well. As far as I can tell, the game saves rendered models to memory so it can read any new instances of the model from memory rather than starting over every time as an efficiency thing. And it saves them based on the model name rather than the file name, which normally shouldn't make a difference because all the original game models have them named the same. And with the functionality of the current tools, there's no reason to have them different, so in general you should rename the model base to match the file name.
  17. You're missing the TXI files. The mods should've come with them, but for future reference what you need is a text file that reads: envmaptexture CM_Baremetal saved as whateverthetextureis.txi. Or envmaptexture whatever other shader you want to use instead of CM_Baremetal (CM_SpecMap, CM_Bright, mycube, etc).
  18. Here were my results: And I've attached the most up to date files for anyone who wants to take a look. I believe all the problems (apart from the weird inverted alpha option) have been sorted on this one. Hand_Normal_Testing_v31.zip
  19. I think somebody fixed the turret already, I just didn't have it installed. I can't unsee those pipes now, though....
  20. I like to keep you all guessing. Or actually, it's a misshapen collection of fixes I've compiled over the span of years and as soon as they're done I forget what they are. From the pictures: The annoying transition messages, yes. That's the plot crystal, the one used to build your first lightsaber... I guess it's hard to tell from the regular crystal items, but it used to be they all had the opila icon. Now they look like the normal blue/yellow/green crystals. The protocol officer's hair seam. Wrists on the clothes were misaligned before. The placeable model was pretty bad before. There were metal parts hovering in the air; the UV mapping was terrible - somebody painted a mural of a droid onto the bottom of the kiosk, apparently; and I never liked the droid head because it looks like an R2 unit rather than a KOTOR droid, the head is too small to be from an R2 unii or a KOTOR droid, and the model is used for non-droid kiosks all over the game, so I thought it made more sense to remove it outright. Ack, you are correct... but what's fixed there is the Sith fighter laser color. The lasers were green in the original game, even though they're red in the Bink videos Full list of changes for v1.0 :
  21. View File JC's Minor Fixes for K1 Summary This is a collection of various things that I found annoying enough to alter. I collect things that I don't think warrant their own mods into a single mod, to be released to the general public when it becomes more substantial. Contents I've divided this mod into five categories: Straight Fixes, Bug Fixes, Resolution Fixes, Aesthetic Improvements, and Things What Bother Me Fixes. Straight Fixes are fixes for issues I think are genuine errors or mistakes or oversights or what have you. There's a problem, here's a fix for it. No artistic license is involved. Bug Fixes really fall under straight fixes but I've separated them into their own category because they're more severe and there's absolutely no reason not to have them. They fix bugs that could potentially break your game. What I've included are either well known and easy for me to do a quick fix or came to my attention directly. There are lots of other bugs this mod doesn't fix, so I strongly suggest that you seek out a more extensive bug-fixing mod. Resolution Fixes are all textures from the game for which there were identical, higher resolution textures somewhere else in the game files. So I've swapped the lower resolution ones for the higher resolution ones. I've separated these from the straight fixes because a) I didn't make any of the content here - it's all extracted from the game, and b) they don't actually fix "problems" per se - it's just an increase in resolution. It looks the same, with slightly more pixels. Aesthetic Improvements are my attempts to improve the visual quality in certain areas. I've tried to maintain the original aesthetic of the game while improving the quality. But the nature of the improvements necessitates new content created by me. You might not like my work, or you might use a different mod that touches on these areas, or whatever, so I've isolated these from the other fixes. Things What Bother Me Fixes fix things what bother me. They might not bother you but they bother me, so I've isolated those as well. For a full release history, see the accompanied file. Submitter JCarter426 Submitted 08/07/2018 Category Mods K1R Compatible No  
  22. Version 1.1

    43,103 downloads

    Summary This is a collection of various things that I found annoying enough to alter. I collect things that I don't think warrant their own mods into a single mod, to be released to the general public when it becomes more substantial. Contents I've divided this mod into five categories: Straight Fixes, Bug Fixes, Resolution Fixes, Aesthetic Improvements, and Things What Bother Me Fixes. Straight Fixes are fixes for issues I think are genuine errors or mistakes or oversights or what have you. There's a problem, here's a fix for it. No artistic license is involved. Bug Fixes really fall under straight fixes but I've separated them into their own category because they're more severe and there's absolutely no reason not to have them. They fix bugs that could potentially break your game. What I've included are either well known and easy for me to do a quick fix or came to my attention directly. There are lots of other bugs this mod doesn't fix, so I strongly suggest that you seek out a more extensive bug-fixing mod. Resolution Fixes are all textures from the game for which there were identical, higher resolution textures somewhere else in the game files. So I've swapped the lower resolution ones for the higher resolution ones. I've separated these from the straight fixes because a) I didn't make any of the content here - it's all extracted from the game, and b) they don't actually fix "problems" per se - it's just an increase in resolution. It looks the same, with slightly more pixels. Aesthetic Improvements are my attempts to improve the visual quality in certain areas. I've tried to maintain the original aesthetic of the game while improving the quality. But the nature of the improvements necessitates new content created by me. You might not like my work, or you might use a different mod that touches on these areas, or whatever, so I've isolated these from the other fixes. Things What Bother Me Fixes fix things what bother me. They might not bother you but they bother me, so I've isolated those as well. For a full release history, see the accompanied file.
  23. Ah, ok. I did some testing and it didn't seem to make a difference whether the height map was there or whether it was all white. It really didn't like having an inverted height map on the alpha channel, however. Did some weird things to it. It should be, yes. And only when using a normal map. It's not an issue with the regular smoothing.
  24. Well, like I said, I file the problem under "don't do that". It would be nice if you could have the tools fix it, but if it the problem can be avoided on my end, I don't mind sorting it. Maybe I'm still scarred by the dark times of NWMax & old MDLOps, but I'm used to adjusting my methods to make the game happy. It is good to understand why these things break, I think, even if the problems can be solved.