Timer Group Reset inconsistent

[bob]

A sample config on a dxNothing. http://privatepaste.com/6a4636dff1
I've added a new test to my other tests as detailed here viewtopic.php?f=44&t=6219

This is to cover an issue where a Timer Group Reset appears to be clearing timers that haven't yet been processed.

The Timer Reset Test button has three actions
1. Timer Group Reset
2. Change button 2 text
3. Change button 2 text, but on a 3 second timer delay using Timer Group that is reset in the 1st action.

What happens is that action 3 never fires!.

In contrast if you look at the Timer Test2 button, it does the same thing, although it has more actions, which all fire correctly, so the Timer Group Reset in one instance is preventing some actions from processing in one case, but not the other.

One of the reasons that I'm posting this is to find out whether I'm doing something wrong, as I've setup a number of keymaps like presented on this post viewtopic.php?f=14&t=6140&p=28442&hilit=timer#p28442 which is performing a group reset, and then the subsequent reuse of the same timer in a set of actions under the same step, and if the reset means that the later action doesn't fire it explains why sometimes my stepping through the combat config interrupts itself.

[bob]

An update on my own question.

I assumed that actions were processed in order of appearance, despite having previously been told that they are all processed at once and there is no guaranteed order. Thinking I know better, It turns out, is really my problem.

It seems that in certain circumstances the issuing of processing of actions in whatever unguaranteed order they are issued in will mean that the later Timer is created before the action that Resets the Timer Group is processed, and so, when the Reset Timer Group is processed it stops the later action from taking place.

This means that some of the more complex PRO configurations proposed on the forums may have bugs as they use this same setup of a Reset Timer Group action for a later action in the same step.

[firescue17]

Some random notes:

I assumed that actions were processed in order of appearance, despite having previously been told that they are all processed at once and there is no guaranteed order.

I have been told actions are processed top to bottom in the SAME STEP in the CURRENT WINDOW. For this reason the Timer Pool Reset is the lead Action in every Mapped Key with Window: Current as the Target.

I have also been told Timer Pool Resets are asynchronous between windows and can be further compounded by calling Timer Pool Resets via Virtualized Mapped Keys which may manifest as the Reset arriving prior to the Action it is supposed to be timing. The follow will not work due to the asynchronous reset:

Action 1: Timer Pool 'X' Reset -> all

This can be solved by splitting the reset of a Timer Pool shared by all Windows into two separate Actions:

Action 1: Timer Pool 'X' Reset -> self
Action 2: Timer Pool 'X' Reset -> all other

I personally spent significant time (as in weeks) with a stop-watch double checking, troubleshooting, and generally fighting various issues similar to those mentioned. Some tips (which may not be the best or most efficient) but do work:

1) Always set the Target of the Reset and Window: Current. Correct implementation of the Pro method should prevent the Timer Group from residing in the wrong window from the Character using the Action; however, even if this does occur, the Timer will still only have a single occurrence.
2) Avoid sharing Timer Groups between Windows if at all possible. Some of my profile architecture is overly complex specifically to avoid this.
3) Use unique Action Timer Groups for EVERY ... SINGLE ... ACTION ... ALL ... THE ... TIME ... I had poor success overwriting Time Pools while they were running. I had poor success sharing Timer Pools across Characters (Windows). Unique Action Timer Groups per Character may lead to profile bloat, but helps to alleviate (or at least isolate and troubleshoot) issues.
4) Force Timer Pool Reset Actions on all initiating Steps, even when you expect the Timer Pool to have expired.

[bob]

I personally spent significant time (as in weeks) with a stop-watch double checking, troubleshooting, and generally fighting various issues similar to those mentioned.

I'm dedicated, but I don't have a stop watch . I agree with what you have said and follow points 1, 2, 3, and 4.


The issue I have with the timer group reset action is as I presented though (even with following the points); I get different results depending on the number of actions within the step/button. This has resulted in the need to pad some steps/button to call some other mapped key that does nothing (because it will slow down the processing of later actions), or having enough actions taking place that the need to pad it out doesn't exist.

Another workaround for mapped keys is to set them up to be "press OR released", and have the Timer Group reset occurring on Step 1 and all other actions on Step 2. This resolves it for the most part (but limits configuration in other ways), except in the Menus, which is where I came across the crux of the problem anyway. This method resolved the issue for a couple of low level characters where I only have one set of mapped keys to maintain the current skill state (i.e. adjust the availability in a single rotation rather than multiple).

My initial finding was because I wanted to have a Menu button act as a label showing a timer countdown (hence the sample), but if I reset the timer as the first action, then the countdown doesn't always work because of the asynchronous nature of the Timer Reset.

[lax]

I have also been told Timer Pool Resets are asynchronous between windows

if I reset the timer as the first action, then the countdown doesn't always work because of the asynchronous nature of the Timer Reset.

Just to clear this up...

This has nothing to do with Timer Pool Resets being asynchronous. They're just as synchronous as everything else. What is asynchronous is the communication between game instances. The same asynchronous behavior happens with ANY action you send to All and compare to actions you send to Window:Current. In ALL cases, the actions you send to Window:Current will be executed by the current window, before any action that sends to All, whether it is first, second, third, or hundredth Action. This is because as the Actions are performed, all the one that goes to All does is send a message for "all" to do the desired Action, and that is going to happen only AFTER the main Inner Space program accepts and routes the message, sending it to each appropriate window...

Reset the timer as the first Action, but instead of doing it in all windows, do it in the current window like firescue17 said.

I get different results depending on the number of actions within the step/button. This has resulted in the need to pad some steps/button to call some other mapped key that does nothing (because it will slow down the processing of later actions), or having enough actions taking place that the need to pad it out doesn't exist.

How are you getting different results depending on the number of actions? What sort of different results?

In your testing you should stick to only Window:Current so you can get consistent behavior that you can find easier to understand. The entire test as privatepasted above is ruined by Window:All w/ Current, and would work fine with the ONE action that is set to that, set to Window:Current instead. It made no sense for it to be set to Window:All w/ Current anyway because the test Character Set has only one Character...

[bob]

Sweet, good to know I did something wrong and it caused a problem. TBH, I hadn't gone back and checked my sample studiously to figure out whether I had followed all the points when setting up the example. I should have done so.

How are you getting different results depending on the number of actions? What sort of different results?

IIRC this came out of me trying to get a menu button to update itself, but the mapped keys driving it are routed through a number of ATG's and slot specific targeting which are not necessarily aimed at the current window where the menu is (this all makes ISBoxer popup message boxes about my targeting I try and edit one of these too, even if the end result is a single window), but will eventually call back to the current window where the menu is via an ATG, so it is probably along the same lines as you've outlined with the message routing. Now it makes me wonder if I can fix that by some careful planning.....