Viewing Issue Simple Details Jump to Notes ] Wiki ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005138 [DCSS] Bug Report minor always 2011-12-29 14:19 2014-04-04 13:14
Reporter Galefury View Status public  
Assigned To KiloByte
Priority normal Resolution done  
Status closed   Product Branch 0.10 ancient branch
Summary 0005138: cloud targeting leaks information
Description 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.
Additional Information
Tags No tags attached.
Attached Files ? file icon cloud_info_leak_fix.patch [^] (659 bytes) 2013-09-02 06:16 [Show Content]

- Relationships
related to 0007093closedwheals Spell targeting can leak information about unseen monsters 

-  Notes
mumra (developer)
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.
KiloByte (manager)
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.
elliptic (developer)
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".
KiloByte (manager)
2013-03-15 15:17

elliptic: it's not that simple. Here's an example:


"," 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).
elliptic (developer)
2013-03-15 19:08

Okay, right, it is more annoying to compute this than I thought at first.
minmay (reporter)
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)
mumra (developer)
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.
minmay (reporter)
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.
Naruni (reporter)
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: [^]

FeyGriffin (reporter)
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.
KiloByte (manager)
2013-09-05 03:15

FeyGriffin: neither assuming walls nor open space is enough.
KiloByte (manager)
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.

- Issue History
Date Modified Username Field Change
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

Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker