QQuix

No. SetPos and SetAngle are absolute values. In this case, it sets the angle to 90 every time.

Puzzling, as the code seems OK to me. Some comments... One thing I deduced along the years is that the engine has a 'Script' phase, a 'Physics' and a 'Rendering' phase, one after the other in each frame. This accounts for the difference between the script position and the visual position: (1) you position the actor in the script phase, (2) in the physics phase the engine applies the gravity pull and moves the actor down and (3) in the rendering phase the actor is rendered in this new position. I remember my first attempts tries with flying actors where I kept them in the air with SetPos and the result was a heavy flickering up and down. ([EDIT] Maybe SetVelocity would solve the visuals, but it did not exist at the time.) In my esp, I used a dog scaled down to the size of a flea, so I could not really see it to notice any movement. Also, during the script phase there is no physics involved, so you may use SetPos just once before the loop, I don't think so. As mentioned above, by the time the engine renders the creature, the GetLOS computation has long been done. I do not remember if setting angleX forces the actor to move the head. Maybe it doesn't. The "Look" function certainly does. Yes, maybe. But I suppose you have tried with the player looking down, which would solve the problem (if this was the problem). The Wiki says that the field of view for GetLOS is 95 degrees. The only practical suggestion I have is that you place the source creature a little below the player Z position. Maybe the player himself is considered in the way. For debugging purpose, you might keep the loop running always 10 times and printing the results each time. Something like this: Label 2 if posZsrc - posZtrg <= 2000 PrintToConsole "LOS source Z: %.2f" posZsrc DragonDistanceTarget.SetPos X posXtrg DragonDistanceTarget.SetPos Y posYtrg DragonDistanceTarget.SetPos Z posZtrg PrintToConsole "LOS target Z: %.2f" posZtrg let losdistance := posZtrg - posZsrc let losdistance := Abs losdistance if DragonDistanceSource.GetLOS DragonDistanceTarget PrintToConsole "source sees target at distance: %.4f" losdistance else PrintToConsole "source does not see target at distance: %.4f" losdistance endif let posZtrg -= 200 Goto 2 endif

I checked the code in my files and I do not see some things I do remember, like the two actors I mentioned. My code will not help much, as it is pre-OBSE (still uses SaveIP and GoTo as loop control). I probably exercised GetLOS further some other time later. The nice thing about GetLOS is that you can move the target and check its visibility several times in the same frame. But it has a limit. If memory serves, after around 20 times, it starts to return erratic results. I clearly remember implementing some control to limit the number of loops per frame to avoid this glitch, interrupting the probing and continuing in the next frame(s). Another thing I remember is that Oblivion ground is at different depths, depending on the detection method. For collision, it is where it seems to be, but for visibility it is about one foot deeper, as can be noticed in the video when targeting the ground.

I once had this problem and used GetLOS to detect the distance, with pretty good results (Youtube video) (code). If memory serves, I used two micro actors, actor A near the player and actor B positioned at a distance and checked if A can see B. The nice thing about it is that you don't need to position actor B gradatively farther. You can start from a random distance (previous distance would be a good start) and move it farther or closer as necessary and quickly find the distance with a few successive approximations. Again, if memory serves, using GetLOS from the player does not work well in third person view, so I used actor A near the player. I used actors because I read somewhere that GetLOS is not CPU efficient with inanimate objects. Once more, if memory serves, there is a maximum distance beyond which GetLOS will always return false.

The engine keeps most references where they were when you last saved the game. Some references snap back to their original CS position at Cell Reset. The initial paragraphs of the Cell Reset WIKI article give you some detail of the process. Also, check Drake's comments here.

[had to leave the PC while composing the message and did not notice you had already solved it. Glad it helped a bit.]

Long ago I wanted that and got these instructions from TomBrightblade. If memory serves, It worked flawlessly. ----------------------------------Item to Static 1---------------------------------- If it is really a static apple that you want, I mean, a static like a wall, you can do the following: - go for NifSkope 1.0.16 and load apple NIF file - in Block List expand all nodes - search for: 4 bhkRigidBody and left click on it - press F3 or go to menu View -> Block Details - - - in Block Details search for "Motion System" and change it to MO_SYS_FIXED - - - in Block Details search for "Quality Type" and change it to MO_QUAL_FIXED (not necessary) in Block Details search for "Layer" and change it OL_STATIC (not necessary) in Block Details search for "Layer Copy" and change it to OL_STATIC save the NIF file in Oblivion\Data\meshes\your_mod_name (or sth like that) and close the NifSkope open CS, load your plugin, make a new Static and as a model choose the NIF file that was just created in NifSkope "Not necessary" steps are only for a proper color of a layer, that can be seen in CS and in game, when you toggle collision geometry. Now you should have a static apple. -TomBrightblade ======================================================= Also found this on my Oblivion notes (not what you asked, but may help someone) ----------------------------------Item to Static 2---------------------------------- QUOTE (kandiedan @ Sep 26 2009, 11:50 PM) I want to make some activators based on armor/items that can not be moved. What is the easiest way to do this? Do I need to remove the havok information from the nif (and how do I do that in nifscope)?-dan Its fairly simple to do. Open the item up in nifscope, switch on the View, Block Details option in the Menu. Then highlight the bhkRigidBody section in the Block list. Then under Block details find Inertia and change all those values to 0, and Mass to 0 as well. That will remove all havok.Then you can use this altered mesh as a container item or an activator or just an immovable static, whichever suits your purpose.-Iliana

As far as I remember from tests I did long ago, it seems Fast Travel calculates the travel time using the shorter path grid route to the destination. E.g. If you add a door in Anvil connected to a door in the imperial city, and use Fast Travel (not the door) you will arrive about the same time as you left the previous position. Remove the door and Fast travel will take the normal time. I have no idea how the game reacts if there is no grid connection at all.

The answer requires some clarifications: All variable in your script are 4 bytes long. All are saved in the savegame, whether they contain a meaninfull value, zero or some garbage. Some, like ints and floats, contains the value (number) itself (e.g. a conter may contain 0,1,2,3...) Setting them to zero does not reduce savegame size. A string_var contains a pointer to the actual string stored elsewhere in memory. sv_destruct tells the engine (OBSE, in this case) that you dont need that string anymore, therefore the engine will free the memory and will not save that string in the savegame. The 4-byte string_var itself will be saved. An array_var also contains a pointer to the actual array stored elsewhere in memory, but it has a more elaborated internal engine. Arrays are designed/optimized to be used by multiple scripts. In other words, multiple scripts my have string_vars pointing to the same array. It would not be wise for a script to destroy an array, since other scripts may still need it, so there is no ar_destruct. Instead, OBSE keeps track of how may array_vars are pointing to the array. When the count reaches zero, the array data is automatically 'destructed' (memory freed, no savegame space). "let myArray := ..." adds to that count. "let myArray := ar_null" reduces the count. Ref vars contains the FormID of the reference. Like other vars, this 4-byte var is saved in the savegame, whether it contains a FormID or zero. As you see, regarding savegame space, you only have to worry about strings and arrays. Zeroing the other types is pretty much a matter of coding style. (btw, savegame bloating caused by irresponsible use of PlaceAtMe ia a completey different matter).

For the sake of completeness ... Yes, Oblivion also has no way of changing the day of the week. But there is a function (not really sure which . . . maybe SetPCSleepHours.) that, instead of jumping to a new date, makes the game run faster (a day goes by in a few seconds, sun/stars rush thru the sky and such). I suppose it advances the day of the week correctly.

Oblivion has two sets of special variables to keep track of time: (1) GemeDaysPassed and (2) GameYear/Month/Day/Hour. Changing one does not automatically change the other. Maybe the mod in question is changing only one of them.

IsInCombat

Check the script on vanilla lamp posts. It turns the light on and off at a certain times of the day. Add the GetDayOfWeek function to restrict it to Saturdays. To avoid adding the script to all objects, choose one as the parent and make it the parent of all others using the Enable Parent Tab. This way you only need to add the script to the parent and all the others will Enable/Disable with it..

When you say it happens when you 'cross this point in time', i understand it means a certain time on a certain date. For debugging, it may help (or not) to know the values of the other time global variables at that point (GameDay, GameMonth, GameYear and GameDaysPassed)

According to the Wiki and this StackOverflow reply, "-1.#IND" means 'indeterminate' / 'NaN - Not a Number' and is used when a math operation returns a value that is not a real-number (like a square root of a negative number). Which leads to the conclusion that either the vanilla fast travel or some mod has a bug with that scenario. I suppose a console command "Set Gamehour to 1" should return the game to normal.

If you are talking about Oblivion, you may take a look into my conceptual mod "The Collector". It kind of does that (without the NPCs).

For the record, I have never had any problems with email notifications in the last 10 years. I have not changed my settings in years. (Just checked and noticed that today I completed exactly 10 years with the Nexus. Yay!!)

Yes, all scripts run when the player enters the cell containing the creature (assuming it is an internal cell) Yes, all creatures in a cell load on the same frame. The bottom line is that you project depends on whether the function always returns the same value in the same frame. I suggest you check it with something like this short rval1 short rval2 set rval1 to Getrandompercent set rval2 to Getrandompercent Message "rval1: %.0f rval2: %.0f " rval1 rval2

There is a DeleteReference, but it is OBSE.

Getrandompercent returns only integers, therefore the smallest percentage you can consider is 1% (like if shinyvalue = 99) But you could use a second roll if shinyvalue = 99 if shinyvalue >66 <this code would run 1/300 times> (Although this would not work if the function returns the same value in the same frame) Rand returns floating point number, but, as you noted, requires OBSE.

Something like this should work: short rnd set rnd to Getrandompercent if shinyvalue >= 75 Disable(); PlaceAtMe "ShinyMudCrab" 1 0 0; endIfBased on the note in the Wiki page, It may be possible that this function returns the same number number on all calls in the same frame (not sure and I don't have Oblivion installed to check it), but it, certainly, should return a random number over multiple frames.

Ckeck Rand and GetRandomPercent in the WIKI. Note the comment in the Rand page alerting to the fact that it returns a float with with quite a few decimal places.

Not related. AI processing occurs to all Actors in high-processing, no matter if it is in front, behind, above or below the player (or visible/faded, for that matter). Fading saves rendering processing time, if the actor is in front of the Player (I suppose... not really my area).

Related to the first question, check Script Processing. It explains when Actor AIs are processed, which may be the main reason to the FPS drop when more than 12-15 actors are around.

I once played a litle with a similar idea. Check QQuix Oblivion Test Environment - GetLOS (Youtube) The code is in QQuix Test Environments (Nexus) At the time (2008-2009) somebody created a flashlight mod using (and probably improving) my code. I can't find it. I did find a more recent one: :Bettys Flashlights ( which may use some other concept)