Difference between revisions of "Remote Activators"
Byline removed
imported>DragoonWraith (changing categorization from link to proper category tag) |
imported>QQuix (Byline removed) |
||
| (9 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| 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> | 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 | 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 | 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 | 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 | 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 [[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. | |||
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=== | ===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 | 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 | 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]] | ||