State of Angband master branch

[Taha]

Haven't played since August (on the latest nightly from the time), but looking at that character, all my priest book autoinscriptions were @p1, etc, and the quick fire macros are p1e and so on. It is definitely a change within the last few months.
So my question - is it intentional or a bug, and will it be changed back?

And with the latest nightly, p is working again. Maybe it was just me...
________
Live Sex Webshows

[ewert]

Can you describe the changes to level feelings in iVanilla? Is it just that they're instant, or have the contributions changed? After all, it's only OOD monsters that contribute to the level feeling, so by the time you're unique-hunting at dl98 they're all in-depth, and wouldn't show up in the feeling at all ...

I decided to scrap the old system totally, it is too vague IMHO as it can mean just about anything really, hence having no worth at all almost in the end if it is positive, only negative feeling is "telling something".

In iVanilla is now purely a boolean check for
a) interesting room? (pit-like or vault)
b) unique monster?

An item quality delayed feeling is "maybe" something on the to-do list, but as I have never used the older feelings as item detectors, I don't have any needs to do it really ...

[Magnate]

And with the latest nightly, p is working again. Maybe it was just me...

No, it wasn't - 'p' had been removed and has been replaced ... for now. Nightly players be warned that takkaria plans a major reworking of input after 3.2 is out ...

[Magnate]

I decided to scrap the old system totally, it is too vague IMHO as it can mean just about anything really, hence having no worth at all almost in the end if it is positive, only negative feeling is "telling something".

In iVanilla is now purely a boolean check for
a) interesting room? (pit-like or vault)
b) unique monster?

An item quality delayed feeling is "maybe" something on the to-do list, but as I have never used the older feelings as item detectors, I don't have any needs to do it really ...

Interesting - thanks. No difference between Lagduf and Lungorthin then ...

[fizzix]

I've played a couple games with ivanilla's level feelings and I can't say it's much better than the current level feelings. The biggest problem is that there's no difference between a jelly pit and a greater vault. Both set off the 'dangerroom' boolean.

[ewert]

Interesting - thanks. No difference between Lagduf and Lungorthin then ...

Nevertheless, I like it 100% better than current "you have absolutely no idea what but there is something in this level, it maybe a single item, or a troll pit, or a vault or a greater wyrm really OoD, or ..." Atleast you know you can go unique hunting on the level or not.

As for fizzix's mention about jelly pit vs. greater vault ... that's what exploration is for. Ofcourse can't cater to all different playstyles, oh wait we can. =P I like pits and onwards, ESPECIALLY with fizzix's (hehe) zoo/graveyard/jellypit item additions. I now clear all of them if I am able.

[Timo Pietilä]

As of now (commit 87a261ebd99090fb3bd0c2a6342faa3b5fcda107 in the master branch of the angband/angband repo on github [1]) the following changes have been made:

6. misc bugfixes

Noticed new bug which I'm not sure is in trac. I have inscribed my rods of recall with {!*!*!*} which should force me to confirm any action three times. Instead it forces me to confirm them six times. I thought I had seen it before with other inscriptions with drop confirmation before (I have three high-dice weapons and several DSM:s autoinscribed with !k!d), and now I am sure. Those confirmations are multiplied.

Actually I think it asks for each "!" for confirmation in inscription, because inscription !k!d!v=g also gives three prompts for dropping an item.

Testing...yes, it asks for confirmation for action for each "!" no matter what the action is.

Opened an ticket for that in Trac.

[Taha]

Testing...yes, it asks for confirmation for action for each "!" no matter what the action is.

Also, inscriptions with numbers seem to be broken in the latest nightly, c58056f377. My books are inscribed with @m1@p1@b1@G1!d!k!v! and so on, m1 just leaves the Cast from which book prompt. ma asks are you sure three times before using the book. Browse and Gain have the same issue.

Don't know if these are separate issues or not; I assume it is all to do with changes to the input code in some way.

And throwing anything crashes the game as noted elsewhere.
________
red head girl Webcams

[Timo Pietilä]

Also, inscriptions with numbers seem to be broken in the latest nightly, c58056f377. My books are inscribed with @m1@p1@b1@G1!d!k!v! and so on, m1 just leaves the Cast from which book prompt. ma asks are you sure three times before using the book. Browse and Gain have the same issue.

Don't know if these are separate issues or not; I assume it is all to do with changes to the input code in some way.

And throwing anything crashes the game as noted elsewhere.

I made an bugreport for all of these in trac and got almost immediate response from Takk that they are already fixed, but not yet pushed to master.

Fast work, I have to say.

[d_m]

I made an bugreport for all of these in trac and got almost immediate response from Takk that they are already fixed, but not yet pushed to master.

Fast work, I have to say.

Thanks for reporting them! The state of work is fast right now, and even many of us devs aren't really sure exactly what is happening (which is partially why I created this thread) so it's really useful to have people reporting bugs as they hit them.

I'm hoping it will calm down a bit (or at least, become stable for a 3.2 release before going back to crazytown).

[AnonymousHero]

Just a little note to those reporting bugs (and to those developers who don't know about this git feature):

If you can figure out how to use "git bisect", I'm sure it would be of enormous help to the people fixing the bugs if you could bisect to the actual commit that caused the problem.

Essentially all you'll have to do is:

git bisect start
(compile, run, check for bug)
if you can't compile say "git skip"
if the bug is present say "git bisect bad"
if the bug is gone say "git bisect good"
go to the "compile" step.

In a few iterations you'll hit the exact commit that introduced the bug and git will tell you.

EDIT: If you want to speed up the process you can give the "git bisect start" command a ref (tag or commit ID) of a known good version (say, a previous release) as a parameter.

[Magnate]

Just a little note to those reporting bugs (and to those developers who don't know about this git feature):

If you can figure out how to use "git bisect", I'm sure it would be of enormous help to the people fixing the bugs if you could bisect to the actual commit that caused the problem.

Essentially all you'll have to do is:

git bisect start
(compile, run, check for bug)
if you can't compile say "git skip"
if the bug is present say "git bisect bad"
if the bug is gone say "git bisect good"
go to the "compile" step.

In a few iterations you'll hit the exact commit that introduced the bug and git will tell you.

EDIT: If you want to speed up the process you can give the "git bisect start" command a ref (tag or commit ID) of a known good version (say, a previous release) as a parameter.

git bisect is indeed excellent (as is git blame - my favourite command name ever!) - but if you know enough to use it, you can probably fix the bug yourself!!

Just in case anyone is interested, we are down to 22 tickets remaining before 3.2 is able to be released. Obviously new tickets are opened when new bugs are found but we are hoping that these will tail off as we fix them. Not many of the 22 are particularly big tasks (all those have been moved to 3.3 and beyond) so we are hopeful of releasing 3.2 around xmas. There are at least five of us working regularly on changes, which is more than have been active at once for a very long time (3.0.9 era I think).

[pav]

off topic: blame command goes all the way back to the ancient mother of all version control system - teh CVS - where it serve as an alias to 'annotate'.

I always type blame thou, and not only because it's shorter

[Timo Pietilä]

Just in case anyone is interested, we are down to 22 tickets remaining before 3.2 is able to be released. Obviously new tickets are opened when new bugs are found but we are hoping that these will tail off as we fix them. Not many of the 22 are particularly big tasks (all those have been moved to 3.3 and beyond) so we are hopeful of releasing 3.2 around xmas. There are at least five of us working regularly on changes, which is more than have been active at once for a very long time (3.0.9 era I think).

Is the autobuilder broken or are those fixes not in master yet? Nightly builds have been last updated 22.11, and last one has numerous bugs that, according to Takk, are already fixed.

[AnonymousHero]

git bisect is indeed excellent (as is git blame - my favourite command name ever!) - but if you know enough to use it, you can probably fix the bug yourself!!

The crucial thing is that you don't need to know the first thing about C to use 'git bisect'. You just need to know a few commands + "compile + run + check for bug".