Bug in vanilla 3.0.9

Timo Pietilä wrote:
> Hi all.
>
> Penance comic made me try bookless hobbit mage. For that I downloaded
> 3.0.9 which is causing me some headaches:
>
> Can anyone explain to me why Vanilla 3.0.9 macro
>
> # Macro '63'
>
> A:\e\e\e\e\ef1*
> P:[F1]
>
> works but
>
> A:\e\e\e\e\ef1*
> #A:\e\e\e\e\e\e\em1a*
> P:[F1]
>
> doesn't?

Actually that is even worse. In my angband dumped macros there is this:

A:\e\e\e\e\e\ef1*t
P:[shift-F1]

that doesn't work. If I make that same macro using angband interface and
then dump it in pref-file it is EXACTLY SAME, and works????

Something is badly wrong in 3.0.9 macro handling.

Timo Pietilä
 >> Stay informed about: Bug in vanilla 3.0.9 

On Feb 2, 12:15 pm, Timo Pietilä <timo.piet....DeleteThis@helsinki.fi> wrote:
> Timo Pietilä wrote:
> > roustk wrote:
> >> On 2008-02-02 17:43:36, Timo Pietilä <timo.piet....DeleteThis@helsinki.fi>
> >> wrote:
>
> >>> Hello? Anyone? Any reason why that would do that?
>
> >> in the savefile proper. However, there are quite a few .prf files it
> >> does read and later ones do overwrite earlier ones.
>
> >> The first few .prf files are pref.prf, graf.prf, and font.prf in some
> >> order, plus any files listed within those. The last four .prf files
> >> read (if your character is "Timo") are, as far as I can reconstruct,
> >> these:
>
> >> lib/pref/user.prf
> >> lib/pref/user-sys.prf (from user.prf) lib/pref/Race.prf (from user.prf)
> >> lib/pref/Class.prf (from user.prf)
>
> > Hmmm... There is no lib/user/Class.prf
>
> >> lib/user/user.prf or ~/<...>/lib/user.prf lib/pref/Timo.prf
> >> lib/user/Timo.prf or ~/<...>/lib/Timo.prf
>
> > So reading Eddies answer and this my guess is that for some reason
> > player-written Class.prf and Race.prf should be placed in /lib/pref
> > instead of /lib/user, even that when you save pref-file form angband
> > interface it puts them in /lib/user
>
> > This would explaing why it doesn't work. Also reading user.prf it seems
> > to have name "Mage.prf", so maybe filename has to be case-sensitive.
>
> > I'll try copying them in /lib/pref to see if that works.
>
> OK found the bu. It is after all typo in macro definition. P:[F1]
> doesn't work, it should be P:\[F1]
>
> So this was lot of noice about nothing.
>

Timo, is there no bug at all, or is there still a bug in what pref
files are being read? You were talking about a (non-)bug in the
macros and another about incomplete initialization from pref files.
 >> Stay informed about: Bug in vanilla 3.0.9 

conkstah.TakeThisOut@gmail.com wrote:
> On Feb 2, 10:06 am, Timo Pietilä <timo.piet....TakeThisOut@helsinki.fi> wrote:
>> Hi all.
>>
>> Penance comic made me try bookless hobbit mage. For that I downloaded
>> 3.0.9 which is causing me some headaches:
>>
>> Can anyone explain to me why Vanilla 3.0.9 macro
>>
>> # Macro '63'
>>
>> A:\e\e\e\e\ef1*
>> P:[F1]
>>
>> works but
>>
>> A:\e\e\e\e\ef1*
>> #A:\e\e\e\e\e\e\em1a*
>> P:[F1]
>>
>> doesn't?
>>
>> Also why doesn't it load class-specific macro-files automatically
>> (rogue.prf, mage.prf, warrior.prf etc.)?
>>
>> How can I turn old shop behavior back? Which part of the code is
>> responsible of that change? New one is ugly.
>>
>> Where is complete list of changes between 3.0.7s3 and 3.0.9?
>>
>> It seems that I need to go back to 3.0.7s3.
>>
>> Timo Pietilä
>
> Might be controversial, but personally, I stick with 3.0.6. I just...
> didn't like the 'tone' of the changes past that. Hard to explain. My
> only gripe with my decision is that a few bugs like the infinite
> recharge thing are unfixed in 3.0.6, but other than that, it's
> definitely worth it for the old shop behaviour if nothing else.

3.0.7s3 is basically 3.0.6 with squelch, fixed panel change behavior and
that recharge -bug fixed. I just noticed that this is not in
http://rephial.org/release/ -list of releases even that that was *the*
first release with squelch and as such a major improvement. Much bigger
improvement than 3.0.8 over 3.0.6 or 3.0.9 over 3.0.8. List jumps from
3.0.6 to 3.0.8.

Timo Pietilä
 >> Stay informed about: Bug in vanilla 3.0.9 

Timo Pietilä <timo.pietila.RemoveThis@helsinki.fi> writes:

> 3.0.7s3 is basically 3.0.6 with squelch, fixed panel change behavior and that
> recharge -bug fixed. I just noticed that this is not in
> http://rephial.org/release/ -list of releases even that that was *the* first
> release with squelch and as such a major improvement. Much bigger improvement
> than 3.0.8 over 3.0.6 or 3.0.9 over 3.0.8. List jumps from 3.0.6 to 3.0.8.

3.0.7s was never an official release. It was something Andrew put together
before he became the maintainer. That's probably why it is not in the list.

I know next to nothing about macros, but I have a few observations.

There are occasionally strange things about macros. The only one I use is
mapping F1 to f1*t, and even that breaks occasionally. In the past, though I
have not had this problem lately, some times it would just stop working until
I redefined it, even though it would offer the same definition when prompting
me for the new one.

Also, sometimes even when I have properly inscribed ammo, for some strange
reason the 'f' in the macro is lost, and it executes "1*t", moving me and
then going into targetting mode. Perhaps it has something to do with long
lists of messages I "more" through, but I think I might get the problem even
when I have used space enough times to clear all "more" prompts.

Now I define it, save it [along with visuals changing various walls to
different characters or colors] into a CharacterName.prf file, and when I
start a character with a new name I manually copy the prf to NewName.prf.
I haven't lost the definition since I started doing this. You could create
TimoFighter.prf, TimoPriest.prf, etc, and after starting a new character
manually copy the appropriate file to CharacterName.prf. Perhaps that would
change things from unplayable to merely annoying.


Eddie
 >> Stay informed about: Bug in vanilla 3.0.9 

Timo Pietilä wrote:
> Timo Pietilä wrote:
>> Hi all.
>>
>> Penance comic made me try bookless hobbit mage. For that I downloaded
>> 3.0.9 which is causing me some headaches:
>>
>> Can anyone explain to me why Vanilla 3.0.9 macro
>>
>> # Macro '63'
>>
>> A:\e\e\e\e\ef1*
>> P:[F1]
>>
>> works but
>>
>> A:\e\e\e\e\ef1*
>> #A:\e\e\e\e\e\e\em1a*
>> P:[F1]
>>
>> doesn't?
>
> Actually that is even worse. In my angband dumped macros there is this:
>
> A:\e\e\e\e\e\ef1*t
> P:[shift-F1]
>
> that doesn't work. If I make that same macro using angband interface and
> then dump it in pref-file it is EXACTLY SAME, and works????
>
> Something is badly wrong in 3.0.9 macro handling.

Hello? Anyone? Any reason why that would do that? I think game doesn't
read all lines in pref-file, and what it reads is somehow stored in
savefile. This makes all of my pre-defined 30+ macros useless and i need
to re-define them again using angband slow method. Game is pretty much
unplayable to me now compared to earlier versions.

Timo Pietilä
 >> Stay informed about: Bug in vanilla 3.0.9 

On 2008-02-02 17:43:36, Timo Pietilä <timo.pietila.TakeThisOut@helsinki.fi> wrote:

> Hello? Anyone? Any reason why that would do that? I think game doesn't
> read all lines in pref-file, and what it reads is somehow stored in
> savefile.

Timo --
A quick look at the source doesn't reveal any place that these could be saved

in the savefile proper. However, there are quite a few .prf files it does read
and
later ones do overwrite earlier ones.

The first few .prf files are pref.prf, graf.prf, and font.prf in some order,
plus
any files listed within those. The last four .prf files read (if your character
is
"Timo") are, as far as I can reconstruct, these:
lib/pref/user.prf
lib/pref/user-sys.prf (from user.prf)
lib/pref/Race.prf (from user.prf)
lib/pref/Class.prf (from user.prf)
lib/user/user.prf or ~/<...>/lib/user.prf
lib/pref/Timo.prf
lib/user/Timo.prf or ~/<...>/lib/Timo.prf

Note that the class-specific files must have a leading capital letter, and are
read very early in the process. Note also that PLAYER.prf is not read once
your character is named.

Also note that it quits reading a .prf file after any parse error -- the first
character
on each line must be '
 >> Stay informed about: Bug in vanilla 3.0.9 

Hmm -- the oook interface apparently parsed that post, cutting it off at a nul.
It also adjusted my line lengths in an annoying way. Sorry about that, but I
have no nntp access through my isp.

On 2008-02-02 19:35:01, roustk <roustk.DeleteThis@alumni.caltech.edu> wrote:

> Also note that it quits reading a .prf file after any parse error -- the first
> character on each line must be

First character must be null, isspace(), #, or one of [RBQKFLSEAPCVTXYWM?%]
followed by a ':'.


I also commented that your first post used a format like:
A:ef1
#A:em1a
P:[F1]
That looks perfectly acceptable, so that isn't the problem.


Please check exactly where you are putting your macros.

Thanks,
Kevin
 >> Stay informed about: Bug in vanilla 3.0.9 

roustk wrote:
> On 2008-02-02 17:43:36, Timo Pietilä <timo.pietila DeleteThis @helsinki.fi>
> wrote:
>
>> Hello? Anyone? Any reason why that would do that?

> in the savefile proper. However, there are quite a few .prf files it
> does read and later ones do overwrite earlier ones.
>
> The first few .prf files are pref.prf, graf.prf, and font.prf in some
> order, plus any files listed within those. The last four .prf files
> read (if your character is "Timo") are, as far as I can reconstruct,
> these:

> lib/pref/user.prf
> lib/pref/user-sys.prf (from user.prf)
> lib/pref/Race.prf (from user.prf)
> lib/pref/Class.prf (from user.prf)

Hmmm... There is no lib/user/Class.prf

> lib/user/user.prf or ~/<...>/lib/user.prf lib/pref/Timo.prf
> lib/user/Timo.prf or ~/<...>/lib/Timo.prf

So reading Eddies answer and this my guess is that for some reason
player-written Class.prf and Race.prf should be placed in /lib/pref
instead of /lib/user, even that when you save pref-file form angband
interface it puts them in /lib/user

This would explaing why it doesn't work. Also reading user.prf it seems
to have name "Mage.prf", so maybe filename has to be case-sensitive.

I'll try copying them in /lib/pref to see if that works.

Timo Pietilä
 >> Stay informed about: Bug in vanilla 3.0.9 

Timo Pietilä wrote:
> roustk wrote:
>> On 2008-02-02 17:43:36, Timo Pietilä <timo.pietila.RemoveThis@helsinki.fi>
>> wrote:
>>
>>> Hello? Anyone? Any reason why that would do that?
>
>> in the savefile proper. However, there are quite a few .prf files it
>> does read and later ones do overwrite earlier ones.
>>
>> The first few .prf files are pref.prf, graf.prf, and font.prf in some
>> order, plus any files listed within those. The last four .prf files
>> read (if your character is "Timo") are, as far as I can reconstruct,
>> these:
>
>> lib/pref/user.prf
>> lib/pref/user-sys.prf (from user.prf) lib/pref/Race.prf (from user.prf)
>> lib/pref/Class.prf (from user.prf)
>
> Hmmm... There is no lib/user/Class.prf
>
>> lib/user/user.prf or ~/<...>/lib/user.prf lib/pref/Timo.prf
>> lib/user/Timo.prf or ~/<...>/lib/Timo.prf
>
> So reading Eddies answer and this my guess is that for some reason
> player-written Class.prf and Race.prf should be placed in /lib/pref
> instead of /lib/user, even that when you save pref-file form angband
> interface it puts them in /lib/user
>
> This would explaing why it doesn't work. Also reading user.prf it seems
> to have name "Mage.prf", so maybe filename has to be case-sensitive.
>
> I'll try copying them in /lib/pref to see if that works.

OK found the bu. It is after all typo in macro definition. P:[F1]
doesn't work, it should be P:\[F1]

So this was lot of noice about nothing.

Timo Pietilä
 >> Stay informed about: Bug in vanilla 3.0.9 

pete m wrote:
> On Feb 2, 12:15 pm, Timo Pietilä <timo.piet....TakeThisOut@helsinki.fi> wrote:
>> Timo Pietilä wrote:
>>> roustk wrote:
>>>> On 2008-02-02 17:43:36, Timo Pietilä <timo.piet....TakeThisOut@helsinki.fi>
>>>> wrote:
>>>>> Hello? Anyone? Any reason why that would do that?
>>>> in the savefile proper. However, there are quite a few .prf files it
>>>> does read and later ones do overwrite earlier ones.
>>>> The first few .prf files are pref.prf, graf.prf, and font.prf in some
>>>> order, plus any files listed within those. The last four .prf files
>>>> read (if your character is "Timo") are, as far as I can reconstruct,
>>>> these:
>>>> lib/pref/user.prf
>>>> lib/pref/user-sys.prf (from user.prf) lib/pref/Race.prf (from user.prf)
>>>> lib/pref/Class.prf (from user.prf)
>>> Hmmm... There is no lib/user/Class.prf
>>>> lib/user/user.prf or ~/<...>/lib/user.prf lib/pref/Timo.prf
>>>> lib/user/Timo.prf or ~/<...>/lib/Timo.prf
>>> So reading Eddies answer and this my guess is that for some reason
>>> player-written Class.prf and Race.prf should be placed in /lib/pref
>>> instead of /lib/user, even that when you save pref-file form angband
>>> interface it puts them in /lib/user
>>> This would explaing why it doesn't work. Also reading user.prf it seems
>>> to have name "Mage.prf", so maybe filename has to be case-sensitive.
>>> I'll try copying them in /lib/pref to see if that works.
>> OK found the bu. It is after all typo in macro definition. P:[F1]
>> doesn't work, it should be P:\[F1]
>>
>> So this was lot of noice about nothing.
>>
>
> Timo, is there no bug at all, or is there still a bug in what pref
> files are being read? You were talking about a (non-)bug in the
> macros and another about incomplete initialization from pref files.

No bug at all. I changed those pref-files by hand, and made same mistake
in every entry made by hand. I'm sorry about yelling from nothing but it
really did scare me. I started to question my own perception about a bug
when no-one did answer that immediately. If it were real then I would
have expected a lot of "me too" messages.

Timo Pietilä
 >> Stay informed about: Bug in vanilla 3.0.9 

Timo Pietilä wrote:
> Hello? Anyone? Any reason why that would do that?

Sorry; I hadn't had time to check out the code properly to figure out
where that bug might have been. I'm glad there isn't one, though,
because I haven't touched the pref file code myself.

--
Andrew Sidwell
http://rephial.org/
 >> Stay informed about: Bug in vanilla 3.0.9 

Andrew Sidwell wrote:
> Timo Pietilä wrote:
>> Hello? Anyone? Any reason why that would do that?
>
> Sorry; I hadn't had time to check out the code properly to figure out
> where that bug might have been. I'm glad there isn't one, though,
> because I haven't touched the pref file code myself.

I somehow expected someone to spot that "bug" immediately. I gave example:

A:\e\e\e\e\ef1*
P:[F1]

which I claimed to be working. It doesn't. Actually what happened was
that when I dumped macros it included all of my previous non-working
macros too (which made me wonder that how does it work now) and made
last macro entry this:

A:\e\e\e\e\ef1*
P:\[F1]

which I didn't notice immediately.

But anyhow, my typo was clearly visible in my first post. I guess heavy
macro-users didn't read my example.

Timo Pietilä
 >> Stay informed about: Bug in vanilla 3.0.9