PushTheWinButton

Are we sure that it's definitely not a game setting (or ini setting like some other extra FOV settings are)? If it's hardcoded, disabling the key is the only thing that'll work but it's a bit invasive imho for something so trivial. Personally I'd just exert some self control, but meh. It'd be interesting to know what the zoomed FOV is, and if it's smaller than some weapons with low zoom factor. Anyway, JSawyer Ultimate works by temporarily overriding a weapon's FOV setting with a null value, hence disabling zoom. Since you're not using a weapon, that method obviously isn't applicable here.

Cipscis explains this in more detail here but essentially when you use an if or while you're setting up some code which will run when an expression is evaluated to true. True is defined as any non-zero value. Hence, if [deadNPC].GetDead ......is true because it will return 1 - a non-zero value. Likewise, if PlayerREF.GetItemCount Stimpak ......is true if the player has any number of Stimpaks. On the other hand, if [deadNPC].GetDead == 1 ......will also return true. Including the == operator simply adds an extra step, as == will only return true if left and right are equal. Basically, the first example is saying "if (1)" - yes, 1 is true so the code runs; and the second example is saying "if (1 == 1)" - yes, 1 equals 1 so true again. Turning it on its head, if [deadNPC].GetDead == 0...is saying "if (1 == 0)" which is false, so the code won't run. It's a minor thing, and I thought the same as you at first, but its useful to know when optimising code. Using more operators will be more performance intensive, especially in large foreach and while loops. Priority means that conditions don't evaluate left to right either, which can be important if you have an && and the function to the right shouldn't be called if the function to the left evaluates to false. I always omit unnecessary operators for these reasons (and I think it looks nicer).

You don't really need the "== 1"s. The only problem with your original script was that you'd put "GetDead 1" (was that meant to be GetDead == 1?), and that you were missing an endif. Indenting helps with that, though I understand you might have just left that out when typing your post. Anyway, here's what I mean: SCN AQquest1END begin GameMode if (AQtestNPCREF.GetDead) if (GetObjectiveDisplayed AQquest1 10) SetStage AQquest1 20 endif endif end

http://www.nexusmods.com/newvegas/mods/62513/?

Thats good to know ... but it seems there would be a game bloat problem having a few hundred unique scripts keeping track of their own DoOnce short variable ... No ??? In theory, yes, but I think It's harder than people think to cause significant bloating. Remember, all the encounters in Fallout 3 use PlaceAtMe functions and there's technically no limit to how many times they can occur; likewise potion crafting and enchanting in Oblivion and Skyrim use cloned objects. Saves naturally increasing in size is just a fact of playing the game, and of using mods in general. That's not to say you shouldn't avoid adding unnecessary stuff when possible. So in this case, yes, perhaps a different method would be more professional due to the number of objects.

EDIT: Scripts attached to objects have a unique instance for each reference, btw. Sorry, I don't want to get involved with instructing you if you're not familiar with scripting because then I just end up troubleshooting beginner problems. It's simple stuff, so just following some basic tutorials and checking the wiki should get you through. Here are some example scripts which will work, though: scn PreWarBookSCRIPT begin OnAdd PlayerREF PlayerREF.AddItem PreWarBookAid 1 1 RemoveMe end scn PreWarBookXPEffectSCRIPT begin ScriptEffectStart if (GetIsReference PlayerREF) RewardXP 15 AddItem PreWarBookUsed 1 0 else AddItem PreWarBookAid 1 1 endif end

Should something like this work? If player.GetBaseActorValue charisma > 9 If GetReputation RepNVGoodsprings 1 > 2 && < 8 SetReputation RepNVGoodsprings 1 15 endif endif If player.GetBaseActorValue charisma > 9 If GetReputation RepNVGoodsprings 0 > 7 SetReputation RepNVGoodSprings 0 7 endif endif Nope, that won't work. You need to call the function twice and use the logical operators to produce the range you want (like rickerhk said); there's no range checking in the GECK language. The GECK Wiki says you can't store the result of GetReputation in a variable, which I think is wrong because I've done it before and I'm pretty sure that's how disguises work, but I could be mistaken. Anyway, you are saving the player's true reputation before you change it, right? There's only a finite amount of fame available in the game for most factions, so changing it without having a way to revert the change can, in a way, screw up someone's game if they decide to uninstall your mod.

Well that was partly my point with the first bit. Basically it adds a slightly meaningless 'must scavenge all Pre-War books for extra XP' aspect to the game. Why make the player actually use the book as an item when, if they pick it up, they're pretty much guaranteed to use it? I mean you could just cut out the middle man and make activating a book give XP in a do-once block. That way you wouldn't even have to pick it up and ruin some nice clutter placement. But meh, I was just answering the question as the OP posed it.

It's a bit of an unbalancing idea, and encourages player's to ruin the decor of some interiors, but hey - that's not stopped people before. Anyway, you can't add an effect to a misc item, but you can add a script which swaps Pre-War books for a new ingestible-type (aid) item when you pick them up. The new book will have to be an aid item because you won't be able to attach a new experience-adding effect to books (the form type - i.e. the one skill books use). Such an effect would also need to be scripted.

Deffo YUP.

Two 'if' tests is complicated? I modify dozens of game settings, skill rates, global variables, and mod variables. I'm not going to hard code all that in a custom mod that is then tied to a specific load order, and need to modify it every time I want to adjust something. That's what ini files are for. And to answer the original question, it's unlikely that this mod was causing CTDs if that is all it's doing. My point was the reason for the original post was to fix a specific mod, which makes a specific change a single gamesetting. Having a setup like you mentioned is fine if you want to make lots of personal changes and know what you're doing, but for a released mod which simply changes a single setting and is meant to have a low profile, it's massively overkill. Personally I'd say just using FNVEdit to change the records is more straight-forward than your method, too, since basically you're method is still scripting the change, just in a .ini instead of in the CS. But apples and oranges and all that. Basically the lesson of today is that you don't need to use a script to change a gamesetting. I frankly don't care what method you prefer.

That's still massively over-complicating things, but whatevs.

What's wrong with just changing fMaxArmorRating in the CS? That doesn't require a script. (And yes, you're calling the function every time the script runs - 5 seconds by default - which isn't necassary. Things like that should be placed after if(GetGameRestarted). There should be no performance impacts, however, but it's just messy.)

I've had some bugs recently with NVSE and OBSE not properly clearing arrays and strings so I always like to do it manually to be sure. Best to be safe and there's no negative impacts, anyway.

I know. The purpose of the reference was to re-equip the same weapon in case the player has multiple (i.e. so that it has the same condition and enchantment, etc). Using UnEquipItem and EquipItem equips your highest condition version of the item. Re-equipping the item is needed to change the grip animation visually, and should force-unequip the shield. Of course, it wasn't my intention to fix all the problems with the concept - that wasn't what the OP asked for. But here goes: To stop all NPCs using the grip, you'll need to clone the weapon - there's no way around that. By using two remote containers you could use the indices to pair all cloned weapons with their original versions, to save re-cloning weapons. So, for example, one container could be for one-handed and the other for two, and index one of the first chest will be the vanilla one-handed Iron Longsword and index one in the other will be the clones two-handed variant. When the player switches grip, their current weapon is removed (probably to a third container for safekeeping), and the paired weapon is added and equipped. The upside of using clones is that changes to them are saved permanently, therefore any grip and damage changes would only need to be done once. Therefore all you have to do is write a script to retrieve/make clones when the player presses the key, depending on whether or not a clone already exists (container.GetItemCount would be the check). The downside is that there's a potential for savegame bloat. Enchanted items and player-made potions are also clones, though, so its down to you to decided whether cloning weapons only when the player switches their grip is more or less detrimental. A TempCloneForm like in New Vegas would be better, but Oblivion doesn't have that. Hope that helps. I don't have time to write an example right now.

Oops, I ordered the parameters wrong. Change them all to have rWeap after the number. Also noticed that "GetInvRefsForItem" in the UDF needs to read "rActorRef.GetInvRefsForItem". Sorry 'bout that. TBH, the UDF function could be incorporated into the main script but I just like to separate stuff like that out for ease of reading.

UNTESTED: First, I made a UDF to get an actor's exact equipped weapon. This needs to be an Object script: scn FnGetEquippedWeaponRef ;returns the passed actor's currently equipped weapon as an inventory reference ref rActorRef ref rWeap array_var aEntry begin Function { rActorRef } let rWeap := rActorRef.GetEquippedObject 16 if (rWeap) foreach (aEntry <- GetInvRefsForItem rWeap) let rWeap := *aEntry if (rWeap.IsEquipped) break endif loop endif let aEntry := ar_Null SetFunctionValue rWeap end And this script will handle the keypress and grip changing (attach to a quest): scn GripChangerQuestSCRIPT float fQuestDelayTime ref rWeap begin GameMode if (fQuestDelayTime != 0.1) let fQuestDelayTime := 0.1 endif if (PlayerREF.IsWeaponOut) if (OnControlDown 200) let rWeap := PlayerREF.GetEquippedObject 16 if (rWeap) if (GetWeaponType rWeap == 0) SetWeaponType rWeap 1 elseif (rWeap.GetWeaponType rWeap == 1) SetWeaponType rWeap 0 elseif (rWeap.GetWeaponType rWeap == 2) SetWeaponType rWeap 3 elseif (rWeap.GetWeaponType rWeap == 3) SetWeaponType rWeap 2 else let rWeap := 0 return endif let rWeap := Call FnGetEquippedWeaponRef PlayerREF rWeap.UnEquipMe rWeap.EquipMe let rWeap := 0 endif endif endif endHopefully that should work...

Base DAM of 41 is very high for a weapon that fires 5.56mm. The Marksman Carbine only does 24 and that's a powerful weapon - the All American does 26. I'd say it's already pretty balanced tbh. You have to consider that the 5.56mm is half the value and far more common when compared to the Sniper Rifle's .308 Round.

Yeah, but you'll have conflicts out the wazoo. YUP and MMUE shouldn't really be used together because they have the same scope but different implementation. YUP is also more up to date, so I suggest dropping MMUE and you'll be fine.

I'm pretty sure that infamy doesn't affect AI, and that they only attack due to scripted changes in faction relations (which of course can be conditionalised on infamy). I remember testing it for a mod not long ago. In which case, SetEnemy and SetAlly are the commands you want.

Leveled items have a 'chance none' which is the chance the list will produce no item. Mods increase rarity by increasing the chance none, hence you get nothing more often. The GECK allows you to set the chance none of a leveled list to reference a global variable. This is how mods usually let you customise rarity - they set all the 75 chance none leveled lists to reference a single global variable, and then alter this variables based on the player's choice. Rinse & repeat for each different chance none. So, to answer your question, you need to increase the variable to increase the rarity. 100% - 15% = 85% if you want me to be patronising. However I doubt this will work for you if you're editing someone else's mod. It's likely the global is controlled by a script, so your change will just be overridden when inside the game. It might also be worth saying that globals aren't the only way to control the chance none. Some mods (*cough* by some very handsome people *cough*) use Lutana NVSE's Get/SetChance none functions to do it without any edits.

Mod Organizer >> NMM (for now anyway - fingers crossed)

Just unpack the Meshes BSA and select the model you want for the activator. You're over-complicating things.

Does the mod require NVSE plugins that you don't have? Also, does GECK PU require an .exe? The version I have is just a .dll.

Same here *cough* unfortunately *cough*. Endorsements are irrelevant anyway - rich get richer and all that jazz - so the question is, why does OP really care that much?