Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old February 8, 2016, 10:53   #1
PowerWyrm
Prophet
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,672
PowerWyrm is on a distinguished road
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.
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Old February 8, 2016, 11:04   #2
PowerWyrm
Prophet
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,672
PowerWyrm is on a distinguished road
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.
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Old February 8, 2016, 11:10   #3
PowerWyrm
Prophet
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,672
PowerWyrm is on a distinguished road
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?
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Old February 8, 2016, 21:46   #4
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 7,862
Donated: $60
Nick will become famous soon enough
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).
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old February 8, 2016, 21:55   #5
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,419
Donated: $40
Pete Mack is on a distinguished road
The ANSI changes are essentially all true/false lowercase, with a few changes to main-win.c to allow. 64bit builds.
Pete Mack is offline   Reply With Quote
Old February 9, 2016, 14:55   #6
PowerWyrm
Prophet
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,672
PowerWyrm is on a distinguished road
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.
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Old February 9, 2016, 21:46   #7
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 7,862
Donated: $60
Nick will become famous soon enough
Quote:
Originally Posted by PowerWyrm View Post
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.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old February 10, 2016, 11:01   #8
PowerWyrm
Prophet
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,672
PowerWyrm is on a distinguished road
Quote:
Originally Posted by Nick View Post
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 View Post
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.
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Old February 11, 2016, 13:29   #9
PowerWyrm
Prophet
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,672
PowerWyrm is on a distinguished road
Quote:
Originally Posted by PowerWyrm View Post
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).
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Old February 11, 2016, 17:46   #10
PowerWyrm
Prophet
 
PowerWyrm's Avatar
 
Join Date: Apr 2008
Posts: 2,672
PowerWyrm is on a distinguished road
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.
__________________
PWMAngband variant maintainer - check http://powerwyrm.monsite-orange.fr (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!
PowerWyrm is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
4.1 feature branches Nick Vanilla 117 June 26, 2016 06:20
Implementing stat swap concepts Derakon Development 11 December 10, 2015 12:58
Implementing the restructure changes PowerWyrm Development 244 October 28, 2015 17:55
Implementing different difficulty levels Greebley Vanilla 14 January 11, 2012 15:39
Angband source branches vs trac ctate Vanilla 1 July 14, 2007 12:43


All times are GMT +1. The time now is 12:59.


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