Posted by Splat on 02/01
What's with priority now? I find it damn frustrating not getting
hits in vs mobs, but it isn't even working in pkill as it should.
I'm a sniper type with 90 perc at the moment, just fought a plain
fighter with low perc.. We were both max agg.
He got priority 5 times, I got priority twice!
The breakdown being:
2 x I initiate, I got priority.
2 x I initiate, HE got priority.
3 x HE initiates, HE got priority.
It's bad enough 2.stun is gone, but hit/flee is what makes this
fight system different from other MUD's.
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!
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...
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.
Monday, January 31, 09:21PM
Rufus, don't wanna be rude here, but could you please
post in english for us coding impaired types? ;)
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,
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?
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!