Torches

[jens]

I guess I have some sort of resource management optimisation syndrome, so it's hard for me to waste fuel. If I have a used torch in hand, and a bunch of new ones in my back pack, and it's time to refuel the torch, I don't just fill up the torch with one in the back pack, because then I'd loose about a 1000 turns of fuel. Instead I wear one of the new torches, carrying around the old one in an extra inventory slot. When I have burned those 1000 turns of fuel, then I refill the torch using the old one that is now in my inventory.

It's a bit of a hassle, and it wastes an inventory slot (well if I really need the slot I refill earlier). So, does anyone else have the same problem I do?

In any case, I just thought of a solution to my problem:
Change torches so they have a maximum capacity of 6000, but start out at 3000. IIRC they used to have 3000 fuel, so it should work OK, and we can always increase allocation to match.

One problem is that then torches would in my opinion be strictly better than lanterns. Today torches are better, except that I want to avoid the hassle, so I prefer Lanterns. I'd suggest changing ego items so only Lanters would apply.

[Derakon]

...well, I was going to say that the disadvantage to torches is their increased weight, but that doesn't seem to apply any more. Torches are 1.2 pounds each and lanterns are 5. Torches used to be 3 pounds apiece, which made a powerful weight-saving argument in favor of lanterns.

Still, lanterns have the advantage of being able to store 15000 turns of light at a time, which is more than enough for one dungeon dive (especially as you'll find other sources of fuel in the dungeon). Typically with lanterns I fill up in town, and fill-and-discard with any oil or lanterns I find in the dungeon, then don't bother carrying oil at all. That's not so easy to do with torches, so you end up wasting an inventory slot.

In any event, if you're worried about fuel, just carry more light with you. I can't remember the last time my light source went out. It's not like either type is expensive.

[jens]

...well, I was going to say that the disadvantage to torches is their increased weight, but that doesn't seem to apply any more. Torches are 1.2 pounds each and lanterns are 5. Torches used to be 3 pounds apiece, which made a powerful weight-saving argument in favor of lanterns.

Yeah, could increase the weight of torches a bit again I guess :-)

Still, lanterns have the advantage of being able to store 15000 turns of light at a time, which is more than enough for one dungeon dive (especially as you'll find other sources of fuel in the dungeon). Typically with lanterns I fill up in town, and fill-and-discard with any oil or lanterns I find in the dungeon, then don't bother carrying oil at all.

I usually bring a flask of oil with me, just as a precaution, but ready to throw it away if needed.

In any event, if you're worried about fuel, just carry more light with you. I can't remember the last time my light source went out. It's not like either type is expensive.

Well, that's why I prefaced my note with me having a syndrome... I mean, I know what I could do. It's just what I actually do that is a problem. And I know how to change the game so I would not have that problem...

[Philip]

description of problem

In any case, I just thought of a solution to my problem:
Change torches so they have a maximum capacity of 6000, but start out at 3000. IIRC they used to have 3000 fuel, so it should work OK, and we can always increase allocation to match.

Of course, different times mean different needs, but while browsing old threads I saw one about making torches always have max fuel, so combining them into one stack with half the torches wouldn't be necessary to save fuel. This may have been back when torches gave one radius light, meaning that it may not apply. Also, why make torches lighter? That is supposed to be a major problem.

[jens]

Of course, different times mean different needs, but while browsing old threads I saw one about making torches always have max fuel, so combining them into one stack with half the torches wouldn't be necessary to save fuel. This may have been back when torches gave one radius light, meaning that it may not apply. Also, why make torches lighter? That is supposed to be a major problem.

Back in those days torches had a somewhat random amount of fuel, so you ended up with several stacks of them. If they had only decided to always give torches half of max instead ;-)

[buzzkill]

Torches should stack regardless of the fuel remaining. Inspecting the stack could display the individual fuel amounts to the player (if this info is deemed relevant). Problem solved.

Wands should works this way too, rather than combining charges. Staffs too. Once staffs stack, they should stay stacked even if the numbers of charges then change. The current behavior makes no sense.

[jens]

Yeah, that sounds better :-) I started by checking the stacking code for wands, but I felt it was too involved to bother bringing torches to that...

[Magnate]

Yeah, that sounds better :-) I started by checking the stacking code for wands, but I felt it was too involved to bother bringing torches to that...

It is better, but it's one of those improvements whose effort to code is way beyond the expected benefits.

Currently, a "stack" is actually a single object. All objects have a property "num" which is how many in the stack (usually 1, up to 99). Charges are stored using the object's pval, which is why they get combined in a stack (multiple pvals are a red herring here). I confess that I can't remember whether lights use o_ptr->pval or o_ptr->timeout for fuel, but it's the same issue. (That said, stacks of rods recharge one at a time, so there must be some way to track individual timeouts - but I suspect a terrible hack.)

Anyway, making a stack of objects a collection of individual objects is quite a lot of work at quite a fundamental level, for fairly small gains. (There are almost no properties other than fuel/charges which are affected by this approach.)

The good news is that it's essentially the same code needed to create bags of holding (or potion belts, or whatever - any container-type code). d_m has been saying for a long time how much he dislikes the INVEN_FOO hackery (scarred by the quiver experience), so maybe he'll rewrite it one day (but it's not on his to-do list for 3.4 ...).

[Max Stats]

Anyway, making a stack of objects a collection of individual objects is quite a lot of work at quite a fundamental level, for fairly small gains. (There are almost no properties other than fuel/charges which are affected by this approach.)

I can only think of one instance where this would be a significant improvement, which is when you have emptied out all the charges from something but don't want to discard it because you might recharge it in town and use it again (Staffs of Mapping in the early levels would probably be the best example). But if you happen to find a like item with charges, they merge and you are stuck with two combined items with half the charges in each one.

This could be solved without going to all the trouble of tracking individual items, though, by swapping the empty item with the one on the ground rather than merging them, if you are playing with the "auto-pickup like items" option on. If, for whatever reason, the player really did want to combine the items, the pickup command 'g' could combine them.

[Magnate]

I can only think of one instance where this would be a significant improvement, which is when you have emptied out all the charges from something but don't want to discard it because you might recharge it in town and use it again (Staffs of Mapping in the early levels would probably be the best example). But if you happen to find a like item with charges, they merge and you are stuck with two combined items with half the charges in each one.

This could be solved without going to all the trouble of tracking individual items, though, by swapping the empty item with the one on the ground rather than merging them, if you are playing with the "auto-pickup like items" option on. If, for whatever reason, the player really did want to combine the items, the pickup command 'g' could combine them.

But that wouldn't address your use case, would it? What you want is to be able to carry both items in your inventory (one to use, one to sell/recharge) without the charges merging. I don't think there's an easy way to do that.

Besides, adding special-case code for pickup commands would be icky.

[Max Stats]

But that wouldn't address your use case, would it? What you want is to be able to carry both items in your inventory (one to use, one to sell/recharge) without the charges merging. I don't think there's an easy way to do that.

I would be happy leaving the empty behind and just carrying the charged one. I can't say that every user would feel the same, though.

Besides, adding special-case code for pickup commands would be icky.

I wondered about that. I don't suppose that the pickup code currently cares whether it was called from auto-pickup or manual pickup, and this would require differentiating them. I guess this would be almost as icky as keeping track of each item separately.

[Magnate]

I wondered about that. I don't suppose that the pickup code currently cares whether it was called from auto-pickup or manual pickup, and this would require differentiating them. I guess this would be almost as icky as keeping track of each item separately.

Ah, I meant to distinguish "icky" from "difficult". Keeping track of each item separately is a laudable aim, if perhaps a dubious ROI. Writing special-case code for manual pickup is not difficult, but is the kind of thing that the real programmers on the devteam would not be happy about!

[buzzkill]

While I'm not fluent in C and have no knowledge of the Angband code-base, which is where I suspect the majority of the problem lies, how hard would it be to just expand the inventory slots behind the scenes and then consolidate the info when displayed.

In this way we could stack other things. CLW,CSW,CCW and healing could stack. Slow poison and Neut poison could stack. Same-type rings but with different pvals.

[Magnate]

While I'm not fluent in C and have no knowledge of the Angband code-base, which is where I suspect the majority of the problem lies, how hard would it be to just expand the inventory slots behind the scenes and then consolidate the info when displayed.

In this way we could stack other things. CLW,CSW,CCW and healing could stack. Slow poison and Neut poison could stack. Same-type rings but with different pvals.

It's hideous, honestly. The inventory slots are hard-coded #defines!! We need a completely different approach to inventory management, which is a low-level rewrite. It's connected with (but not identical to) the rewrite of the o_list[] array - one of those (numerous) situations where you wouldn't do one without the other, and they're both big jobs without much in the way of satisfying development.

[Max Stats]

It's hideous, honestly. The inventory slots are hard-coded #defines!! We need a completely different approach to inventory management, which is a low-level rewrite. It's connected with (but not identical to) the rewrite of the o_list[] array - one of those (numerous) situations where you wouldn't do one without the other, and they're both big jobs without much in the way of satisfying development.

I know we're not really going there now, but if such a rewrite is ever undertaken, I have always thought that the number of inventory slots should be unlimited (or at least large enough to almost never be reached) but that the number of items that can be carried should be constrained by volume. So in addition to weight, each item would be given a volume and once the total volume of your pack is exceeded, the item that was just added will overflow, just like slot 'x' does now. This solves the nonsense that you can carry 99 scrolls of the same type, but not 24 scrolls of different types, or that the same pack that maxes out at 23 distinct potions can also hold 23 sets of full plate armor.

After that we would get to argue about whether max volume should be fixed for all characters, variable by race/class but otherwise fixed, or variable by some combination of DEX, CLev, race, class, etc. What fun!