Preparing for 4.2 release

[Gwarl]

The reason for not using Makefile.std is that it only gets updated at version change, and version.sh tries to be more precise for if people are playing a nightly or something modified. Are you making changes before you compile?

No, I think what it might have been is that they were all in subfolders of a folder that still had a hidden .git folder, and so maybe they looked around and saw that they were inside a git repo and declared themselves (from 3.3 onwards) to be 4.1.3-dirty.

I'm inclined to think, in contradiction to my previous post, that this might not be worth looking into afterall.

[Nick]

found a rather obscure bug

when using autoconf to compile variants on angband.live, it seems they were using scripts/version.sh to look for a version number to describe themselves with. This finally explains why 4.1.3 has been showing up in-game as 4.1.3-dirty all this time on the site. Using Makefile.std seems to avert this and then everyone knows which version they are, but it might be nice if future angbands don't like to lie about their version number credentials

The reason for not using Makefile.std is that it only gets updated at version change, and version.sh tries to be more precise for if people are playing a nightly or something modified. Are you making changes before you compile?

[Sphara]

I dunno if a closing wall-trap is such a good idea, if it works this way. This character in question survives only because he happened to find a ring of teleportation just a few moments earlier.

[Gwarl]

found a rather obscure bug

when using autoconf to compile variants on angband.live, it seems they were using scripts/version.sh to look for a version number to describe themselves with. This finally explains why 4.1.3 has been showing up in-game as 4.1.3-dirty all this time on the site. Using Makefile.std seems to avert this and then everyone knows which version they are, but it might be nice if future angbands don't like to lie about their version number credentials

[Nick]

Ok, thanks for the answer.
For slow digestion: I have sDigest and it CERTAINLY did not divide the characters hunger rate by 5. Did you mean 2? I lost 1% in about every 60 turns of waiting and 1%/30 turns without it. This was tested by resting at 32% satiation level.

The problem with testing like this is there is insufficient accuracy in the food bar. Also digestion only happens every 100 game turns - 10 player turns at normal speed - so testing for only 30-60 turns would not be accurate.

I have just tested this in a debugger where I can see the amount of digestion and how often, and I can guarantee slow digestion does actually divide digestion by 5.

I find out now that blackguards have ImpHP as an intrinsic. That seems an important drawback. Maybe it should be mentioned on the character creation screen?

Yes indeed, it's kind of a bug that it isn't already. Will be in the next build.

[fph]

I find out now that blackguards have ImpHP as an intrinsic. That seems an important drawback. Maybe it should be mentioned on the character creation screen?

[Sphara]

I don't think there are any bugs here, but let me clarify exactly what's happening:

• Half-trolls get regen, which means an added 15 (food bar is 10000) digested every game turn (usual digestion per game turn is roughly 10+speed, so at normal speed digestion is more than doubled);
• Blackguards get impaired HP regen, which stacked with Half-troll regen means a HT blackguard just gets normal speed regen;
• All characters regenerate hitpoints faster the fuller they are;
• HP makes no difference to digestion speed.

So HT blackguard gets fast digestion with no effect on regen. Slow digestion (which divides digestion by 5) is probably a good thing to have.

Ok, thanks for the answer.
For slow digestion: I have sDigest and it CERTAINLY did not divide the characters hunger rate by 5. Did you mean 2? I lost 1% in about every 60 turns of waiting and 1%/30 turns without it. This was tested by resting at 32% satiation level.

[Nick]

Half-Troll Blackguard's regeneration consumes food even when you're not wounded. Resting with already full HP consumes 1% in precisely 30 turns, exactly the same time it takes to lose when resting wounded. Eating one food ration keeps you fed about 500 turns before hunger penalties kick in. This no good.

I guess this is because Blackguard's innate regeneration penalty overlaps with Half-Troll's own regen all the time? Innate impaired HP-regen and infravision both show non-highlighted gray plus in character sheet.

It kinda makes sense Trolls needing to eat much, but for me, it's too much. Let me know if this is a bug or not. I won't touch Half Troll-Blackguard, if this is intentional.

I don't think there are any bugs here, but let me clarify exactly what's happening:

• Half-trolls get regen, which means an added 15 (food bar is 10000) digested every game turn (usual digestion per game turn is roughly 10+speed, so at normal speed digestion is more than doubled);
• Blackguards get impaired HP regen, which stacked with Half-troll regen means a HT blackguard just gets normal speed regen;
• All characters regenerate hitpoints faster the fuller they are;
• HP makes no difference to digestion speed.

So HT blackguard gets fast digestion with no effect on regen. Slow digestion (which divides digestion by 5) is probably a good thing to have.

[Sphara]

Half-Troll Blackguard's regeneration consumes food even when you're not wounded. Resting with already full HP consumes 1% in precisely 30 turns, exactly the same time it takes to lose when resting wounded. Eating one food ration keeps you fed about 500 turns before hunger penalties kick in. This no good.

I guess this is because Blackguard's innate regeneration penalty overlaps with Half-Troll's own regen all the time? Innate impaired HP-regen and infravision both show non-highlighted gray plus in character sheet.

It kinda makes sense Trolls needing to eat much, but for me, it's too much. Let me know if this is a bug or not. I won't touch Half Troll-Blackguard, if this is intentional.

[Nick]

But... code golfing aside, does it actually make the code more comprehensible? Seems like two loops, an inner and an outer, are really easy to understand...

Yeah, I'm thinking along those lines too (and Gwarl has been from the beginning). My basic guideline is "make the code look like it's describing the game world", and so I'm deciding which of the current two loops or "define this area, then do stuff to it" is more intuitive. And the fact that I'm still wondering probably means there's not enough difference to go through all the fuss

[takkaria]

On reflection, I think the best way to handle this whole idea is to create a point_set of the relevant grids (probably by making a new create_rectangle_point_set(), or something), and then iterate across the point_set.

But... code golfing aside, does it actually make the code more comprehensible? Seems like two loops, an inner and an outer, are really easy to understand...

[clouded]

Yeah, that is sometimes a problem, too. But it was the illumination code that used to have "show reduced light radius while running" performance optimization. And it is running--and only runnning--where performance matters.

Just started up a 4.1.3-nightly game on angband.live and movement is noticably laggy. Even moving singular tiles takes more time than it should (and does in old variants) and running down a winding corridor takes seconds. I read phase door and my @ changed position, seeing a kobold in the darkness and then the (newly found) room appeared a few ms later, it was quite delayed. Similarly moving in and out of a lit room I can see the game updating the wall lighting in a very delayed fashion. This is with base delay 10 and movement delay 0.

Downloaded a local version and it seemed totally fine there though.

Edit: A couple things while playing necromancer: wielding a light should give a message saying it impacts spellcasting I think. Firing nether bolt at an undead produces no message and upon inspecting it (in this case a zombie kobold) it says that it "does not resist nether" despite being immune.

[Nick]

It is indeed much nicer. I've updated my iterator to reflect on this, keeping pointers instead of structures because I don't like passing structs to functions.

On reflection, I think the best way to handle this whole idea is to create a point_set of the relevant grids (probably by making a new create_rectangle_point_set(), or something), and then iterate across the point_set.

[Nick]

Playing a gnome mage on latest nightly build (gbaacb2d0c) on Windows 10 x64.

When my character dies and I select "n) new game" at the tombstone screen, sometimes the application dies immediately after displaying "Initialization complete" (or something similar - it only appears for a moment). The window just disappears. Re-starting the application works fine.

This is not always reproducable though - sometimes it happens, and sometimes it doesn't.

Thanks - I'm a bit surprised there haven't been more problems with this.

[Pondlife]

Playing a gnome mage on latest nightly build (gbaacb2d0c) on Windows 10 x64.

When my character dies and I select "n) new game" at the tombstone screen, sometimes the application dies immediately after displaying "Initialization complete" (or something similar - it only appears for a moment). The window just disappears. Re-starting the application works fine.

This is not always reproducable though - sometimes it happens, and sometimes it doesn't.