Home

Suggestions and changes. Feel free to edit this.

• Event system

We need something better than the “Request” system. An event system where we make analyzer listen to certain events and send out other events probably is the way to go. I think we can do this a bit like how we did the Data classes (ie. an “Event” class with subclasses like “ReceivedItemEvent” (or possibly better, “ReceivedItemsEvent” with a list of received items to reduce amount of events).

edit DrS: We definitely want to coalesce them into just one event, otherwise we’ll have TAEB’s problem where we aren’t sure whether or not to wait on an item because there might be a better one and we can’t carry both. I plan to have analyzers register themselves with an EventBus class, specifying which events they want to receive; this means we can broadcast lots of events without paying a performance penalty for having analyzers that simply do nothing. (Because the events are dynamically dispatched, the empty calls can’t be optimized away.)

• Sliding priorities

This makes analyzers more complex, but the idea is to make her smarter. Currently she will go to the other side of a level to kill a grid bug rather than picking up that wand of wishing right next to her. Instead of setting up a bunch of priorities in Globals.h we rather set a max priority for each analyzer and then each analyzer calculate an “urgency” (a value between 0.0 and 1.0) that we multiply with the max priority and we’ll get the priority of that analyzer.

edit DrS: That should be based on path length. Another good example would be not to run up ten levels to beatify armor if it has a low probability of being better than our current armor. (This suggests that each analyzer should be responsible for telling Beatitude how urgently it wants stuff beatified, and once a certain threshold is reached Beatify goes and does it — and when an altar is nearby, that threshold decreases.)

• Looting

Looting bothers me. The analyzers are supposed to be as independent as possible, yet several of them depend on the Loot analyzer. I don’t think the Loot analyzer should be a part of the main “framework” (ie. not an analyzer), and i don’t want Request (or an event system) to say “pick this up for me, please”. Each analyzer should be able to pick up items, but what should we do about visiting unknown stashes and going back to stashes?

edit DrS: Let Loot broadcast events like “stash nearby, here’s what I remember being there, do you want anything?” and let the analyzers that are responsible for those types of items decide. (This goes along with having Loot broadcast events saying “here’s stuff on the ground, do you want anything?” This way the analyzer responsible for e.g. armor gets to decide what armor should be picked up (no point in picking up mithril-coats if you’re wearing DSM, for example) while not having to have code that manipulates the pickup menu.)

• Fight (by DrS)

The Fight analyzer is currently pretty stupid about ranged attacks. It’ll happily dust E like crazy when something’s zapping a wand or breathing at it rather than getting out of the way. It should learn about ranged attacks, determine where they’re coming from, and try to get out of a line with their source. Of course, if it has reflection, it doesn’t need to care about wands of sleep, fire, etc. — but it should still care about striking.

• Level recognition (DrS)

I took a first stab at this with the LevelData class, but there’s currently no data for it and nothing uses it. At the very least, this should help saiph find secret doors on special levels; more advanced behavior might be needed when we get around to killing Rodney or such.

• Dig

Dig needs to be fixed so it can be re-enabled. DrSaiph gets stuck in the mines without it.