Implementing the changes from the 4.1 feature branches

[PowerWyrm]

Only a couple of weeks after porting the 4.0 features, it's time to look at the new stuff from the 4.1 feature branches...

Currently, there are four batches of changes to look at:
- fixes
- cone-shape breaths
- player knowledge
- ANSI standard

Fixes are trivial, most of them are irrelevant to PWMAngband. I'll add cone-shape breaths blindly into the current PWMAngband version since it doesn't require any core changes. About player knowledge, I'll have to look that one very closely, since PWMAngband already uses a different system (cave flags like SQUARE_MARK are already part of the player structure, since they are different for each player). Concerning the ANSI changes, I need to adapt them to my compiler.

[PowerWyrm]

Commit ed778dd: second parameter for the DRINK_BREATH activation has been set to 30, while the potion has a parameter set to 20.

On a side note, activation for WAND_BREATH and the corresponding wands (dragon frost/fire/breath) has been changed somewhere between 3.5 and 4.0 from BALL to BREATH. No idea if that was intended, but in that case the description for WAND_BREATH should probably be changed.

[PowerWyrm]

Parameter for monster breath has also been increased from 2 to 30. Is that really intended, as powerful monsters will have an arc of 60?

[Nick]

All intentional. You're right about the activation description; I think I kind of like the potion arc being smaller (which means it drops off more slowly in power).

[Pete Mack]

The ANSI changes are essentially all true/false lowercase, with a few changes to main-win.c to allow. 64bit builds.

[PowerWyrm]

Done and done. Now I'm standing at the foot of the big "player knowledge" cliff...

Currently, PWMAngband already has a separate cave structure for each player containing the SQUARE_MARK and SQUARE_DTRAP flags, the "flow" fields (cost/when) and the feeling squares. This will become the "known cave".

Easy: cave->feat. Should be as simple as porting the first few changes from the master branch and adding "feat" to the player cave structure. This will require a savefile change, but should not break savefile compatibility. I will probably be able to add this to the current version.

Unknown: cave->trap & cave->mon. Looking at the new changes, I've not seen anything related to these yet. Am I missing something? Probably not since monster detection is temporary (doesn't affect cave) and only the player can interact with traps (so they are instantly known). For PWMAngband, I should probably add cave->trap to the player cave structure and do the same as cave->feat, since other players may trigger/detect/disarm traps out of LOS of a player on the same level.

Hard: cave->obj. Huge change there... I still don't see how I can port that easily, since I cannot create a copy of caves and store stocks for each player. Currently, PWMAngband uses a simplified system for object knowledge: everything except flavor is stored on the object, so a player identifying an object will identify all properties except its flavor for all players. And the "marked" flag is already part of the player structure.

The Vanilla system is trivial ("known" field on the object):
- object is generated: object is added to list, known object is null
- object is detected: known object is created with an "unknown object" tval
- object is seen: known object is updated with basic properties
- object is picked up (and worn): object is removed from list and added to gear, known object is updated with learned properties
- object is dropped: object is removed from gear and added to list

The PWMAngband system... not so trivial ("known" field on the object, "obj_marked" array on the player):
- object is generated: object is added to list, known object is null, obj_marked is null for every player
- object is detected by player: known object can be anything (could remain null to spare memory), obj_marked is set to "unknown object" for that player
- object is seen by player: known object can be anything (could remain null to spare memory), obj_marked is set to something (flag? tval? object?) for that player
- object is picked up (and worn): object is removed from list and added to gear, known object is created with learned properties, obj_marked is null for every player that can "see the pickup"
- object is dropped: object is removed from gear and added to list, obj_marked is set for every player that can "see the drop"

The biggest problem here will be memory management. I could simply align the obj_marked array with the corresponding cave_k->objects list, but it would probably result in memory overflow. So I will probably have to keep a flag for "marked" objects.

[Nick]

Currently, PWMAngband uses a simplified system for object knowledge: everything except flavor is stored on the object, so a player identifying an object will identify all properties except its flavor for all players.

Right - I had been kind of assuming the split would make things easier for you, not harder.

There will be another big shake-up with rune-based ID, where known objects are going to become proper (partial or full) copies of actual objects, and what to fill in is determined by object knowledge on the player struct.

[PowerWyrm]

Right - I had been kind of assuming the split would make things easier for you, not harder.

That's because V assumes in many places that there is only one player. So there's one "cave" entity, one "player" entity, visibility is put on monster/object, and so on... The "simplified" system in PWMAngband, for example, forced me to forget about persistence of object visibility on static levels, because it would require having "marked" on all objects and make that an array of MAXPLAYERS size. Doing so would make porting player knowledge trivial (just changing "marked" to "known"). But then how to manage that array, considering that players come and go... and what about non-connected players? And that would consume a ton of memory... So the easiest way for me will be to keep "marked" on the player and just change the way it's set/unset as objects get created/destroyed/dropped/picked up...

There will be another big shake-up with rune-based ID, where known objects are going to become proper (partial or full) copies of actual objects, and what to fill in is determined by object knowledge on the player struct.

That's why I'll add the "known" field on the object. This part should not impact object visibility and really help for future changes. The only difference will be the split between "known" object and "marked" flag.

[PowerWyrm]

Unknown: cave->trap & cave->mon. Looking at the new changes, I've not seen anything related to these yet. Am I missing something? Probably not since monster detection is temporary (doesn't affect cave) and only the player can interact with traps (so they are instantly known). For PWMAngband, I should probably add cave->trap to the player cave structure and do the same as cave->feat, since other players may trigger/detect/disarm traps out of LOS of a player on the same level.

New terrain knowledge is now implemented. Sometimes it feels weird, like when a player uses earthquake/destruction and another player which had previous knowledge of the terrain discovers the new layout.

As I feared, the new knowledge doesn't take into account the trap layout, so traps are revealed/removed for any player on the level. As a consequence, this is also the case for glyphs, and since monsters can interact with them, any player out of LOS of a monster removing a glyph will still see that glyph removed. Easy to reproduce with the latest autobuild (angband-4.0.3-138-g4f1cac1).

[PowerWyrm]

I'm struggling to understand square_isview() vs square_isseen() in project-feat.c -- there's even one occurence of square_isknown() in project_feature_handler_MAKE_DOOR(). Each handler seems to use these randomly for messages, obviousness, forgetting, updating... For example, destroying a door uses "view", while destroying a wall uses "seen", even if both effects have the same result.

I think square_isview() should be used only for effects that have no impact on terrain, like elemental effects; square_isseen() should be used for the rest; square_isknown() should not be used. The difference is probably marginal though... maybe only for characters wandering in the dungeon without a light.

[PowerWyrm]

I don't understand the "square_mark" part in effect_handler_MAP_AREA.

			/* Forget unprocessed, unknown grids in the mapping area */
			if (!square_ismark(cave, y, x) && !square_isknown(cave, y, x))
				square_forget(cave, y, x);

The only purpose of "marking" the grids in this function is this bit of code... that does nothing. Forgetting a square sets cave_k feature to FEAT_NONE... but if the square is not "known", cave_k feature is already set to FEAT_NONE.

And looking at the latest build, mapping doesn't work correctly: just use *destruction* and then mapping, the squares that should be mapped around @ are not mapped properly.

Edit: enlightenment is also broken; using *destruction* and then enlightenment doesn't refresh all grids properly.

[PowerWyrm]

Most of the previous stuff probably comes from the fact that being "known" sometimes means that the "cave" square is equal to the "cave_k" square. The negation of that should then be "cave square not equal to the cave_k square", and not "cave_k square is FEAT_NONE".

[PowerWyrm]

Alright... creating square_isnotknown() that does (cave->squares[y][x].feat != cave_k->squares[y][x].feat), using the same code in wiz_light() as in effect_handler_MAP_AREA() and just replacing the call to "!square_isknown" by "square_isnotknown" in the previous code fixes enlightenment.

Problem is... this still doesn't fix mapping.

[PowerWyrm]

Ok found the reason why mapping was still broken: enlightenment uses delayed screen update (PU_UPDATE_VIEW) while mapping uses immediate screen update (square_light_spot). Removing the calls to square_light_spot() and adding delayed update fixes mapping.

[Nick]

Thanks for chasing this stuff up. I knew I had not got the cave stuff quite right.

I had planned to do some fixes on master, but I'm deep in the rune-based ID branch at the moment and didn't want to lose my place there. But I should be back to it before too long.