forli

Nope, that's not a "message queueing problem". set light to firestaffuser.GetActorLightAmount if light < 25 if firestaffuser.HasSpell Glow == 0 firestaffuser.AddSpell Glow endif endif if light => 25 if firestaffuser.HasSpell Glow == 1 firestaffuser.RemoveSpell Glow endif endif Message "Player's light %.2f " light Let me fix and optimize this for you: set light to firestaffuser.GetActorLightAmount if light < 25 ;AddSpell command and its variants already include the "HasSpell" check, and return 1 if succesfully added, 0 if already present firestaffuser.AddSpellNS Glow ;the -NS version does not show up the message "spell X added to spellbook". else ;if condition is false, then surely light >= 25 ;same for RemoveSpell command and its variants firestaffuser.RemoveSpellNS Glow endif Message "Player's light %.2f " light Also this check: if light => 25is an error. It should be: if light >= 25 ;equal character must be placed AFTER greater characterBut in the solution this check is not even necessary

A script may crash and stay broken for good during the execution. There are many possible way to break a script, mainly by having a condition with an unchecked reference variable. This is a generic example: If refVar.IsActor ;refVar has not been checked for null before thisThis cause no error when compiling/saving the script and the esp in CS. When the game runs the script, if refVar is null, the script break and may stay that way for good, with no way to make it run again. If the script is an Object/Magic script, it won't be a permanent damage, as the problem only affect that specific instance of the object/spell/function, which can be destroyed. Other objects with the same script are safe (but of course, they may crash in the same way, if their ref variable is null as well). If the script is a Quest scripts the damage is permanent, as Quests can't be destroyed or resetted, and the problem can only be fixed by reloading a previous save, or if you already saved with the frozen script, you can only the game, disable the esp, make a clean save, and enable the esp back. In the case of your staff, even if your current staff's script is broken, you can always drop/sell it and get another one (even with AddItem). Of course: the best way is preventing such problems, by checking the variable before using it: If refVariable If refVariable.someCommand ... EndIf EndIfThis way, you're safe 100% of times, no matter what. Of course 2: you can avoid the check if you're 100% SURE the variable won't be null (maybe you just assigned it or the logic of your code is good enough to allow such assumption). Example: Set refVariable To <something> If refVariable.someCommand ... EndIf This is safe as long as <something> is an EditorID (so the variable is surely not null), or if <something> is a command/function which NEVER return null. Example: GetCrosshairRef is a function which may return null, if you're not looking at any object. GetParentCell never return null if called on an object instance, as any instance exists in the gameworld and is contained in a cell (NOTE: objects in containers/inventories are not really instances, and they are handled differently by the game. These objects will transform into real instances when they are dropped from the container/inventory). In your case, to make an example: ... Begin OnEquip Set user To GetContainer ... ;user is not checked for null End The logic here is robust enough: only actors can equip an object and fire the OnEquip event, so you're sure the object is placed in some actor's inventory when you do GetContainer, which will then surely returns a valid reference, and you don't strictly need to check if the variable is null (checking it for null is not a bad idea anyway). In this case: ... Begin GameMode If user ... EndIf End In this case, the check is necessary, as GameMode block run continuously when not in Menus, even when the object is not equipped, so the variable "user" may be null at any time here. Another case in your code: Begin MenuMode if IsEquipped ... ;you can use "user" without checking for null EndIf End Here the logic is safe too, as IsEquipped means the object has been equipped, and this means the OnEquip block must have fired at some point before this check, and so the variable "user" has surely been assigned to some actor (as above, checking if user is null is not a bad idea anyway). I hope this solve most of your doubts!

Careful with this: SelectPlayerSpell IceStaffBlizzardSpellIf you're disarmed in the middle of combat and the enemy steal your staff, he may attempt to equip it and this command will try to equip the spell on the player! And if it can't find the spell, I'm not sure what happens! Put a check If user.GetIsReference PlayerRefto prevent such problems. . GetIsCurrentWeather Snow == 1You can remove the == 1. Not needed. Every condition is checked implicitly for "!= 0" (and since "!= 0" is equivalent to "== 1" with true/false commands, that's exactly what you need). You can use this trick also to check whatever a numeric variable is not 0 or a reference is not <null> If someCommand ;true if the command returns true, or returns any FormID, or any number but 0 If someNumericVariable ;true if someNumericVariable contains any number but 0 If someRefVariable ;true if someRefVariable contains any FormID. in GameMode: if user.GetEquipped ElementalIceStaff == 1There's another check to add. Check whatever user is <null>. If user is <null>, and you do "user.<something>" the script may crash for good and never run again for the rest of its life (and this may explains why you can't regenerate the staff's charge). If user ;ensure user is not <null> If user.GetEquipped ElementalIceStaff ;now we can do the "equipped" check ... ;code EndIf EndIf Don't put these two conditions on the same line with &&. Oblivion doesn't have shortcircuit && and ||, so it will not stop at the first condition if it's false. This means, even if user is <null> (and thus False) it will still read the second condition and will crash. Writing like my solution instead prevents this problem. Also more performant and more correct version of this: if user.GetEquipped ElementalIceStaff == 1 ;true if ANY ElementalIceStaff is equippedis this: if IsEquipped ;true if THIS SPECIFIC ElementalIceStaff is equippedIf multiple staffs exists in the game world, the first condition may be true for them all, even if only one of them is equipped. Instead the second condition is true only for the specific staff equipped by user (and it's even faster to check).

Let's see... First, those "Player." can be a problem. They add the spells/abilities to the player... even if someone else equip the staff. I would do: ref actor Begin OnEquip Set actor To GetContainer ;this actor is equipping the staff actor.AddSpell IceStaffSpell actor.AddSpell IceStaffShield actor.AddSpell IceStaffBlizzard ;actor.AddSpell RechargeWeaponSpell If (actor.GetIsReference PlayerRef) ;Equip the spell on player, only if player is the actor SelectPlayerSpell IceStaffSpell EndIf End Begin OnUnEquip ;No need to use GetContainer again. ;The variable was already assigned by the OnEquip block, and the actor who was equipping the staff is the same who is unequipping it now. actor.RemoveSpell IceStaffSpell actor.RemoveSpell IceStaffShield actor.RemoveSpell IceStaffBlizzard actor.RemoveSpell IceStaffBlizzardShield actor.RemoveSpell IceStaffBlizzardSpell ;actor.RemoveSpell RechargeWeaponSpell Message "ICE ITEMS REMOVED" 2 End Also, remove all "Player." and replace them with "actor." also in the GameMode block (Again, there's no need to use GetContainer in the GameMode block)This way, the staff become usable by NPCs too (including your followers). Then: the problem with SetEnchantment is the wrong usage: http://cs.elderscrolls.com/index.php?title=SetEnchantment "reference.SetEnchanment nuEnchantment:ref" can only be used with a reference. This is not the case, because ElementalIceStaff is not a reference, but a base object. To make it work, you need to use the other way: "SetEnchantment nuEnchantment:ref objectID:ref", which means: SetEnchantment ElementaIceStaffBlizzardEnchantment ElementalIceStaff WARNING 1: whatever you use the reference of base object version of the command, the enchantment is tied to the base object, which means ALL ElementalIceStaff staffs in the game will change their enchantment at once when you call this command. WARNING 2: the enchantment is not saved in the savegame, which means every time you reload a save, the staff will revert to its original enchantment (the one assigned in CS). To avoid problems, put a "If GetGameLoaded" condition in that GameMode block, which assign the correct enchantment when game loads.

I'm not sure there's another mod which fixes the "Rain roof bug", the "Crash returning main menu", the "Camera on feet after player's resurrection", and unlock the "Decal time", the "Grass distance settings", the "HDR + MSAA in the video option menu" and the "distance grass limitation to the 3x3 grid" OR is much more than "shaders" and "effects". It's an unofficial game patch which alter the very game C++ code to realize features no other esp/esm could ever achieve. Even without shaders, OR still apply a big amount of changes, including fixes to hardcoded bugs (bugs you can't fix with CS) and new features which esp/esm mods can only simulate with the limited capabilities of the CS scripts. Mounted combat is something already seen in DR and UV... except it requires ugly workarounds and expensive scripts to achieve, while OR achieve it natively and with a negligible performance cost. Same for Dual Wield and Shield on back. Windowed mode, FPS manager, Immersive camera... already seen, but they use either external tools or scripts, which are many times slower than OR's native C++ code. For shaders, you could use the old OBGE (which is "4 times slower and heavier than OR"), or ENB (beautiful but heavy) To make an example: in UV, when you hit someone with the left weapon, no real attack/hit is happening. It's just an animation with a simulation of the damage formula, but no "hit" is registered by the game. If a mod is waiting for some "Hit" event, it would not work with UV left attack. That's the point: other mods use scripts. OR recreated them with C++ (waaaaaay much faster) and included them natively in the game engine. To make an example: if I could recreate my mod HUD Status Bars in native game code (I lack the skill to do so), the performance hit would be drastically reduced by (minimum) 90%. And for an heavy mod like that, it would be a HUUUGE gain. If you have enough CPU power to waste on heavy scripts, then good for you. I would turn my entire load order into C++ code and dll if I could. Yes, as I said, OR is much more than "shaders" and "effects". It's very modular and you can choose the features you need (in your case, you can start by disabling the shaders/effects, if they are too much for your hardware)- Yes, 17 replace the water textures and settings, while OR replace the water shaders. You should be able to use both them at once or either one of them alone. I'm not sure about the underwater fog settings, as I recall OR override them to improve the underwater visibility.

You can use OR in any computer, as long as you configure it. Performance hit come from the shaders, effects, grass/LOD distance, etc... but you can disable them all. Other features like mounted combat, dual wield and all the engine fixes (rain roof bug, etc...) comes with minimal to none performance cost, and can be used on on old computer too. But this is going off topic, so let's end this talk about OR.

Oh, my bad! I read OR and I confused Enhanced Water with Improved Water :sweat: ... so many similar names out there... I should stop posting in the middle of night! :laugh: Well, anyway, there's no water mod really better or worse than another one. It only depends on your taste, that's why you received no answer!

You're talking about two completely different mod, which do different things. - Water 17 is a simple texture replacer and adjust some of the exposed fog settings. - Enhanced Water/Oblivion Reloaded include a complete water shader replacement, which is on a completely different level. You can't even compare it to the above one, but this doesn't mean they're incompatible. Despite the "incompatibility" warning in Water 17, you should be able to use both as they touch completely different things. It's like asking to choose between coffee (Water 17) or sugar (EW/OR), where coffee states it's incompatible with tea (other water/texture replacers mods). You can have both coffee and sugar (or tea and sugar, if you find another mod you like more than water 17, but sugar is still valid!). Also, Oblivion Reloaded is fully modular, which means you can disable every single feature you don't want. You can pick all the features you like and disable all performance intensive features. OR has many fixes for the game engine you may want and have no impact on performances. Just ensure the shaders/effects are disabled and you should be fine.

Some clarifications: - The event is called OnHealthDamage - Despite the OBSE docs says the event is called before the damage, the event is actually called after the damage (you can check: while running the function, the health has already been altered by the damage), but, in case the damage was fatal and the health is below 1**, no dead event has been called yet, so you can restore the health and save the actor before the game checks for his death. - The damage of the event is already the final damage, comprehensive of any alteration made by any armor/weakness/resistance. Just think about it: a damage event can't be fired before the damage has been applied, and the damage can't be applied before all alterations have been applied, which means the damage event can't be fired before that as well! (As I said, when the event is called the damage has already been applied, so the final damage is already known). To answer your question: yes OnHealthDamage is the one you need. ** Yes, in Oblivion an actor dies if health drop below 1 (and not when it drop to 0, like you would guess)

I discourage the use of more than one mod manager. Mod managers have a delicate task: instal mods and ensure the right installation order of the files. If 2 mods contains the same file, the one installed last wins, and this is important: some mods MUST be installed in the right order (example: a patch after the patched mod) to ensure the Data folder contains the right/most recent files. With WB you can adjust the installation order at any time, by changing the order of the packages in the Installers tab. But if the mods are installed by more mod managers, how could each one possibly know the order of the other mods? How can they know if a file must not be touched at all? When a mod manager is installing a mod and find another version of the same file in the data folder (installed by someone else: either manually by you or by another mod manager) will force overwrite that file, no matter what, even if that file should reasonably wins and stay. All this is to say: one of the possible reasons your game have problems may be a messed up data folder, due to presence of old/outdated files which should have been replaced by newer ones, but instead "won" simply because the mod managers can't cooperate, and can't communicate each other which files can be replaced. I suggest you choose one mod manager and stick with it. Of the three you use, my choice would be WB, because: - NMM is the most useless of all. You may have plenty of problems simply because some mods require a complex installation procedure or have a complex package and nearly no Oblivion mod have a NMM script to support it. And anyway, no mod requires NMM. If NMM is able to install a mod, all other mods managers are able too. - OBMM is superior to NMM (except the lack of a download/upload manager) as it supports near all mods (and near all mods have an OBMM script, if necessary), but it's a very basic mod manager, and you could use it the first months for learning. - WB is a complete mod manager, superior to the other two, which supports all mods (and doesn't even needs scripts for most of them, as it natively support complex packages. It have tons of useful tools (like the ESSENTIAL Bashed Patch) and can also manage the "installation order" (like I said above, which is completely different from "load order"). It's more complex to use but reward the most.

Normally, this is impossible, as in Oblivion, while sitting or riding, you can't enter the fight stance (raise fists/unsheath weapon) at all. It's an hardcoded limitation you can't remove with a simple esp/esm. Esp/Esm files could only try to emulate the behaviour by playing a custom animations, and someone even tried to do so, but the results were quite bad in my opinion, because that's only an imitation. You're not really in a fight stance and you're not really attacking, but everything just "appear" as a combat stance and attack. A dll instead, can do it. Oblivion Reloaded is an example: (among tons of other changes) it unlocks the ability to unsheat your weapon and fight while riding (you really enter combat stance and attack, they're not simple imitations). I'm not sure if it also works while sitting, but you could try.

For "IsEquippable", you have two commands: - IsPlayable Only return true if the item has the flag playable/equippable, and the flag is checked. - IsPlayable2 As above, but also return true if the item doesn't have the flag at all (if the flag it doesn't appear when you open the object in the editor) What you're asking for, equipment slot, is more complicated. What you need is GetBipedSlotMask, but watch out for the result: the returned values in the bitmask are not the same as the slots. You need to reconvert the values to slots indexes. There are two ways: if refTest ;true if the variable contains a reference (doesn't check it's a valid reference) If IsFormValid refTest ;true if the variable contains a VALID referenceThe second one also include the first, it's a little slower but more secure and it's recommended when you receive the reference from an unknown source and you want to be sure something valid is in there before using it. In your case, since you get the reference from a checked source (the actor's inventory), you can't just use the first one.

When a mod delete a base object from a parent mod, it actually just set a "delete" flag on the object, which tells the game to ignore that object. If you change those objects in your mod then revert the changes, they will still be marked as modified by your mod. This way your mod will override all the changes the other mod made to those objects, including the delete flag, so this should un-delete them. I'm not sure if this applies also to instances places in the world, but you could try.

I may think about two possible causes: 1) I repeat: don't use quotes in the script name: after scn the game expect a simple word for the script name (like a variable name), not a quoted string. Quotes must only be used for creating strings. 2) Don't use scriptname as name of script. ScriptName is a keyword (scn is an abbreviation of this keyword). When the game see scn scriptname it doesn' read: <ScriptName keyword> <name of the script>but this instead: <ScriptName keyword> <ScriptName keyword>So it become crazy, for not finding the name of the script but another keyword in its place. Generally speaking, never use keywords for names (scripts/functions/variables/etc name) in any programming language. Other programming languages would not let you compile the code. CS scripts are a row imitation of a programming language, so it may silently accept the error but crash in game.

You're trying to assign a variable to a command! In other words, you switched the command GetSelf and the variable npctarget. The correct syntax is: Set <variable> to <value> GetSelf is a command which return the reference of the actor where the script is running. In this case, the script run on the target of the spell, so GetSelf return him/her. You should take the reference returned by GetSelf and assign it to npctarget (not the opposite!). Also, spells must not use GameMode. They have their own set of commands like this: http://cs.elderscrolls.com/index.php?title=ScriptEffectStart Refer to the tutorials to learn how to create scripts. You'll find everything you need here: http://cs.elderscrolls.com/index.php?title=Main_Page Here's the correct script, and some suggestions: scn scriptname ;Don't use quotes here. Only use quotes in strings' short npctarget begin ScriptEffectStart ;runs once, when the spell hit and the script effect is applied on the target set npctarget to getself ;call the command getself, get the returned value and store it in npctarget player.moveto npctarget end