Fair Strides

GetModule() returns the object reference to the level itself, just like you'd refer to a creature or an item, or a placeable. For any of this to work, going off of the level you're in or were in at the time of this scripting, you'd need GetModuleFileName(). If you're in "001EBO.mod", the function would only return "001EBO".

...Then doesn't that last comment negate all of this talk about K_LAST_MODULE, which is the module you had been in, not the module are currently in?

I see no difference from here in the execution of the OnEnter and the OnExit, so I would suggest a test using an OnExit and a conversation warp. Probably just a simple SendMessageToPC in the OnExit and then see if it shows up in the feedback log. As to the OnEnter itself, the only way this would work for getting the last, or previous, module would be if it also checked for the nearest door/trigger so that you knew which warp point was actually used to get to this module.

As in, the K_LAST_MODULE in the global strings section of the savegame? If so, then it must be a hard-coded change Obsidian made, since I see no mention of the k_sup_guiopen script being called in any way in the levels...

Yes, KSE shows a last module value, though this is in one of the save's files itself (I believe savenfo.res off the top of my head), not stored in an accessible way. Sadly this will not work out of the box. The K_LAST_MODULE global string was used exclusively for the Rapid Transit System in K1. The code carried over to K2, even though they took the button off of the GUI. In K2, any mention of K_LAST_MODULE is found only in three files: k_inc_utility (whose UT_ValidateJump function checks for the K1 Ebon Hawk level), k_sup_guiopen.nss and its compiled form. The k_sup_guiopen script was fired as part of the Rapid Transit System itself and so is void in K2 as it currently stands. However, levels do have an OnExit script event in their .are file. One could probably use this to set K_LAST_MODULE to the current level using something like this: void main() { SetGlobalString("K_LAST_MODULE", GetModuleFileName()); } From what I recall of the function, if you're in 003EBO.mod, the function would return "003EBO", without the extension.

Thanks for helping Effix out, Kex. I'm not always around, so it's nice that people don't have to wait too long.

I was not aware of the Star Forge content requireing the post-kiss scene conversation... Can I include this mod into K1R, or would you prefer it be kept separate? If separate, can I link to this mod in the read-me and mod page?

The issues here arise from MDLOps not writing default values for the emitter pieces and NWMax expecting some more than "" as a setting when importing the emitters. Because the info isn't imported, it can't be exported, much less anything to do with animations of emitters.

In your main K2 folder are up to three folders: "gameinprogress", "futuregame", and "currentgame". Delete all three with the game not running. Then run the game. Not saying it'll fix the bugged save, though.

^^^ That's going to be at least eight different install options, so if you do go through with that, I'll be around to help with the installer and proof it before it's tested.

Is it at all possible that the Flawless Widescreen was all that was needed for the Steam or GoG version? The GoG version should have been exactly like the old 4CD.

I would need to know the context of this "certain area" to be able to help more. Primarily, you'd set up a Trigger in the area's .git file or hijack one that already exists if it's in the right spot. A Trigger is a .utt file that has several events that fire scripts, one of which is an On-enter event that activates whenever something enters the area. In this case, you'd do something like this (all marks are ignored; you want to pay attention to what's between them): void main() { // Get the object that triggered the event object oTarget = GetEnteringObject(); object oTalker = GetObjectByTag("<tag of the object/person initiating the conversation>"); if(oTarget == GetFirstPC()) // If the triggering object is the current player-controlled character { // Have oTalker start a conversation with the PC. The code looks long because we need the last three pieces to make the // game ignore the distance between oTalker and oTarget. Otherwise, the player would move to oTalker first... AssignCommand(oTalker, ActionStartConversation(oTarget, "<name of .dlg file, minus the extension>", FALSE, CONVERSATION_TYPE_CINEMATIC, FALSE)); } }

Okay, where it gets the appearance type, try changing OBJECT_SELF to GetFirstPC(). I'm assuming that OBJECT_SELF refers to the computer instead of the PC like I thought it did.

...In that case, can you please post the current version of the script so I'm not taking potshots at an old version?

Okay, looking at my redo of the script, I made a rather severe typo that got carried over through all the iterations. I'll show it on the first example: This: if (int1 == 91 && int1 <= 93) { // If P_FEM_A_01, SML, MED, or LRG string1 = "DP_LS_SF_Robe_F01"; } Is read by the game as "If they have appearance.2da row 91 AND their appearance.2da row is less than or equal to 93, proceed." What it should be: if (int1 >= 91 && int1 <= 93) { // If P_FEM_A_01, SML, MED, or LRG string1 = "DP_LS_SF_Robe_F01"; } This now translates to "if they have an appearance.2da row that is equal to or between 91 and 93, proceed."

Yeah, that should be enough, but I realized I overlooked something when you had your script up here for examination. All of your UTI resrefs are 17 characters long, when the game only accepts 16.

The new functionality of the CreateItemOnObject and DestroyObject functions are advancements made by Obsidian and won't work in K1. The CreateItemOnObject function has an optional bHideMessage argument at the very end that defaults to 0 (FALSE). This argument will hide the popup. The DestroyObject function has the optional bHideFeedback argument, which I would assume prevents the entry from being posted to the Feedback screen.

Have you tried emulating commented out code from a_swapimplant.nss? Changing this: object oNewItem = CreateItemOnObject(sItem, OBJECT_SELF); To this: object oNewItem = CreateItemOnObject(sItem, OBJECT_SELF, 1, TRUE);

Now there's an interesting idea. I wonder if Dantooine ever gets snow? Guess I'd better look for the Polar Plateau, huh?

Please post the code that you've already tried to use. Oftentimes it just needs a slight tweak, but if not, I can help out more.

I've looked at the spells.2da and I can only make guesses, but I believe the Affect Mind and Dominate Mind are only available to the PC because they have a valid number in the forcepassive column and no numbers in forcefriendly and forcehostile. These three columns are in control of where powers are arranged in the spells screen. As for the feats, I don't believe you actually can restrict them in K1. The Force Sensitive feat is given to any Jedi class at level 1 and is not shown in the available feats window in-game because of how it's set up in the .2da file. We only see it for the PC because any Jedi party members are already level 1 when we find them.

The script should work, but it can be modified to be a bit cleaner/less redundant. the only bit of code that really needs to change is your uti resref:

Not quite, as I've just found out with DarthTyren on Skype while investigating how the games scale enemies. I know almost everything and can probably help find the rest. He has had issues getting JRLEdit to work. I pretty much abandoned the tool when I began working on the Toolset, but it'll still be a bit before I get to the JRL part of it... @JC2: I'll contact you on Discord, but I can probably give some time to look at and try to figure out the issue with JRLEdit.

Seeing as I failed rather epically to proofread the dialog like I said I would, I volunteer any help required for the bug-fixing.

You can try turning on V-sync, which should lock your framerate, I believe.