Difference between revisions of "Talk:Activate"

Jump to navigation Jump to search
1,441 bytes added ,  11:10, 28 February 2009
imported>Quetzilla
imported>QQuix
Line 104: Line 104:
::::Yeah, that's the kink in that theory. If the theory is true, then the fact that it checks the stolen status is a bug (likely an overlooked check in a sub function).  If the theory is false, then I have absolutely no idea.  Regardless, there's little chance of proving any of this. [[User:Waruddar|Waruddar]] 19:45, 1 February 2008 (EST)
::::Yeah, that's the kink in that theory. If the theory is true, then the fact that it checks the stolen status is a bug (likely an overlooked check in a sub function).  If the theory is false, then I have absolutely no idea.  Regardless, there's little chance of proving any of this. [[User:Waruddar|Waruddar]] 19:45, 1 February 2008 (EST)
:::::Well actually it makes perfect sense in regards to your theory... Unless: have you tried picking up the item ''before'' doing it in-game for the 1st time (from the console and without the flag)? Logically it should ''not'' increment the theft count if your theory is correct. --[[User:HawkFest|HawkFest]] 03:37, 5 February 2008 (EST)
:::::Well actually it makes perfect sense in regards to your theory... Unless: have you tried picking up the item ''before'' doing it in-game for the 1st time (from the console and without the flag)? Logically it should ''not'' increment the theft count if your theory is correct. --[[User:HawkFest|HawkFest]] 03:37, 5 February 2008 (EST)
I have found that picking up items with the RunOnActivateBlock = 0 leaves data behind, bloating the savegame (reported [[User:QQuix/On Dynamic Items and Savegame Bloating|here]] - and I must say that the text above was most fundamental to my tests).
Now I found that the statement about activating unscripted items (item 3 under "Buggy Bug Bug of a Weird, Weird Bug") is only true if activating it with RunOnActivateBlock = 0:
*Non scripted containers: as the article says - you cannot 'open' them anymore
*Dynamic carryable items - Everything works, but bloats the savegame
*Non-dynamic carryable items, scripted or not - 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).
I wonder if there is any reason at all to use the Activate function with the RunOnActivateBlock set to 0. 
[[User:QQuix|QQuix]] 11:10, 28 February 2009 (EST)


== Can't activate while on a horse ==
== Can't activate while on a horse ==
Anonymous user

Navigation menu