ebizoe

I think GECK has problems on loading multiple master files. Use GECK Extender instead.

ShowOff:OnPreActivateInventoryItem event handler comes handy for that purpose.

"end)" is how Lambda statement is closed in this case. The following two numbers are arguments for SetOnMenuOpenEventHandler. 1027 is the menu code for the levelup menu.

If you need to store the value for the level requirement in a separate file, create data\config\amokrun1s mod.ini and place the following in it: [General] iModLevel=15 ;Give the player a trait at every 15 level. Since the code I posted is an event-handler, it needs to run once at the start of a session. Place it in the GameMode block of a quest script, like this: scn QuestScript float fSetting int iMenuID int iModLevel int iQ begin GameMode if GetGameRestarted ; Read the level requirement value from a config file. TestExpr iModLevel = GetINIFloat "General:iModLevel" "amokrun1s mod.ini" if 0 < iModLevel ; Set an event-handler so it runs everytime the levelup menu is opened. SetOnMenuOpenEventHandler (begin function {iMenuID} ; Test if the player's level meets the requirement. iQ = Floor ((player.Getlevel) / iModLevel) if 0 == (player.Getlevel) - (iQ * iModLevel) ; If the requirement is met, run the trait menu after the levelup menu is closed. CallWhen (begin function {} ; Give the player only 1 trait. fSetting = GetNumericGameSetting "iTraitMenuMaxNumTraits" SetNumericGameSetting "iTraitMenuMaxNumTraits" 1 ShowTraitMenu ; Set "iTraitMenuMaxNumTraits" the original value. SetNumericGameSetting "iTraitMenuMaxNumTraits" fSetting end) ({} => 1 != MenuMode) 16 endif end) 1 1027 endif endif end Or for a Script Runner script, create a script file with "gr_" prefix, something like this: "data\nvse\plugins\scripts\gr_amokrun1s_mod.txt" So that it runs once at the start of a session. In gr_amokrun1s_mod.txt: float fSetting int iMenuID int iModLevel int iQ ; Read the level requirement value from a config file. TestExpr iModLevel = GetINIFloat "General:iModLevel" "amokrun1s mod.ini" if 0 < iModLevel ; Set an event-handler so it runs everytime the levelup menu is opened. SetOnMenuOpenEventHandler (begin function {iMenuID} ; Test if the player's level meets the requirement. iQ = Floor ((player.Getlevel) / iModLevel) if 0 == (player.Getlevel) - (iQ * iModLevel) ; If the requirement is met, run the trait menu after the levelup menu is closed. CallWhen (begin function {} ; Give the player only 1 trait. fSetting = GetNumericGameSetting "iTraitMenuMaxNumTraits" SetNumericGameSetting "iTraitMenuMaxNumTraits" 1 ShowTraitMenu ; Set "iTraitMenuMaxNumTraits" the original value. SetNumericGameSetting "iTraitMenuMaxNumTraits" fSetting end) ({} => 1 != MenuMode) 16 endif end) 1 1027 endif

ShowOff:OnPreActivate event-handler from ShowOff NVSE Plugin will cover that.

I think this would do. Giving 1 to bShowTraitMenu will activate the trait menu after the levelup menu is closed.: int iMenuID int bShowTraitMenu SetOnMenuOpenEventHandler (begin function {iMenuID} if bShowTraitMenu CallWhen ({} => ShowTraitMenu) ({} => 1 != MenuMode) 16 endif end) 1 1027

TTW has two global variables for it: if bInDCWasteland == 1 printC "Player is in DC" endif if bInNVWasteland == 1 printC "Player is in Mojave" endif

Yes, apparently it is bugged. According to GECK wiki:

It'll be easily done by using a ref-walking function. There are several ways to do ref-walking, but you probably should try GetFirstRef/GetNextRef first.

This first chunk in the first script needs the variable "Stamp" to be 0 to run, but "Stamp" stays 5 after the first run. if (Stamp == 0) ;Stamp will never be 0 after the first run imod FadeInFromBlack4sISFX EPDoor.disable ;make sure the Exit door is disabled endifSo I think setting Stamp to 0 instead 5 on the "stage 4" solves your problem here. EDIT: Damn, sullyvanj93 solved it first.

This mod has been published. https://www.nexusmod...egas/mods/82482

Here is the final, version 1.0. We are going to publish this! forEach array_var aIter <- (array_var aWeapons = GetLoadedTypeArray 40) if GetWeaponKillImpulse (*aIter) != 0 SetWeaponKillImpulse (*aIter) 0 endif loop

Since I didn't particularly like the last script, I rewrote it (BETA 4). This is a "JIP LN NVSE Script Runner" script that runs only once on game start. It's much more efficient than previous quest-script version. The script processes all the weapons from all loaded plugins thanks to "GetLoadedTypeArray" script function, so it covers any weapons from any DLC/mod. array_var aWeapons array_var aIter ref rWeapon if eval (aWeapons = GetLoadedTypeArray 40) forEach aIter <- aWeapons rWeapon = *aIter if GetWeaponKillImpulse rWeapon != 0 SetWeaponKillImpulse rWeapon 0 endif loop endif aWeapons = aIter = ar_Null ;I'm not sure if this line is necessary, but just for safety.I think I'll stick to this design and test this for a while. I can't promise when I'll publish this as a mod or even publish it at all, though.

Your idea sounds good, but on my end, this particular game-setting value never resets other than at the start of the session. Not even at reloading saves. I've been monitoring game's behaviour by running this quest script all the time. scn TestScript begin GameMode if GetNumericGameSetting fAutoAimScreenPercentage != 0 SetNumericGameSetting fAutoAimScreenPercentage 0 printC "NoAutoAim:fAutoAimScreenPercentage 0" endif end And "SetNumericGameSetting fAutoAimScreenPercentage 0" happens only once, at the start of the session. I suspect that there is a mod, in your mod-setup, that modifies the value at certain events. And one more thing. According to GECK wiki, setting the value of fAutoAimScreenPercentage to 0 removes auto aim, not -100. Of course we know that -100 works, and on my test, there was no difference on game's behavior between the two. Well, I just thought I should let you know this. Anyway, I really like how disabling auto-aim affects gameplay. You definitely should share the end product with public!

I agree with sullyvanj93, a quest script is a good start. This script spits out console message every time it changes the value of "fautoaimscreenpercentage" to -100, so you will know when value-resetting happens. scn NoAutoAimScript begin GameMode if GetGameRestarted || GetGameLoaded SetNumericGameSetting fautoaimscreenpercentage -100 printC "NoAutoAim:fautoaimscreenpercentage -100" endif if GetNumericGameSetting fautoaimscreenpercentage != -100 SetNumericGameSetting fautoaimscreenpercentage -100 printC "NoAutoAim:fautoaimscreenpercentage -100" endif endOn my very brief test, exiting conversation with NPC (tested with Cass) didn't trigger the reset. You should pin-point which event triggers the reset, and write much more efficient script accordingly.

I wrote a simple script that blindly sets every single weapon's "Kill Impulse" to 0. The idea is basically the same as Realistic Death Impulse, but I implement it as a quest script so that it covers every single weapon in the game, including the ones that are added by any DLC/mod. I've been testing this mod for a while and so far, I think I like this. Requires NVSE, JIP NVSE Plugin and JohnnyGuitar NVSE Plugin. Or, if you're familiar with GECK, you can compile this code as a quest script and attach it to a quest with the Script Processing Delay set to 0.1. scn skiMainScript ref rRef ref rWeaponPlayer ref rWeapon begin GameMode if GetGameRestarted SetDebugMode 0 endif if rWeaponPlayer != player.GetEquippedObject 5 if eval (rWeaponPlayer = player.GetEquippedObject 5) if GetWeaponKillImpulse rWeaponPlayer != 0 SetWeaponKillImpulse rWeaponPlayer 0 debugPrint "SKI:Nerfed %n(%i), player" rWeaponPlayer rWeaponPlayer endif endif endif rRef = GetFirstRef 200, 1 while rRef if IsFormValid rRef != 1 rRef = GetNextRef continue endif if rRef.GetActorProcessingLevel != 0 rRef = GetNextRef continue endif if rRef.GetLifeState != 0 rRef = GetNextRef continue endif if eval (rWeapon = rRef.GetEquippedObject 5) if GetWeaponKillImpulse rWeapon != 0 SetWeaponKillImpulse rWeapon 0 debugPrint "SKI:Nerfed %n(%i), %n(%i)" rWeapon rWeapon rRef rRef endif endif rRef = GetNextRef loop end

Before ditching those great UI mods, you should try these fixes if you haven't already. - Scripted Ammo Fix by Roy Batty - Ammo Script Fixes by migck Ammo scripts are known to cause container/pipboy lag. Either of these mods removes ammo scripts and uses event handlers for ammo effects instead. Ammo Script Fixes goes further than that and fixes how ammo effects are handled by the game, so you'd probably would like to try it first to see if it works for your mod setup.

You probably have mixed up with two different filepaths. FileExists is relative the Data folder, while ReadStringFromFile is the Game's installation path. string_var svString = ReadStringFromFile "data\config\The File You Want to Read Strings From.txt" 1 1The format for the contents of the source file ("The File You Want to Read Strings From.txt") is just a plain text. It goes like this; Coffee mug My toaster is the shiniest one in Mojave. Brahmin milk And since the sample code only reads the first line from the source file; svString == "Coffee mug"Hope this helps.

It's good to know the problem is solved anyway. >I ended up basically doing what you did. I would show off my new quest script, but it looks fresh out of an Italian restaurant. It does work, however. I guarantee that in a month or so, you'll curse your own code being too cryptic. Well, good luck on your mod development. We all love to play new quests!

No, it doesn't work in my test either. I think we should try alternatives. How about letting the quest script to retrieve the new values (iStage, rQuest, rGiver) by itself. I tested following scripts and they worked. I set up a quest called "MainQuest" just for holding values for these variables. This is the attached script for "MainQuest": scn MainQuestScript int iStage ref rQuest ref rGiverThis is my test script pretending to be one of the radiant quest scripts: scn sdRadiantQuestScript1 int iStage ref rQuest ref rGiver int bInit begin GameMode {} if bInit != 1 bInit = 1 iStage = MainQuest.iStage rQuest = MainQuest.rQuest rGiver = MainQuest.rGiver printc "QuestScript1:iStage=%.0f, rQuest=%i, rGiver=%n" iStage rQuest rGiver endif endAnd then, the main user function script: scn sdGenRQ begin function {} ref rGiver = BobbyPin array_var sdRadiantQuests = ar_List sdRadiantQuestScript1, sdRadiantQuestScript2, sdRadiantQuestScript3 array_var aQuests = ar_List sdQuest1 sdQuest2 sdQuest3 ForEach array_var aIter <- aQuests ref rQuest = *aIter if (GetQuestFlag rQuest 5) == 0 ResetQuest rQuest int iKey = GetRandomInRange 0 (ar_Size sdRadiantQuests) ;The return value is inclusive. min <= x < max. ref rQuestScript = sdRadiantQuests[iKey] MainQuest.iStage = 1 MainQuest.rQuest = rQuest MainQuest.rGiver = rGiver SetScript rQuestScript, rQuest StartQuest rQuest break endif loop endNote that since "MainQuest" is just for holding variables, it doesn't need to run.

I think you mixed up with refs and forms on these lines. ;Sets up variables for the quest rQuest.SetVariable "iStage", 1 rQuest.setRefVariable "rQuest", rQuest rQuest.setRefVariable "rGiver", rGiverAccording to GECK wiki, the syntax for setRefVariable is this: ref.SetRefVariable VarName:string NewValue:form Parent:ObjectSo if these ref variables hold base forms, which they do in this case since rQuest is a quest, you need to write them like this: ;Sets up variables for the quest SetVariable "iStage", 1, rQuest setRefVariable "rQuest", rQuest, rQuest setRefVariable "rGiver", rGiver, rQuest

Take your time. It could be very small things that we overlooked. However, since I use this script function in my mod, I'm very curious to learn what causes this problem. So if you find it out, please don't forget to report it here.

I tried the latest JIP LN NVSE Plugin v56.72 (I was using v56.52), and found that "%r" on WriteStringToFile works as it should. code: int intVar = 10 ref refVar = BobbyPin WriteStringToFile "data_file.txt" 1 "Two times four is %g and no more.%rIts name is %n" intVar refVar "data_file.txt": Two times four is 10 and no more. Its name is Bobby Pin So, maybe your xNVSE, JIP LN NVSE Plugin and JohnnyGuitar NVSE need to be updated to the latest version?

That's strange. I double checked my code in my previous post, and they both do work as I intended. The result "data_file.txt" is like this for both code: Two times four is 10 and no more. Its name is Bobby Pin Two times four is 10 and no more. Its name is Bobby Pincode: int intVar = 10 ref refVar = BobbyPin WriteStringToFile "data_file.txt" 1 "Two times four is %g and no more." intVar WriteStringToFile "data_file.txt" 1 "Its name is %n" refVar array_var aArray = ar_List ("Two times four is " + $intVar + " and no more."), ("Its name is " + (GetName refVar)) forEach array_var aIter <- aArray string_var svString = *aIter WriteStringToFile "data_file.txt" 1 $svString loop And interestingly, if I put "%r" on the end of each string data, "data_file.txt" would look like this: Two times four is 10 and no more. (empty line) Its name is Bobby Pin (empty line) Two times four is 10 and no more. (empty line) Its name is Bobby Pin (empty line) code: WriteStringToFile "data_file.txt" 1 "Two times four is %g and no more.%r" intVar WriteStringToFile "data_file.txt" 1 "Its name is %n%r" refVar array_var aArray = ar_List ("Two times four is " + $intVar + " and no more.%r"), ("Its name is " + (GetName refVar +"%r")) forEach array_var aIter <- aArray string_var svString = *aIter WriteStringToFile "data_file.txt" 1 $svString loop So, seems like "%r" actually does something. By the way, I use this script function in my mod to store array data to a text file, one array entry per line. If you'd like to check it out. Here is my mod.

I would do it like this: WriteStringToFile "data_file.txt" 1 "Two times four is %g and no more." intVar WriteStringToFile "data_file.txt" 1 "Its name is %n" refVar or: aArray = ar_List ("Two times four is " + $intVar + " and no more."), ("Its name is " + (GetName refVar)) forEach aIter <- aArray svString = *aIter WriteStringToFile "data_file.txt" 1 $svString loop