Dungeon Crawl Stone Soup Tracker - DCSS
Viewing Issue Advanced Details
5138 Bug Report minor always 2011-12-29 14:19 2014-04-04 13:14
Galefury Local  
KiloByte Windows  
normal Tiles  
closed 0.10 ancient branch  
ae15d2e done  
none    
none 0.14 ancient branch  
0005138: cloud targeting leaks information
In tiles spreading clouds (ice, poison) display what locations they will affect before casting. This depends on the adjacent terrain. The preview is the same no matter whether the adjacent terrain is explored or not. This leaks information.

I don't know how the cloud targeting display works in console, but I expect the same information leak to be present.
related to 0007093closed wheals Spell targeting can leak information about unseen monsters 
? file icon cloud_info_leak_fix.patch [^] (659 bytes) 2013-09-02 06:16 [Show Content]
Issue History
2011-12-29 14:19 Galefury New Issue
2013-03-15 13:43 mumra Note Added: 0021531
2013-03-15 14:41 KiloByte Note Added: 0021532
2013-03-15 15:05 elliptic Note Added: 0021537
2013-03-15 15:17 KiloByte Note Added: 0021539
2013-03-15 19:08 elliptic Note Added: 0021545
2013-03-20 22:05 minmay Note Added: 0021721
2013-03-20 22:18 mumra Note Added: 0021722
2013-03-20 22:50 minmay Note Added: 0021723
2013-07-06 07:27 Medar Relationship added related to 0007093
2013-09-02 06:16 Naruni Note Added: 0023962
2013-09-02 06:16 Naruni File Added: cloud_info_leak_fix.patch
2013-09-02 06:33 Naruni Issue Monitored: Naruni
2013-09-02 06:36 Naruni Note Edited: 0023962
2013-09-05 01:03 FeyGriffin Note Added: 0023972
2013-09-05 03:15 KiloByte Note Added: 0023973
2013-12-16 01:24 KiloByte Note Added: 0024742
2013-12-16 01:24 KiloByte Status new => resolved
2013-12-16 01:24 KiloByte Fixed in Branch => 0.14 development branch
2013-12-16 01:24 KiloByte Resolution open => done
2013-12-16 01:24 KiloByte Assigned To => KiloByte
2014-04-04 13:14 Galefury Status resolved => closed

Notes
(0021531)
mumra   
2013-03-15 13:43   
This appears to still be the case. I wonder what the best solution is - we have to make an assumption for unexplored terrain, either that it's open or enclosed. I think it's best to assume that walls are there until it's explored, this makes sure the player is aware if there's any chance the clouds will explode on themselves.
(0021532)
KiloByte   
2013-03-15 14:41   
The info leak is really minor: it's quite hard to tell between anything other than "a dead end" vs "a big open area just outside", further limited by the spell's range being smaller than LOS.

When I coded this (e16a1ef9), I was already aware of this leak, but preferred to get at least something that works first.

It would be a bug to claim the cloud will hit something that it won't, so assuming walls is not a good idea. On the other hand, note that the targetter shows three values: "this place won't be hit", "maybe hit", "surely hit". In case of a doubt, everything should go to the middle region.
(0021537)
elliptic   
2013-03-15 15:05   
I think it is actually pretty clear what should be done here.

Have the targetter compute its won't/maybe/surely values once with the assumption that unexplored terrain is all open space and once with the assumption that unexplored terrain is all walls. Then mark squares as "won't be hit" if they are "won't be hit" under _both_ assumptions, mark squares as "surely hit" if they are "surely hit" under _both_ assumptions, and mark everything else as "maybe hit".
(0021539)
KiloByte   
2013-03-15 15:17   
elliptic: it's not that simple. Here's an example:

XXXXX
XXXXX
xx,xx
x.x*x
x1x.x
x.x.x
x.@.x
x...x

"," stands for unknown floor, "X" for unknown wall. You aim at "*", the cloud size is 7. Will the monster at "1" be hit? Assuming all walls, there will be no passage at ",". Assuming all open, the cloud will harmlessly spill into the "X"es (which are really walls).
(0021545)
elliptic   
2013-03-15 19:08   
Okay, right, it is more annoying to compute this than I thought at first.
(0021721)
minmay   
2013-03-20 22:05   
How about this: cloud fill treats out of LOS squares as walls. That way, there are no problems with unexplored territory. And it's a nerf to some overpowered spells too!

(I'd still like for player clouds to be removed when they leave LOS, too)
(0021722)
mumra   
2013-03-20 22:18   
If the LOS edge is treated as a wall then you can abuse LOS around terrain to shape the cloud placement. (I'm not sure, maybe this could be tactical and interesting, but it sounds dodgy to me.)

On the other hand you could treat out-of-LOS as open space, but not actually create any of the clouds that would fall outside LOS.

Either way; both these solutions plausibly fix the issue without the will hit / won't hit complexity.
(0021723)
minmay   
2013-03-20 22:50   
I don't see that being more of an abuse than using LOS around terrain to place clouds out of LOS! But yeah, treating it as open space would work too.
(0023962)
Naruni   
2013-09-02 06:16   
(edited on: 2013-09-02 06:36)
Uploaded patch file which will cause the targetter to treat unknown cells as cloudable and will not reshape the cloud.

POSSIBLE BUG but I can't get it to happen: does a monster's cloud spell use the targetter function? Even if it does, I don't see it having much effect on gameplay, but could it crash the game?

Filename: cloud_info_leak_fix.patch
Master branch: 7a74111b

Edit: I made another patch to cause clouds to be not dropped outside of LOS here: https://crawl.develz.org/mantis/view.php?id=5548 [^]

(0023972)
FeyGriffin   
2013-09-05 01:03   
I think that this is really a 2 part problem - the targeting (and therefore the initial feedback) should assume that out of LOS is empty space (unless previously explored - in this case walls should be assumed to still be there). On casting the cloud the actual terrain should be used to affect the cloud - without revealing said terrain directly.
(0023973)
KiloByte   
2013-09-05 03:15   
FeyGriffin: neither assuming walls nor open space is enough.
(0024742)
KiloByte   
2013-12-16 01:24   
The info leak is now fixed, although I'm afraid shaping the affected area is now a lot easier. That's a separate (if related) issue, though.