Bug - Fixed r17261: Arrowed and digitized the same monster, both trigger digitize tracking in DMT

When I have monster X both arrowed and digitized, encountering the arrowed version in the DMT advances my digitize counter.

So, at a point in my run, I have both arrow and the digitize pending, I went to the Madness Bakery to burn off the digitize since it has priority.


So far, so good. I still have an arrow of the Bishop pending. Since I couldn't figure out how this was handled from the commit log, I decided to test it.


My arrowed monster is still on the list (which I expect because that isn't accounted for by r17261). But my digitize got pushed out from 323 to 333. Since digitize is known determinisitc, maybe just checking that the digitize is expected (since it has priority over the arrow) may be sufficient?

This also breaks my own ASH code that attempts to resolve this problem, but that's an issue I have to deal with myself.

LoLoLoLoLoLoL

I don't actually bother checking the window, though I could...

If both windows are up, it's completely impossible (even for a person sitting there, thinking through all the possible game mechanics) to determine which wanderer you just saw. Technically you can tell once you see the other wanderer, if they are outside DMT, but that logic is too complicated to handle, I think.

I thought about putting a note in the commit saying the tracking isn't perfect (because it can't be). I suppose it should check for the counter being about to expire, but it's going to break anyway when someone brings an arrowed monster in the DMT while the digitize counter is at 0. Unless they always show up in a certain order, but I think it's random what order they show up in.

Also, I have no plan to handle an arrowed monster showing up there, since it's out of Standard and sufficiently unpredictable that using DMT shouldn't save turns anyway.

lostcalpolydude said:

I don't actually bother checking the window, though I could...

If both windows are up, it's completely impossible (even for a person sitting there, thinking through all the possible game mechanics) to determine which wanderer you just saw. Technically you can tell once you see the other wanderer, if they are outside DMT, but that logic is too complicated to handle, I think.

I thought about putting a note in the commit saying the tracking isn't perfect (because it can't be). I suppose it should check for the counter being about to expire, but it's going to break anyway when someone brings an arrowed monster in the DMT while the digitize counter is at 0. Unless they always show up in a certain order, but I think it's random what order they show up in.

Click to expand...

I have many, many data points showing that the digitized monster comes first (before an arrowed monster). And no counter-examples. My ASH code that handles this in HCCS was based on this ordering and hasn't had any issues that I'm aware of.

lostcalpolydude said:

Also, I have no plan to handle an arrowed monster showing up there, since it's out of Standard and sufficiently unpredictable that using DMT shouldn't save turns anyway.

Click to expand...

Of course, I had assumed that you only did digitize because it was deterministic.

This is probably all handled in 17269. I would bet money on this being handled wrong when another wanderer source is created, though probably not in a way that most people will notice.

lostcalpolydude said:

This is probably all handled in 17269. I would bet money on this being handled wrong when another wanderer source is created, though probably not in a way that most people will notice.

Click to expand...

Heh, yeah, probably. Or if someone arrows and digitizes a holiday wanderer. Thanks! I'll repeat my test case after rollover and confirm the results.

cheesecookie said:

Or if someone arrows and digitizes a holiday wanderer.

Click to expand...

Naturally wandering monsters are often nocopy, though I guess TLAPD enemies are not.

lostcalpolydude said:

Naturally wandering monsters are often nocopy, though I guess TLAPD enemies are not.

Click to expand...

Well, that's a bit more of an edge case. In any case, r17269 passes the test I tried earlier so it seems all good to go for now. Thanks for the patch!