Player knowledge

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • Nick
    replied
    Originally posted by Ingwe Ingweron
    One bug found so far. If @ has autoinscription set up, say for MB1, that includes a !k so that it can't be "ignored" and then ignores all other instances of MB1, every new MB1 that @ comes across is inscribed upon walking over it, so it is not ignored.
    Thanks for the reminder - I had noticed some weirdness with autoinscription, but forgotten to chase it down.

    Originally posted by Ingwe Ingweron
    And now a replicable crash bug. Savefile is attached. @ is standing on the Dtrap line and has a Rod of Trap Location inscribed with @z2. Press z2, and game crashes.
    Thank you. This has a moderate chance of happening with every attempt at Trap Location (more precisely, if the region contains an unsensed wearable item). In fact, it has highlighted a number of unsafe bits of code which I need to fix. I'll put an improved version out when I have it.

    I'm pleased you made it to DL11 before getting a crash

    Originally posted by Ingwe Ingweron
    I love that "The only intentionally visible changes" all occur out of sight of @.
    Indeed. "The only visible change is that less changes are visible" might have been a better way of putting it

    Leave a comment:


  • Ingwe Ingweron
    replied
    And now a replicable crash bug. Savefile is attached. @ is standing on the Dtrap line and has a Rod of Trap Location inscribed with @z2. Press z2, and game crashes. Blind_Bat.zip

    Elsewhere on the level you will also see a magic book and prayer book reflecting the previously reported inscription/ignore bug. (Why does a Half-Troll warrior have an auto-inscription for magic books? I have a standard prf file that I load for all @. Nonetheless, if @ were a mage and didn't want to be bothered with new books already in inventory, the inscription/ignore bug would still apply.)

    I love that "The only intentionally visible changes" all occur out of sight of @.

    Leave a comment:


  • Ingwe Ingweron
    replied
    One bug found so far. If @ has autoinscription set up, say for MB1, that includes a !k so that it can't be "ignored" and then ignores all other instances of MB1, every new MB1 that @ comes across is inscribed upon walking over it, so it is not ignored. I assume this bug was introduced with the work *not* done on rune-based id.

    Leave a comment:


  • Nick
    replied
    Let's try that again (and yes, that does mean recycling my previous post with the essentials edited).

    There is a fairly thoroughly tested version of the player knowledge feature branch available. It is compiled for windows and OS X, or you can get a zip of the source.

    A few points to note:
    • It is *not* savefile compatible with 4.0.x (but you can use your 4.0.x lore.txt file with it).
    • The only intentionally visible changes are
      1. Dungeon features can change out of the player's LoS without the player seeing (doors open but apparently remain closed, walls apparently remain despite having been tunnelled away, etc) and
      2. Objects can be destroyed or picked up by monsters, and the player will not realise until they see the place the object was, or kill the monster and retrieve the object.

      In particular, rune-based ID has *not* been implemented yet.
    • There is a lot of underlying code change to achieve this modest outcome; consequently it is quite likely to crash, in which case sending me or posting a savefile would be appreciated.

    Leave a comment:


  • Nick
    replied
    Originally posted by Nick
    OK, I have just uploaded a mostly working version of the player knowledge branch - as in it failed to crash after 10-15 minutes of running around the town and dungeon
    Quick update - probably don't bother yet. The uploaded version crashes any time a monster drops an ego item. I'll post an updated version when it's a bit more stable.

    Leave a comment:


  • Nick
    replied
    Originally posted by Avenger
    Still, simply marking a monster's last known location is rather simple piece of the solution to the issue of separating a character's knowledge from reality.
    The general feeling was that that would be a bit confusing; it was also the only reason for including monsters in the player's knowledge, so I haven't bothered for now.

    Leave a comment:


  • Avenger
    replied
    I haven't read the entire thread, so I may be redundant here, but... Dwarf Fortress remembers the last place you saw a monster and leaves it marked on the map(until you see the tile again and refresh it). Of course, Dwarf Fortress also provides information on sound, smell, and tracks, so if you start borrowing from it, you'll have quite a lot more work then you might have expected to do here.

    Still, simply marking a monster's last known location is rather simple piece of the solution to the issue of separating a character's knowledge from reality.

    Leave a comment:


  • Nick
    replied
    OK, I have just uploaded a mostly working version of the player knowledge branch - as in it failed to crash after 10-15 minutes of running around the town and dungeon - for which I would appreciate testing by those that feel like it. It is compiled for windows and OS X, or you can get a zip of the source.

    A few points to note:
    • It is *not* savefile compatible with 4.0.x (but you can use your 4.0.x lore.txt file with it).
    • The only intentionally visible changes are
      1. Dungeon features can change out of the player's LoS without the player seeing (doors open but apparently remain closed, walls apparently remain despite having been tunnelled away, etc) and
      2. Objects can be destroyed or picked up by monsters, and the player will not realise until they see the place the object was, or kill the monster and retrieve the object.

      In particular, rune-based ID has *not* been implemented yet. I regard testing this as a favour to me rather than an exciting experiment for you.
    • There is a lot of underlying code change to achieve this modest outcome; consequently it is quite likely to crash, in which case sending me or posting a savefile would be appreciated.

    Leave a comment:


  • Nick
    replied
    Originally posted by Carnivean
    There are probably 800 threads on this.
    It turns out this is an exaggeration - there are in fact 66 threads containing "rune-based". The first of these was started in late 2008, just under 7 years ago and before the release of Angband 3.1. Some of them make pretty interesting reading.

    We have, in fact, been discussing the ID system and how it can be improved for longer than that. Many things have been suggested, but I think it's fair to say that we have reached a broad consensus that rune-based ID is at least worth a try.

    So what is going to happen is that it will be implemented in an experimental feature branch and released for playtesting. It may turn out that everyone hates it and we throw away the whole idea, or that the basic idea works but it needs major surgery; it is almost certain to need at least considerable calibration.

    In these circumstances, I am very glad to hear suggestions about how various aspects should work, but posting "we shouldn't do rune-based ID, we should do <idea X>" is not going to have any effect on the production of this experimental release.

    I should also make it clear that I took on the maintainership with the clearly enunciated intention of not being afraid to change things, and that intention hasn't changed. Anyone not happy with that is free to play old versions, or start their own variant, or make their own version and claim it's the real Angband.

    Leave a comment:


  • Egavactip
    replied
    That's fine, too.

    Leave a comment:


  • Bogatyr
    replied
    Originally posted by Egavactip
    This seems like a huge change, with possible major negative implications, for a very small issue.

    Moreover, it is an issue that could be solved in much simpler ways, such as scrolls or staves or magic item abilities such as "Mass Identify" that would identify all items in sight.

    Another magical ability could be item class identification. For example, if a weapon has this ability, the user could automatically identify any item of X class (potions, for example, or staves, or scrolls).

    Ideas like this are a lot better than replacing one of the fundamental engines of the game.
    If we want ID to progress to "disappearing" by the end of the game, just make it dependent on character level then, like pseudo-id at level 20.

    Leave a comment:


  • Egavactip
    replied
    This seems like a huge change, with possible major negative implications, for a very small issue.

    Moreover, it is an issue that could be solved in much simpler ways, such as scrolls or staves or magic item abilities such as "Mass Identify" that would identify all items in sight.

    Another magical ability could be item class identification. For example, if a weapon has this ability, the user could automatically identify any item of X class (potions, for example, or staves, or scrolls).

    Ideas like this are a lot better than replacing one of the fundamental engines of the game.

    Leave a comment:


  • Derakon
    replied
    Originally posted by Nick
    I think another change that probably should come in at the same time is that potions, scrolls etc get full ID from a single use, regardless of circumstance.
    I suggest that items with non-obvious effects be given a "flavorful" obvious effect. Like, wands of Wonder always give off a blue light when activated, potions of Neutralize Poison taste of onions, scrolls of Detect Invisible produce an ominous echo when read, etc. So if you don't get any "real" effect from using the item at least you get given the flavorful effect and thus a justification for why the character learns what it is.

    Leave a comment:


  • krazyhades
    replied
    Originally posted by Nick
    I think another change that probably should come in at the same time is that potions, scrolls etc get full ID from a single use, regardless of circumstance.
    I more or less agree. The first few times it can be fun to inscribe your guesses onto devices that did not appear to do anything, but it very quickly becomes tedious, especially when you feel like you have to inscribe all the unided consumables with the floor you found them in order to improve guessing.

    Though the latter would still be the case, if you want to be well prepared for an emergency use-id...the floor of discovery matters a great deal when you're wondering "hmm which of these is more likely to be Neutralize Poison?"

    Leave a comment:


  • Nick
    replied
    Originally posted by Estie
    You can throw out the runebased system without any "intended" methods for identifying each rune, and see what players come up with. If some runes turn out to be annoyingly hard to find out, new methods and ways can be devised by the designer, but I wouldnt make too many assumptions about how the gameplay is going to pan out. Its a big change.

    Edit:

    I think making it hard to find out the runes is a good thing, what I wouldnt like to see is a lot of difference between character and player knowledge of runes.
    For example, you are fairly sure that rune X does Y, but you would have to go to great length to force the game to admit it. This is when some easy new test should be considered.
    This is an excellent summary.

    I think another change that probably should come in at the same time is that potions, scrolls etc get full ID from a single use, regardless of circumstance.

    Leave a comment:

Working...
😀
😂
🥰
😘
🤢
😎
😞
😡
👍
👎