cheesecookie
Member
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.
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.
Code:
[294] Madness Bakery
Setting: lastEncounter: Witchess Bishop
Encounter: Witchess Bishop
Setting: _lastCombatStarted: 20161008202800
Setting: _sourceTerminalDigitizeMonsterCount: 2
Setting: relayCounters: 293:Romantic Monster window end loc=* type=wander:rparen.gif
Setting: relayCounters: 293:Romantic Monster window end loc=* type=wander:rparen.gif:323:Digitize Monster loc=* type=wander:watch.gif
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.
Code:
[294] The Deep Machine Tunnels
Encounter: Witchess Bishop
Setting: _lastCombatStarted: 20161008202834
Setting: _sourceTerminalDigitizeMonsterCount: 3
Setting: relayCounters: 293:Romantic Monster window end loc=* type=wander:rparen.gif
Setting: relayCounters: 293:Romantic Monster window end loc=* type=wander:rparen.gif:333:Digitize Monster loc=* type=wander:watch.gif
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.