forked from Strilanc/Tinker
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Docs.txt
46 lines (40 loc) · 2.12 KB
/
Docs.txt
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
----------------
General Architecture:
The bot is divided into components, which follow Model-View-Controller. The 'View' is usually suffixed with 'Control' and the
'Controller' is usually suffixed with 'Manager'. The View/Control is used for interacting with the user, the Controller/Manager
implements the IBotComponent interface, and the Model/whatever does all the nitty gritty stuff. As a rule of thumb, the main
bot class has no special knowledge of any component, the Controllers have no internal knowledge of their View, and the Models
have no knowledge of their Controller, View, or the main bot.
----------------
Concurrency via Futures and Call Queues:
Many classes are synchronized using message passing, not locks. Internally these classes use an inQueue (sometimes named 'ref') to
queue requests, and an outQueue (sometimes named 'eref') to queue outgoing events. Any 'public' function which is not thread-safe
will be private, and provide a public QueueThatFunction method which returns a future for the result.
Programming with message-passing and futures is not the same as programming with locks. In particular, there is no directy equivalent for
holding two locks at the same time. However, it is impossible to deadlock using message-passing (although you can create a self-
queueing loop). Keep in mind it is not guaranteed what thread the a future callback will arrive on. If your code uses
future.CallWhenReady(some_thread_unsafe_function), you have introduced a bug! Use the Queue-variants of the extension methods or
change the callback to properly synchronize the real callback.
----------------
Command Permission Levels ~:
root: control the bot
1 say stuff
2 download maps
3 access to other clients and servers
4 complete control over clients and servers
5 load plugins
users: control access to the bot
1 promote existing users
2 create new users
3 demote existing users
4 destroy users
5
games: control and host bot games
1 host normal games, view maps
2
3
4 manual instance control
5 manual control over bnet client advertising
local: No remote usage (eg. from bnet commands)
-
----------------