Difference between revisions of "Talk:Script Processing"
imported>Haama (→Problem with specific assertions: Some answers) |
imported>QQuix (Asking for more details on processing levels) |
||
(7 intermediate revisions by 3 users not shown) | |||
Line 67: | Line 67: | ||
:::--[[User:Haama|Haama]] 11:27, 12 November 2007 (EST) | :::--[[User:Haama|Haama]] 11:27, 12 November 2007 (EST) | ||
::::Actually, I want it to verify the contents of the container at the very moment I leave its menumode (after putting or getting stuff out of it). That's why I was considering using its menumode block, for setting a flag that would then trigger a Gamemode code block. However, maybe that this is redundant : when in menumode, does the gamemode code continues to execute, or does it stop until menumode is left? Is there a more efficient way to render the desired behaviour? Regards, --[[User:HawkFest|HawkFest]] 15:33, 12 November 2007 (EST) | |||
:::::Assuming it's a normal container: | |||
<pre>begin onActivate | |||
if (IsActionRef player) | |||
set CheckContainer to 1 | |||
Activate | |||
endif | |||
end | |||
begin GameMode | |||
if CheckContainer | |||
set CheckContainer to 0 | |||
;check contents | |||
endif | |||
end</pre> | |||
:::::That way, the contents will only be examined when your container is opened, instead of any container. You could also add "buttons" to the container that, when the player selects them, do the proper processing. Those are a bit harder and require OBSE, though. | |||
:::::--[[User:Haama|Haama]] 16:49, 12 November 2007 (EST) | |||
::::::I am actually doing this, but what I really want to do is the following : after having added/removed items or checked chest's inventory, i.e. right at the moment I leave its inventory menu, that's when I'd like the verification process to start. I want to check whether or not a specific item is inside the container AFTER having played in its inventory, NOT during nor before, after. Regards, --[[User:HawkFest|HawkFest]] 15:57, 13 November 2007 (EST) | |||
[moving back to edge]<br> | |||
Sorry, I misspoke earlier. The code I gave will do exactly that - when the container is closed the items will be checked. When I said "the contents will only be examined when your container is opened, instead of any container" I'd meant to put the emphasis on 'your container' rather than when it's opened. Should've been "the contents will only be examined when your container has been opened and closed, instead of any container". | |||
To answer a question in the other block - GameMode and MenuMode blocks are mutually exclusive. MenuMode runs whenever it's not GameMode, and vice versa for GameMode. | |||
--[[User:Haama|Haama]] 17:51, 13 November 2007 (EST) | |||
== Remote Ref Heartbeat == | |||
For non-dynamic activators (activators placed in the CS) I could not find much difference between persistent and non-persistent. In both cases, after triggered by an Activate function, the process started running and, most of the times, continued running after the player moved from place to place. A few times the process stopped and had to be re-triggered. | |||
Dynamic activators (activators created with PlaceAtMe), most of the times, stopped running after the player moved from place to place and the process had to be re-triggered when possible, i.e., when the ref to the activator was valid, i.e., while the activator's cell remained loaded. | |||
[[User:QQuix|QQuix]] 00:09, 11 March 2009 (EDT) | |||
== Processing levels == | |||
From what I can remember from reading the WIKI and forum posts, there are four processing levels for actors. | |||
Does anyone have any additional info to share? Or links to other articles, maybe? | |||
:1. High level processing - actors in the same cell as the player (and the surrounding cells, if in exterior) | |||
::*scripts and AI process every frame. | |||
:2. Mid level processing - actors in cells the players visited recently and are still loaded | |||
::*no info on how frequently these scripts and AI run. | |||
:3. Low level processing - persistent actors in unloaded cells | |||
::*scripts and AI run every 15 game minutes / 30 real seconds (at standard settings) | |||
:4. No low level processing - non-persistent actors in unloaded cells (actors get unloaded with the cell) and persistent actors with the "No low level processing" flag on, in unloaded cells. | |||
::*scripts and AI don't run at all. | |||
[[User:QQuix|QQuix]] 17:55, 14 October 2010 (EDT) |
Latest revision as of 16:55, 14 October 2010
Good job here. There are at least two other timing effects I'm pretty sure I'm seeing. Firstly when you first AddItem to a remote (persistant) actor/container, this seems to force the GameMode on that item to be processed one time. Secondly there may be something going on with cells linked via a door. My token scripts, on a persistant actor in a shop in IC, trigger when I approach the (outside) door to the shop. I've also seen this while in connected interior cells. GuidoBot 17:34, 11 November 2006 (EST)
Scripts on actors: AI packages required?[edit source]
Is it necessary that an actor have one or more AI packages in order for a script on that actor to run when the player is in a different cell? Abramul 12:27, 5 April 2007 (EDT)
Problem with specific assertions[edit source]
# Scripts on references: processed every frame when its cell is loaded, not at all when the cell is not loaded. So these scripts run only when the player is nearby (which means these are often a good place to put relatively expensive scripts, doing things like distance checks).
I have a countainer in an interior cell linked by two doors with the IC Waterfront District, namely cells 02 and 03. Within that interior cell is a container using a non-persistent reference. However, its MenuMode block gets executed from the very begining - the first menu when entering the game, when no game is even loaded! try the following script, it will display the message "Entered MenuMode..." on top of the very first menu... Any clue?
scn fjPCMStoneChestLarge1Script Short CheckContainer Short DoIt Begin OnLoad If fjPCMGlobalStoneChestLarge1 pms fjPCMeffectStatueMarvels Endif End ;---***** THE FOLLOWING BLOCK EXECUTES FROM THE VERY FIRST MENU, WHEN NO GAME IS EVEN LOADED! Begin MenuMode ;--- Should be MenuMode 1008 for container Menu, but it does not work Set CheckContainer to 1 message "Entered MenuMode..." Return End ;---***** Begin OnReset ;--- Notify a Respawn Event ; (... several sets and checks code ...) If DoIt Set fjPCMGlobalStoneChestLarge1 to 1 Messagebox "You've aquired so many experience levels, that a new armament up to your persona is at hand. If you use the correct set of magic stones in the correct order inside the Stand of Marvels in your Magic Room, a new Lord's Armor Set of Marvels will respawn. Watch out for Bubo and Siomo!" Endif End Begin GameMode If CheckContainer Set CheckContainer to 0 Message "Verifying the Star Dust Receptacle's Inventory...",4 if (GetItemCount fjPCMArmorMarvelousGreavesLvl1 > 0) || (GetItemCount fjPCMArmorMarvelousGreavesLvl5 > 0) || (GetItemCount fjPCMArmorMarvelousGreavesLvl11 > 0) || (GetItemCount fjPCMArmorMarvelousGreavesLvl16 > 0) || (GetItemCount fjPCMArmorMarvelousGreavesLvl21 > 0) || (GetItemCount fjPCMArmorMarvelousGreavesLvl27 > 0) Set fjPCMGlobalStoneChestLarge1 to 1 pms fjPCMeffectStatueMarvels Else Set fjPCMGlobalStoneChestLarge1 to 0 sms fjPCMeffectStatueMarvels Endif Endif End
# Scripts on objects in containers: these are processed when the container's script is processed -- so, items on actors are processed when the actor is processed; items in other containers are processed every frame when the cell is loaded.
When the cell is loaded is not correct in regards to the above-mentioned oddity. It needs to be clarified IMHO...
- Surprised that it happens for non-persistent objects, but see When do remote activators run for more information. Haven't looked at this page, but it does sound like it needs to be updated.
- --Haama 00:40, 10 November 2007 (EST)
- Thanks haama! I am amazed to see how you are taking your time in replying to many moders, either here or on the Bethesda site. Indeed, it's very generous of you. Are you working on a mod? Since I am learning and building a mod, I also read others questions, and sometimes when I feel that I can leave a path of an answer (if not the answer itself), I respond. At the same time it makes me dig and learn more...
- When you say that remote activators run once when the mod is first loaded, and when a variable is set on that remote activator, do you mean that if I did not set any variable within the above-mentioned MenuMode block (or if I include all its code within an if clause), then it wouldn't pass through and stop executing after the 1st frame? More over, it seems to go beyond a single frame pass, since that as in your case, a message (in my case "Entered MenuMode...") is displayed indefinitely until I get out of that menu (until I actually load a saved game)...
- --HawkFest 20:09, 11 November 2007 (EST)
- I try to help out a bit when people get stuck. At first I found modding very frustrating because the information on it is scattered and incomplete - I wasn't even sure if variables would reset themselves every frame, etc., so I try to help others away from the same frustrations. "Are you making a mod?" - LOL, yes, too many of them at one time in fact. Right now I'm working on updating the Alchemical Sorter for COBL, and then I'll probably get back to updating my own mods (Alchemical Formulas really needs an update).
- Anyway, "do you mean that if I did not set any variable within the above-mentioned MenuMode block (or if I include all its code within an if clause), then it wouldn't pass through and stop executing after the 1st frame?" - yes. Get rid of the 'Set CheckContainer to 1' line and the script will only run the one time when entering the game. An 'if' clause would be good though, since you don't want the message to display every frame when the player finally enters the room. Container MenuMode (1008) works fine for me, but I don't think that's what you want (unless it's the only container in the room, well, actually couple of rooms since it'll remain loaded in memory). Do you want it to start once the player opens the container? If so, use an onActivate block instead (just be sure to never activate it from a remote object script). Good luck.
- --Haama 11:27, 12 November 2007 (EST)
- Actually, I want it to verify the contents of the container at the very moment I leave its menumode (after putting or getting stuff out of it). That's why I was considering using its menumode block, for setting a flag that would then trigger a Gamemode code block. However, maybe that this is redundant : when in menumode, does the gamemode code continues to execute, or does it stop until menumode is left? Is there a more efficient way to render the desired behaviour? Regards, --HawkFest 15:33, 12 November 2007 (EST)
- Assuming it's a normal container:
begin onActivate if (IsActionRef player) set CheckContainer to 1 Activate endif end begin GameMode if CheckContainer set CheckContainer to 0 ;check contents endif end
- That way, the contents will only be examined when your container is opened, instead of any container. You could also add "buttons" to the container that, when the player selects them, do the proper processing. Those are a bit harder and require OBSE, though.
- --Haama 16:49, 12 November 2007 (EST)
- I am actually doing this, but what I really want to do is the following : after having added/removed items or checked chest's inventory, i.e. right at the moment I leave its inventory menu, that's when I'd like the verification process to start. I want to check whether or not a specific item is inside the container AFTER having played in its inventory, NOT during nor before, after. Regards, --HawkFest 15:57, 13 November 2007 (EST)
[moving back to edge]
Sorry, I misspoke earlier. The code I gave will do exactly that - when the container is closed the items will be checked. When I said "the contents will only be examined when your container is opened, instead of any container" I'd meant to put the emphasis on 'your container' rather than when it's opened. Should've been "the contents will only be examined when your container has been opened and closed, instead of any container".
To answer a question in the other block - GameMode and MenuMode blocks are mutually exclusive. MenuMode runs whenever it's not GameMode, and vice versa for GameMode.
--Haama 17:51, 13 November 2007 (EST)
Remote Ref Heartbeat[edit source]
For non-dynamic activators (activators placed in the CS) I could not find much difference between persistent and non-persistent. In both cases, after triggered by an Activate function, the process started running and, most of the times, continued running after the player moved from place to place. A few times the process stopped and had to be re-triggered.
Dynamic activators (activators created with PlaceAtMe), most of the times, stopped running after the player moved from place to place and the process had to be re-triggered when possible, i.e., when the ref to the activator was valid, i.e., while the activator's cell remained loaded. QQuix 00:09, 11 March 2009 (EDT)
Processing levels[edit source]
From what I can remember from reading the WIKI and forum posts, there are four processing levels for actors.
Does anyone have any additional info to share? Or links to other articles, maybe?
- 1. High level processing - actors in the same cell as the player (and the surrounding cells, if in exterior)
- scripts and AI process every frame.
- 2. Mid level processing - actors in cells the players visited recently and are still loaded
- no info on how frequently these scripts and AI run.
- 3. Low level processing - persistent actors in unloaded cells
- scripts and AI run every 15 game minutes / 30 real seconds (at standard settings)
- 4. No low level processing - non-persistent actors in unloaded cells (actors get unloaded with the cell) and persistent actors with the "No low level processing" flag on, in unloaded cells.
- scripts and AI don't run at all.
QQuix 17:55, 14 October 2010 (EDT)