Bugs and issues in 4.1.0

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • kandrc
    replied
    Originally posted by PowerWyrm
    Still got one problem left:

    Code:
    ..O...#
    ##.~###
    .....@#
    #####.#
    ....#.#
    The ogre here has a damaging tile to his southeast and doesn't want to move, though the tile south is open and perfectly viable. I imagine that the "noise" value for that tile isn't high enough so it's discarded.
    If this were Nethack, I'd say that a projectile launched over that tile should catch fire and do fire damage.

    To be clear, I would not advocate that for Angband.

    Leave a comment:


  • PowerWyrm
    replied
    Would be the same if there was a monster instead of a damaging tile:

    Code:
    		/* Get the heard noise, compare with the best so far */
    		heard_noise = base_hearing - cave->noise.grids[y][x];
    		if ((heard_noise > best_noise) && (cave->noise.grids[y][x] != 0)) {
    			/* Best so far */
    			best_noise = heard_noise;
    			best_direction = i;
    			found_direction = true;
    			if (square_monster(cave, y, x)) {
    				monster_blocking = true;
    			}
    			continue;
    		} else if ((heard_noise == best_noise) && (cave->noise.grids[y][x] != 0)
    				   && (!square_monster(cave, y, x)) && monster_blocking) {
    			/* Equal best so far, and no monster in the way */
    			best_direction = i;
    			found_direction = true;
    			monster_blocking = false;
    			continue;
    		}
    The south tile is processed first with heard noise = best noise and no monster, but monster_blocking is false so it's discarded. The southeast tile is processed next with heard noise > best noise, so it's chosen and monster_blocking is set to true. Unfortunately, no other tile is viable, so the monster will try to go southeast and fail.

    Leave a comment:


  • PowerWyrm
    replied
    Still got one problem left:

    Code:
    ..O...#
    ##.~###
    .....@#
    #####.#
    ....#.#
    The ogre here has a damaging tile to his southeast and doesn't want to move, though the tile south is open and perfectly viable. I imagine that the "noise" value for that tile isn't high enough so it's discarded.

    Leave a comment:


  • Nick
    replied
    Thanks, pathfinding stuff is great. The pathfinding in 4.1.0 was a bit immature because (a) I was too impatient to leave it until 4.2 and (b) I was then too impatient to wait for 4.1 until it had settled properly (and analysed by someone competent).

    Leave a comment:


  • PowerWyrm
    replied
    Originally posted by PowerWyrm
    Lava tiles are NO_SCENT, but not NO_FLOW, so they're ok for pathing by sound and therefore chosen for best direction. However, Huan has not IM_FIRE, so he cannot enter the tile. I guess the same should be applied for damaging tiles in get_moves_advance() as what is done when a monster is in the way.
    Implemented in PWMAngband, works perfectly.

    Leave a comment:


  • PowerWyrm
    replied
    Originally posted by PowerWyrm
    C is Huan, the tile to his west is a lava tile created by the breath from a great hell wyrm, but somehow he cannot figure out that he can move around the tile by using the northwest direction instead of getting stuck by wanting to go west.
    Lava tiles are NO_SCENT, but not NO_FLOW, so they're ok for pathing by sound and therefore chosen for best direction. However, Huan has not IM_FIRE, so he cannot enter the tile. I guess the same should be applied for damaging tiles in get_moves_advance() as what is done when a monster is in the way.

    Leave a comment:


  • PowerWyrm
    replied
    Originally posted by PowerWyrm
    IMO, the following should be factorized:
    - leave monsters active if they're in scanning range; this means removing the test in monster_check_active()
    - use best direction from get_moves_advance() to trigger sound/scent pathfinding (found_direction boolean)
    - change check in process_move() using the trigger above
    I've implemented that in PWMAngband, and suddenly monsters seem to be much more intelligent when pathfinding. There's one little problem left:

    Code:
    ########
    #......@
    #.######
    #.......
    #...#C..
    ########
    C is Huan, the tile to his west is a lava tile created by the breath from a great hell wyrm, but somehow he cannot figure out that he can move around the tile by using the northwest direction instead of getting stuck by wanting to go west.

    Leave a comment:


  • PowerWyrm
    replied
    Toying some more with monster pathfinding. This is PWMAngband, need to confirm with V.

    - takes a turn before a monster changes pathing (dig a squared passage, stand south with monster north, move west then east twice, monster moves west twice then east)

    Maybe because process_world() which updates noise/scent is only called every 10 game turns?

    - dig a C-shaped area with 2 big horizontal corridors and one small vertical path, monster and @ to the end of the southern and northern corridors, @ moves, monster remains passive (although @ is like 2 squares away and should make a ton of noise)
    - same configuration, but @ moves inside walls (wraithform in PWMAgband), monsters like fire ant (pack AI) and storm of unmagic (erratic movement) move, other monsters stay passive

    The original code in monster_check_active() was bypassing the flow algorithm when monster was in scanning range. Now only passwall/killwall monsters do that. @ behind a wall cannot be heard (?), and is too far to be smelled. The strange part is that if @ is wraithed in walls, normal pathfinding should be triggered (passwall player is equivalent to passwall monster), but it's only triggered for packs and erratic walkers. Seems that this bit of code (in process_move) triggers the new behavior:

    Code:
    		/* Tracking monsters have their best direction, don't change */
    		if ((i > 0) && !stagger && !square_isview(c, oy, ox)) {
    			break;
    }
    But the best direction is only set in a particular case in get_moves_advance(). IMO, the following should be factorized:
    - leave monsters active if they're in scanning range; this means removing the test in monster_check_active()
    - use best direction from get_moves_advance() to trigger sound/scent pathfinding (found_direction boolean)
    - change check in process_move() using the trigger above

    Leave a comment:


  • Nick
    replied
    Originally posted by Sky
    i have found a blade of chaos {??} that refuses to identify, even casting the spell.

    here is the link : https://drive.google.com/open?id=0B9...WR0ZnpBTWhnQWM

    WOHA .. if i try to sell it, the game hangs.
    OK, thanks for that - it's a bug in curses.

    Leave a comment:


  • PowerWyrm
    replied
    Toying with the new V pathfinding algorithm for PWMAngband, I looked at monster.txt and saw some inconsistencies:
    - white lice have smell 20, black lice don't (since other insects don't have smell, probably remove from white lice)
    - zombified kobolds have smell 20, none other zombies have (probably remove)
    - giant white ticks have smell 20, none other spiders have (probably remove)
    - Ulfast, Son of Ulfang has smell 20, none other p have (probably remove)

    Also, I'd think those would qualify for having smell:

    - dragons + ancient dragons (they're big reptiles after all)
    - bats (nearly blind, without smell they wouldn't be able to hunt preys)
    - hydras (also big reptiles)

    Leave a comment:


  • Bostock
    replied
    Reading a scroll of Phase Door in the linked save causes the game to hang.

    Hopefully I am doing this save-posting thing right. If not, just let me know.

    Leave a comment:


  • Nick
    replied
    Originally posted by Sky
    well, here is the entire lib folder https://drive.google.com/open?id=0B9...DYtcnZvVlE4M0E

    i ran it just now, it works, so the file is somewhere here.
    Excellent, I have it now. Will look at it soon.

    Leave a comment:


  • Sky
    replied
    well, here is the entire lib folder https://drive.google.com/open?id=0B9...DYtcnZvVlE4M0E

    i ran it just now, it works, so the file is somewhere here.

    Leave a comment:


  • Nick
    replied
    Originally posted by Sky
    well the randard.log that is in that folder does have Ningol in it. is there another file we need? because i've checked every file in archive and none have it.
    randart.log is just a record of the randart generation process. We need the file that contains all the randart definitions, like this:
    Code:
    name:of Galadriel
    base-object:light:Phial
    graphics:~:y
    info:5:10:10000
    alloc:40:5 to 100
    power:0:1d1:0:0:0
    flags:NO_FUEL
    values:LIGHT[3]
    act:ILLUMINATION
    time:10+d10
    desc:A small crystal phial containing the light of EƤrendil's Star.  
    desc:Its light is imperishable, and near it darkness cannot endure.
    but with Ningol in it.

    The first line will be something like
    Code:
    # Artifact file for random artifacts with seed 0083c53f
    but with a different seed.

    Leave a comment:


  • Sky
    replied
    well the randard.log that is in that folder does have Ningol in it. is there another file we need? because i've checked every file in archive and none have it.

    Leave a comment:

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