Difference between revisions of "Remote Activators"

16 bytes removed ,  00:17, 11 October 2006
added internal links
imported>DragoonWraith
(changing categorization from link to proper category tag)
imported>DragoonWraith
(added internal links)
Line 9: Line 9:
The term ''remote activator'' is used here to mean any <u>persistant</u> object you created for your MOD that is placed in a hidden room. A hidden room is a very useful thing to have for most MODs since it allows you to add to the game without causing any conflicts with anyone else's MOD or the unmodified (''vanilla'') game of Oblivion. From this room you can teleport ('''MoveTo''') any of these objects to other areas of the game, using some existing object (e.g. XMarker or Cell ID) as a reference point.
The term ''remote activator'' is used here to mean any <u>persistant</u> object you created for your MOD that is placed in a hidden room. A hidden room is a very useful thing to have for most MODs since it allows you to add to the game without causing any conflicts with anyone else's MOD or the unmodified (''vanilla'') game of Oblivion. From this room you can teleport ('''MoveTo''') any of these objects to other areas of the game, using some existing object (e.g. XMarker or Cell ID) as a reference point.


However, this article is mainly concerned with using the '''OnActivate''' method of those objects where they stand. In fact for this article the functionality is all performed using just the one general command from any <u>script</u>:
However, this article is mainly concerned with using the [[OnActivate]] method of those objects where they stand. In fact for this article the functionality is all performed using just the one general command from any <u>script</u>:


  <MyRemoteActivator>.Activate player
  <MyRemoteActivator>.Activate player
Line 19: Line 19:


===Remote Activators===
===Remote Activators===
This refers to objects that are classified as Static/Activators in the Oblivion Construction Set (CS). Such items are usually specifically intended for running a script (the '''OnActivate''' block) when the player touches them.
This refers to objects that are classified as Static/Activators in the Oblivion Construction Set (CS). Such items are usually specifically intended for running a script (the [[OnActivate]] block) when the player touches them.


These objects are the natural way to create static (in-game) functions that can be activated remotely to run pretty much any script you want. Because these objects are remote from the player and static, you should not consider using the GameMode block. If you do want something that runs every frame then you should add an unplayable item (token) to the player, teleport a disabled item to the players location or use a ''shadow'' (see '''Remote Actors''' below).
These objects are the natural way to create static (in-game) functions that can be activated remotely to run pretty much any script you want. Because these objects are remote from the player and static, you should not consider using the GameMode block. If you do want something that runs every frame then you should add an unplayable item (token) to the player, teleport a disabled item to the players location or use a ''shadow'' (see '''Remote Actors''' below).
Line 26: Line 26:
This refers to objects that are classified as Static/Containers in the CS.
This refers to objects that are classified as Static/Containers in the CS.


These objects are great for creating 'pockets' in your inventory and even better when accessed from spells, etc. As 'pockets' you have to be aware that you can put anything in them and you (the player) will lose the pocket item if you place it inside itself! (I like to think of this as turning it inside out.) However, by careful scripting using the '''RemoveAllItems''' command, you can guard against this and make the 'pocket' only contain certain items by putting them back (e.g. by testing mass, type and/or use of the '''OnAdd''' block, '''GetContainer''' function, etc.). Typically your remote containers will start off empty but you can have them initially hold anything you like or even produce stuff regularly, such as food.
These objects are great for creating 'pockets' in your inventory and even better when accessed from spells, etc. As 'pockets' you have to be aware that you can put anything in them and you (the player) will lose the pocket item if you place it inside itself! (I like to think of this as turning it inside out.) However, by careful scripting using the [[RemoveAllItems]] command, you can guard against this and make the 'pocket' only contain certain items by putting them back (e.g. by testing mass, type and/or use of the [[OnAdd]] block, [[GetContainer]] function, etc.). Typically your remote containers will start off empty but you can have them initially hold anything you like or even produce stuff regularly, such as food.


===Remote Actors===
===Remote Actors===
These can be used as remote objects for some things, and would start out this way, but the real uses for remote actors are what I call '''shadows'''. The reasoning here is that the actor is always disabled and teleported to the player's current location (one frame) before they are actually used. At any other time they may be truely remote, and exactly where they are doesn't really matter
These can be used as remote objects for some things, and would start out this way, but the real uses for remote actors are what I call '''shadows'''. The reasoning here is that the actor is always disabled and teleported to the player's current location (one frame) before they are actually used. At any other time they may be truely remote, and exactly where they are doesn't really matter


There are many uses for shadows. The default '''Activate''' command itself is actually the least useful since you would have to enable the actor first (could still be set invisible) and then effectively have a conversation with a ghost. Three very useful features I've employed so far are:
There are many uses for shadows. The default [[Activate]] command itself is actually the least useful since you would have to enable the actor first (could still be set invisible) and then effectively have a conversation with a ghost. Three very useful features I've employed so far are:


#As an hidden inventory. The advantage of using an actor as an inventory is mainly because you want to temporily store items to move between it and the player. This is great for ''replacer'' items where an item in your inventory is exchanged for a different one when dropped or thrown, and then back again when picked up [activated]. A nearby container is required so that the objects can move themselves using the '''RemoveMe''' command. You can also use the '''RemoveItem''' command on the shadow itself to destroy a bunch of objects without creating any message spam.
#As an hidden inventory. The advantage of using an actor as an inventory is mainly because you want to temporily store items to move between it and the player. This is great for ''replacer'' items where an item in your inventory is exchanged for a different one when dropped or thrown, and then back again when picked up [activated]. A nearby container is required so that the objects can move themselves using the [[RemoveMe]] command. You can also use the [[RemoveItem]] command on the shadow itself to destroy a bunch of objects without creating any message spam.
#As a picker-upper. A shadow actor is great for picking up [remote] items so they can be moved between inventories. This is very useful when first getting items into the game, e.g. for sale at merchants. Although not so useful, you can also use this to drop items near the player. Again, all these actions will go on silently and avoid "over emcumbered" messages, etc. One thing to note here is that the shadow will have to be temporily enabled to perform an '''Activate''' command, but you wont see it if you disable the next frame. (I also like to shrink my shadow since their size is irrelevant. '''SetUnconscious''' is also useful here if you dont want to hear ghost voices.)
#As a picker-upper. A shadow actor is great for picking up [remote] items so they can be moved between inventories. This is very useful when first getting items into the game, e.g. for sale at merchants. Although not so useful, you can also use this to drop items near the player. Again, all these actions will go on silently and avoid "over emcumbered" messages, etc. One thing to note here is that the shadow will have to be temporily enabled to perform an [[Activate]] command, but you wont see it if you disable the next frame. (I also like to shrink my shadow since their size is irrelevant. [[SetUnconscious]] is also useful here if you dont want to hear ghost voices.)
#As a target for running scripts. A shadow can run scripts, either directly on itself when near the player, or as the target for objects added to its inventory using '''AddItem 1'''. This is a way to create true dynamic functions in Oblivion, although in most cases its easier just to add a token to the player.
#As a target for running scripts. A shadow can run scripts, either directly on itself when near the player, or as the target for objects added to its inventory using [[AddItem|AddItem 1]]. This is a way to create true dynamic functions in Oblivion, although in most cases its easier just to add a token to the player.


===Remote Furniture===
===Remote Furniture===
Line 54: Line 54:
===Comments===
===Comments===


Important note: When using remote activators that bring up menu boxes, such as scrolls or containers, although the player cannot do anything until he clicks Close, your scripts will continue running. This means several such windows may open up at the same time if you are not careful. The situation is very similar to that when using the '''MessageBox''' command. I find setting flags between MenuMode and GameMode the easiest way to control this.
Important note: When using remote activators that bring up menu boxes, such as scrolls or containers, although the player cannot do anything until he clicks Close, your scripts will continue running. This means several such windows may open up at the same time if you are not careful. The situation is very similar to that when using the [[MessageBox]] command. I find setting flags between MenuMode and GameMode the easiest way to control this.




[[Category: Useful Code]]
[[Category: Useful Code]]