Tefnacht

Thank you for your reply. That is pretty much how I ended up doing it. Just that I used sound emitters instead of dragging and dropping sounds directly from the object window. I did some testing to see if there is any difference between those two and I couldn't really find any. My testing was not very thorough though. I assume now that the X size of the sound emitter primitive is indeed used as some kind of multiplier to control the inner and outer 2D sound radius used to attenuate the sound ... but how it works exactly is beyond me. Well, my sounds are audible, loud enough if you're standing close to a klaxon and they carry far enough through the cell before they get too silent. I am quite happy with it.

Hello. Personally, I would keep the StopQuest line but drop the If-statement around the AddItem command altogether. AddSomethingQuest comes with the same mod the Something item comes with, so there is no way the player could already have that item. If the player starts a new game or loads the mod into an existing savegame for the first time, the quest is running, the script is executed after roughly 5 seconds, adds the item and stops the quest. Another job well done. What I have seen in a lot of mods is this approach: ScriptName AddSomethingQuestScript Short doonce Begin GameMode If doonce == 0 Player.AddItem Something 1 Set doonce To 1 EndIf End To me this seems like a waste of resources. Well ... yes ... not a big waste. You'll probably never notice that this quest is now forever running in the background, eating a couple CPU cycles every fife seconds and never doing anything. However: ScriptName AddSomethingQuestScript Begin GameMode Player.AddItem Something 1 StopQuest AddSomethingQuest End achieves the exact same thing. The script is shorter and the quest is stopped. So now the game engine doesn't have to keep track of it anymore or execute the script every fife seconds. Its done. This might seem like nitpicking. But imagine you run a game with 100 mods that all use their own quest to add a item. Then you have 100 quests constantly running in the background that don't do anything except eat away precious CPU cycles. @Nadin: I am really not trying to troll or flame here. Is there a reason why you would want to keep the quest running in this case? If all it does is add that one item?

Hello. Building macabre little piles of naked raider bodies as a landmark is something you can probably forget. Not because there are no nude mods for raiders but because the game engine doesn't support this. You can kill a whole gang of raiders, pile their bodies as a landmark an leave. But after some time passed (usually three ingame days) the engine will remove the bodies and spawn new (living) raiders that you have to shoot dead all over again. This is a necessary game mechanic because without it, after some time playing there wouldn't be any enemies left in the whole wasteland for your to shoot. They would all be dead and lying in piles ... pretty fast you would start to notice how small the gameworld actually is. Therefore new enemies are spawned and the old bodies have to be removed, because otherwise you would end up with a outdoor cell containing 50 or more dead bodies. Sooner or later you would reach the limit of what your computer can render in real time. The poly count would shoot through the roof. Framerates would drop below the bearable limit very fast. Memory usage would climb even beyond the capabilities of modern rigs. Even a dead NPC is still a NPC whose body mesh is made up of rougly 6.000 vertices and 10.000 faces. Those have to be rendered. If you use a good looking body replacer, those numbers get much bigger. My favorite body, Type 3 Berry HD uses 15.445 vertices and 30.671 faces (numbers taken from Blender). A single rendered body of this type requires almost three times the resources of a vanilla body. Of course it also looks ten times better ... but at the end of the day you still have to pay the bill. You just cannot have 30 dead, havoced Type 3 Berry bodies rendered at the same time without the framerate noticeably dropping. Even the most powerful graphics board can only render so many polygons at once. There is a limit. Okay. End of rant :) Back to topic. There are MANY good nude body mods. The “Type 3” I already mentioned is very popular. The link given by GenocideLolita is probably THE most popular type 3 body replacer on the Nexus. Another good one is Exnems Body. However, Exnem and Type 3 are INCOMPATIBLE. They use very different UV maps. Armor and clothing made for Type 3 will have a horribly distorted skin texture when equipped on a Exnem body. And vice versa. There are many other, less popular body mods too, all of them compatible with type 3: Skinny 6, Malos and Naouak to name just a few. So far we only spoke about nude female body mods. Of course there is also an option for nude males: Roberts Male body. There are a lot of options available for these bodies. Type 3 has the most of course, since it is so popular. All of these bodies can be applied to Raiders. Raiders use a different race, so you have to copy/move the replacer files into a different directory. As far as I remember, the Type 3 Readme explains how to do this in great detail. On the topic of prostitution mods: If you can find it on the Nexus, it does NOT contain rape. That is one of the Nexus rules. If it is available on the Nexus, it only contains consensual (sometimes animated) sexual activity. “Animated Prostitution” is 'clean'. There is no violence involved. Either you pay/get paid or you decline and nothing happens. The decision to use such mods is yours alone. Between all the violence, people getting their limbs blown of, blood spraying every which way, intestines flying around ... watching your character perform the reproductive act with both parties involved doing it willingly just cannot be THAT bad. Can it?

Heh. So nobody here is willing to comment on the problem, let alone give a hint? That is very disappointing. :( I decided to go with sound emitters. After trying some other options, this seems to be the way to go. Still, I don't fully understand what I am doing. Placing a sound emitter into a cell, by clicking the “Create a sound emitter” button, causes a 'primitive' to appear. A box primitive. But when I 'draw' it in the render window, it appears more like a line. It behaves different than drawing a cubic activator primitive. Still, if I double click it and edit the reference data, it IS a box primitive. I ended up making them small cubes and placed them to enclose my klaxon activators. I now have six sound emitters being small cubes, one being a persistent reference and the other fife having their enable state parented to the persistent one. To sound the alarm I enable the persistent sound emitter and they all get going: “Meep! Meep! Meep!” When I disable the parent, there is silence again. Very well. I still have many unanswered questions. For example, if I drag and drop the QSTKlaxonB sound from the object window directly into the render window ... I get a green, transparent thing, looking roughly like a speaker. In the cell window, this reference has the same properties like a sound emitter ... but it isn't a primitive. There seems to be a difference between a sound emitter and a sound dragged and dropped directly ... I don't understand why a sound emitter has a primitive attached at all. What is the point? The shape, size and form of the primitive doesn't seem to matter. The sound emits at the primitives root and as you move away, the sound becomes more silent. IS there a difference between a sound emitter and a sound dropped directly into the render window? If there is: does the shape of the emitter primitive have any effect on the sound? Maybe the primitive is just there so you can click on it, move it and edit it. But if that is the case, why doesn't a sound emitter use the same green, transparent speaker mesh for a marker like a dragged & dropped sound does? What's the point? Any ideas? Anyone?

Well, you ARE modding, so the mod talk section isn't exactly the wrong place :) That your mesh isn't visible in the GECK is a problem. Before I get to that, I want to tackle something else. Why do you add your new armor as a “Armor Addon” item? Armor addon items are “special” items, purely visual cosmetic, that get loaded and rendered along with a regular armor item. For example: The gloves of power armor are armor addon items. If the power armor (the real armor) is equipped, the gloves (the armor addon items) replace whatever other item is currently equipped in the hand slots. But they do so only in a “cosmetic” way. They are now rendered INSTEAD of what is really equipped. A armored business suit would be a “real” armor item on its own. At least in my book. Anyway ... lets get to business. No phun intended. ;) I have absolutely no knowledge of 3DS Max or the respective export tools. I am a freeloader, I use Blender and NIFScripts. However, I ran into the “invisible in the GECK” problem myself a couple of times. If you export a mesh as armor from Blender with NIFScripts, you have to select the right settings. I assume the same is true for 3DS Max. We're talking about simple bitflags here. The mesh is good. The UV mapping is good. The bone weighting is good. Everything is good ... except the shader type and flags. Personally, if I failed to set the right export settings, I usually use NifSkope to correct the error. Exporting meshes from Blender sometimes takes a lot of time. Exporting a really complex mesh might take 10 minutes or more. Therefore my advise is: Check your exported NIF file with NifSkope to make sure all the bitflags and options are set up correctly. The primary cause for “invisible” meshes, from my experience, are incorrect or missing shader flags. Using NifSkope, in your NiTriStrips blocks, find the BSShaderPPLightingProperty block. Unless the block describes a “naked skin” part of your armor, the selected shader should be “SHADER_DEFAULT” and the shader flags should be: “SF_ZBUFFER_TEST | SF_SHADOW_MAP | SF_SHADOW_FRUSTUM | SF_EMPTY | SF_UNKNOWN_31”. Check your exported files if they match those settings. If they don't, correct it and try again. It that helps, consult the documentation of your exporter tool to learn how to set these settings on export, so you don't have to use NifSkope every time you export something. If it doesn't help ... well ... I am no expert myself. I just trial&error my way through to my goal. Usually I get there sooner or later ... sometimes I give up. Good luck. And keep us posted if it does or doesn't work.

I am looking for the right way to do this. There seem to be so many different ways ... I am a little lost which one is the intended one for my situation. Here is what I want to do: I have a interior cell with some rooms behind a locked (pickable) door being a restricted area with a guard. One way to solve my quest is to sneak in there. The layout is such that it is possible for the player to sneak into the area without being seen. However, if he is seen (either by the guard on duty or another actor in the area) I want an alarm to sound. I placed a couple of animated klaxon activators in the area that start flashing (and stop flashing) the way I want to. Now I also want a sound to loop while the klaxons are flashing. QSTKlaxonB is the sound of my choice. How would I do this? I suppose a sound emitter which I enable/disable is the way to go? The GECK wiki doesn't have much info on those things though and my dosage of trial&error is already taxed for this week. Or should I use a hidden activator with a looping sound attached and then disable/enable that? Or what is with an acoustic space enclosing the restricted area? Or should I use PlaySound/PlaySound3D commands in my scripts? Or something completey different? The alarm loop sound should be audible within and close to the restricted area. In a perfect world, it should be loudest close to the six klaxon lights. Any tips how to do this? Thanks in advance.

Hello. Let me start with some general information. Object scripts (scripts that are attached to items like your terminal, armors, doors, etc.) will only be executed if the player is in the same cell as the object, otherwise they are dormant and don't do anything. There are a few very specific exceptions to this “rule” but those don't really matter here. ;) Another thing: I noticed your use of GetSelf. This is not necessary and can be very misleading. A script attached to an object, is running ON that object. This means to send commands to this object, there is no reference prefix needed. set rSelf To GetSelf rSelf.Activate Player and Activate Player does the exact same thing. The second version is much simpler and easier to read, don't you think? :D Okay, now to your problem. You don't need a script on the terminal (because it won't be executed most of the time anyway) but the terminal reference itself must be a persistent reference and have a name. After you placed the terminal somewhere into the gameworld, double click on it, check “Persistent Reference” and give it a “Reference Editor ID”. “RemoteTerminalRef” for example. Now to open the terminal, you can use the command “RemoteTerminalRef.Activate Player” from any other script. For example from the script that sets your UsingDB global variable to 1 (thus making the global variable obsolete). If you need the global for some reason, you should use a quest script to monitor it or even a script running on a token item in the players inventory, depending on how fast you want the terminal to respond to setting UsingDB to 1. If you need immediate response, you should use a token item, otherwise a quest (quest scripts use less resources because they are not executed as often). I hope this helps. Have fun.

To present the player with a specific selection of answers, without the game adding generic topics to it (like GOODBYE or other topics containing infos with currently valid conditions) you use the “Choices” box. If the “Choices” box of a info is not empty, then only the topics contained in that box will be shown to the player after the NPC has spoke the info. Of those topics, only those will be visible, that actually have a valid info inside (if no topic inside the “Choices” box has a valid info, the player will get stuck in the conversation). Go to your info that leads to the players choice (where the NPC says something like “Take your pick!”) and add the topics containing the skill checks to the “Choices” box of that info. After the NPC said: “Take your pick!”, only those topics will be available for the player to choose from and nothing else. I hope this helps.

Hello, the problem with GetEquippedObject in a OnEquip block is that when that block is executed, it is already too late to detect the old hat. It has already been replaced. So you would have to go the way Rickerhk suggested and monitor the content of the slot all the time during game and menu mode ... which is, in my humble opinion, not a very elegant way to do it. The script would run all the time and eat up resources. Not much of course, but still. My mantra is to avoid such scripts at all costs whenever possible. Does it have to be a hat? You could change the Biped slot to something more obscure. One of the three BodyAddOn slots, for example. Or the MouthObject slot. Those are usually empty. You could even go so far and select NO slot at all (and remove the NIF model files). The GECK will complain about this and warn you, but it saves and works. The OnEquip block of this armor (without slot) is still executed in the game, if you equip the item. Personally, I would do it completely different. I would use a ingestible, not a armor item to do the teleporting. You can hotkey them, they don't need a Biped slot, and the ingestible tab of the inventory is cluttered up with “crap” anyway. Adding a script effect to an ingestible is not totally straight forward though, so I'll explain it step by step, in case you want to do it this way. If you want to do it with a armor item, you can stop reading now ;) First we need our ingestible. Lets use Buffout as a template. Go to Game Effects → Ingestible and locate Buffout. Give it a new name “SummonSashaPill” and choose Yes to create a new form. Then open our new ingestible with a double click. Change the ingame name from Buffout to “[summon Sasha]” (the brackets will make it show up at the bottom of the inventory), set “Use Sound” to NONE, Addiction Chance to 0, Addiction to NONE, delete the four existing effects and tick the Auto-Calculate Checkbox. Then click OK. The GECK will complain that our pill has no effect, we just ignore this for now, we come back later. Now we create the script. Open the script editor (the pencil icon in the tool bar) and create a new script. Make sure “Script Type” is set to Effect, then copy paste the following short script into the editor and save the new script: ScriptName SummonSashaPillEffectScript Begin ScriptEffectStart SashaREF.MoveTo Player ;move actor to player Player.AddItem SummonSashaPill 1 1 ;silently add a new pill, we used the existing one End The AddItem command will make sure we never run out of summon pills. Doing this during a ScriptEffectStart block will also make sure that the pill is not removed from the hotkey. Now we need to create an Effect with this script. Go to Game Effects → Base Effects, right click into the list and choose New. As ID enter “SummonSashaEffect”, as Name enter “Summon Sasha”, change “Effect Archetype” to Script and in the “Assoc. Item” dropdown menu you select our script “SummonSashaPillEffectScript”. In the Flags field, make sure the “Self” checkbox is checked. Then click OK. Almost done. Go back to Game Effect → Ingestible, locate the SummonSashaPill and open it with a double click. Rightclick into the Result list and choose new to add a new effect. Choose SummonSashaEffect, make sure Range is set to Self and click OK. Done. Click OK again to close the ingestible editor. At this point you might want to write down the Form ID of the new pill we created so you can add it to your character in the game. Now every time you “take” one of these pills, the actor should be teleported to your location and you immediately get a new pill. You can hotkey the pill and it will stay hot-keyed. I hope this, rather lengthy post, helps. Have a nice day.

Greetings, I recently ran into Edmond Dantes problem myself and today I found a solution that works for me. I had created my own special idle animations with blender, had them set up in the GECK to loop indefinitely (by ticking the “Loop Forever” checkbox in the Idle Animations dialog) and when I started the idle with the playidle command I could not stop it again, or even force the actor/player to play a different idle. All subsequent playidle commands were ignored. Bummer. This is how I set up my animations with NifSkope now, so I can start them with playidle xxx and then stop them at any time by calling “playidle xxx” again or by starting another idle animation. I use specialidles, so the name in the “NiControllerSequence” obviously has to begin with “SpecialIdle”. The cycle type must be set to CYCLE_LOOP, the start time and end time must be “correct”. With this I mean start time should be 0 and end time should be how long the animation really is, ie. 2.4 for a 2.4 second animation loop. In the NiTextKeyExtraData array at the very bottom of the tree I have four text keys: The first is simply called “Start” (without quotes of course) and has time set to 0. The second is called “Startloop” and has time set to 0 too. The third is called “Endloop” and has the time set to the actual ending time of the animation. 2.4 for example. The fourth is called “End” and has time set to “<float_max>”. Without the quotes, of course. Yes, you enter this string into the number input field, no joke. This means the animation doesn't actually loop indefinitely, it would stop after roughly 10^38 seconds (that is a couple billion years, so I guess that counts as infinite anyway). From the GECK's point of view, this animation is now defective. You will get a bunch or warnings in the EditorWarnings.txt file saying that xxx should not be a looping animation. Heh, what does the GECK know. It works just fine. When you set up the file in the GECK, “Loop forever” should NOT be checked and Min and Max should be set to 0. I hope this helps. If anyone knows a way to do this without causing the GECK to burp up warnings all the time ... let me know, please :)

Hi, the script you have there is actually only half of the deal. The statue object is created in another script, called MartinScript, which is attached to the “Brother Martin” NPC, who in turn is called MartinRef. I have no idea why Bethesda chose to disperse the statue code all over the place, but they did. MartinRef.playerstatue will be 0, until that script (MartinScript) chooses to actually create the statue. The statue is a dynamic object, that is why you cannot find it anywhere in the construction set. It is created at runtime. Look at MartinScript to learn how its done. Once the statue was created, MartinRef.playerstatue will no longer come back as 0 and the script you posted there will kick in and move it, make it look like stone, etc. pp. Good luck.

Whoever programmed the search engine for this bulletin board needs a severe beating with the NERF-bat. I was searching for: “Let vs Set”. ERROR, ERROR! One or more keywords were below 3 characters... bla, bla, bla. Damnit, I put quotation marks around the search term for a reason! I didn't ask you to search for “Let” OR “vs” OR “Set”. I asked you to search for “Let vs Set”. As one term. Bha! Useless! Anyway ... now that I finally found this thread, back to the topic: --- Personally I usually only use the “Let” command. “Let” is so much more powerful than “Set”. Not only does “Let” support arrays and strings, it also supports many more operators than “Set”. “Let” is superior to “Set” in almost any way. It is true that a compiled script using “Let” will sometimes be bigger than the same script using “Set”. “Let foo := 1” results in a longer compiled bytecode than “Set foo To 1”. BUT “Let foo += 1” results in a shorter bytecode than “Set foo To foo + 1”. AND “Let MyQuest.foo += 1” results in a much shorter bytecode than “Set MyQuest.foo To MyQuest.foo + 1”. In the end, “Let” wins. “Set” should be used only to assign a value to a variable. “Set foo To bar” is better than “Let foo := bar”. If you do math, “Let” is almost always the better choice. Because “Let” is so much more powerful than “Set”, it is of course also a little slower if you benchmark it against “Set”. But if your script causes the game to slow down, it is not because you used “Let” instead of “Set”, it is because your script is crap. :) --- However, there is one big difference between “Let” and “Set” that recently caused me quite a headache. If the “Set” command is used to assign a value to a script variable on a persistent remote reference, the script on that reference will be forced into high processing, no matter if the scripted object is in the players cell or not. The script will be executed once during the next frame, and then go back to “sleep”. This is called “heart-beating” a remote reference. The script on this object can in turn write a value to one of its own local variables, thus causing itself to run again during the next frame. It is “heart-beating” itself. This way a script on a remote persistent reference can keep itself running, even if it is in a different cell than the player. But! This only works with the “Set” command. Writing a value to a persistent remote reference with the “Let” command does NOT cause a heartbeat. The value will be written, but the remote script will NOT be executed during the next frame. “Let” does not cause heartbeats, only “Set” does. Many people probably have no idea what I am talking about ... let's just say “Set” is much more aggressive than “Let”.

If I understand you correctly, the problem you describe indeed has to do with the automatic head tracking Oblivion does. I can think of two solutions for the problem. A fast one with major drawbacks and a more complicated one without. The source of the problem is a “fault” in the animation/pose file itself. A animation file not only holds the information for each bone how to translate, rotate and scale it, in addition it also has a “priority” for each bone (ranging from 1 to 99). If two animations are playing at the same time, the game looks at each bone and uses only the animation data from the file, where that bone has a higher priority. For example: If you are running and swinging your sword at the same time, the leg bones are animated by the “run forward” animation, while the upper body and arms are animated by the “attack with sword” animation. “Run forward” has a high priority for the leg bones but a low priority on the arms, while the “swing the sword” animation has a high priority on the arms and low on the legs. That way the game can “mix” multiple animations together with good looking results, as long as the bone priorities are set up correctly when the animations were created. The head tracking is a kind of special animation (there are no files for it) that Oblivion creates “on the fly”. Like any other animation, this one too has a priority. And a pretty high one at that. I think its 75 or 80). This means head tracking will override almost any other animation when it comes to the head. The simple solution is to just globally disable head tracking. In the Oblivion.INI file, find the line that sais “bDisableHeadTracking=0” and set it to 1. The downside is that now all actors (and the player) will always stare straight ahead. They will turn their whole body towards other actors if necessary but not adjust their head and shoulders anymore. For screenshots this might be good enough. But if you want to play the game, this isn't really a good solution. The complex solution requires editing of the pose/animation file in question to adjust the bone priority for “Neck”, “Neck1” and “Head” bones to something very high (higher than automatic head tracking). 99 for example. This can be done either with Blender or NifSkope. Blender is difficult to setup properly but the editing itself is fast and easy, NifSkope on the other hand is very easy to use, but you have to manually sift through the file, identify the correct bones and adjust their priority one by one. I cannot explain here how to do it with Blender (the post is long enough already) but I can give instructions for NifSkope. -Find the animation (.KF) file in question and open it with NifSkope. -In the upper left list, click on “NiControllerSequence”. The content of the bottom list will change. -In the bottom list, extend the “Controlled Blocks” tree by clicking on the + besides it. -Find the “Controlled Blocks” branch with the value “Bip01 Neck” and extend it. -Find the key named “Priority” and change its value to 99. -Do the same for the branches “Bip01 Neck1” and “Bip01 Head”. -Save the file. Now the edited pose/animation should override the head tracking (and everything else trying to manipulate the head bones) while it is playing. Good luck.

How about using the leveled list to add a token item to the actor, which in turn is scripted to spawn the whole armor set associated with the token? You would have one token for the light armor set and one token for the heavy armor set (and more tokens for other sets you want to spawn). The leveled lists chooses one (and only one!) of these tokens at random when the actor is (re)spawned. Then the script on the token would add the actual armor items, equip them on the actor and finally remove itself again. A token is a “clothing” item, without biped model, set to go into the “tail” slot, with the “playable” checkbox unchecked (this will prevent actors from equipping it and the player from looting it by accident). You would need one script (and one token) for each armor set. Here is a example for a script that adds and equips a whole set of steel armor. You would need other scripts (and tokens in the leveled list) for Fur, Glass, Elven, etc. ScriptName SteelArmorTokenScript Short done ;set to 1 once all armor items have been added Ref actor ;reference to the actor we are equipping with armor Begin GameMode If (done) ;if all items have been added actor.EquipItem SteelBoots ;|equip them on the actor actor.EquipItem SteelCuirass ;| actor.EquipItem SteelGauntlets ;| actor.EquipItem SteelGreaves ;| actor.EquipItem SteelHelmet ;| actor.EquipItem SteelShield ;/ RemoveMe ;remove this token (also stops the script) EndIf Set actor To GetContainer ;get reference to actor the token was added to If (actor) ;if a reference was returned actor.AddItem SteelBoots 1 ;|add a full steel armor set to the actor actor.AddItem SteelCuirass 1 ;| actor.AddItem SteelGauntlets 1 ;| actor.AddItem SteelGreaves 1 ;| actor.AddItem SteelHelmet 1 ;| actor.AddItem SteelShield 1 ;/ Set done To 1 ;all items added, equip them next frame EndIf End I am not sure if this is the most elegant way to do it, but I've tested it and it works. The script is running not on the base NPC, but on the spawned child. So there should be no danger of ending up with a NPC with all kinds of armor sets, once he respawned a couple of times (each new child starts with a empty inventory). Maybe this helps you.

Wrong. Well, not completely wrong, but still... Oblivion.ESM is always index 0, not 255. However, index 255 (FFxxxxxx) is reserved for dynamic objects the Oblivion engine creates “on the fly”. Like custom spells, custom enchanted items, items dropped into the gameworld by the player, stuff like that. This leaves index 1 to 254 (both inclusive) for mod files. So yes, you can have a maximum of 254 ESM/ESP files loaded at any given time, but not because Oblivion.ESM is indexed as 255 (FF). Telling people that Oblivion.ESM is indexed as 255 (FF) is dangerous misinformation. Actually, index 255 should be seen as the savegame you load, because that is where all the information about the FFxxxxxx items comes from. No offense intended. I just want to clarify things. And on topic: I also want to put out a general “Thank you” to all the people that “waste” their free time to make Oblivion a better game. To those who write tools that help with modding, like the OBSE crew, the author of TES4Edit, the NifScripts crew and each and every single modder out there. It is YOU who keep this game alive for the rest of us. Never forget that. I humbly thank you.

The quest controlling that kind of dialog is called: “Generic”. The lines you are looking for are part of the special HELLO topic, found in the “Conversation” tab of that quest. That topic handles a lot of other “generic” things too, therefore I advise extreme caution when modding it.

I suppose you're a Linux user at heart? Not to play Oblivion, but maybe at work? Windows does not differentiate uppercase and lowercase letters when it comes to folder and filenames. For Windows, “CHARACTERS”, “characters”, “Characters” and “CHarACteRS” is the exact same thing. If the mod archive you download has files to place into “.\Data\Meshes\Characters\” but on your harddisk you only have a “.\data\meshes\characters\” folder... the files from the archive are absolutely destined to go into your existing folder, no matter the upper\lowercase spelling difference. Windows does not differentiate that way. You can prove this to yourself very easily. Go to your Oblivion directory and look at the name of your data directory. It will probably be called “data”. Now create a new folder and try to name it “Data”. Windows will reject that name, because a folder with that name already exists. Some compression utilities (like 7zip) care for upper\lowercase folder and filenames. Because they originate from the Linux platform or are designed to be compatible with those platforms. If you manually sort where your files have to go on your Windows system, always imagine everything spelled in lowercase. Source and target alike. That is how Windows does it. If some mods conflict with each other... it is ABSOLUTELY not because one filename was uppercase while the other one was the same, but lowercase. Windows filenames are NOT case sensitive, ever. The operating system itself does not support that.

I was unable to find the mod made by Duke Patrik that VileTouch referred me to, so instead I just concentrated on testing my solution. I have now been using this script for a couple of days of intense marksmanship and it seems to work well. I couldn't find any problems with it. There is another “wrong amount of arrows rendered in the quiver”-glitch when the game was restarted and a savegame is loaded that was made with the arrows equipped, but that is a vanilla Oblivion problem (that I never noticed before). In this case the quiver always looks completely full, even if there should be just one arrow in it. But that is Oblivions fault, it happens without my script too. Also, the quiver rendering is not updated if you loot arrows of the type you have equipped from a actors inventory or a container. Again, this is a vanilla bug. Both are only visual and so rare, I decided not to try scripting a workaround. The bloating problem exists, however. But it is not “persistent” bloating, as far as I can tell. The savegame bloats the same way it does when a normal arrow is shot into the gameworld. After three ingame days, when a cell reset occurs, the garbage is cleared. So I think, my last solution, dropping all but one arrow into the gameworld, equipping the remaining arrow, then searching and picking up the dropped stack again is the best working way to do this. The bloating is negligible and not permanent. There are many vanilla Oblivion actions that cause much worse savegame bloat. This method should be save to use. With this conclusion, I consider my problem solved. Thanks again to those who posted comments. I do not claim credit for the method or the script itself, feel free to use it (or parts of it) if you need to equip arrows on the player within your own mods. Have fun.

I have no idea. I just copy&pasted the scripts I posted into a new plugin, created a new quest and soulgem with the names my posted scripts use and...it works. I even double checked that I did not use any OBSE commands by accident. I didn't. Everything is vanilla script. Those scripts should work. Make sure you test your mods with a “clean” savegame. If you created a mod containing a quest, started the game with that mod loaded, then created a savegame, exited the game, edited the quest in the mod and then restart the game and load that savegame again... you enter a world of potential pain, suffering and malice. Depending on what you edited in the quest, it can work... or not work... or cause a CTD (crash to desktop). If you make a mistake the Construction Set didn't recognize (or your editing caused a unexpected game-state), Oblivion will normally stop processing the script with the mistake in it. If you make or cause a BIG mistake, Oblivion will CTD before it even had a chance to notice that there is something amiss. Since your game didn't CTD, it is probably a minor issue. Try again with a savegame created BEFORE you added your mod to the load list. Other than that, I really have no idea. Need. More. Input. If worse comes to worse, you can always resort to shotgun-debugging: If you are not sure if a script is run, or if a script reaches a certain If-EndIf block, put a MessageBox command in there. If you start the game and the message box does not pop in your face, you know for sure the script itself is not running. If you use OBSE, use PrintToConsole instead. It is less intrusive and doesn't prevent you from gracefully exiting the game in case your messagebox command is called inside a infinite loop.

1. You don't need to create a key for the door at all if you only want to restrict the time when it can be opened. All you need is a script for the door that does its “magic” within a OnActivate block. A scripted object with a OnActivate block will NOT execute its default action when it is activated, unless the script itself uses the Activate command. So a scripted door will not open, unless the script specifically tells it to. The command to get the current ingame time is GetCurrentTime (Beware, the returned time is in 24 hour decimal format!). A script for a door that can only be opened between 1:43 pm and 2:00 pm would look like this: ScriptName TEFDemoTimedDoorScript Begin OnActivate If (GetCurrentTime >= 13.7166) && (GetCurrentTime <= 14) ;if the time window matches Activate ;open the door Else ;otherwise give feedback MessageBox “This door only opens between 1:43 pm and 2:00 pm. Come back later.” EndIf End 2. While Dysheins solution should work, I find it overly complicated. No offense. Just enable the door from a OnEquip block of a scripted scroll/book. For this to work, the door has to be a persistent reference, so we can “access” it with a script running on a different object (the scroll). Find the door in the render window, double click it, make sure “Persistent Reference” is ticked (on a load door it will be ticked already and grayed out, load doors are always persistent), enter a unique “Reference Editor ID” and then tick “Initially Disabled”. This will make the door invisible when the game starts until we enable it later. Lets assume you gave the door the ID “TEFDemoDoor”. The script on the scroll would look like this: ScriptName TEFDemoScrollScript Begin OnEquip Player TEFDemoDoor.Enable ;make the door visible and usable End The OnEquip block of scrolls and books is run when the scroll/book is read. This means the door reference will be enabled every single time the player reads the scroll/book, but that doesn't matter. If it was already enabled, enabling it again doesn't do anything bad. 4. The behavior of Azura's Star seems to be hardcoded into the game, there is no “simple” way to duplicate its effects. To my knowledge, there is no script block that gets executed when a soul gem is used on a enchanting altar either. I just did some tinkering and couldn't find any. I managed to duplicated the effect with a quest script and a item script though. It would require some more polishing I guess, I am not sure that it is water-proof. There might be some situations where a new gem is added although the old one wasn't really used. Here are the scripts I punched together. They assume that the re-usable soul gem is called “TEFSoulGem”, and the quest “TEFSoulDemoQuest”. The quest needs to have “Start game enabled” ticked. If you use different names, make sure to change them in the scripts too. The object script for the re-usable soul gem: ScriptName TEFSoulGemDemoScript Begin OnDrop ;if the gem is dropped Set TEFSoulDemoQuest.checkforgem To 0 ;we do not need to check for it anymore End Begin MenuMode 1042 ;if we are in the enchantment menu If (Player.GetItemCount TEFSoulGem > 0) ;if the player has the re-usable soul gem in his inventory Set TEFSoulDemoQuest.checkforgem To 1 ;set the quest variable to check if the gem is still there afterwards EndIf End The quest script: ScriptName TEFSoulDemoQuestScript short checkforgem ;set to 1 if the player has the reusable soul gem and used a enchanting altar Begin GameMode ;in game mode If (checkforgem) ;if we should check for the gem If (Player.GetItemCount TEFSoulGem == 0) ;if the gem is gone (was used) Player.AddItem TEFSoulGem 1 ;add a new (empty) one EndIf Set checkforgem To 0 ;we do not need to check again EndIf End Maybe this helps, even if it is a huge wall of text. Shadow hide you.

Thanks a lot for the tip, VileTouch. I'll go take a look at that mod right away. This is really driving me crazy (laughs) and not the good kind of crazy. Yesterday I found a “almost free lunch” solution after hours of trying, thinking and more trying. It seems to work well, the ammo counter is correct, there is just one stack, rendering of the quiver is right, but it requires dropping of one item into the gameworld every time the script has to equip more than one arrow... which, from my understanding, will lead to savegame bloating, very slow bloating, but bloating nonetheless. So... not quite a “free” lunch, but at least a cheap one. Here is my newest solution. Its not fully tested yet, but besides the bloating problem (which might not even exist, no idea, need more testing) it looks promising. This time, instead of removing the arrows and then adding them back, all but one arrow get dropped as a stack into the gameworld, then the one remaining arrow is equipped, and then the script scans through the cell the player is in until it finds the stack we dropped, and picks it up again. All in one frame, so the player will not notice any of the jazz that is going on behind his back. It looks great from third person view. Again, this comes after the Loop in the LYDIAChooseArrow script: If (arrowref) ;if we found a "best" arrow Set i To Player.GetItemCount arrowref ;get amount of arrows in the players inventory If (i > 1) ;if there is more than one Set i To i - 1 ;calculate how many more than one Player.Drop arrowref i ;drop all but one arrow as a stack into the gameworld Else ;otherwise we have only one arrow Set i To 0 ;and did not have to drop any EndIf Player.EquipItemNS arrowref ;equip the single arrow If (i) ;if we dropped arrows into the gameworld Set itemref To GetFirstRef 34 1 ;start scanning the current call for ammo (and 8 adjacent cells, in case we are standing on a cell border) While (itemref) ;as long as we find ammo references If (itemref.GetBaseObject == arrowref) && (itemref.GetRefCount == i) ;if the reference is a child of our arrow base and a stack of matching size itemref.Activate Player ;make the player pick up the stack Set itemref To 0 ;set itemref to 0 to leave the loop, we have found what we were looking for Else ;otherwise it is some other arrow Set itemref To GetNextRef ;scan for next ammo reference EndIf Loop EndIf EndIf SetFunctionValue arrowref ;return what we found All that just to equip some damned arrows (laughs). Hopefully Duke Patrick found a better solution...

I think I found a solution for equipping all the arrows. I had to, or shelf the whole idea, because I noticed a serious issues with the two stacks of the same arrow type in the inventory. Imagine this scenario: One arrow got equipped by the script, 19 more are in the second, not equipped stack. I shoot the arrow, but it bounces off a wall. Another arrow gets equipped, 18 are now in the second stack. If I now pick up the arrow I fired first, it is added to the already equipped arrow, so now I have a stack of two arrows equipped and 18 in the second stack. If I shoot now... the equipped stack of two is correctly reduced to one, but the second stack of 18 goes poof and vanishes. After a short dungeon crawl I was wondering where all my hundred daedric arrows went... heh. The trick seems to be to remove all but one arrow of the stack from the player inventory, then equip that single arrow and then add back all the previously removed arrows. Since we're not really adding or removing items, just adding and subtracting from a stack, there seems to be no problem with doing this in a single frame. This is how I modified my LYDIAChooseArrow script. This stuff comes after the Loop: If (arrowref) ;if we found a "best" arrow Set i To Player.GetItemCount arrowref ;get amount of arrows in inventory If (i > 1) ;if there is more than one Set i To i - 1 ;calculate how many more than one Player.RemoveItemNS arrowref i ;and remove all but one Else ;otherwise there is just one Set i To 0 ;we did not have to remove any EndIf Player.EquipItemNS arrowref ;equip the one remaining arrow If (i) ;if we removed arrows Player.AddItemNS arrowref i ;add them back to the player EndIf EndIf SetFunctionValue arrowref ;return what we found Of course, there is no free lunch. While the whole stack of arrows now gets equipped correctly (and the ammo counter works again) the amount of arrows rendered in the quiver is now wrong. There is always only one single arrow rendered in the quiver. Picking up another arrow corrects this though and it is really only a “cosmetic” problem. But it is still not a perfect solution.

Hello. I have the following “problems” with a weapon script, maybe someone here knows a way around it. My character is a sneak, using primarily bows. After some time I got really tired of all the mini-stacks of two to five arrows of different flavor piling up in my inventory. Its a real hassle to switch back to the inventory every few odd shots to equip new arrows. I finally got so sick of it, that I decided to automate this somehow. I wrote a script attached to “my” bow, that would walk through my inventory, look for arrows, choose the “best” one (enchanted with highest damage if available or just highest damage) and equip them. I have it working pretty well, but it doesn't really satisfy me yet. My first problem: I did not find a CPU-friendly way to execute the script when the bow is fired. Currently I check the quiver slot each and every frame in a GameMode block while the bow is equipped. If the slot is empty, the script will search the best arrow and equip it. I did not notice any rendering slowdown but my computer is a power horse. There must be a better, less “expensive” way to do this? Something more elegant? My second problem: The script will only equip one single arrow (using EquipItemNS), not the whole stack. If I have 20 silver arrows, one will get equipped (and shown as equipped in the inventory screen), the remaining 19 get separated into a second stack. No big deal, really, but this means the ammunition counter in the GUI always shows 1. Of course, with the auto arrow equip, the ammo counter is now pretty useless anyway. But... I play mostly in third person. Since there is technically only one arrow equipped, the quiver on my characters back will disappear when the arrow is used. Of course the auto equip immediately kicks in and equips the next arrow, but for one render frame the quiver is gone. It “flickers” after every shot, if you will. This looks... a bit odd. Funny enough: The amount of arrows rendered in the quiver is always correct. If I have three silver arrows left, there will be three arrows visible in the quiver, although the ammo counter still reads 1. Odd, huh? Is there any way around this? Some trick to equip the whole stack of arrows? For reference, here are the scripts I wrote. OBSE 18 is required. This is the script attached to my bow: ScriptName LYDIABowScript ;******************************************************************************* ; LYDIABowScript (Object script) ;******************************************************************************* ; This script is attatched to the bow and will automagically equip the ; "best" arrow from the player inventory. Short worn ;set to 1 while the bow is equipped Ref arrowref ;reference to the currently equipped arrow Begin OnUnEquip Player Set worn To 0 ;the bow is no longer worn by the player If (arrowref) ;if the player has an arrow equipped Player.UnEquipItemNS arrowref ;unequip the arrow EndIf Set arrowref To 0 ;no arrow equipped anymore End Begin OnEquip Player Set worn To 1 ;the bow is now being worn by the player Set arrowref To Call LYDIAChooseArrow ;choose and equip best arrow from player inventory End Begin GameMode If (worn) ;if the player is wearing the bow If (Player.GetEquippedObject 17 == 0) ;if the player has no item in the quiver slot Set arrowref To Call LYDIAChooseArrow ;choose and equip best arrow from player inventory EndIf EndIf End And this is the OBSE user function script called by the bow script: ScriptName LYDIAChooseArrow ;******************************************************************************* ; LYDIAChooseArrow (User function) ;******************************************************************************* ; This function will choose the best arrow from the player inventory, ; equip it and return a reference to the arrow, or 0 if no arrow was found. ; "Best arrow" means the arrow with the highest damage. If magical ; arrows are available, those will be chosen over mundane arrows, even ; if their damage is lower. Long i ;index counter variable Long j ;total number of inventory objects Long damage ;best found damage so far Ref arrowref ;reference to best arrow so far Ref itemref ;reference of inventory object currently being checked Short ismagic ;set to 1 if a magic arrow was found Long d ;variable with current arrows damage Begin Function {} Set i To 0 ;start with first inventory object Set j To Player.GetNumItems ;get total number of unique inventory objects Set damage To 0 ;best damage found so far is 0 Set arrowref To 0 ;no "best arrow" reference found so far Set ismagic To 0 ;no magical arrows found While (i < j) ;loop over all inventory objects Set itemref To Player.GetInventoryObject i ;get reference to the inventory object If (IsAmmo itemref) ;if this is an arrow Set d To GetAttackDamage itemref ;get that arrows damage If (GetEnchantment itemref) ;if the arrow has a enchantment If (ismagic == 0) ;if this is the first magical arrow we found Set damage To d ;it does best damage (override any mundane arrow) Set arrowref To itemref ;it is the best arrow Set ismagic To 1 ;now we found a magical arrow Else ;otherwise we already found a magical arrow If (d > damage) ;if it does better damage than our current "best" arrow Set damage To d ;it is the new best damage Set arrowref To itemref ;and the new best arrow EndIf EndIf Else ;otherwise the arrow is not enchanted If (d > damage) && (ismagic == 0) ;if it does better damage and we have not found a magical arrow Set damage To d ;this becomes best damage Set arrowref To itemref ;and the arrow is now "best" arrow EndIf EndIf EndIf Set i To i + 1 ;increment to next inventory object Loop If (arrowref) ;if we found a "best" arrow Player.EquipItemNS arrowref ;equip it EndIf SetFunctionValue arrowref ;return what we found End Any help or comment would be appreciated. Thank you in advance.