priority

Posted by Splat on 02/01

From: Sammael Monday, January 31, 03:04PM I honestly don't think the imms even understand prio :P I think its buggy, but it works, so they just leave it be. Who knows!

From: Ea! Monday, January 31, 06:18PM Fight priority has nothing to do with perc. It's based on a variety of things, but the main factor is who intiates the combat. It does take wary/agg into consideration. In the case you give, assuming that you attacked the fighter, you should have approximately at 70% chance of getting priority. I'd chalk it up to bad luck that it wasn't as close to the expected numbers as it could have been. It's hard to tell with a statisitcal sample of only 7. I'm pretty sure when Rufus reworked the code he was pretty careful to test that priority was working the right way. Whereas I doubt that the overall priority queue for combat is in error, it wouldn't suprise me at all if there were locations in the code where the code gets confused about who is initiating the combat -- there at least used to be (and may still well be, it's hard to tell) problems of this sort with the shoot code. I wouldn't be suprised if it existed elsewhere as well. If you notice specific places in the initiation of combat where the wrong person is getting priority, let us know and we'll fix them. Of course, there's always the chance of a much more subtle problem, but those types of bugs are much harder to track down... -Ea!

From: Rufus Monday, January 31, 06:41PM Okay, just for arguments sake, let's consider for a moment that I might know how priority works... Pretty much the way Ea! explained it, however, it's not a true queue in the sense that's it's first in, first out, but it goes through a number of checks. It decides who is going to be placed in the queue first, then places them, then the other person. Now depending on a few factors, this can go either way, but it should be somewhere around the 70% that Ea! mentioned. Sometimes it needs to place someone at the end of the queue, but most of the time it places them at the beginning. By this, I mean that it places it in the first free slot in the beginning of the queue, or the first free slot, counting backwards, from the end of the queue. If a person already happens to be on the fight queue for some reason (there are reasons a person remains on the fight queue for a while, even after they stop fighting, there is also a built-in thing where people sort-of 'hang around' on the queue for a while, although the time is reasonably short) so if the person attacking is attacking someone else on the fight queue already, they may get placed on the fight queue after the person who gets placed 'last'. On the flip side, there's also no guarantee, when someone gets placed in the back of the queue, if the person they're attacking is already on the queue somewhere, even farther towards the end than the first person. I expect to make changes to this someday. Ideally, I'd like to roll for 'initiative' every combat round, but that would take a significant rewrite of the way fight queuing and priorities work. -Ruf

From: Viagra Monday, January 31, 09:21PM Rufus, don't wanna be rude here, but could you please post in english for us coding impaired types? ;)

From: Manticore Monday, January 31, 09:18PM There are times i think when the fight queue gets screwed over, and backstab and offensive spells are some of them, i think. In my experience anything that lets the opponent walk out of the room or go ooc/rent after initiation is something that can screw up the queue, but then again, i haven't seen the code :p It's pretty silly imho that headbutt and other stunning specials reset priority. For some reason the code must think that stunned people aren't fighting, and i've noticed some prio diff with stuns against mob depending on whether they manage to growl in anger after they wake up/when they don't. Well, i personally wouldn't mind going back to the renting for priority system, simply cuz there are too many cases where both of them want the same thing... headbutters don't mind having later prio, and backstabbers don't mind having earlier prio... etc. But if that's not the way it works, it should just be made so that whoever initiates combat (the way we see it, not the way the code sees it) gets prio, period.

From: Splat Monday, January 31, 11:53PM Mmm, I had a feeling that backstab wasn't inititiating like other skills since you could rent right after a backstab, perhaps that's messing up priority in some way. Also, I'm quite sure it was said long ago that perception would play a part in it.. That's why I brought this up. Anyway, isn't it possible to do a check of both parties wimpy settings AFTER each fight round and make them flee whether hit or not so priority would no longer be an issue?

From: Splat Tuesday, February 01, 12:08AM On second thoughts, it'd probably be easier to use a 'will_flee' flag after being hit to get around the prob of fleeing on the first round.. There'd be other issues involved but probably be less overhead than a queue and both would get their hits in!