virtual_reality 
The virtual reality turned component. Originally created to overcome issues of mob polymorphing locking the player inside virtual reality and allow for a more "immersive" virtual reality in a virtual reality experience. It relies on comically complex order of logic, expect things to break if procs such as mind/transfer_to() are revamped. In short, a barebone not so hardcoded VR framework. If you plan to add more devices that make use of this component, remember to isolate their code outta here where possible.
Procs | |
| PostTransfer | Required for the component to be transferable from mob to mob. |
|---|---|
| action_trigger | The following procs simply acts as hooks for quit(), since components do not use callbacks anymore |
| connect | Called when attempting to connect a mob to a virtual reality mob. This will return FALSE if the mob is without player or dead. TRUE otherwise |
| on_player_transfer | Takes care of moving the component from a mob to another when their mind or ckey is transferred. The very reason this component even exists (else one would be stuck playing as a monky if monkyified) |
| player_hijacked | Called when someone or something else is somewhat about to replace the mastermind's mob key somehow. And potentially lock the player in a broken virtual reality plot. Not really something to be proud of. |
| pre_player_transfer | Called to stop the player mind from being transferred should the new mob happen to be one of our masterminds'. Since the target's mind.current is going to be null'd in the mind transfer process, This has to be done in a different signal proc than on_player_transfer(), by then the mastermind.current will be null. |
| quit | Takes care of deleting itself, moving the player back to the mastermind's current and queueing the parent for deletion. It supports nested virtual realities by recursively calling vr_in_a_vr(), which in turns calls quit(), up to the deepest level, where the ckey will be transferred back to our mastermind's mob instead. The above operation is skipped when session_paused is TRUE (ergo no player in control of the current mob). vars: |
| switch_player | Called when the mastermind mind is transferred to another mob. This is pretty much just going to simply quit the session until machineries support polymorphed occupants etcetera. |
| vr_in_a_vr | Used for recursive virtual realities shenanigeans and should be called by the above proc. |
| you_only_live_once | emag_act() hook. Makes the game deadlier, killing the mastermind mob too should the parent die. |
Proc Details
PostTransfer
Required for the component to be transferable from mob to mob.
action_trigger
The following procs simply acts as hooks for quit(), since components do not use callbacks anymore
connect
Called when attempting to connect a mob to a virtual reality mob. This will return FALSE if the mob is without player or dead. TRUE otherwise
on_player_transfer
Takes care of moving the component from a mob to another when their mind or ckey is transferred. The very reason this component even exists (else one would be stuck playing as a monky if monkyified)
player_hijacked
Called when someone or something else is somewhat about to replace the mastermind's mob key somehow. And potentially lock the player in a broken virtual reality plot. Not really something to be proud of.
pre_player_transfer
Called to stop the player mind from being transferred should the new mob happen to be one of our masterminds'. Since the target's mind.current is going to be null'd in the mind transfer process, This has to be done in a different signal proc than on_player_transfer(), by then the mastermind.current will be null.
quit
Takes care of deleting itself, moving the player back to the mastermind's current and queueing the parent for deletion. It supports nested virtual realities by recursively calling vr_in_a_vr(), which in turns calls quit(), up to the deepest level, where the ckey will be transferred back to our mastermind's mob instead. The above operation is skipped when session_paused is TRUE (ergo no player in control of the current mob). vars:
- deathcheck is used to kill the master, you want this FALSE unless for stuff that doesn't involve emagging.
- cleanup is used to queue the parent for the next vr_clean_master's run, where they'll be deleted should they be dead.
- mob/override is used for the recursive virtual reality explained above and shouldn't be used outside of vr_in_a_vr().
switch_player
Called when the mastermind mind is transferred to another mob. This is pretty much just going to simply quit the session until machineries support polymorphed occupants etcetera.
vr_in_a_vr
Used for recursive virtual realities shenanigeans and should be called by the above proc.
you_only_live_once
emag_act() hook. Makes the game deadlier, killing the mastermind mob too should the parent die.