[Announce] Poschengband 3.4.0 Released

[wobbly]

Bug: Putting on, then removing gloves at low sp on a caster regenerates sp(s).

Edit: Being ambushed by orcs during the day is a little annoying immersion-wise. I don't tend to notice till I zap them with wands of light but when I do it reminds me, it's a minor one but still a little annoying.

[chris]

I new minor version (3.4.4) is available here. This is mainly a bug fix version that I wanted to push before beginning some bigger changes.

Bug Fixes
* Fixed Psion Energy Blast descriptions
* Fixed bug with extended attacks (Archaeologist, Samurai, etc). These techniques should not allow the player to attack with innate attacks as well (e.g. horn mutation).
* Fixed some incorrect spell descriptions
* Fixed bug with ninja bumping into hidden permanent walls
* Fixed infinite loop in TELE_TO with regard to levels generated with just a single room which also happens to be a vault (of course, this too is a bug, but I can't figure it out!)
* Mounts can no longer move when sleeping or paralyzed
* Magic-Eaters can no longer circumvent anti-magic with the various device keys
* Inspecting un-identified objects no longer displays artifact descriptions or activations
* Fixed attack dragon bug regarding number of blows being reduced too low.
* Fixed display for a bronze dragon's Deadly Bite

Enhancements
* Clear Mind now happens automatically while resting (If you have the power, of course!)
* Fixed escape delay in curses port.
* Object activations are now autoinscribed
* The Easy Destroyer is now turned off by default

Game Changes
* Monster saving throws now use a competing dice approach
* Duelist combat changed to make weapon choice more meaningful
* Duelists no longer gain a two-handed bonus on weapons
* Halfheart + Weaponmastery is no longer crazy-broken
* Artifact ammo no longer gains activations
* Improved monster AI versus distance attacks
* Chaos Warriors no longer receive level up reward on CL1
* Dungeon Guardians no longer receive special AI tactics
* Rogues no longer benefit from wizardstaves
* Monsters hurt by light should no longer show up in the wilderness during the day time

Source and a diff of changes are available.

[HugoVirtuoso]

* Dungeon Guardians no longer receive special AI tactics

Oh man...why did you remove special Al tactics from Dungeon Guardians?

[wobbly]

Started 3.4.4 - working. Save, open 3.4.3 character - working. Save, open 3.4.4 - out of memory, crash to desktop. Restart computer, same. Open 3.4.3 - works till I try to open save, crash to desktop. Open 3.4.3 - out of memory, crash to desktop. Windows 7.

Edit: Unzip 3.4.4 in to new folder. Open, works. Quit. Load old copy of 3.4.4 - out of memory. Reopen new copy. Load save - working so far.

[chris]

Started 3.4.4 - working. Save, open 3.4.3 character - working. Save, open 3.4.4 - out of memory, crash to desktop. Restart computer, same. Open 3.4.3 - works till I try to open save, crash to desktop. Open 3.4.3 - out of memory, crash to desktop. Windows 7.

Edit: Unzip 3.4.4 in to new folder. Open, works. Quit. Load old copy of 3.4.4 - out of memory. Reopen new copy. Load save - working so far.

I'm not sure I understand ... are you saying that it is OK with the version unzipped to a new folder? By the way, you should always do this:
[1] Unzip new version to a new clean folder.
[2] Copy over relevant files from old version (Savefile and pickup preferences and macros) to the new folder.
[3] Play from the new folder with the copies of your save. If there is an immediate problem, you can always go back to the previous version's folder.

Can you confirm that you are having problems doing this way? If so, can you attach your savefile? Thanks.

[chris]

Oh man...why did you remove special Al tactics from Dungeon Guardians?

Mercy? ........

[wobbly]

I'm not sure I understand ... are you saying that it is OK with the version unzipped to a new folder? By the way, you should always do this:
[1] Unzip new version to a new clean folder.
[2] Copy over relevant files from old version (Savefile and pickup preferences and macros) to the new folder.
[3] Play from the new folder with the copies of your save. If there is an immediate problem, you can always go back to the previous version's folder.

Can you confirm that you are having problems doing this way? If so, can you attach your savefile? Thanks.

3.4.3 in own folder
3.4.4 (old copy) in own folder
3..4.4 (new copy) in own folder

Problem is occuring before new or load, Opening screen isn't coming up. After problem occured in old copy of 3.4.4, my copy of 3.4.3 (in seperate folder) stopped working. But my new copy of 3.4.4 unzipped afterwards is working. So I'm a little confused. Not sure the save will help, the error occurs before loading the save & I can open the save in the working version of the game.

Edit: Perhaps loading 3.4.4 then 3.4.3 then 3.4.4 is what did it? Will play around later & see if I can reproduce

[chris]

3.4.3 in own folder
3.4.4 (old copy) in own folder
3..4.4 (new copy) in own folder

Problem is occuring before new or load, Opening screen isn't coming up. After problem occured in old copy of 3.4.4, my copy of 3.4.3 (in seperate folder) stopped working. But my new copy of 3.4.4 unzipped afterwards is working. So I'm a little confused. Not sure the save will help, the error occurs before loading the save & I can open the save in the working version of the game.

I'm Windows 7 as well and not seeing any problems at all. (I did even try unzipping a 3.4.4 on top of a 3.4.3, which is a bad idea, but it worked just fine). Has anyone else tried this release on Windows?

[debo]

Mercy? ........

I'm curious to see the effect this has. Maybe it's time to finally spin up another poscheng character! Or, at the very least, wizmode for a while

[Cold_Heart]

EDIT: see edit below

Can't run 3.4.4 built from github tag 3.4.4 on debian unstable.

After './configure --disable-x11 --disable-sdl --with-no-install' and 'make -j8' I get a segfault.

Managed to get this bt full out of GDB:

Program received signal SIGSEGV, Segmentation fault.
0x0000260000002500 in ?? ()
(gdb) bt full
#0  0x0000260000002500 in ?? ()
No symbol table info available.
#1  0x000000000065c58b in ralloc (len=256) at z-virt.c:124
        mem = 0x7ffff735fa2c <__libc_calloc+172>
#2  0x000000000065bdad in term_init (t=0x97dfc0 <data>, w=129, h=53, k=256) at z-term.c:2588
        y = 32767
#3  0x0000000000656646 in term_data_init (td=0x97dfc0 <data>, rows=53, cols=129, y=0, x=0) at main-gcu.c:1150
        t = 0x97dfc0 <data>
        __PRETTY_FUNCTION__ = "term_data_init"
#4  0x0000000000656b60 in init_gcu (argc=1, argv=0x7fffffffdf38) at main-gcu.c:1392
        desired_inv_cx = 60
        spacer_cy = 0
        map_cx = 129
        inv_cy = 28
        msg_cy = 7
        next_win = 0
        desired_msg_cy = 7
        map_cy = 53
        recall_cx = 60
        spacer_cx = 1
        inv_min = 30
        msg_min = 2
        inv_cx = 60
        msg_cx = 129
        recall_cy = 32
        i = 64
        path = "(skip)"...
#5  0x000000000065ce9e in main (argc=1, argv=0x7fffffffdf38) at main.c:642
        i = 1
        done = 0 '\000'
        new_game = 0 '\000'
        show_score = 0
        mstr = 0x0
        args = 1 '\001'
(gdb)

EDIT: launching with 'TERM=xterm ./src/poschengband' fixes it; my original $TERM is 'rxvt-unicode-256color'. This looks a bit like a bug

[chris]

Well (regarding segfault in gcu), I'm puzzled and out of my element (being a former Windows developer). The GCU port does work for me, though I confess to having started mucking with it a bit, so it wouldn't surprise me if I broke it.

But here is what I don't understand. Your gdb stack trace indicates the segfault on this line of code (z-virt.c:124):

    /* Use the aux function if set */
    if (ralloc_aux) mem = (*ralloc_aux)(len);

Now, I cannot find where ralloc_aux might be set. It is initialized here (z-virt.c:94):

vptr (*ralloc_aux)(huge) = NULL;

And a grep reveals the following usage:

~/Src/poschengband/src > grep -n ralloc_aux *.c *.h
main-mac.c:7206:        ralloc_aux = hook_ralloc;
z-virt.c:94:vptr (*ralloc_aux)(huge) = NULL;
z-virt.c:124:    if (ralloc_aux) mem = (*ralloc_aux)(len);
z-virt.h:19: * Set ralloc_aux to modify the memory allocation routine.
z-virt.h:149:extern vptr (*ralloc_aux)(huge);

In other words, it is only set by the mac port, and should be null for everybody else. But clearly, it was not null for your build since you faulted when attempting to call this hook. Does anyone have any thoughts or ideas on this?

[Cold_Heart]

It does not crash with different $TERM though.

Also, vanilla works fine with original $TERM....

[chris]

It does not crash with different $TERM though.

Also, vanilla works fine with original $TERM....

Maybe the problem is using a unicode terminal? PosCheng forked from V sometime around 1994 (via Zangband) when code was 16 bit and unicode was never even considered. I know that modern V supports unicode (and has received much rewriting since Ben H's refactoring). PosCheng code no longer remotely resembles modern V.

Can you try rxvt instead? I'll look into trying rxvt-unicode-256color myself, but not being proficient in Linux, these things take time for me

EDIT:
This works fine for me
> TERM=rxvt ./poschengband -mgcu

This blows up!
> TERM=rxvt-unicode-256color ./poschengband -mgcu

I'm pretty sure that the problem is with unicode.

[chris]

The problem is actually with colors, not unicode. Consider the following code, all from main-gcu:

static int colortable[16];
...
 /* Attempt to use customized colors */
if (can_fix_color)
{
  /* Prepare the color pairs */
  for (i = 1; i <= 63; i++)
  {
    /* Reset the color */
    if (init_pair(i, (i - 1) % 8, (i - 1) / 8) == ERR)
    {
      quit("Color pair init failed");
    }
    /* Set up the colormap */
    colortable[i - 1] = (COLOR_PAIR(i) | A_NORMAL);
    colortable[i + 7] = (COLOR_PAIR(i) | A_BRIGHT);
    /* XXX XXX XXX Take account of "gamma correction" */
    /* Prepare the "Angband Colors" */
    Term_xtra_gcu_react();
  }
}

Notice the problem? This is a write out of bounds which, I guess for your build, clobbered that ralloc_aux global which must have been positioned nearby to the colortable global in memory (I don't reproduce this, but then I'm using a different compiler and build settings).

Puzzling. So try:

diff --git a/src/main-gcu.c b/src/main-gcu.c
index dee34c0..d605580 100644
--- a/src/main-gcu.c
+++ b/src/main-gcu.c
@@ -361,7 +361,7 @@ static int can_fix_color = FALSE;
 /*
  * Simple Angband to Curses color conversion table
  */
-static int colortable[16];
+static int colortable[256];
 
 #endif

You will no longer crash, but the colors don't look to be working correctly. I don't understand this code at all (I inherited it, of course) so if somebody could suggest the correct way to handle colors in curses, I'd be relieved! I'll keep looking for a solution.

In the meantime, rxvt works fine if you really don't want to use xterm.


EDIT: Turns out main-gcu.c in Vanilla is similar enough to what I have for me to snag a workaround. But the appearance of colors is so different depending on which terminal you use! Thanks to V code for coming to the rescue!

[debo]

How would you feel about giving the Minotaur of the Labyrinth like, 1500HP instead of 500? It's sort of incongruous to have normal badguys down there who are several times scarier than the final boss of the dungeon.

I get that he's kinda fast (+15 is no joke) but 500HP is pretty sad even with that.