embark-assistant

[myk002]

The existing analysis logic will likely still be correct, but the integration with the DF interface will need to be redesigned. Input widgets would be nicer using the Lua widget toolset, but the existing full-screen text input interface would work if converting it is too much trouble. Overlaying results on the map would need complete reworking, though.

world map region identification numbers have also changed, so we'll have to compensate for that. discord discussion

[myk002]

some notes and thoughts:
it would be nice to integrate into the vanilla UI and algorithm. We could add vanilla-like widgets to the list and implement the corresponding predicate functions. If the underlying algorithm calls functions in a vector, we could add our predicates to that vector. The advantages are that we don't need to reimplement the loop logic or the scanning/matched region overlay logic.

BUT

the vanilla algorithm appears to do no caching. embark-assistant goes about the same speed as the vanilla algorithm for the first search, but subsequent searches are much much faster. the vanilla algorithm is slow every time. Can we replace the matching portion of the algorithm so we can take advantage of caching?

In addition to the scanning/matching phase, we might also want to implement an overlay panel that shows more information about the area that the cursor is over.

[myk002]

We also need to consider the question: how much information should we show/be able to filter on? We could display some baseline of useful, uncontroversial information, and if mortal mode is not enabled in the DFHack preferences, we could display more detailed/hidden information.

E.g. always display:

• presence of a waterfall
• whether the area is flat
• number of towers within striking distance

When mortal mode is disabled, additionally display:

• what kinds of syndromes evil weather can inflict
• blood rain
• reanimation effects
• thralling effects
• how many adamantine spires/approx adamantine count

[myk002]

some notes from PatrikLundell: http://www.bay12forums.com/smf/index.php?topic=169634.msg8508451#msg8508451

[PatrikLundell]

You say that the native DF search is slow every time. Is this still the case, or is that statement based on how it worked before the Premium release? The reason for this question is that DF now loads the mid level tiles and doesn't unload them, which would suggest to me that the loading that took the most of the time wouldn't have to be repeated. I haven't looked at the large block structures (don't remember their name. the structure that covers several world tiles in one big block).

[myk002]

It's in reference to v50 UI and behavior. In the current v50 vanilla UI, two successive site searches will both execute at the same speed. I'm not sure what's happening internally on the second search and why it still takes as long as the first, but it's pretty clear that whatever embark-assistant was doing in pre-v50 to speed up later searches, vanilla is not doing it in v50.

[myk002]

Another thing to filter on and to make visible on the map: presence and strength of wind

edit: more ideas from reddit:

• number of z levels
• shallow magma

[PatrikLundell]

A reasonable additional filter parameter.