-
Notifications
You must be signed in to change notification settings - Fork 0
/
CrowdControl.Packs.Base.lua
117 lines (92 loc) · 4.13 KB
/
CrowdControl.Packs.Base.lua
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
--[[ Effect Pack Terminology
Pack: (AKA Effect Pack, Module...)
* Adds effects to the CrowdControl.Effects table
* New packs can nest their effects inside sub-tables to have unique paths
* It may be more convenient to keep all effects in a shared namespace
* We will see what the convention ends up being used
Effects: (AKA Effect Functions)
* Keys in the CrowdControl.Effects table must always be purely lowercase strings, for technical reasons
* Can be of any 'order':
- A function that directly affects the game is a first order effect
- A function that dynamically delegates to another function to affect the game is a second order effect
- etc...
* Effects have a responsibility to eventually call NotifyEffect on their id
* Return a boolean to automatically call NotifyEffect by the surrounding call of InvokeEffect (true for success/finished, false for retry/failure)
* Any time an effect is invoked, it should be via InvokeEffect in case of timeouts and to automatically notify
* An effect can be formed by binding a trigger with an action via BindEffect (see below for triggers and actions)
* Timed effects can be formed via TimedEffect by providing an enable function and corresponding disable function, enable will be given the duration
* If an effect should fail when it returns false instead of being retried, use RigidEffect, to reverse that use SoftEffect
The following are optional abstractions:
Actions: (AKA Child Effect Functions)
* An action usually performs the actual mechanics of the effect
* An action may be the final step for an effect instance, if so it should call NotifyEffect or return a boolean
Triggers: (AKA Parent Effect Functions)
* A trigger is a higher order effect that takes an effect id and an action (child effect)
* The trigger must eventually invoke the action with the id passed in
* Triggers that handle their actions in batches may benefit from using InvokeEffects
Parametric: (for Parametric.Actions and Parametric.Triggers)
* Not directly a trigger or action, until called with some arguments (one step removed to be more general)
]]
local cc, invoke = CrowdControl, CrowdControl.InvokeEffect
local packs = ModUtil.Mod.Register( "Packs", cc, false )
local pack = ModUtil.Mod.Register( "Base", packs )
pack.Effects = { }; pack.Actions = { }; pack.Triggers = { }
pack.Parametric = { Actions = { }, Triggers = { } }
local getCheck
do
-- Triggers
function getCheck( check, ... )
if type( check ) == "string" then
check = ModUtil.Path.Get( check )
end
if ModUtil.Callable( check ) then
check = check( ... )
end
return check
end
function pack.Parametric.Triggers.Condition( check )
return function( ... )
if getCheck( check, ... ) then
return invoke( ... )
end
return false
end
end
function pack.Parametric.Triggers.AntiCondition( check )
return function( ... )
if not getCheck( check, ... ) then
return invoke( ... )
end
return false
end
end
function pack.Parametric.Triggers.Delay( s )
return function( ... )
local args = table.pack( ... )
return thread( function( )
wait( s )
return invoke( table.unpack( args ) )
end )
end
end
-- Actions
function pack.Parametric.Actions.Invoke( func, ... )
local args = table.pack( ... )
return function( )
return true, func( table.unpack( args ) )
end
end
-- Effects
-- ...
end
-- Example of how to put effects into the centralised Effects table:
-- since this is the default pack we would merge directly (but there are no effects in this pack)
-- ModUtil.Table.Merge( cc.Effects, pack.Effects )
-- Internal
pack.Internal = ModUtil.UpValues( function( ) return getCheck end )
-- If you have internal components (local variables and functions: i.e. local1, local2, local3 etc.)
-- You can add a global interface for them with this snippet:
-- pack.Internal = ModUtil.UpValues( function( ) return local1, local2, local3 end )
-- This allows for them to be manipulated by the REPL (interactive console / terminal), for example:
-- PathToPackHere.Internal.valueA = 5 -- sets the local valueA to 5 from the REPL
-- PathToPackHere.Internal.runTestB( ) -- calls the local function runTestB from the REPL