Difference between revisions of "Remote Activators"

From the Oblivion ConstructionSet Wiki
Jump to navigation Jump to search
imported>GuidoBot
imported>QQuix
(Byline removed)
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
=Remote Activators=
'''By GuidoBot'''  ([[User:GuidoBot|GuidoBot]] 22:29, 10 October 2006 (EDT))




Line 7: Line 4:
This article is simply a collection of useful tips on how to use the default activation methods on objects to provide some useful functionality.
This article is simply a collection of useful tips on how to use the default activation methods on objects to provide some useful functionality.


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>persistent</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 16: Line 13:
By ''items'' I really mean anything that can go to your inventory: armor, torches, keys, soul gems, potions, apparatus, etc.
By ''items'' I really mean anything that can go to your inventory: armor, torches, keys, soul gems, potions, apparatus, etc.


The only real point of this is to have the player aquire something immediately to their inventory without the usual message spam that would result from '''AddItem'''.  Typcally these items would be special; usually unique and scripted in some way, although not necessarily. Many objects have nice features when used (typically when equipped or activated) but are not really ''remote activators'' since they have to be in your inventory first.
The only real point of this is to have the player aquire something immediately to their inventory without the usual message spam that would result from [[AddItem]].  Typcally these items would be special; usually unique and scripted in some way, although not necessarily. Many objects have nice features when used (typically when equipped or activated) but are not really ''remote activators'' since they have to be in your inventory first.


===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 23:
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 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|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 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.
Activating an actor may also be useful in itself. For example, you could set up a remote merchant this way that you access by a spell to acquire various items, although the effect might seem a little odd. If you have the reference of a nearby actor, e.g. as a result of casting an AoE spell, then you can also 'activate' them, even if they are not persistant. This can be handy for forcing a guard to arrest the player with a bounty or performing a remote pick-pocketing spell, in combo with [[SetForceSneak]].
#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.


===Remote Furniture===
===Remote Furniture===
Line 48: Line 48:


===Other===
===Other===
I've not mentioned a few other types of remote activators that I haven't found a use for yet (but perhaps you could). Activating doors (using their REF ID for those you didn't add) is an alternative way of teleporting to a location. Remote flora could be useful if you did some wierd stuff with ingredients. If you find any other uses for remote activators not mentioned here, please feel free to add to the comments below.
I've not mentioned a few other types of remote activators that I haven't found a use for yet but perhaps you could. If you find any other uses for remote activators not mentioned here, please feel free to add to the comments below. Some objects are useful to use as ''remote objects'' but without employing their default 'activation' method. For example, using a persistant trap that you temporarily [[MoveTo]] a location is a handy way to force damage that creates blood splatter and/or a push-back effect.


----
----
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 ''current'' script and MenuMode scripts will continue running. This means several such windows may open up at the same time if you are not careful, although only the last of a particular type will be displayed. The situation is very similar to that when using the [[MessageBox]] command.




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

Latest revision as of 06:18, 24 June 2012


Introduction[edit | edit source]

This article is simply a collection of useful tips on how to use the default activation methods on objects to provide some useful functionality.

The term remote activator is used here to mean any persistent 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 script:

<MyRemoteActivator>.Activate player

Remote Items[edit | edit source]

By items I really mean anything that can go to your inventory: armor, torches, keys, soul gems, potions, apparatus, etc.

The only real point of this is to have the player aquire something immediately to their inventory without the usual message spam that would result from AddItem. Typcally these items would be special; usually unique and scripted in some way, although not necessarily. Many objects have nice features when used (typically when equipped or activated) but are not really remote activators since they have to be in your inventory first.

Remote Activators[edit | edit source]

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).

Remote Containers[edit | edit source]

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.

Remote Actors[edit | edit source]

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:

  1. 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.
  2. 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.)
  3. 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.


Activating an actor may also be useful in itself. For example, you could set up a remote merchant this way that you access by a spell to acquire various items, although the effect might seem a little odd. If you have the reference of a nearby actor, e.g. as a result of casting an AoE spell, then you can also 'activate' them, even if they are not persistant. This can be handy for forcing a guard to arrest the player with a bounty or performing a remote pick-pocketing spell, in combo with SetForceSneak.

Remote Furniture[edit | edit source]

This refers to objects that are classified as Static/Furniture in the CS.

It turns out that chairs are actually equivalent to beds when activated remotely. This effect will bring up the Rest Menu from a script and acts exactly like you were going to sleep (i.e. you will not be allowed to if there are enemies nearby.)

Remote Scrolls[edit | edit source]

(My favorite!) This refers to objects that are classified as Items/Books in the CS. Although not typically static, there are made so by setting the Can't be Taken option.

These are a great alternative for bringing up information message boxes in-game from a script. Not only do you not have to worry about large amounts of text in your script, you can totally format it and even display pictures! You also have the option of adding skills this way and/or running a script. I usually use scrolls to get a nice single page of text but books work just as well.

Other[edit | edit source]

I've not mentioned a few other types of remote activators that I haven't found a use for yet but perhaps you could. If you find any other uses for remote activators not mentioned here, please feel free to add to the comments below. Some objects are useful to use as remote objects but without employing their default 'activation' method. For example, using a persistant trap that you temporarily MoveTo a location is a handy way to force damage that creates blood splatter and/or a push-back effect.


Comments[edit | edit source]

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 current script and MenuMode scripts will continue running. This means several such windows may open up at the same time if you are not careful, although only the last of a particular type will be displayed. The situation is very similar to that when using the MessageBox command.