Feature Update the proxy fullness for pizzas when you have Pizza Lover

Theraze

Theraze

Active member
> ash $item[plain pizza]

Returned: plain pizza
plural => plain pizzas
descid => 709742161
image => plainpizza.gif
smallimage => plainpizza.gif
levelreq => 1
quality => decent
adventures => 2-4
muscle => 0
mysticality => 0
moxie => 0
fullness => 2
inebriety => 0
spleen => 0
minhp => 0
maxhp => 0
minmp => 0
maxmp => 0
dailyusesleft => 0
notes =>
quest => false
gift => false
tradeable => true
discardable => true
combat => false
reusable => false
usable => false
multi => false
fancy => false
candy => false
bounty => none
bounty_count => 0
seller => none
buyer => none
name_length => 11
You learned a new skill: Pizza Lover

> ash $item[plain pizza]

Returned: plain pizza
plural => plain pizzas
descid => 709742161
image => plainpizza.gif
smallimage => plainpizza.gif
levelreq => 1
quality => decent
adventures => 2-4
muscle => 0
mysticality => 0
moxie => 0
fullness => 2
inebriety => 0
spleen => 0
minhp => 0
maxhp => 0
minmp => 0
maxmp => 0
dailyusesleft => 0
notes =>
quest => false
gift => false
tradeable => true
discardable => true
combat => false
reusable => false
usable => false
multi => false
fancy => false
candy => false
bounty => none
bounty_count => 0
seller => none
buyer => none
name_length => 11
Click to expand...
As you can see, I learned the Pizza Lover skill and yet the pizza stats stayed at 2-4 adventures (1.5 average) - however, in the fullness tab of the item manager, it does display the correct 2.5 average. It would be great if the proxy stats displayed the correct adventures as well.
 
The proxy stats correctly state the adventures gain from the item database, which is the base value, not the value for the particular logged on character and current skillset. That's currently the way things are done I believe for all the databases and proxy values reported.
 
Darzil said:
The proxy stats correctly state the adventures gain from the item database, which is the base value, not the value for the particular logged on character and current skillset. That's currently the way things are done I believe for all the databases and proxy values reported.
Click to expand...

Would they be updated if the Milk of Magnesium effect is active? I don't think so - I think it should be up to the user to use the proxy field and known spaded information about the game to determine the value of food.
 
The Food Manager shows the correct values, though. If you have Pizza Lover and Milk, it shows the adventures with the bonus factored. I'm not saying it should be yanked out of Food Manager, just that Theraze has a point. Mafia is saying 2 different things about the same item.
 
As I was looking through the code, it appears that there's an extra adventures value that gets calculated for all of these various things. Any chance we can expose that as an additional proxy field and then we can see that there are extra adventures as we gaze at the items?

It just seems silly to have different values for the item depending on if you look at its proxy records or the item in the food manager. I expect those to be the same, or if different, to have some logic as to how you get from one to the other.
 
Theraze said:
It just seems silly to have different values for the item depending on if you look at its proxy records or the item in the food manager.
Click to expand...

Why? The item proxy field is a property of the item. The food manager is giving you a view of what will happen when you eat the item.

Asking proxy values to update according to character status seems like an un-feature to me. If I ask for an item's adventure range, I expect the value I get to not be munged together with any milk-like effects that I may have going. Am I supposed to reverse-engineer the base value out of what it reports? Even if I do that, it's fragile - new effects (exactly like the one you're asking to be added) will break my attempts at reverse-engineering what the base value is until I update my script.

So I'm very opposed to exposing this information to scripters via updating the existing proxy field. It's the wrong way to do it.

I'm not opposed to exposing the information in a sensible way. An ash function seems clunky but you can't do this through modifiers... eh. Open to suggestions.
 
The item proxy field for adventures is how many adventures that item should give me. Milk is a separate effect and goes away, but the pizza lover skill will be there until you ascend, at the very least... it's not going away. That character WILL get those adventures regardless of if you eat the pizza today, tomorrow, or three weeks from now. For that character, NOT showing that there are extra adventures that will be gained for pizza means you get incorrect information on what happens when you eat the pizza, through the proxy information at least... which is what I tend to use for eating when I'm not using ED or Omnivore or some other script to do it. I've just gotten used to mafia giving me correct and accurate information about what will happen.

Another way to do this would be to expose conditionalExtraAdventures as a proxy field.
 
As you say, it can go away if you ascend. It most certainly goes away if you're selling the item to someone else; perhaps you are doing some sort of price analysis on every item you can create.

I maintain that extra adventures granted by a skill should not be in that proxy field. It is the Principle of Least Astonishment: I am the Least Astonished if no skills/effects/modifiers can affect that proxy field. Once you start going "oh okay this one counts, but not that one because" you've already lost me.

I've just gotten used to mafia giving me correct and accurate information about what will happen.
Click to expand...

Mafia has never reported milk's effect on adventures in that proxy field. You're used to that. This is the exact same thing.
 
roippi said:
Asking proxy values to update according to character status seems like an un-feature to me. If I ask for an item's adventure range, I expect the value I get to not be munged together with any milk-like effects that I may have going. Am I supposed to reverse-engineer the base value out of what it reports? Even if I do that, it's fragile - new effects (exactly like the one you're asking to be added) will break my attempts at reverse-engineering what the base value is until I update my script.
Click to expand...

Playing devil's advocate here, but monster.base_initiative is indeed updated according to character status. Granted, monster.raw_initiative is also available.
 
Theraze said:
Any chance we can expose that as an additional proxy field and then we can see that there are extra adventures as we gaze at the items?
Click to expand...
Given roippi's points, this would seem like a much more coherent solution.

I have to ask how variable numbers are handled. Take the astral consumables and spaghetti breakfast. The lower your level, the less you get from it.
Then there's the ghost pepper, which gives an extra 8-10 adventures after 4 turns.
White Citadel burgers change depending on how many you've eaten (granted, a difficult stat to track).
Is the policy to have the adventure proxy field be the lowest value possible?
 
Fluxxdog said:
Given roippi's points, this would seem like a much more coherent solution.

I have to ask how variable numbers are handled. Take the astral consumables and spaghetti breakfast. The lower your level, the less you get from it.
Then there's the ghost pepper, which gives an extra 8-10 adventures after 4 turns.
White Citadel burgers change depending on how many you've eaten (granted, a difficult stat to track).
Is the policy to have the adventure proxy field be the lowest value possible?
Click to expand...

They vary. Items with intrinsically variable gains, such as astral consumables do have the base value in the database changed, and will show the current value based on characters level in the proxy.
Ghost pepper etc don't have the extra stuff handled, there is no way to guarantee you'll get it.
Some helpers are reflected in the food manager stats, others aren't.
Skills are now, and some helpers are.

Food Manager is pretty basic really. It only shows what you can expect to get based on some things, and doesn't have the complexities of interaction that someone writing an eating/drinking script would want to consider. If it did, you wouldn't have eating and drinking scripts. It's also (mostly) based on what you currently have, not what you could get.

The (current) policy is that the adventure item proxy field is what the item gives you, not what the item + helpers + skills give you.
 
Last edited:
Darzil said:
The (current) policy is that the adventure item proxy field is what the item gives you, not what the item + helpers + skills give you.
Click to expand...
OK, so variable returns are accounted, but not bonuses outside of the item itself. That makes a lot of sense.

So is there any way to expose the work you did in the Food Manager to scripters?
 
Fluxxdog said:
So is there any way to expose the work you did in the Food Manager to scripters?
Click to expand...

Oh, doing it is pretty trivial. However, it doesn't take into account helpers, milk, ode etc, so they'll still have to manage that. It still uses the fairly basic logic of that function, rather than the sort of stuff something like Eat/Drink would do. The risk therefore is that people will assume it is actually more accurate than it is, and not handle the information themselves. If I were using a script for Eating/Drinking I'd hope that the person writing it did understand the complexity and handle it themselves.
 
heeheehee said:
Playing devil's advocate here, but monster.base_initiative is indeed updated according to character status. Granted, monster.raw_initiative is also available.
Click to expand...

I wouldn't be opposed to secondary proxy fields that give access to what we think the adjusted adventure range/fullness value is, as long as we leave the extant proxy fields alone. Or, like, an ash function add_adjustments(item) that returns an "adjusted" $item with any/all context-sensitive adjustments that mafia knows about. Or individual get_xxx_adjustment functions, etc.
 
You must log in or register to reply here.
Back
Top