Improve event handling

[GregHib]

Different indexes per type:

Interface [id, component, option]
Object [id, option]
Player [index, option]
ItemOnItem [id, option, id2]

Type	Category	Global
"big_bones"	"_bones"	"_"

handlers.getOrDefault(entity.id, handlers.getOrDefault("_${entity.category}", handlers.get("_"))))

No need to store per entity. It currently uses 170MB to store them all!

Will still need event bus for some things (prob just for player?)

itemOnItem() {
}
on(ItemOnItem::class, "bowl_of_water", "pot_of_flour") { player: Player ->
}
useOnItem("bowl_of_water", "pot_of_flour") { player: Player ->
}
useOnObject("bones", "altar") { player: Player ->
}
use("category.bones", "object.altar") { player: Player ->
}
use("item.bones", "object.altar") { player: Player ->
}
cast("earth[a-z]+", "_") { player: Player ->
}
on("shop", "sample", "Take *") { player: Player ->
}

[GregHib]

Would be nice to have arriveDelay() by default for interactions but also disable-able.

[GregHib]

https://github.com/isaacs/minimatch#minimatch

[GregHib]

Event	Count
InterfaceOption	163
CombatSwing	130
CombatAttack	116
Command	111
Consume	109
NPCOption	89
Registered	79
CombatHit	73
TimerStart	65
TimerTick	41
TimerStop	40
PrayerStart	40
PrayerStop	39
InventoryOption	38
ObjectOption	38
ItemChanged	37
InterfaceOpened	31
ItemOnObject	26
VariableSet	24
Moved	19
Unregistered	15
CurrentLevelChanged	14
InterfaceClosed	12
InterfaceRefreshed	11
ItemOnNPC	11
ContinueDialogue	10
Death	8
Teleport	7
FloorItemOption	6
ItemOnItem	6
PlayerOption	5
ItemOnPlayer	4
InterfaceSwitch	4
CombatReached	3
CombatInteraction	3
CombatStop	3
AreaEntered	3
GrantExp	3
Consumable	3
LeaveClanChat	3
PublicQuickChat	2
PublicChat	2
AddFriend	2
DeleteIgnore	2
DeleteFriend	2
ItemUsedOnItem	2
AreaExited	2
MaxLevelChanged	2
AddIgnore	2
HuntNPC	1
HuntFloorItem	1
HuntPlayer	1
JoinClanChat	1
RegionRetry	1
PublicChatMessage	1
ClanQuickChatMessage	1
VariableAdded	1
PublicQuickChatMessage	1
KickClanChat	1
IntEntered	1
PrivateQuickChatMessage	1
InventoryUpdate	1
CloseInterface	1
BlockedExperience	1
VariableRemoved	1
OpenShop	1
PrivateQuickChat	1
StringEntered	1
PrivateChat	1
UpdateClanChatRank	1
ItemOnFloorItem	1
ClanChatMessage	1
PrivateChatMessage	1
AiTick	1
ReloadZone	1
StartBot	1
DoorOpened	1

[GregHib]

https://support.microsoft.com/en-gb/office/examples-of-wildcard-characters-939e153f-bd30-47e4-a763-61897c87b3f4

[GregHib]

• Phasing out Priority
• Move event emitting from Entities into a single Store
• Add a Handlers system for 1:1 O(1) lookups
• Add a different Events system for 1:Many lookups
• Optional: Add feedback mechanics for when actions failed Ai Robustness #241

[GregHib]

Phasing out priority

1. CombatSwing/Hit/Attack - Could have a list made and ordered with priority and have one handler that loops through them all.
2. onNPC FloorItemOption for "Take" - Should be handled by more specific overriding defaults
3. spellOnNPCApproach - Not used can be removed
4. itemChange(EquipSlot.Weapon, "worn_equipment", Priority.HIGH) { player -> should be fine to remove, but double check
5. AddFriend, DeleteFriend, LeaveClanChat, AddIgnore, RemoveIgnore etc.. - Problematic.
6. Consume - Tricky but defaults should be enough?
7. inventoryItem Overriding "Empty" for ectophial - defaults enough
8. NPCOption "Attack" Dummy - defaults enough

So long as the handlers are called in order of specificity it shouldn't be too difficult. As a stepping stone it might be worth counting the number of wildcard parameters as a psudo priority/depth until that system is in place.

It's going to be hard to determine specificity however, knowing that interface "option" > "component" > "id" means the order the options are passed in is important. I suppose a vararg passing these in should be fine, how it's possible to do that with wildcard matching I don't know though.

[GregHib]

Approaches:

Wildcard trie

https://gist.github.com/GregHib/90baabe67092f0acdc5cd6250ad6eac5

Have a character trie which contains all the wildcards, recursive search for the wildcard at runtime to get a list of handlers to execute.

Pros:

• No processing on startup just entry into trie

Cons:

• Uses extra memory to hold trie at all times
• Extra steps to look up list of handlers
• No guarantee of order of handlers ("" could match before "_dragon")
• Doesn't solve override problem

Id trie

Load all ids for each definition (npcs, objs, items) into trie's and use that to get list of wildcard matches before inserting into map

Pros:

• Low memory as Tries can be removed after startup
• No processing on lookup? Depends if want to keep pure * wildcards

Cons:

• Slower startup, potentially faster than wildcard filter though
• Uses a lot of memory if matching * against all (approx 7MB)
• Doesn't solve override problem

Filter all

On startup get definition and filter by wildcards to insert all into map

Pros:

• No processing on lookup - Depends if want to keep pure * wildcards or not

Cons:

• Slow startup time
• Nested loops/complexity in script helpers
• Uses a lot of memory if matching * against all (approx 7MB)

Handler and subscribers

Have a single handler and a bunch of subscribers to cover most scenarios

Pros:

• No processing on startup

Cons:

• Processing on lookup
• Doesn't handle pure * wildcards

Handler trie?

Have several roots for each type which get the correct handler?

[GregHib]

Make the naming consistent so approachNpc, npcApproachNpc etc...

[GregHib]

#471 removed priority and added a trie system in place with most content converted. It's not as perfect as I would like but it shall do for now. I would be good to phase out overriding and introduce something truely 1:1 but it's not a priority at the moment.