Open GoogleCodeExporter opened 9 years ago
You are attempting an impossible combination by trying to merge a cmdset with a
high priority onto a stack yet expecting it to behave differently with a cmdset
further down in that stack.
Here is the merge order (ignoring channel/exit cmdsets):
PlayerCmdSet (prio -5, Union)
CharacterCmdSet (prio 0, Union)
TestCmdSet (prio 29, Replace, Union for PlayerCmdSet)
What happens here is that these are merged in reversed priority order:
CharacterCmdSet is merged onto the PlayerCmdSet to form a new, merged set named
CharacterCmdSet. Onto this is then merged TestCmdSet, but since it is merging
onto the merged set (named CharacterCmdSet) it will not trigger its special
condition, which was set for PlayerCmdSet.
TestCmdSet and its key_mergetype exception will only work on the cmdset it is
actually merging with, i.e. CharacterCmdSet. If you want it to operate on
PlayerCmdSet further town in the stack), you need to insert it in the right
place of the priority queue (give it say, priority=-4).
So what you want to do is not possible with this combination of permissions and
stack. custom mergetypes were originally intended to be used mainly on simpler
merges, on top of object-level cmdsets. I can see why it would be confusing,
but I'm not sure how one would do the merging to have it work the way you want
it to.
I'll try to expand the docs on just how mergetype comes into the merge order.
(The code also had a bug which made it impossible to insert custom cmdsets with
priorities<0, this is fixed in latest push. This was due to the Empty sets
having prio 0 and getting weeded out. Empty sets have prio -100 now instead)
Original comment by griatch
on 4 Jan 2014 at 5:13
Original issue reported on code.google.com by
daniel@benoy.name
on 19 Dec 2013 at 5:32