Difference between revisions of "Talk:Activate"
Jump to navigation
Jump to search
→RunOnActivateBlock Flag: More tests
imported>Haama (→RunOnActivateBlock Flag: Self-activation) |
imported>QQuix (→RunOnActivateBlock Flag: More tests) |
||
| Line 110: | Line 110: | ||
*Non scripted containers: as the article says - you cannot 'open' them anymore | *Non scripted containers: as the article says - you cannot 'open' them anymore | ||
*Dynamic carryable items - Everything works, but bloats the savegame | *Dynamic carryable items - Everything works, but bloats the savegame | ||
* | *Nonscripted, non-dynamic carryable items - if picked up with "Item.activate player 0", after dropping it later on, the item will not respond to spacebar 'pick up' (you can still move it with the grab key). | ||
Building up on Waruddar's guess, it seems that the engine not only doesn’t parse the ExtraData, but also messes up the data structure for that particular FormId (or skips something that should be done), so the next time you activate a non-dynamic reference (same FormId) it will not respond as expected. Dynamic items, themselves, don’t suffer the consequences of this bug (?), as they always get a new, fresh FormId (but, as mentioned, the old, useless data will remain in the game). | Building up on Waruddar's guess, it seems that the engine not only doesn’t parse the ExtraData, but also messes up the data structure for that particular FormId (or skips something that should be done), so the next time you activate a non-dynamic reference (same FormId) it will not respond as expected. Dynamic items, themselves, don’t suffer the consequences of this bug (?), as they always get a new, fresh FormId (but, as mentioned, the old, useless data will remain in the game). | ||
| Line 119: | Line 119: | ||
:Good to know, QQuix. To answer your question - you would want to run an Activate without the ''Run'' flag from an object's own script (i.e., scripted cupboard opening upon correct answer to a riddle). Not sure if it creates the same bug, though. | :Good to know, QQuix. To answer your question - you would want to run an Activate without the ''Run'' flag from an object's own script (i.e., scripted cupboard opening upon correct answer to a riddle). Not sure if it creates the same bug, though. | ||
:--[[User:Haama|Haama]] 14:09, 28 February 2009 (EST) | :--[[User:Haama|Haama]] 14:09, 28 February 2009 (EST) | ||
::Ooops . . . forgot about that. A few more tests: | |||
::*A plain activate within the OnActivate block does not break the item (as, of course, the item has an OnActivate block). | |||
::*Containers: using Activate within its own gamemode block seems to have the same effect as if activated from other script: | |||
:::* 'Activate' - does not break the container, but does not open it either. | |||
:::* 'Activate player 0' without an OnActivate block - opens the container once, but breaks the container for further activations. | |||
:::* 'Activate player 1' - works OK | |||
::The bottom line seems to be that RunOnActivateBlock = 1 always works and RunOnActivateBlock = 0 only works if the activated object has an OnActivate block. (I am adjusting the article) | |||
::Therefore, recommendation could be: | |||
::*Use RunOnActivateBlock = 0 only if you know for sure the object has an OnActivate block and, for some reason, you don't want that block code to run. | |||
::*Use RunOnActivateBlock = 1 otherwise, especially when activating items you are not familiar with (cell scan, spell effects, etc) | |||
::[[User:QQuix|QQuix]] 16:59, 28 February 2009 (EST) | |||
== Can't activate while on a horse == | == Can't activate while on a horse == | ||