Re: [Crawl-ref-discuss] Auto-explore safety

[Odds O. <cra...@gm...>]

Thanks! Looks like there's more slowdown than I initially thought. Here's
some data (with substantial noise, but definitely some signal), from
wizmode experiments like you suggest:
normal; 10xD:1 - 5264 turns
x=1.5; 10xD:1 - 6283 (+19%)
x=2; 10xD:1 - 8810 turns (+66%)

normal; 10xD:2 - 5567 turns
x=1.5; 10xD:2 - 7040 (+26%)
x=2; 10xD:2 - 8141 turns = (+46%)

At both x=1.5 and x=2, I'm happy that the algorithm is working as desired;
I haven't tried smaller values (x=1 is likely to be a breakpoint where it
stops doing much at all). There's obviously no sensible way to quantify
that.

>From my dive into the autoexplore code, some things (like this) are not too
hard; and some things are nigh on impossible (without way more
understanding of the code than I have). Particularly, anything that cares
about where you reveal a square from seems tough, and anything that just
cares about what square you reveal next is more likely to be doable.

On Mon, Oct 31, 2016 at 8:04 AM, Alex Jurkiewicz <al...@ju...> wrote:

> Nice work! If you could collect data showing what the impact is on total
> level explore time that would probably very helpful. For example, visit a
> floor in wizmode, use &G to remove all creatures, time auto explore, then
> &R egenerate the level.
>
> I mentioned in the crawl thread, but biasing to minimise discovered
> squares would be great. In particular, avoid opening doors and if you have
> to, prefer to do it from the side.
>
> On Mon., 31 Oct. 2016, 10:50 am Odds Odds, <cra...@gm...> wrote:
>
>> Hi,
>>
>> I've been experimenting with options to make autoexplore safer by
>> exploring near upstairs. The intended change is that exploration is
>> generally around up-stairs, creating a safer map - because the explored
>> area is more circular, so the player is near more safe places, and the
>> up-stairs are easily accessed from the whole explored territory. The
>> trade-off is that exploration is likely to be slower, as it involves more
>> backtracking across explored territory.
>>
>> Thoughts on whether something like this might get merged - either behind
>> an option, or as default behaviour?
>>
>> The change I've tried so far is to aim for the unexplored square which
>> minimises:
>>
>> [Distance from player] + 2*[Distance from [nearest up-stair to player]]
>>
>> Experiments seem to show that this has the desired effect, and that it
>> slows down exploration a bit (from a *very* small sample, maybe 20%).
>>
>> Prototype can be seen on https://github.com/CrawlOdds/
>> crawl/tree/explore_from_stairs if you want to try it - though this is
>> likely to have bugs and/or use the autoexplore code in unintended ways
>> (since I don't understand it fully).
>>
>> Cheers,
>>
>> Odds
>> ------------------------------------------------------------
>> ------------------
>> The Command Line: Reinvented for Modern Developers
>> Did the resurgence of CLI tooling catch you by surprise?
>> Reconnect with the command line and become more productive.
>> Learn the new .NET and ASP.NET CLI. Get your free copy!
>> http://sdm.link/telerik_______________________________________________
>> Crawl-ref-discuss mailing list
>> Cra...@li...
>> https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
>>
>
> ------------------------------------------------------------
> ------------------
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> _______________________________________________
> Crawl-ref-discuss mailing list
> Cra...@li...
> https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
>
>