Feature - Implemented Improve skill use tracking, particularly for daily-limited skills
- Thread starter zarqon
- Start date
roippi
Developer
_lunchBreak already exists!
Er.. these would all be new preferences, so nothing would break. I do agree they should be descriptive names to be consistent, though.
Winterbay
Active member
_lunchBreak already exists!
What do you know, another one of those things that you only discover are there after you make a fool out of yourself for not checking
zarqon
Well-known member
Descriptive name. Not only consistent, but easy to search with the prefref alias.
Although adding new tracking properties is fine, part of the point of my original feature request was to make adding new properties less important, since 1) the daily limit would be part of skill data, and 2) all skills use would be tracked in-session. Anyone who played one day in multiple sessions would probably squander a few server hits bumping their heads up against the casting limit again, but it's still a significant improvement on no tracking at all -- even without a tracking property, scripts can check s.timesCast against s.castingLimit.
I always use two spaces between sentences, even if HTML doesn't show it. I also write out the word "you" and use punctuation in text messages. And when walking with a girl, I walk on the side closer to the street.
Although adding new tracking properties is fine, part of the point of my original feature request was to make adding new properties less important, since 1) the daily limit would be part of skill data, and 2) all skills use would be tracked in-session. Anyone who played one day in multiple sessions would probably squander a few server hits bumping their heads up against the casting limit again, but it's still a significant improvement on no tracking at all -- even without a tracking property, scripts can check s.timesCast against s.castingLimit.
I always use two spaces between sentences, even if HTML doesn't show it. I also write out the word "you" and use punctuation in text messages. And when walking with a girl, I walk on the side closer to the street.
I like the idea of adding the cast limit to the data file, even though it's hard to conciliate with the idea of preferences with descriptive names. Using a server hit to discover the player has already hit the limit seems kind of wasteful though. Maybe a _skillXXXX preference isn't such a bad idea.
I always hold doors, I still use a ball-mouse, and when there is an asterisk somewhere, I can spend a full 5 minutes looking for an inexistent footnote.
I always hold doors, I still use a ball-mouse, and when there is an asterisk somewhere, I can spend a full 5 minutes looking for an inexistent footnote.
Winterbay
Active member
Oh, yes. That is the most annoying thing in the entire world...
zarqon
Well-known member
Please don't interpret me as suggesting that the tracking properties are bad or unnecessary. Adding them is useful. I'm merely saying that currently if you tell mafia to cast any limited skill which is not tracked in properties 1,000,000 individual times, that's 1,000,000 server hits telling you that you're out of casts.
With the all-purpose tracking I suggest, even for skills freshly added to mafia's data files, it would be only 1 server hit per session for mafia to know you've reached the limit. Proper, property-based tracking can then be added later if it's deemed important, but in the meantime simply adding a little number -- the daily limit-- into the data file would be enough to save server hits.
IDEA: a single _property containing all daily skills use. If this is too much information for a single property to hold, skills without limits could be omitted, being tracked purely during your session. It could be formatted as JSON or however is convenient for mafia itself, indexing skills by integer rather than string, whatever. Making the property easy to understand/parse is not a concern since all of the information would be available in proxy records.
Previous tracking properties could be
1) left in. They would work in addition to the new property.
2) omitted from prefs but internally hardcoded to point to the new property's information so as to remain backwards-compatible but hopefully point future scripters in the right direction.
3) completely removed. This would break some scripts -- but would reduce preference bloat, as well as get rid of some of the daily properties which lack an underscore, thus also reducing the recurring questions about why some daily properties have underscores and some don't.
4) phased out gradually using any progression of the above.
I think this is a forward-thinking solution to skills tracking, since it can accept a new skill easily without anything special needing to be coded into mafia for it, or any new properties added. Thoughts, anyone?
tl,dr: Roippi, maybe you ought to hold off on adding lots of new properties just yet.
With the all-purpose tracking I suggest, even for skills freshly added to mafia's data files, it would be only 1 server hit per session for mafia to know you've reached the limit. Proper, property-based tracking can then be added later if it's deemed important, but in the meantime simply adding a little number -- the daily limit-- into the data file would be enough to save server hits.
IDEA: a single _property containing all daily skills use. If this is too much information for a single property to hold, skills without limits could be omitted, being tracked purely during your session. It could be formatted as JSON or however is convenient for mafia itself, indexing skills by integer rather than string, whatever. Making the property easy to understand/parse is not a concern since all of the information would be available in proxy records.
Previous tracking properties could be
1) left in. They would work in addition to the new property.
2) omitted from prefs but internally hardcoded to point to the new property's information so as to remain backwards-compatible but hopefully point future scripters in the right direction.
3) completely removed. This would break some scripts -- but would reduce preference bloat, as well as get rid of some of the daily properties which lack an underscore, thus also reducing the recurring questions about why some daily properties have underscores and some don't.
4) phased out gradually using any progression of the above.
I think this is a forward-thinking solution to skills tracking, since it can accept a new skill easily without anything special needing to be coded into mafia for it, or any new properties added. Thoughts, anyone?
tl,dr: Roippi, maybe you ought to hold off on adding lots of new properties just yet.
Last edited:
zarqon
Well-known member
This particular feature request is for daily casts, not per-combat casts. I'd imagine per-combat tracking would be a separate field. I'm not actually as excited about that as you might guess, either -- BB needs to track skill availability itself anyway, due to its predictive combat queue.
Knowing daily casts of combat skills is still useful -- a consult script such as SS could check to see whether the player is using combat skills to kill monsters or only regular attacks, and make decisions accordingly.
Knowing daily casts of combat skills is still useful -- a consult script such as SS could check to see whether the player is using combat skills to kill monsters or only regular attacks, and make decisions accordingly.
I was thinking about adding a field in classskills.txt for the maximum number of casts per day of every skill (-1 or maybe 0 = unlimited), but for combat skills that same field could be interpreted as the maximum number of casts per fight.
This would be part 1 of the feature request: only the cap, not the actual tracking.
I thought this would help for the predictive abilities of BatBrain, since it would know easily if a given skill could be used several times.
This would be part 1 of the feature request: only the cap, not the actual tracking.
I thought this would help for the predictive abilities of BatBrain, since it would know easily if a given skill could be used several times.
zarqon
Well-known member
Like I said, you'd need a separate field for per-combat casting limits. Unless you want the value to be meaningless for Consume Burrowgrub.
And other than Burrowgrub, offhand I can't think of any X-per-combat skills where X is more than 1. BB needs to predict and track this anyway, so I'd much rather that the value mean daily casting limits, for all skills, including combat skills.
And other than Burrowgrub, offhand I can't think of any X-per-combat skills where X is more than 1. BB needs to predict and track this anyway, so I'd much rather that the value mean daily casting limits, for all skills, including combat skills.
Well, technically, Consume Burrowgrub doesn't have a daily limit (practically, though, it'd be 6.) You can only use the Burrowgrub Hive once per day, and using it sets your "available grubs" counter to 3; that counter doesn't get reset at rollover, however, so you can use the hive on day X-1, consume three grubs on day X, use the hive on day X, and consume another three grubs on day X.
Last edited:
Limit of 3 and set current uses to 0 when used out of combat seems best.
roippi
Developer
Well, I thought I had the framework for this done, but then I did this:
Hm. Does kol silently reduce the number of casts to be maximum allowable?
Now that I look at the responseText, we should probably just parse the "Y / 5 casts used today." message received from a successful cast to keep our state in sync with KoL.
Code:
> cast 8 inigo
Casting Inigo's Incantation of Inspiration 8 times...
You acquire an effect: Inigo's Incantation of Inspiration (duration: 50 Adventures)
Inigo's Incantation of Inspiration was successfully cast.Hm. Does kol silently reduce the number of casts to be maximum allowable?
Now that I look at the responseText, we should probably just parse the "Y / 5 casts used today." message received from a successful cast to keep our state in sync with KoL.
Winterbay
Active member
Sometimes and sometimes not...
Casting too many libram-casts makes it cast as many as you can, casting too many Pastamancy leads to it not casting any with an error message...
roippi
Developer
r9691 adds _inigosCasts, mostly because that's the only limited-use buff that I have. The framework is there to easily add the remaining ones, I'm just lazy. I'll get around to it.
Fortunately we have a "N casts used today." message to parse, so we do that here in order to keep states synced.
Fortunately we have a "N casts used today." message to parse, so we do that here in order to keep states synced.
roippi
Developer
r9699 finishes out the limited-use buffs that come with the "casts used today" message. New preferences added:
_benettonsCasts
_companionshipCasts
_donhosCasts
_elronsCasts
_precisionCasts
_thingfinderCasts
All untested.
Still need Managerial Manipulation and Summon hobo underling.
_benettonsCasts
_companionshipCasts
_donhosCasts
_elronsCasts
_precisionCasts
_thingfinderCasts
All untested.
Still need Managerial Manipulation and Summon hobo underling.
Last edited: