Angband Forums

Angband Forums (http://angband.oook.cz/forum/index.php)
-   Development (http://angband.oook.cz/forum/forumdisplay.php?f=10)
-   -   Implementing the changes from the 4.1 feature branches (http://angband.oook.cz/forum/showthread.php?t=7720)

PowerWyrm February 8, 2016 10:53

Implementing the changes from the 4.1 feature branches
 
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 February 8, 2016 11:04

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 February 8, 2016 11:10

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 February 8, 2016 21:46

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 February 8, 2016 21:55

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

PowerWyrm February 9, 2016 14:55

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 February 9, 2016 21:46

Quote:

Originally Posted by PowerWyrm (Post 108852)
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 February 10, 2016 11:01

Quote:

Originally Posted by Nick (Post 108858)
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...

Quote:

Originally Posted by Nick (Post 108858)
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 February 11, 2016 13:29

Quote:

Originally Posted by PowerWyrm (Post 108852)
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 February 11, 2016 17:46

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.


All times are GMT +1. The time now is 04:50.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.