"the city guard appears to be slightly healthier than you" I have 2 hp. I wouldn't be suprised if this guard was anywhere but th, sora, 2005-05-02 20:56:37

"the city guard appears to be slightly healthier than you" I have 2 hp. I wouldn't be suprised if this guard was anywhere but the CH temple? Its a peaceful place, how could he have lost it

hmm, allaryin, 2005-05-03 18:24:57

I checked him just now, and he was fully healthy (70 hp - a rather wimpy guard, really)

The reason for the rating you got would have been a bad skill check I think ;)

ahh, sora, 2005-05-05 13:58:26

so what you're saying is that sometimes my results may not only be complete, but inaccurate?

If I had 100 hp and my opponent had 99, obviously the correct reposonse would be abotu the same or, I have slightly more, could it also report that (based on skill rolls), I have "significantly more"? "slightly less"? "significantly less"? how far off can I be? How much can I trust the results?

general rule, allaryin, 2005-05-06 16:52:28

The lower your skill, the wider the variation might be. Though, in general, you shouldn't ever be too horribly wrong. Just consider them a few times if you're in doubt.

heh, sora, 2005-05-07 00:38:32

I don't know where the thread is, but I remember talking about how when you do something (like consider), the result given is as if you had done the thing already several times.

I remember it being explained like that to remain IC, but the code works something like this.

When a player considers a mob, the result is cached for the user, so that next time they consider that same mob the same result is given, this was partially done to preven the user from constantly queuing "consider snake" to give free practices to the consdier command.

So we can't just consider a few times for good measure.

moving to idea, malap, 2005-05-09 19:55:12

OK, established that there wasn't a consider bug, just an unlucky attempt.

Consider does not currently cache considers but should definitely do so. Wizards, this is a pretty straightforward opportunity -- remember that a verb is an object, so it can have state. Just have an array with a timestamp or something.

Prolly a bug, sora, 2005-05-09 20:23:14

Maalox had more HP than I did, and I repeatedly got "you are way healthier than maalox. EVERY time I did it I got the same result.

Its prolly caching it somewhere, it kinda has to be for this result to occur, whether or not it is intended, or desired is required to know whether this is a bug or a feature.

well..., allaryin, 2005-05-10 07:52:39

If it is caching, then it is a desired feature ;) Probably implemented as a way to prevent spamming the command in order to practice the skill.

uhh, yes, sora, 2005-05-10 11:55:33

but the code doesn't say to do that (At least according to malap). Malap guessed that it was a bug.

Woah, it's not that hard, acius, 2005-05-24 16:59:14

The lib has direct support for caching skill checks. Compare:

player->skill_check( "knowledge.carpentry", 10, 40 );

to

player->cached_skill_check( 120, "buildtable", "knowledge.carpentry", 10, 40 );

... The second does the same thing, except that the result is cached. The first extra parameter is the amount of time for the skill check to stick, in seconds; so you should wait 2 minutes before trying again in this case. The second parameter is a 'tag' to attach to the skill check. This can be a constant value, or it can be the name of a monster, etc. ... If the tags differ, then the attempts are cached separately. So if you consider a guard, and then consider a bunny, the sticky check for the guard doesn't stick for the bunny; but it does stick if you reconsider the guard.

This is a pretty neat feature. Thus, I share.

hmm, sora, 2005-05-24 18:29:14

so is it using the cached call now? I think that Malap said it wasn't. What's the cause of the behavior then?