Multiple attacks cannot occur on the same clock tick
Brought to you by:
bob_the_hamster,
teeemcee
Menu
▾
▴
#2041 Multiple attacks cannot occur on the same clock tick
open
nobody
Battles
All/Unknown
Bug Report
20171201 Etheldreme
2020-03-15
2019-03-23
No
At first glance this might not look like a bug, but allow me to persuade you!
If two attacks would occur on the same tick of the combat clock, one of them always occurs first and the other occurs on the next tick, allowing "energy meters" to advance by one tick in between them.
For example, I create a chain of attacks: the first greatly increases the hero's speed, and the second returns it to normal with a delay of 1 tick (this creates a sort of "quick recover" effect where the energy bar gains a chunck all at once). If an enemy happens to do another attack right when that second attack was scheduled to happen, the enemy's attack will occur first and the clock will tick one more time before the hero's speed returns to normal, giving the player two ticks of "super speed" rather than one.
This isn't a "bug" per se, but it does randomly goof with our ability to precicely schedule interesting effects using chains and delays.
If all attacks scheduled for a particular tick would resolve before the clock ticked, it would fix the issue.
Currently, in active-time battles, all the ready meters/etc are advanced and then the attack queue is checked to see whether there's an attack ready. Getting the behaviour you want requires swapping the order of these, so a ready attack prevents that meter advance. But this would be dangerous for backcompat, since it would make all sorts of things "see" one less tick for each attack that's queued. That could be pretty significant in battles with enemies/heroes with speed 999. I would definitely want to add a backcompat bit to enable that new behaviour.
That would be really easy to implement (provided I don't bother to test it properly; the scenario you describe isn't easy to set up). But... I don't really want to. The active-time battle code is already so complex (as these bugs and quirks show) that anything that makes it more complex is definitely a bad thing. Every line of code gets written once and read a hundred times. Having two different paths through such a fundamental piece of code is a lot of extra complexity to think about.
However, we wanted to add a direct way to read and write ready meters anyway. That would be a far better solution for what you want to do, for you, me, and everyone else.
The question is just, should you be able to select "Target Stat: Ready meter" in the Damage Settings menu, or should it be separate setting somewhere? We also want to add a way to modify elemental resists and other values with attacks, so I imagine we'll have a whole Additional Effects submenu for that sort of thing.
Hmm, I could easily just do both!
BTW, when I tested out the one-tick chain to increase the ready meter, as you described, I was very confused that the time bar didn't show what was going on. Turns out that you have to use the Show Battle Meters (F10) debug key to see the ready meter increase; the actual value is hidden while a hero has a blocking queued attack.
I like the idea of targeting the ready meter and elemental resists directly via the Damage Setting menu. It makes sense from a user standpoint, but I'm not sure how this would work with a varying number of element types. Maybe the "target stat" list could always have the element types at the very end to accomodate the varying number of them? Or maybe they could be indexed with negative numbers?
I like the Damage setting idea better than the submenu since we would be able to see it as a popup, rather than it being hidden like the "reset poison register" bitset, etc.
On a side note, how about if the time bar didn't momentarily show as full when a delayed attack is being executed? (not sure why it does that anyways)
I think that the "reset ... register" bits belong in an Effects submenu, not in the Bitsets submenu. Also, the Bitsets menu has been reorganised in the next version anyway; it's an awful mess in Etheldreme.
Of course the advantage of being able to target elemental resists like other stats is that you can make use of all of the existing damage machinery, but if you want to change more than one elemental resist, it's a poor solution. And the damage settings aren't all the flexible anyway. So I suppose that, again, having both methods would be useful.
The time bar showing as full when an attack is about to happen is maybe something it shouldn't do, but a pretty minor thing; but what confused me is that it shows as empty while you're waiting for a blocked attack even though the time bar is continuing to fill up during that time. Once it fills up, then it shows as full.
This bug has been migrated to our new issue tracker on Github: https://github.com/ohrrpgce/ohrrpgce/issues/1100