JCarter426

There are two things at play here. The first is the grass texture file, which you can edit like any other texture, and that is determined by the module's ARE file as Grass_TexName. In addition to the texture name, the ARE file configures everything else about the grass. The two other settings of interest are the Grass_QuadSize and Grass_Density. The quad size determines how big the grass is. The "quad" in question is essentially a single instance of the texture. Each blade of grass is a rectangular plane with the grass texture drawn on each side. So the quad size is just how big those rectangles are. Increasing the quad size can produce giant corn field-sized stalks of grass. The density determines how spread out the grass is over a surface. It's something like how many quads per square meter, though I'm only guessing with the units. So a higher density means thicker grass, more rectangles closer together. The game distributes the grass quads semi-randomly over any walkmesh that has the grass material on it. There are other settings in the ARE file for affecting that probability, but I'm not entirely sure how they work and I doubt it's worth messing with them.

For feats and most other stats, yes. I don't recall if Force powers can be granted through items. That's a reference to a string in dialog.tlk. The number is the line number in that file. Though applying a hide item to the player would require editing a global script such as k_hen_heartbt01, which is a bit messy. Other mods have done it, so of course there would be compatibility issues. This has to do with how the feat is displayed - whether it's something you get automatically from your class, whether it's something you have to select when you level up, that sort of thing. I believe 4 is to have it not display at all (for example, the player can't see any droid feats) but honestly every time I look at it, I forget how it works five minutes later.

Unlike K2, K1 doesn't have any script functions to give the player feats or Force powers either, unfortunately.

I believe it's the last parameter: void ActionStartConversation(object oObjectToConverse, string sDialogResRef = "", int bPrivateConversation = FALSE, int nConversationType = CONVERSATION_TYPE_CINEMATIC, int bIgnoreStartRange = FALSE, string sNameObjectToIgnore1 = "", string sNameObjectToIgnore2 = "", string sNameObjectToIgnore3 = "", string sNameObjectToIgnore4 = "", string sNameObjectToIgnore5 = "", string sNameObjectToIgnore6 = "", int bUseLeader = FALSE); I'm guessing it's executed through a custom OnDialogue script for the NPC, but I'm not sure what the exact code would be.

I don't believe there's any way to remove or change a class once it's been applied to the character and they've leveled up. Multiclassing Canderous or other characters would be fine though. The issue is that the player already multiclasses from their starting class to Jedi, but nobody else does so it's fine.

I never tried talking to them in 15 years. 🤔 It seems any NPC I talk to turns hostile, but they don't attack unless I attack them. And none of the others seem to care if we start fighting.

I was sent an image through Discord. Pazaak was not mentioned at all, just the fish swoop track, so I wasn't sure if it was K1R or the original game. That's what I'd expect. So K1R's version of the dialogue file was corrupted in some way and needs to be fixed. I've seen that error happen when there's no valid player response to a dialogue node, like from a misplaced conditional script.

You can't, unfortunately. The game only supports two classes and will crash when a third is added.

Hmm, that sounds like it must be a K1R problem, then. I'm not familiar with the changes it makes, unfortunately. Only thing I can think of is to try using the original dialogue and see if you talk talk to the Selkath with it. That would at least confirm if it's a problem with the dialogue file or something else (like scripts that were left out of the .mod, which the older tools did sometimes). I've attached the swoop registrar's original dialogue, just put it in Override. You'll also have to put the .mod file back and load a save from before you entered that area to test it. man26_swpreg.dlg

Could you describe the steps needed to reproduce this bug? This has been reported before and I looked into it, but couldn't reproduce it and couldn't see anything wrong in the files. I was told at the time that K1R shouldn't be editing anything related to those dialogues, too, so it was a total mystery.

She doesn't have a separate head model, so it would have to be extracted. I have a tutorial for this. It's a bit out of date (pre-MDLEdit and MDLOps v1.0) but the procedure is basically the same. She also wears a hood, and without looking at the model I wouldn't be able to say how easy it would be to get rid of that. But her face is geometrically similar to Atris', so it might be possible to borrow some assets from her instead. The model is only the first step. To add a new player appearance would require edits to appearance.2da, heads.2da, and portraits.2da, plus the creation of portrait textures. That's not as difficult as the model stuff, though.

Probably a custom environment map for Korriban. Most outdoor modules have them.

I did some more testing, but it only raises more questions. I noticed that, regardless the save and transit bugs, if you repeatedly enter and exit the Sand People enclave without triggering the the greeter's dialogue, then the Sand People faction switches back and forth with each repeated entrance. I'd suggest executing the original heartbeat script first. That way you know all of it runs correctly and then the part that went wrong is fixed. But I don't think you need to edit 18aa's at all. My guess is that it's actually the OnEnter for 17ab that's going wrong. I'm not sure how, though, because the globals are correct. With both those in mind, I would guess that the scripts are somehow checking the globals incorrectly. Maybe a bunch of if trees that fail to account for a specific combination of things, or maybe something more obscure like case sensitivity. Though we can only keep guessing so long as we can't actually look at the scripts.

I know I've been cheating on my WIP thread with Discord and random status updates, but I hadn't realized I'd been neglecting it so badly. Anyway, I recently ported the K2 robes to K1 and I'm currently working on the actually-for-K2 version of the mod. I didn't just port the robes before; I fixed various things on the model and made new textures specifically for the K1 items. I'm applying the same process to the original K2 textures now. For most of them, I'm simply updating them to fit my new model. For others, though, I've decided to make new textures to fit them better. That's where things get complicated. I've run into a few oddities. First, one of the textures is never used in the game. There isn't any item with texture variant #5. I figured it may have been designed for an item that never made it into the game, so I went digging through the game files. I found this in dialog.tlk: I find that very interesting, but it just raises more questions. There's already an item a_robe_10 - the Norris robe. Time for a little show and tell: Above are all the fishy textures. Texture #5 is unused. Textures 7-10 use what I'm going to call the Baran Do template. They have a distinctive rectangular bit than the random bath robe folds of the other texture variants. I suspect that three of these were originally intended for the three-tiered Baran Do robes (novice, advisor, and sage). Given that Ossus was a Jedi library, I also suspect that the unused #5 could've been for the Ossus Keeper robe. If so, texture #8 presumably would then be the missing Baran Do link. Or maybe the Norris robe texture is the one that's wrong. The point of all this speculation is that I don't want to reproduce this weirdness with my mod. I'd like to straighten things out. I've already decided I don't like the Ossus Keeper and Norris robes looking like Baran Do robes, so I'm going to come up with new designs for them. I already have ideas in mind, so we can put those aside. I'm not entirely sure what to do with the Baran Do robes, though. For one, we now have a pick of four different textures rather than two. Also, we might be dealing with not two but three Baran Do robes, if we include the unused advisor tier. I could use some input on both matters. To implement the third Baran Do robe would require placing the new item somewhere in the game. I've already checked the random loot scripts and they won't support any new robe items. So it' would have to be placed manually. I have no idea where. As for the textures, I actually like the Ossus Keeper and Norris variants rather than the actual Baran Do ones, so I might be inclined to use those designs instead. But I'm open to suggestions, particularly if a third texture has to be made too.

Oh, so that might not even be setting the faction state at all. 🤔

Hmm, that's not what happens to mine. I have a bugged save with everybody disguised just outside the enclave as well. When I load it, nobody in the area attacks me (because I am disguised) but if I enter the enclave, everybody inside immediately goes hostile.

It can, but I don't think it would be a practical solution. Seems the bug isn't limited to that anyway. Hmm, that would explain the problem I had before. I loaded up a bugged save to see what I could do with it with that in mind. I had to exit the Sand People Territory and reequip the items. When I returned to their territory, I triggered one of the [A small group of Sand People ambush you!] encounters, but nobody else was hostile and the disguises otherwise worked correctly. That would suggest the trigger is handled through area scripts. I looked through the module.ifo files and found the Mod_OnAcquirItem scripts set up for the Dune Sea and Eastern Dune Sea. I couldn't get k_ptat18aa_acqui or k_ptat18ac_acqui to decompile, but I can make some educated guesses about what's going on. First, those scripts only fire when items are equipped when you're in those areas. You equip a clothing item, the script runs and does whatever cryptic thing it's doing that we can only guess at. So you have to equip the disguise items in those specific modules - m18aa and m18ac - for the script to fire and set the state correctly. Returning to the Ebon Hawk with the fast travel option likely fails to unset that state. This would be an issue with one of m17ab's scripts, k_ptat17ab_enter. That one wouldn't decompile for me either. It appears that m18ab doesn't do anything at all with regard to the disguise. It seems the AI for the NPCs in that area actively checks if you have the disguise equipped and they'll go hostile if you're not disguised. This is unrelated to the other disguise checks. I was also able to kill them all, leave, equip the disguise, and return and enter the enclave incognito. Conversely, it means they don't bug out when everything else does. The Sand People ambush triggers probably fail to check for the disguise at all. Finally, while I was testing all that, I discovered another bug. If I equip the disguise and then unequip it or equip another item, the game crashes when loading m18ab. It's hard to say what can be done to fix the problem when I can't look at the source scripts, but my instincts tell me to modify the OnEnter scripts. Simply have them check if the disguises are properly equipped and set the state accordingly. And if you do that you could just dummy out the other stuff. I don't know why OnAcquirItem was used instead of that. But it's clearly not behaving as intended, so it's hard to guess how it was supposed to work.

Right click the controller you want to edit > edit values.

I tried it and didn't encounter that problem, but I've had problems like that before. I noticed that fast travel changes the disguise items; there are probably different UTI files contained in each area's static RIM archive, rather than a single global diguise item. But the only oddity that caused, at least for me, was that they're sorted separately in the inventory.