Feature - Implemented Improve skill use tracking, particularly for daily-limited skills

Current standard is some descriptive name... if we were going to skill number, I think it should be consistent, but that breaks anything that people are currently using unless we have duplicate preferences for some period.
 
Winterbay said:
Lunch Break perhaps?
Click to expand...

_lunchBreak already exists! :eek:

Theraze said:
Current standard is some descriptive name... if we were going to skill number, I think it should be consistent, but that breaks anything that people are currently using unless we have duplicate preferences for some period.
Click to expand...

Er.. these would all be new preferences, so nothing would break. I do agree they should be descriptive names to be consistent, though.
 
Well, if we were going to be consistent and go with numbers, then existing commands that use descriptive preferences should be replaced with skill numbered preferences...
 
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.
 
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 too like the idea of castLimit, etc. proxy data, so I don't imagine that adding the preferences will close out the feature request. It's just The Part I Know How To Do.
 
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.
 
Last edited:
Having the limit in the data file has another advantage, for combat skills. I bet Zarqon would be very happy to check if a skill can be used more than once per combat with ( $skill[].combat && $skill[].maxCast == 0 ).
 
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.
 
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.
 
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.
 
Oh, my bad. I couldn't think of any combat skills with daily limits, but things like Consume Burrowgrub and Summon hobo underling do.
 
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:
Terion said:
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.
Click to expand...
Limit of 3 and set current uses to 0 when used out of combat seems best.
 
Well, I thought I had the framework for this done, but then I did this:

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.
 
roippi said:
Hm. Does kol silently reduce the number of casts to be maximum allowable?
Click to expand...

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...
 
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.
 
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.
 
Last edited:
You must log in or register to reply here.
Back
Top