[EVENT] Server Processes

[SWAT One]

Currently we have relays and VCE functions which allow certain processes to occur over a server, but I would really like to see an independent mod with features of both in order to make events more compact.

For example:

0.  onActivate >> Self/NB >> ProcessCreate "Name"

(When the brick is clicked, the targeted brick will create a process with identity of "Name" to the server.  Removing this brick will not remove the Process.  If the process already exists stored on the server, then this event will do nothing.)

1.  onActivate >> Self/NB >> ProcessDelete "Name"

(When the brick is clicked, the targeted brick will delete the process with the identity of "Name" to the server., given that it exists before this event was called.)

2.  onProcessCreated >> ALL >> "whatever"

(When a process is created, this event is triggered.)

3.  onActivate >> Self/NB >> ProcessCall "Name"

(When the brick is activated, the brick triggers all bricks with the event 4 input.)

4.  onProcessCalled >> Self/NB >> ProcessIfIdentity "Name" "Ranges"

(When a process is called, the brick checks if the process that is called has the identity "Name", and triggers the event ranges*.)

5.  onProcessTrue >> ALL >> "whatever"

(When event 4 returns true, this event is triggered.)

6.  onProcessFalse >> ALL >> "whatever"

(When event 4 returns true, this event is triggered.)

7.  onActivate >> Self/NB >> ProcessTimerStart "Name" "Time"

(When this brick is activated, the brick will trigger the process with identity of "Name" in "Time" seconds.  This is to avoid the stupid 30000 ms delay, so that larger times could be applied for larger variety.)

8.  onActivate >> Self/NB >> ProcessTimerAbort "Name"

(Whim this brick is activated, it will check if the process with identity "Name" has a timer, and then will cancel it if it exists.  This will not set it to 0, whick would trigger it instead, but stops the timer completely, and clears it from existence.  The timer would have to be recreated for this event to work again.)

9.  onProcessTimerStart >> ALL >> "whatever"

(When a process timer starts, it triggers this event.)

10.  onProcessTimerAborted >> ALL >> "whatever"

(When a process timer is aborted, this event is triggered.)

11.  onProcessTimerTick >> Self/NB >> ifProcessIdentity "Name"

(When a process timer anywhere has a tick, i.e. when a second off of its timer counts down, this event is triggered, however, it checks if the process timer belongs to process with the identity of "Name".)

The point of this mod is to reduce the number of relays and named bricks, so that you don't need to trigger a network of relays to handle things.  For example, you could trigger an entire game sequence with a few processes.  Suppose you have a bomb arm button, a bomb, an alarm system, and a disarm system.  You must first start by creating two processes, one for launching, and one for the abort sequence.  For instance:

onMinigameReset >> Self >> ProcessCreate "BombArm"
onMinigameReset >> Self >> ProcessCreate "BombDefuse"

Now for calling the events.

On a brick to trigger the bomb to be set,

0.  onActivate >> Self >> ProcessTimerStart >> "BombArm" "60"
1.  onProcessTimerStart >> Minigame >> CenterPrintAll "The bomb is primed, and will detonate in 60 seconds, unless defused!"
2.  onProcessTimerStart >> NB "Bomb" >> SetEventEnabled "whatever"  (This makes it so the bomb can be defused)

On named brick "Bomb",

0.  onProcessTimerTick >> Self >> ProcessIfIdentity "BombArm" "1"
1.  onProcessTrue >> Minigame >> BottomPrintAll "The bomb will detonate in $ProcIDTime_BombArm seconds!"
2.  onProcessCalled >> Self >> ProcessIfIdentity "BombArm" "3"
3.  onProcessTrue >> Self >> spawnExplosion "whatever"
4.  onActivate >> Self >> ProcessTimerStart "BombDefuse"
5.  onProcessTimerTick >> Self >> ProcessIfIdentity "BombDefuse" "6"
6.  onProcessTrue >> Client >> CenterPrint "Defusing in process: $ProcIDTime_BombDefuse" seconds left."
7.  onProcessCalled >> Self >> ProcessifIdentity "Defuse" "8"
8.  onProcessTrue >> Self >> ProcessAbort "BombArm"

And then on the alarms, which require no named brick,

0.  onProcessTimerStart >> Self >> ProcessIfIdentity "BombArm" "1 2" (or "1, 2" for range)
1.  onProcessTrue >> Self >> fireRelay
2.  onProcessTrue >> Self >> SetLight "Alarm"
3.  onProcessCalled >> Self >> ProcessIfIdentity "BombDefuse" "4 5" (or "4, 5" for range)
4.  onProcessTrue >> Self >> SetLight "NONE"
5.  onProcessTrue >> Self >> CancelEvents
6.  onRelay >> Self >> playSound "whatever"
7.  (2000) onRelay >> Self >> fireRelay

*Ranges refer to the following formats:  "1 5" triggers events 1, 2, 3, 4, and 5, "1, 2, 3" triggers events 1, 2, and 3, "1 3, 5" triggers events 1, 2, 3, and 5, "1 3, 6 8" triggers events 1, 2, 3, 6, 7, and 8, and so on.  Marble Man had an Add-On that did this, but I'm not sure if it was deleted or not.

In events, there would be replacer strings much like the VCE strings of <var:whatever>, except it should use the natural strings for detecting it, these being:

$ProcIDExists_"Name"	Boolean
$ProcNum	Number of Processes that exist on the server.
$ProcNum_"BL_ID"	Number of processes that exist on the server owned by this BL_ID.
$ProcIDName_"Name"	The identity name of the process.
$ProcIDTime_"Name"	The amount of time until process with identity "Name" is triggered.  If there is no timer, this returns as "UNDEFINED"
$ProcIDTimerExists_"Name"	Boolean
$ProcIDOwner_"Name"	BL_ID of the owner of the process with the identity of "Name".

Thank you for reading!  If you have any suggestions, including polls or poll options, let me know.

A detailed explanation for basic functionalities is found here.

[Ad Bot]

[SWAT One]

Bump.

Also, some other cool features could include:

• Respawning a group of vehicles without needing to have multiple named bricks.
  
• Organizing independent events per brick, without requiring a large database of bricks to operate server events.
• Creating acurate time simulators through events.
• Creating relay-like events with any time gap.
• (Possibly because processes would be script objects) Dodging event ownership problems after the user leaves.

[alex dude]

This is a really good idea, I hope this gets done.

[Greek2me]

That's quite complicated.

[Advanced Bot]

That's quite complicated.

Yea, I am really lost on this.

[SWAT One]

Okay.  Think of a process as a parasol.  There are a number of tiles on the floor on which you stand, and the shadow falls on all these tiles (bricks) and influences them.  These tiles detect the process and interact given those conditions.

This as opposed to relays where tiles influence one another.

Another example would be minigame events, say in a slayer minigame with VCE, you say:

0.  (5000) onMinigameSpawn >> Client >> VCEifVariable "team" == "3" "1 2"
1.  onVariableTrue ⇒ Success
2.  onVariableFalse ⇒ Fail

Instead of having filters separate, processes are predefined by identity and events will pick up this process, when triggered through:

onProcessCalled >> Self >> ProcessIfID "Name" "range"

Another example is using Command Events to trigger server-wide interaction.

[SWAT One]

Bump.

[Lugnut]

a group of events bundled together? a function?

[SWAT One]

Okay, so for the sake of ease, I will be arranging the way this works in layers.  To see the events of a brick, hover over the navy blue event line number.

Layer 0:  A process is defined.

Brick 0, (unnamed)
0

This creates a process to the server.  If you want to think of it this way, it acts as an imaginary minigame.  In this minigame, things can happen that trigger events.  Perhaps someone captures a point or a flag, and that causes a minigame-sensitive event to be triggered.  Another way to think of it is tuning into a radio.  Tuning to a narrow band of frequencies will only allow you to receive a very limited response, and to send a limited message.

Brick 0 creates a channel named Alpha in which processes can be handled.  However, brick 0 is not "linked" in any way to the Alpha channel and can be deleted as soon as this event is triggered.

Layer 1a:  A process is triggered (Alpha).

Brick 1, (unnamed)
0

Back to our radio channel brown townogy, this sends a signal to the server's Aplha channel, telling it to trigger all Alpha processes on the server.

Layer 1b:  A process is triggered (Beta).

Brick 2, (unnamed)
0

Back to our radio channel brown townogy, this sends a signal to the server's Beta channel, telling it to trigger all Beta processes on the server.

Layer 2:  A called process is detected.

Brick Q^?, (unnamed)
0, 1, 2

Let's just suppose here that green indicates that the channel test succeeds for Alpha, and red indicates a failure.

Line 0 detects whether a process is being triggered at all.  This even will be triggered by any process in the server, when activated.  The output of line 0 serves to detect if the channel that tried to "contact" the brick is under the identity of Alpha, and says that only events 1 and 2 are to respond to it.

Lines 1 & 2 serve to indicate the result.  Supposing we trigger brick 1, brick(s) Q will all turn green.  Supposing we trigger brick 2, brick(s) Q will all turn red.

[SWAT One]

Bump.  If you need further explanations in this area, or explanations in the other areas, let me know.

[SWAT One]

Bump.  Did the explanation help at all?

[SWAT One]

Bump.

[Gen. Hothauser]

Isn't this essentially VCE's Function events?  Also, I like the new parameter event line ranges idea.

You are kind of going against the whole "compact" idea when using strings instead of a system like VCE replacers - some of those strings can get lengthy, and can become a real eyesore to read in large chunks.  This is why VCE is so good - it has a clear, well made, easily readable format for its replacers, values, and variables.  The unnecessary text was removed for the replacers, making typing less of a hassle.

I've never been a fan of compacting basic events into one line - just seems unnecessary to have so many compact, specific-use events.  Rarely do I ever get to line 99 for events, but when I do, the events on the brick are specific to the brick alone, and any sub-process common among any other bricks of the same design are evented into one other brick, and Functions are used.

(does not pertain to your topic)

Your use of strings instead of replacers got me thinking about how the VCE subjects are formatted, though.  It would have been nice if instead of VCE following the format of:

Code: [Select]

[Input] [Self/NamedBrick/Client/Player/Minigame] [VCE_IfVariable, VCE_IfValue]
It would have been more helpful to use the format of:

Code: [Select]

[Input] [Self] [Self/NameBrick/Client/Player/Minigame] [VCE_IfVariable/VCE_IfValue]
where the third field containing all of the standard subjects could be interchanged without messing up the text in the text box, and where VCE_IfValue relies not on the replacer format <var:subject:variable>, but instead just a variable that has been defined by the preceding subject drop-down.