Viewing Issue Simple Details Jump to Notes ] Wiki ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0004280 [DCSS] Bug Report major have not tried 2011-07-17 23:46 2011-12-27 20:45
Reporter KiloByte View Status public  
Assigned To edlothiol
Priority normal Resolution done  
Status resolved   Product Branch 0.9 ancient branch
Summary 0004280: tiles use information not in mon_info
Description There is a number of information leaks in tiles:
* the appearance of a Pan lord makes it possible to get his maxhp, ac and ev (not straightforwardly, a hash)
* ghosts show their maxhp (hashed), AC (fuzzied straight), the value of best skill (straight)
* probably some more for regular monsters

On the other hand, most information from mon_info is not handled, causing problems if a monster tile has to be recreated while out of view. All details, including enchantments, are lost, you need to notice the monster again to get that info.

I'm setting severity to "major" since tile data needs to be invalidated at some points or we risk crashes. I'll do that only when the number of tiles has changed (causing loss of memory out of LOS...), but if this bug is fixed, there'd be no need to save the tilemcache at all.
Additional Information
Tags No tags attached.
Attached Files

- Relationships
related to 0004771closededlothiol items out of LOS sometimes turn invisible upon leaving and reentering a level 

-  Notes
edlothiol (developer)
2011-11-07 01:35

You fixed this already for pan lords, right?
I think the main problem that remains is how to deal with ghosts, since they use the damage and the ac to decide which weapon/armour is displayed. Should we add the (fuzzed) damage/ac to the monster_info ghost struct, or find some other way to decide on the equipment?
Apart from this, I don't see any major obstacles to making everything from tile_place_monster onwards use monster_info (i.e., all the necessary information seems to be there). Do you know of anything I might have missed?
KiloByte (manager)
2011-11-07 01:40

The easiest way to check would be finally purging reference to the real monster from mon_info.
Kyrris (reporter)
2011-11-07 06:15

With the ability to look up log files from both online and offline games, why are the ghost infoleaks even a problem? They allow less technically-minded players easier access to information that is already available in a more precise format.
edlothiol (developer)
2011-11-07 18:04

I tend to agree with that.

kilobyte: Unless you have more changes for this already lined up, I'll start working on fixing the remaining problems and making the tile picking code use monster_info exclusively.
edlothiol (developer)
2011-11-16 00:57

I've done the necessary changes in the tile picking code (including the mcache, and removing monster_info::mon()), but not yet the saving/loading (which I'm not at all familiar with).

One remaining problem is that the monster_info::pos values are invalid after loading a level, since they're relative to the player position. They should probably not be saved at all (and instead regenerated after loading), and/or be normal grid coordinates; having them be player-relative doesn't really hide any information.

Another thing I noticed is that quite a few monster_info properties aren't saved at all. This includes draco_type, which is needed. The others are holi, mintel, mresists, mitemuse, mbase_speed, two_weapons and no_regen, which are probably not strictly necessary; do you know if there is a reason for not saving them?
KiloByte (manager)
2011-11-16 02:14

mcache shouldn't be saved at all -- everything is in monster_info, and if something is missing it needs to be added.

Not sure what would be the issue with monster_info::pos -- does tile ever depend on where the monster is? (mon_info stores what the player knows about the monster, and thus it needs to be preserved out of view...)

draco_type is obviously needed. Holiness is a function of type/base_type, so is mintel and the rest. mresists might be unknown for ghost_demons, not sure what to do there. We currently don't allow viewing monsters out of LOS, right? Still, this probably should be preserved.

In other words: let's finish the initial direction, which is having everything the player knows in mon_info and nothing the player does not know.
edlothiol (developer)
2011-11-16 14:10

pos is used a few times to get to the cell the monster is in, for example to check if it is in water (merfolk) or on fire (burning bushes). So it should always point to the coordinates of the map_knowledge the monster_info is in, which doesn't currently work after loading (since the player could have been in another location when it was saved).
edlothiol (developer)
2011-11-23 19:56

I pushed the branch (tiles-monster-info). Kilobyte, as far as I can tell, everything works, but could you take a look at it before I merge, at least to check I did the save compatibility right in 30efafb7cff9?
edlothiol (developer)
2011-12-27 20:45

As far as I can see, all problems in the bug have now been adressed.

- Issue History
Date Modified Username Field Change
2011-07-17 23:46 KiloByte New Issue
2011-10-19 00:02 edlothiol Relationship added related to 0004771
2011-11-07 01:35 edlothiol Note Added: 0015739
2011-11-07 01:40 KiloByte Note Added: 0015740
2011-11-07 06:15 Kyrris Note Added: 0015741
2011-11-07 18:04 edlothiol Note Added: 0015748
2011-11-16 00:57 edlothiol Note Added: 0015870
2011-11-16 02:14 KiloByte Note Added: 0015871
2011-11-16 14:10 edlothiol Note Added: 0015875
2011-11-23 19:56 edlothiol Note Added: 0015939
2011-12-27 20:45 edlothiol Note Added: 0016402
2011-12-27 20:45 edlothiol Status new => resolved
2011-12-27 20:45 edlothiol Fixed in Branch => 0.10 development branch
2011-12-27 20:45 edlothiol Resolution open => done
2011-12-27 20:45 edlothiol Assigned To => edlothiol

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