Add ways to configure what action performers return when reusing existent WU action ID numbers.

[Joedobo27]

Action performers return true when there aren't any more custom actions to handle. This behaviour conflicts with reusing existent WU action IDs. It would be helpful if we could configure how the various behaviours from Behaviours.class interact with new action performers.

The question is:

• Should action performer return true and end the action object? This may prevent other actions from doing something that use the same ID.
• Should action performer return false and keep the action active. This ensures all other action methods get called. Although, listening to action objects is expensive so we need to make sure it's not be done for no reason.

[ago1024]

I'm working on it

[Joedobo27]

okay, I was going to try and help you but I'd probably just be in the way.

[ago1024]

The default return value for standard actions (those defined by the server) is now "false". This will prevent unimplemented methods in the ActionPerformer from always cancelling server actions. The default for custom actions remains "true". Unimplemented methods will stop the action. This is not an issue since the action is most likely only used by the mod which defined it.

You can use the propagate() method to set the propagation of the action to the server and other mods and get the return value for the action method.

There are six flags for propate() which can be used in together. If conflicting options are supplied the later ones count:

• SERVER_PROPAGATION: The action is passed to the server
• NO_SERVER_PROPAGATION: The action is not passed to the server. This is the default for historic reasons to simulate the old abort of the chain by simply returning from the action performer.
• ACTION_PERFORMER_PROPAGATION: Propagate the action to other ActionPerformers. This is the default
• NO_ACTION_PERFORMER_PROPAGATION: Do not propagate the action to other ActionPerformers. The action might have been processed by previous ActionPerformers however.
• FINISH_ACTION: Finish the action. Sets the default return code to "true"
• CONTINUE_ACTION: Continue the action. Sets the default return code to false. The propagate() method will return the default return code.

Any unimplemented methods and the super.action() methods will call defaultPropagation() which does propagate(action, SERVER_PROPAGATION, ACTION_PERFORMER_PROPAGATION). I.E. the default will propagate to other mods, and the server and uses the default return value (false for standard actions, true for custom actions). You can implement defaultPropagation() and set other values to change the behaviour of unimplemented methods.

So some examples:

• The christmasmod uses the Open action and destroys the present. It's pretty useless to pass the action to the server and other mods: return propagate(action, FINISH_ACTION, NO_SERVER_PROPAGATION, NO_ACTION_PERFORMER_PROPAGATION);
• The ExamineAction from the action demo will print an additional message before the actual examine message. The action is sent to the server and other mods by calling the super.action() method: return ActionPerformer.super.action(action, performer, target, num, counter);. Calling propagate directly would work similarily: propagate(action, SERVER_PROPAGATION, ACTION_PERFORMER_PROPAGATION). The return value is not changed from the default which is now false.
• The DemoAction uses a custom ActionEntry. It's simply returning true and false which does not propagate to the server (but other ActionPerformers). The same could be achieved with propagate(action, NO_SERVER_PROPAGATION, ACTION_PERFORMER_PROPAGATION).

The propagate() method simply modifies the default values of the current action. Therefore it's possible to setup the propagation defaults anywhere in the action() method and then return true and false as needed.

[Joedobo27]

Nice, It would have take me a week at least to make something similar in function but my work wouldn't have been so elegant. Thank you for doing this. One question, What happens if say player A tries to override an existent WU, so propagate(action, FINISH_ACTION, SERVER_PROPAGATION, NO_ACTION_PERFORMER_PROPAGATION)

And player b tries to add a new complimenting action that reuses the that same action ID, propagate(action, CONTINUE_ACTION, SERVER_PROPAGATION, ACTION_PERFORMER_PROPAGATION

Given these two uses will there be conflicts? Since we don't control the order is it possible that conflicting flags will cause problems? I not sure if it's even possible to make sure things that continue are executed before things that don't.

[ago1024]

Sorry for the late reply. I though I had this answered already.

The execution order depends mostly on the order the mods are initialized, so mostly on the name of the mod. This is important with the NO_ACTION_PERFORMER_PROPAGATION. But I think this is mostly used for cases where the affected object is destroyed.

For conflicts between action performers managing the same action the rules are:

• The action will be finished if any action performer wants to finish it.
• The action will not propagate if any action performer wants to not propagate it.

[Joedobo27]

It seems fine so far. I was thinking if it's possible to always order mods so those that want to propagate (whether it be to server or to other action_performer) are done before those that do not. It's a hypothetical that probably doesn't need any attention.

[ago1024]

The propagation is chosen when the action is performed and can very between each performing of the action. The order of the actions is determined when they are registered at server start. I would probably need to address this with a kind of dependency system where the processing order of the mods is set up.

I'm currently not sure if this is a big problem at all. This probably matters most if two actions would consume an item, like eating something. The order would determine which mod gets the cake. Or one would say "eww. You can't eat this" and the other "You eat the tasty rotten fish".

[ago1024]

loading order and dependency system has been added in the meantime. #closing