JCarter426

I did some testing that answered a few questions I had. And I've confirmed that my convoluted head process should work. The spawning procedure is still needed for the initial appearance change, though. And I've yet to determine the best way of spawning the creature somewhere the player won't be able to see them. Every module's coordinates different, so I'm not sure how to go about this. Also it would probably be unavoidable in small modules anyway. As such, I decided not to write the head duplicating function yet. The following code should work work for masks and such, however: /* jc_d_test K2 VERSION This allows for the extension of body model slots through the use of disguise items. When the item is equipped, the heartbeat script will replace that item with a copy that has the desired disguise property. The disguise effect can vary based on the user's gender and phenotype. The character may also retain their original head or be given a new one through the disguise; however, this has not yet been implemented. In the K2 version of the script, feedback is hidden, phenotype is disabled by default, and everything is contained in in one script. */ // This sets the string for gender string JC_SET_GENDER(object oUser) { /* 0 = Male 1 = Female 2 = Both 3 = Other 4 = None */ string sGender; int nGender = GetGender(oUser); if(nGender == 0 ) sGender = "_m"; else if(nGender == 1 ) sGender = "_f"; else if(nGender == 2 ) sGender = "_m"; else if(nGender == 3 ) sGender = "_m"; else if(nGender == 4 ) sGender = "_m"; else sGender = "_m"; return sGender; } // This sets the string for phenotype string JC_SET_PHENO(object oUser) { /* Small - Scoundrel, Jedi Consular, Jedi Master, Sith Lord Medium - Scout, Jedi Sentinel, Jedi Watchman, Sith Assassin, and default Large - Soldier, Jedi Guardian, Jedi Weapon Master, Sith Marauder */ string sPheno; int nClass = GetClassByPosition(1, oUser); if( nClass == 0 || nClass == 3 || nClass == 11 || nClass == 14 ){ sPheno = "_l"; } else if( nClass == 2 || nClass == 4 || nClass == 12 || nClass == 15 ){ sPheno = "_s"; } else sPheno = "_m"; return sPheno; } // This cycles through the inventory to replace disguise items with the dummy item. void JC_SWAP_INVENTORY_CYCLE(string sItemBase, string sDisguise, object oUser) { object oItem = GetFirstItemInInventory(oUser); while( oItem != OBJECT_INVALID ) { string sTag = GetTag(oItem); if( sTag == sDisguise ) { DestroyObject(oItem, 0.0, TRUE, 0.0, TRUE); CreateItemOnObject(sItemBase, oUser, 1, TRUE); } oItem = GetNextItemInInventory(oUser); } } //This just runs the above subroutine for every possible disguise item name. void JC_SWAP_INVENTORY(string sItemBase, object oUser ){ JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_m", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_m" + "_s", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_m" + "_m", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_m" + "_l", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_f", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_f" + "_s", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_f" + "_m", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_f" + "_l", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_s", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_l", oUser); JC_SWAP_INVENTORY_CYCLE(sItemBase, sItemBase + "_d", oUser); } void JC_SWAP_EQUIP(string sDisguise, int nSlot, object oUser, string sScript) { int nGame = 2; object oEquip = GetItemInSlot(nSlot, oUser); ActionUnequipItem(oEquip, TRUE); DestroyObject(oEquip, 0.0, TRUE, 0.0, TRUE); object oItem = CreateItemOnObject(sDisguise, oUser, 1, TRUE); if( nGame == 1 ) { CreateItemOnObject(sDisguise, oUser, 1, TRUE); ExecuteScript(sScript, oUser, -1); } else { DelayCommand(0.1, AssignCommand(oUser, ActionEquipItem(CreateItemOnObject(sDisguise, oUser, 1, TRUE), nSlot, TRUE))); } } void JC_SWAP_HEARTBEAT() { /* Open variables - sItemBase: File name of the item that the user can equip. This item should have no disguise properties on it. The name must be 12 characters or fewer. - sScript: New script to fire equip the disguise. This has to be in a new script file for K1 due to a bug in the script compiler. - nCheckHead: Whether we want to keep the user's original head. - nCheckGender: Whether we want to change appearance based on gender. - nCheckPheno: Whether we want to change appearance based on character class. - nSlot: Which inventory slot the item goes in. 0 = Head 1 = Body 4 = Right Weapon 6 = Left Weapon 7 = Left Arm 8 = Right Arm 9 = Implant 10 = Belt See NWScript for more details. - nB: Boolean used to check if the creature has put the item on. This is currently Boolean 64, but I've left it open for compatibility reasons. */ string sItemBase = "jc_d_test"; string sScript = ""; int nCheckHead = TRUE; int nCheckGender = TRUE; int nCheckPheno = FALSE; int nSlot = 1; int nB = 64; /* Other variables (don't touch) - oUser: The creature that uses the item. But since this is going in the heartbeat script, it should be OBJECT_SELF. - sGender: Suffix to add to the disguise item name, for gender. - sPheno Suffix to add to the disguise item name, for phenotype. - sDisguise: Disguise item name. It's either item base plus the suffixes, or plus "_d" if there are none. For example... Item base = jc_example Disguise (male, small) = jc_example_m_s Disguise (just female) = jc_example_f Disguise (just large) = jc_example_l Disguise (no qualifiers) = jc_example_d Item names and tags should be assigned accordingly in the UTI files. - oEquip: The item currently equipped in nSlot. - sEquip: Tag of oEquip. */ object oUser = OBJECT_SELF; string sGender = ""; if( nCheckGender == TRUE ) sGender = JC_SET_GENDER(oUser); string sPheno = ""; if( nCheckPheno == TRUE ) sPheno = JC_SET_PHENO(oUser); string sDisguise = sItemBase + sGender + sPheno; if( sDisguise == sItemBase ) sDisguise = sItemBase + "_d"; object oEquip = GetItemInSlot(nSlot, oUser); string sEquip = GetStringLeft(GetTag(oEquip), GetStringLength(sItemBase)); //This will clear the player's inventory of any disguise items, replacing them with dummy copies. JC_SWAP_INVENTORY(sItemBase, GetFirstPC()); //This will replace the dummy item with the proper disguise item if equipped. if( !GetLocalBoolean(oUser, nB) && sEquip == sItemBase ) { SetLocalBoolean(oUser, nB, TRUE); JC_SWAP_EQUIP(sDisguise, nSlot, oUser, sScript); } } void main() { int i; for( i = 0; i < 30; i++ ) { DelayCommand(IntToFloat(i) * 0.2, JC_SWAP_HEARTBEAT()); } } It's untested but it compiles properly so I assume there aren't huge problems with it. This the K2 version. A script for K1 would have to be adjusted slightly, but I didn't feel like doing it all yet. So if anyone wants to test it, I'd be very interested in seeing the results.

That wouldn't be compatible with any head mods, though. And would be a fair bit more work with setting up all the 2DAs, and you'd also have to directly map each appearance to each new appearance in the script, which would mean using the TSL Patcher for the script too. But sure, that is an option in theory.

I haven't taken a look at that mod, but that's basically it, yeah. In an ideal situation, the item you actually equip would have no disguise property, then the heartbeat script would fire and replace it with the disguise one. And then similarly swap out any in the inventory with the dummy version. Disguise effect wouldn't preserve the head, though. All that nonsense is just to preserve the head. You shouldn't need booleans if we're talking about mask items. The heartbeat script would only need to check if the item doesn't have the correct disguise property, which could be handled through the item tag. Mm, like I said I've thought about doing it before too... I've just never had a reason to try it. If I have time I might write up some generic code at least as a starting point.

I've given this some thought before. It's totally possible with the heartbeat script, just not... practical. But if you do want to go with that option, there is an alternative to the disguise effect. You could script the heartbeat to remove and replace the item, depending on whoever is wearing it, and then make multiple copies of the item, each with the right disguise property. However, you wouldn't be able to include those items in the upgrade system, since you'd be destroying the upgrade parts every time the item was equipped. That couldn't be removed through ClearAllEffects and as a bonus the disguise would be removed immediately when the item is removed. If you want to retain each character's head though, that's much trickier. There is a function for that, DuplicateHeadAppearance, but it requires two spawned objects in order to compare their heads. You can't just input head numbers. It might be possible to implement, but because it would be so convoluted I never attempted it. It would go something along the lines of... Equip item -> Heartbeat script fires -> get the item user's current appearance, before the disguise item -> apply the disguise item -> spawn a creature, any creature (ideally somewhere the player can't see) -> apply the desired disguise effect to that creature -> DuplicateHeadAppearance with the spawned creature and the item user (assuming it gets the right head) -> delete the spawned creature -> item user now has the desired head and body combination. There are a number of potential issues I can imagine. You'd probably have to set a boolean for whether the item has been equipped or not, to make sure the script is fired when the item is equipped but also when it is removed to fix everything, and also to account for area transitions, party members being sent away and then summoned again, etc. You might also have to store the player's appearance as a numeric so you can call it again later. I'm not sure if simply removing the item would set everything back to normal, so you might have to repeat the spawning and duplicating procedure, or apply a disguise effect using the player's original appearance, or maybe apply any other disguise effect and then clear it... I could go on and on. Like I said, convoluted. But it may be possible. And it's tempting.

I've converted each shot with the stacks into an image sequence for anyone who wants to look into this: Jedi Library Stacks

Looks like it's from one of the visual effect models, v_revmask1_dur or v_revmask2_dur (I believe that's just male/female).

Sounds like one of the metamagic feats. A lot of that was left in KOTOR and may be functional - for example, all the existing spell casting functions include a parameter for metamagic feats - although I never took a look at it. There's other stuff that's in a similar state. It seems the Sith uniform was going to be done through a polymorph spell, and so that might be still functional. Also the time stop effect does work, although it makes the game a little crazy. It freezes literally everything in the game.

I doubt adding model accessories would be possible. It looks like the 2DAs were set up to allow for it, but the models weren't. There are no hooks for the additional items, nor do I see any way of assigning them. A lot of stuff that was fully functional in NWN was simply stripped away from KOTOR. Since they actually made distinct models for all the items, I assume they intended to put it in at some point... but maybe they ran out of time, or they couldn't get it to look nice. So even if the belts and such have models, there's no way to tell the game to render it, at least not that I can see.

User content does not count as "personal information". The terms of service had a whole section covering user content and it affirms that user content was always the intellectual property of the user: It stipulates that the site is free to maintain and distribute copies according to the needs of the site's function (since that's how hosting works) but they claim no ownership of the files and include provisions for removal of files. They have since shut down the site, so all this agreement is effectively terminated. It does not apply to Nexus or any other site. GameFront has nothing to do with where the files are going now. They shut down their site and are no longer hosting the files. But they gave a warning before the shutdown so users could get what they wanted before time ran out. So some people in the modding community used the Internet Archive and other means to create a backup - just copies of the Filefront webpages as they originally appeared, as if the site were still hosted. The Nexus staff then took the files from these backups and began hosting them on their own site, without seeking permission - or even any form of communication at all. So, it's all right because it was their plan to unilaterally ignore everyone's intellectual rights from the beginning. The problem I have is that they're not just preserving the files. The mods were actually already saved and are in no danger of being lost. They may be more difficult to find for the average user, but they are there, in their original state, the state everybody agreed to. This was the most that had to be done to save the content from being lost, and it was the most that could be done while still respecting the rights of everyone involved. Nexus, on the other hand, has chosen to take these files and integrate them into their website structure. These stolen mods appear alongside other mods as if they were uploaded legitimately. They're being allowed to get away with this because they claim to be doing this for the greater good of saving these mods. And the users of their site praise them for this because to them, to the users of Nexus that don't frequent Deadly Stream or JKHub or the other respective communities, Nexus is their savior, because their disregard for intellectual property allows their hosting to be more public and convenient. But I don't know these users on Nexus. And they don't know me. There has never been any interaction between us. I don't upload mods there because I upload them here and on LucasForums, where the KOTOR modding community is active (to a degree). If you take content I created and distribute it on a site I don't use to people don't know, without involving me at all, it feels like you're going behind my back. That's what bothers me. The interaction is cut. I'm never going to hear what they think of my mods and the only mods of mine they ever get to see are the ones that happen to have been stolen - which in this case, are from years ago, some bugs and lacking the updates I've already done. And that's not fair to either side. It's that interaction that keeps the modding community alive.

They don't have to make the mods public on their website in order to preserve the files. They don't have to release them all at once under a dummy account rather than putting the absolute least effort possible in attempting to contact and properly credit any of the authors at all.

Yeah, that's a little crazy. We could go back and forth over the issue ignoring authors' rights to preserve their work, but this part I cannot fathom. How do you justify uploading content created by users of your own site under a different name without their permission... without even contacting them? That's inexcusable. This is not an issue of tracking down people based on the email they used a decade ago. I already had an account on Nexus - I don't upload mods with it because I don't particularly like the site, but it's the same username, email, etc that I used for Filefront. Sithspecter actually uploads mods on Nexus! You don't need to hire a private investigator to figure out who we are.

Well, as soon as I heard about this I contacted their staff to have my mods removed and they did so today. I maintain backups of all my releases and I reupload the old ones I think are not of embarrassingly terrible quality, or which are specifically requested, so they were never lost. I don't care to have my mods on Nexus, and in a couple cases they were uploading older versions that contained bugs. So there are pretty good reasons for these files to not be there, if you needed a reason other than the fact that I never consented to it.

It's PLC_cputerCon, but I'll leave the texturing to someone more competent.

View File JC's Merchant Inventory Fix for K2 This is a slight fix to address a problem that arises with certain mods. Certain weapon and armor textures are present in some other models, so if you install a mod that alters the texture mapping of these items, it creates a bit of a mess. This mod replaces the textures in these instances, so they will always use the original game textures. If you don't have any other mods installed, this won't do anything. But it won't hurt to have it installed either. If you spot any more incidents of this problem, please contact me and I'll add it to a future release. Submitter JCarter426 Submitted 05/19/2016 Category Mods TSLRCM Compatible  

Ah, I wasn't sure if you had or not. I was working on this since I played with Toasty Fresh's models and I was planning to check out yours on my next go.

View File JC's Merchant Inventory Fix for K1 This is a slight fix to address a problem that arises with certain mods. Certain weapon and armor textures are present in some other models, so if you install a mod that alters the texture mapping of these items, it creates a bit of a mess. This mod replaces the textures in these instances, so they will always use the original game textures. If you don't have any other mods installed, this won't do anything. But it won't hurt to have it installed either. If you spot any more incidents of this problem, please contact me and I'll add it to a future release. Submitter JCarter426 Submitted 05/19/2016 Category Mods K1R Compatible  

The camera problem you're having is just one of the game's oddities, and there's no easy way to fix it. When the camera is set to angle 0, the game randomly selects another angle - usually 1, 2, or 3. 1 is a close-up of the speaker, 2 is over the listener's shoulder, and 3 is a wide shot. When angles 2 and 3 can't be displayed correctly - if there are other characters between the speaker and listener, or if they're too close to a wall, or whatever - then the game defaults to another angle instead. In this case, the game is defaulting to a close-up of the player. This problem can happen anywhere at any time, and it's not a problem that's going to arise every time, because it depends on the positioning of the characters and the random selection of the camera angles. So the only thing you can do is what you've been doing - fix each problem as they arise. Changing the angles to 1 shouldn't cause any problems, although it removes the variety of the angles, or at least, the variety that's there when it actually does work correctly.

I hadn't thought to test if it negated other bonuses. That's good to know, although unfortunately it wouldn't do what I want. The attack bonus thing is tricky because DEX is applied instead in certain cases. And it would reduce the character's physical damage rather than the item's damage type. And it would stack if you wield two of that item. So I really don't want to go that route. Yeah, I suspected that... but I was checking the damage in the combat log too. So even putting the equipment screen weirdness aside, it's still not applying the right effects.

Looks great! I'm not sure how to go about the textures. Using the original game texture would be a bit tricky since the mapping on it is all over the place. Lots of overlapping with some parts used multiple times, and adjacent faces using completely different parts. It's probably doable, but obviously a custom texture would look better, if someone is interested in doing one.

Maybe they rewrote it after they had to cut the factory - the line "make my sacrifice matter" from one of the online previews never made it into the game. Or maybe it was only one possible outcome.

- Chris Avellone

Actually, you can use any script as an include file. It doesn't matter if it has main() so long as it has other subroutines. I usually give my include files a blank main() because that way NWNNSSComp will check it for errors. It doesn't affect how the scripts are included in other files in the slightest. Model variations are 8-bit, meaning you can only use numbers 0 through 255.

I'm not sure if all of what you're describing is possible in K1. Unfortunately the upgrade systems for each game function very differently. In K2 you can simply create new upgrade items and their properties will be added to all sabers unilaterally; however, in K1 the upgrade properties are determined in each individual lightsaber item file, so it's a bit of a mess making new ones. I also got a bit carried away with some ideas I've had since yesterday. If I can get everything to function in the game, I'm going to be adding two additional hilt types and doing an overhaul of the lightsaber properties in baseitems.2da. Essentially, I'm planning to get rid of short lightsabers - they'll still be there, just grouped with regular lightsabers different - and use the third available type for my new ideas.