Angband 4.0beta status

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • Nick
    replied
    No update today. The next one will probably break savefiles, to fix the ring swap problem.

    Now some questions and comments about bugs I have been trying to fix:
    • AC not displaying correctly, slowing remaining even after a heavy item is dropped - I can't reproduce either of these. If someone can, please give me a savefile.
    • Monster memory vanishing - I can't reproduce that either. Remember that now all monster memory is in the lore.txt file - and that's added to and accessed by all characters. If you get the latest beta version, you will need to copy the lore.txt from your old version, or you will have no monster memory. As far as I can tell, both by looking at the code and by testing, lore.txt is being correctly written every time the game is exited. Kill counts are stored in the savefile, so those numbers in the monster history come from the savefile, but monster information doesn't.
    • The activation macro thing - I don't think that's actually a bug. Aa5 would not aim at the closest thing, Aa' would, and that works exactly the same macro or typed directly. The reason the 5 at the end behaves like that is that numbers are already macros (so, eg, 4 is ;4 for step left), for moving or standing still. If you give a number in a keymap where a direction would make sense, the keymap can use it, but if you try to use it in a keymap as a direction it won't work, because you can't nest keymaps.


    So the rings, a bunch of message issues and some display problems are the main things that I can reproduce at the moment. Plus a few display improvements that need doing. Anything else, please try and get a savefile, or failing that a really solid description of exactly what's going wrong.

    Leave a comment:


  • Ingwe Ingweron
    replied
    Originally posted by Derakon
    By my reading, the realm determines if your casting stat is INT or WIS, and the text for messages like "you cannot learn any more [spells/prayers]". And that's it.
    Of course, makes perfect sense. Thanks, Derakon and Nick.

    Leave a comment:


  • Derakon
    replied
    Originally posted by Ingwe Ingweron
    I guess I remain confused about exactly what "spell realm" (1 or 2) actually does, since everything you've mentioned here is handled elsewhere.
    By my reading, the realm determines if your casting stat is INT or WIS, and the text for messages like "you cannot learn any more [spells/prayers]". And that's it.

    Leave a comment:


  • Ingwe Ingweron
    replied
    Originally posted by Nick
    The spell realm currently determines the spellcasting stat, and names like "spell" vs "prayer" and "magic book" vs "prayer book"....
    I guess I remain confused about exactly what "spell realm" (1 or 2) actually does, since everything you've mentioned here is handled elsewhere.

    Flags handle Cumber, Zero Fail, Choose Spells, Beam
    book line handles magic book vs. prayer book
    magic line handles: level of first spell, weight that hurts spell, [REALM], number of books

    Does the [REALM] number actually do anything, then? Hmm, maybe that's how the program knows whether to call what @ cast was a spell or a prayer?

    Leave a comment:


  • MattB
    replied
    But I want an ice cream.

    Leave a comment:


  • Nick
    replied
    Originally posted by Ingwe Ingweron
    A question for you, Nick, about the class.txt file. I notice that the class must be assigned a "primary spellcasting realm" in the magic line. Does this mean that hybrid spellcasters will still be prevented? E.g., I wanted to create a hybrid Numenorean Ranger type class that had some of the priest spells, some of the mage spells, rather than only mage as currently.
    The spell realm currently determines the spellcasting stat, and names like "spell" vs "prayer" and "magic book" vs "prayer book". How the magic system operates is determined largely by class flags - so a mage gets CHOOSE_SPELLS and CUMBER_GLOVE in their flags: line, for example.

    Which books the class can use, and which spells they contain, and exactly what those spells do, are completely editable, though. So you could certainly have a class which cast from both red and green books, but they would be confined to a single spell stat, and have the same rules on learning, gloves, blessed weapons, etc

    I would actually prefer a bit more flexibility, but I eventually decided that doing things like allowing a different spell stat (which I seriously thought about for a while) or applying different flags for casting from different books was a lot of coding work for minimal improvement.

    Leave a comment:


  • Ingwe Ingweron
    replied
    A question for you, Nick, about the class.txt file. I notice that the class must be assigned a "primary spellcasting realm" in the magic line. Does this mean that hybrid spellcasters will still be prevented? E.g., I wanted to create a hybrid Numenorean Ranger type class that had some of the priest spells, some of the mage spells, rather than only mage as currently.

    Leave a comment:


  • Nick
    replied
    Originally posted by Nomad
    All right, I think I've spotted the problem! Having just started afresh in the newest version of 4.0, turns out I didn't actually have a lore.txt file. It looks like lore.txt is A, only created when your first character dies, and B, only being updated on character death, not when you save during an ongoing game. So when you exit and restart, monster knowledge is wiped back to the state it was at your most recent character death, and does not retain anything new that your still-living character has learned since then.
    Ah, thank you - my problem was not killing my test characters often enough

    Also thanks everyone for the ring testing. I had an idea it might be order of pickup, but hadn't checked.

    Leave a comment:


  • Nomad
    replied
    Originally posted by Nick
    1. How often is monster memory vanishing? Has anyone checked if their lore.txt file (in lib/user on Windows, ~/Documents/Angband on OSX) seems to correlate with current monster memory?
    All right, I think I've spotted the problem! Having just started afresh in the newest version of 4.0, turns out I didn't actually have a lore.txt file. It looks like lore.txt is A, only created when your first character dies, and B, only being updated on character death, not when you save during an ongoing game. So when you exit and restart, monster knowledge is wiped back to the state it was at your most recent character death, and does not retain anything new that your still-living character has learned since then.

    Leave a comment:


  • Nomad
    replied
    Originally posted by tumbleweed
    After further testing, it seems to depend on which ring was picked up first.
    1. Drop any two rings on the floor.
    2. Pick them up and equip them.
    3. Exit and reload.
    4. Check your hands.
    5. The ring that was picked up last will be on your left hand. Magic!


    Tested with the aforementioned rings of damage, plus a Ring of Constitution <+3> and a Ring of Intelligence <+5> that was lying around nearby.

    Confirm/Deny?
    Yep, after some testing I think you might be right actually. So the high vs. low bonus stuff may just have been a complete coincidence.

    Leave a comment:


  • tumbleweed
    replied
    Originally posted by tumbleweed
    I just did some quick testing: it does seem to depend on the rings.

    For example, I equipped two Rings of Damage, one (+0,+8) and one (+0,+9). After exiting and reloading, the (+0,+9) would always be on the right hand, no matter how I equipped them before exiting.

    The (+0,+8) one is a ring I just found, the other one has been my trusty companion for many levels. Maybe that's a clue?
    After further testing, it seems to depend on which ring was picked up first.
    1. Drop any two rings on the floor.
    2. Pick them up and equip them.
    3. Exit and reload.
    4. Check your hands.
    5. The ring that was picked up last will be on your left hand. Magic!


    Tested with the aforementioned rings of damage, plus a Ring of Constitution <+3> and a Ring of Intelligence <+5> that was lying around nearby.

    Confirm/Deny?

    Leave a comment:


  • Ingwe Ingweron
    replied
    Continuing my perusal of the edit files.

    p_race.txt #height and #weight still have hgtfemale, modhgtfemale, wgtfemale, and modwgtfemale.

    That's fine for them to be present in case the removal of gender choice is reverted or for variants, but note #height female stat and mod are still actually being used for the "Elf" race (not to be confused with High-Elf).

    Leave a comment:


  • Ingwe Ingweron
    replied
    Originally posted by Nomad
    ....So far as I can tell, it happens when you have two stat rings of the same type, where one gives a higher stat boost than the other....
    Not just rings of the same type. I've seen damage swap with stat rings and with element rings. For quite awhile I thought I was going mad, switching rings and forgetting, but finally reported the problem when I was absolutely sure it was happening on its own. The higher - lower theory is interesting. I'll watch for it. It seems to happen on exit and reload.

    I inscribe the "c" rings with @1 and the "d" rings with @2, making swapping with other rings in inventory or rewielding easy. I've got "y" keymapped to "w1c" and "j" keymapped to "w2d". When a @2 ends up in "c" or a @1 ends up in "d" then I know the swap bug has bitten me.

    Leave a comment:


  • Nomad
    replied
    Originally posted by tumbleweed
    I just did some quick testing: it does seem to depend on the rings.

    For example, I equipped two Rings of Damage, one (+0,+8) and one (+0,+9). After exiting and reloading, the (+0,+9) would always be on the right hand, no matter how I equipped them before exiting.

    The (+0,+8) one is a ring I just found, the other one has been my trusty companion for many levels. Maybe that's a clue?
    I've noticed this before with rings of damage, too. (And thank you for reporting it as a bug, and proving I'm not going mad!) So far as I can tell, it happens when you have two stat rings of the same type, where one gives a higher stat boost than the other. Let's call them High Ring and Low Ring.

    The swap bug occurs when you equip High Ring to slot c, and then Low Ring to slot d. If you exit and reload, the rings will have swapped over so that High Ring is now in slot d. (Further exiting and reloading does not cause them to swap back - once it's moved there, High Ring always stays in slot d.)

    This happens most of the time, but not always. I'm not completely certain why not, but I think it has to do with the order you put the rings on - i.e. if you put High Ring in c and then Low Ring in d, they will swap; if you're already wearing Low Ring in d and then stick High Ring in c, they won't. Possibly.

    EDIT: Okay, it effects dissimilar ring pairs as well, so this theory is wrong: looks like it may be down to order of pickup as tumbleweed suggests below.
    Last edited by Nomad; May 13, 2015, 21:11.

    Leave a comment:


  • tumbleweed
    replied
    Originally posted by Nick
    Update 280b6ee fixes:
    1. Rings switching hands - is that every time?
    I just did some quick testing: it does seem to depend on the rings.

    For example, I equipped two Rings of Damage, one (+0,+8) and one (+0,+9). After exiting and reloading, the (+0,+9) would always be on the right hand, no matter how I equipped them before exiting.

    The (+0,+8) one is a ring I just found, the other one has been my trusty companion for many levels. Maybe that's a clue?

    Leave a comment:

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