amilee wrote:I hope my post didn't sound to you like I thought I found a glaring mistake in the script. I can quite well imagine how much time you and others have invested into it. I just didn't understand why my change (whether good or not) made no difference. This however I found out by now - I made the change in another script file than I used with mew
I have a couple of questions regarding the script / sim engine:
- How often is getAction(..) being called with "High Resolution Timer" unchecked / checked?
- Does the sim engine simply do nothing if getAction(..) returns an action which can't be carried out due to lacking cp's or lacking energy or is there more to it?
- How would energy pooling work?
If there should be documentation on this kind of stuff please feel free to just point me to it instead of reciting it here.
This stuff isn't documented at all, though the code for it is fairly straight forward (the Simulation engine itself isn't all that big, though there are some quirks to the code and some outright ugliness in places). FWIW most of the answers are in yawning.mew.sim.SimulationEngine.
Anyway.
There's no set time when getAction(...) is called, because this allows the implementation to be considerably faster, yet still manage to query the strategy often enough to give accurate and useful information.
Things that prevent getAction(...) from being called:
* Rebirth/Tranquility casts. (No actions taken when you're forced into raid utility)
* scheduleIdleTime(double) from within the script. (No actions taken when the script says it will be idle for a while.)
Things that cause getAction(...) to be called:
* Time being 0.0 (Encounter start)
* Whenever a event is set to occur in the simulation space. (Auto attacks, DoT ticks, buff gains/fades, etc etc etc.)
* Whenever you exit a global cooldown.
* Every 1 ms whenever there's absolutely no events scheduled. (Not applicable for cats since the energy regen event will always be scheduled.).
Setting the High Resolution Timer option adds:
* Every 1 ms whenever you're not in a global cooldown.
The attentive readers would be going "Hey, doesn't that limit the frequency at which you can take actions off the GCD?", which is correct. I would look into revising the behavior if someone every presents a clear case for it but I don't particularly see any advantage in a button that essentially would be "make the simulation run really slowly".
The current High Resolution Timer option essentially dramatically increases simulation time granularity at moments when it's interesting to do so (you can take on GCD actions, but you haven't for some reason) and goes back to the default of "whenever something one would take actions off occurs" otherwise (Since Mew has cold robotic perfection, it will happily and perfectly hit a TF + Berserk + a pot + a trinket + a CP builder simultaneously, so off GCD actions don't particularly suffer from this either).
Whenever getAction(...) is called, the engine will attempt to execute the specified action (Depending on if the action taken is on the GCD or not, it will call getAction(...) repeatedly). If it fails for any reason, it will execute events scheduled to occur at this particular moment (potentially nothing, there's one rather overloaded event that has an empty execute handler that is scheduled to force getAction(...) calls), and then move on.
To implement energy pooling you would just return null from getAction(...) if you want to pool.
Leafkiller wrote:I don't know how frequently Yawning checks the posts here.
Once a week or so.
