Difference between revisions of "Remote Activators"
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 | 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 | 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 | 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 | 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 | #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 | #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 | #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 | 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]] | ||
Revision as of 23:17, 10 October 2006
Remote Activators
By GuidoBot (GuidoBot 22:29, 10 October 2006 (EDT))
Introduction
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 persistant 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
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
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
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
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:
- 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 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
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
(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
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.
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.