Nightlies embark on long journey towards 3.3

[PowerDiver]

It was a deliberate change - ticket #855. FWIW, I share your preference for the earlier behaviour and argued against the change, but was outvoted.

In that case, there is no longer a need for the '-' command or any successors. A run from an adjacent square into a trap should mean to jump in, and into an adjacent square with an item should mean to move onto it while toggling autopickup.

[Magnate]

There was a change made with running. It used to be that when your run stopped you at the border of trap detection, if you tried to run again you would not move. Now, the second run succeeds. Was this done on purpose, or by accident? I think I prefer the earlier behavior, but if the change was made on purpose that will allow some useful overloading of the run command, for example to jump into traps.

It was a deliberate change - ticket #855. FWIW, I share your preference for the earlier behaviour and argued against the change, but was outvoted.

[PowerDiver]

There was a change made with running. It used to be that when your run stopped you at the border of trap detection, if you tried to run again you would not move. Now, the second run succeeds. Was this done on purpose, or by accident? I think I prefer the earlier behavior, but if the change was made on purpose that will allow some useful overloading of the run command, for example to jump into traps.

[PowerDiver]

No, the current thinking is that globals are bad and should be removed where possible. I didn't do this refactor so I don't know what the solution was (a linked list, maybe?), but it's been reverted for the time being.

You don't want to be mallocing strings, ever. If this is some sort of religious coding style, then a much better solution is to bloat the object_type with an array of chars large enough to hold the max allowed inscription.

[Magnate]

Why would you change that? That means when you fire an arrow, you either have to generate a new string or else you have to keep reference counts. Either way lies madness.

I thought in this code linked lists are considered too dangerous to implement. Reference counts are an order of magnitude worse.

No, the current thinking is that globals are bad and should be removed where possible. I didn't do this refactor so I don't know what the solution was (a linked list, maybe?), but it's been reverted for the time being.

[PowerDiver]

The memory leaks were caused by the *removal* of the quark array. It used to work exactly as you describe, then we tried to remove the global quark array and make inscriptions a property of each object

Why would you change that? That means when you fire an arrow, you either have to generate a new string or else you have to keep reference counts. Either way lies madness.

I thought in this code linked lists are considered too dangerous to implement. Reference counts are an order of magnitude worse.

[Magnate]

I identified a blessed weapon because my pack was full and I had a rod of ID. Usually I test-wield, and toss blessed weapons unless they have ESP. This one provided protection from confusion, and I did a double-take before realizing the long-awaited changes of some high resists into abilities must be in 3.3 dev already.

Yes, that went in a week or two ago. The clue should be in the resists screen: rConf is now shown as pConf and is grouped with pFear and pBlnd.

[Magnate]

Wait a minute. A memory leak with quarks shouldn't be possible unless you are working too hard. Store the strings sequentially in a huge array, and don't ever remove anything. On level change, do garbage collection and compact the array. Is whatever alternative that is in use now worth the effort?

The memory leaks were caused by the *removal* of the quark array. It used to work exactly as you describe, then we tried to remove the global quark array and make inscriptions a property of each object, but that caused the leaks. We reverted to the quark arrangement until we've rationalised all the object copying and modification code, to make it easier to debug quark removal next time.

[PowerDiver]

I identified a blessed weapon because my pack was full and I had a rod of ID. Usually I test-wield, and toss blessed weapons unless they have ESP. This one provided protection from confusion, and I did a double-take before realizing the long-awaited changes of some high resists into abilities must be in 3.3 dev already.

[PowerDiver]

This is because the memory-leak-causing inscriptions change (quark removal) was reverted in between, nuking the fix.

Wait a minute. A memory leak with quarks shouldn't be possible unless you are working too hard. Store the strings sequentially in a huge array, and don't ever remove anything. On level change, do garbage collection and compact the array. Is whatever alternative that is in use now worth the effort?

[PowerDiver]

This is because the memory-leak-causing inscriptions change (quark removal) was reverted in between, nuking the fix. Sorry. Was there a ticket I can reopen?

It got fixed before I got around to opening a ticket, so I didn't bother.

[Magnate]

This had been fixed in what I got from git clone on 2011/01/03 but has reverted to buggy behavior [uninscribed not merging with inscribed] in what I got from git clone on 2011/01/13.

This is because the memory-leak-causing inscriptions change (quark removal) was reverted in between, nuking the fix. Sorry. Was there a ticket I can reopen?

[PowerDiver]

In yet another strangeness, I had two staves of teleport stacked and a third one unstacked in my pack that did not merge. The cause has something to do with my !* autoinscription. When I uninscribed the one, they merged and kept the !*. Of course, my savefile may be corrupted by the back-and-forth.

This had been fixed in what I got from git clone on 2011/01/03 but has reverted to buggy behavior [uninscribed not merging with inscribed] in what I got from git clone on 2011/01/13.

[takkaria]

I guess I am running through gdb for the forseeable future. I don't yet know if this is reproducible. I started up again, shot a few arrows inscribed f0 [4 I think] and then a bunch with no inscription. I plan to save and reload, but first I'll copy some messages.

I really wish recent messages got dumped in the char dump even when you didn't just die.

A couple messages with increasing numbers:

You combine 57 arrows (1d4) (+0, +0) {f0} in your quiver (n).

Then several increases with the f0 missing up to 63
You combine 59 arrows (1d4) (+0, +0) {} in your quiver (n).

Somewhere in there I wield one arrow of wounding into the quiver. Then I pick up another arrow, I think one I shot from the ones with empty {} inscription.

You have 62 arrows (1d4) (+0, +0) {0C-??}
where the ?? are chars I do not know how to type, first a + over a - and second a superscore [an _ but up high]

Woohoo! -- it saved and reloaded with the strange inscription. Savefile available if you want it.

OK, with that info I know where the problem is: wield_item():cmd-obj.c needs fixing to take account of how inscriptions work now. Previously, they were stored as references into a big array of inscriptions that was never freed, only added to (quarks). Now each item contains its own inscription, and what's happening is wield_item hasn't been modified to take account of that. Not got the time to figure it out myself for a little while, though...

[PowerDiver]

Ugh!

I think there are some memory corruption issues that have been introduced with some of the big refactors going on. I also think similar refactors may have caused the bug where the message "You see a XYZ" occasionally gets printed N times instead of once.

I guess I am running through gdb for the forseeable future. I don't yet know if this is reproducible. I started up again, shot a few arrows inscribed f0 [4 I think] and then a bunch with no inscription. I plan to save and reload, but first I'll copy some messages.

I really wish recent messages got dumped in the char dump even when you didn't just die.

A couple messages with increasing numbers:

You combine 57 arrows (1d4) (+0, +0) {f0} in your quiver (n).

Then several increases with the f0 missing up to 63
You combine 59 arrows (1d4) (+0, +0) {} in your quiver (n).

Somewhere in there I wield one arrow of wounding into the quiver. Then I pick up another arrow, I think one I shot from the ones with empty {} inscription.

You have 62 arrows (1d4) (+0, +0) {0C-??}
where the ?? are chars I do not know how to type, first a + over a - and second a superscore [an _ but up high]

Woohoo! -- it saved and reloaded with the strange inscription. Savefile available if you want it.