Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove bogus pvals #3609

Closed
angband-import opened this issue Jan 11, 2020 · 8 comments
Closed

Remove bogus pvals #3609

angband-import opened this issue Jan 11, 2020 · 8 comments
Labels
R: fixed (in v4) Resolution: Fixed in v4 (only for v4, no longer current) T: enhancement Type: An improvement to the game
Milestone

Comments

@angband-import
Copy link
Collaborator

Reported by magnate on 22 Sep 2011 13:00 UTC
Prior to lots of other object stuff (see [[Goals for 3.4]] but in particular #1039) we need to stop using pvals for stuff that isn't a pval flag. The three cases are:

food: I suggest a simple o_ptr->food value would suffice, though there are probably better solutions long-term

fuel: again, o_ptr->fuel suggests itself. In fact this could do for both fuel and food, unless we envisage some sort of elvish draught that would have one value when quaffed and another when poured into a lamp. Decrementing this value for in-use lights would probably be easier than using o_ptr->timeout.

gold: IMO this ought to be fixed by making o_ptr->number u16b and multiplying by sval to get the gp value

@angband-import angband-import added T: enhancement Type: An improvement to the game M: 3.4.0 labels Jan 11, 2020
@angband-import angband-import added this to the 3.4.0 milestone Jan 11, 2020
@angband-import
Copy link
Collaborator Author

Comment by magnate on 22 Sep 2011 13:02 UTC
Ooops. I forgot about case four: charges. ISTR discussion a while ago about moving to o_ptr->charges[] so that stacks of charged items remember their individual charges.

@angband-import
Copy link
Collaborator Author

Comment by takkaria on 22 Sep 2011 17:12 UTC
Moving to o_ptr->charges[] is really really difficult - it took me months to figure out how to do it, and that was independently of any other changes. The problem comes from the fact that the object management code is not set up to allow leak-free allocating and freeing of arrays within the object structs. It seems sensible for fuel/food/charges to all share the same field, though.

If number is u16b and we use that to store the GP value, why would multiplication be needed?

@angband-import
Copy link
Collaborator Author

Comment by magnate on 23 Sep 2011 07:57 UTC
I was envisaging o_ptr->number to be the number of coins, rather than the gp value. That's probably unnecessarily complicated though, and your way is better.

So in the first instance we move to o_ptr->fuel for light/food/charges, and charges remain munged together for a stack until we sort out the array-leakage ...

@angband-import
Copy link
Collaborator Author

Comment by takkaria on 23 Sep 2011 12:14 UTC
On a slightly pedantic and OT note, the game's exact wording is "ten gold pieces worth of silver" - it's a lump of metal rather than coins that the player picks up.

@angband-import
Copy link
Collaborator Author

Comment by magnate on 13 Oct 2011 09:35 UTC
This ticket is addressed in (or enabled by) #94

@angband-import
Copy link
Collaborator Author

Comment by magnate on 13 Oct 2011 13:45 UTC
This is done in http://github.com/angband/angband/pull/94

@angband-import
Copy link
Collaborator Author

Comment by magnate on 21 Oct 2011 15:58 UTC
Initial assignment to v4 per http://trac.rephial.org/roadmap

@angband-import angband-import modified the milestones: 3.4.0, 4.0 Jan 11, 2020
@angband-import
Copy link
Collaborator Author

Comment by magnate on 22 Oct 2011 12:56 UTC
Fixed in the affixes merge [r48ccc16f]

@angband-import angband-import added the R: fixed (in v4) Resolution: Fixed in v4 (only for v4, no longer current) label Jan 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R: fixed (in v4) Resolution: Fixed in v4 (only for v4, no longer current) T: enhancement Type: An improvement to the game
Projects
None yet
Development

No branches or pull requests

1 participant