First of all what you say is incorrect, at least with some patch/data version of warcraft 3, as shown by edo494's post. If you took the time to open it yourself instead of spouting purely anecdotal "evidence" as fact you wouldn't have made this mistake.
I tested extensively with units attacking each other. My evidence is concrete for the attack behaviour not allowing armor to reduce base damage below 1. I never tested with fractional damage I do admit (units do not really like that or reflect it in the UI) and I made it clear that I am entirely basing my statement on this fact. I also said it could apply differently so you really have no room to make such comments. The fact you needed someone else to provide the evidence says you were as clueless about the mechanic as I was.
This problem can equally occur with timers of small period (eg 0.01 damage 10 times per second might do 10 damage) - the general solution is to use logic to calculate when to deal 1 damage and when not to, rather than heuristically (guessing) what kind of timer period would make the game "close enough".
The correct approach is to not deal damage sub frame (no need for timers with frequency faster than 60 Hz for this) and to do what you described.
Did you know that Maker can recognize Frame rates even with his eyes?
He considers 0.04 as laggy, and considers 0.03 smooth.
That is because 0.03 is ~1 update per 2 frames or better and 0.04 is ~ 1 update per 2 frames or worse. It is a big difference because your orc Grunt will move smoothly at 60 FPS where as both will be changing at half that rate right next to it. You will notice changes right up to a period of 0.0166 on a computer of reasonable resources as only then will each frame receive an update and so no further smoothness can be resolved (unless you work around the 60 FPS hard cap that WC3 has which I think some managed to with varying results).
Please, tell me how to make a "healing over time" trigger without SetWidgetLife? Your other options are invariable worse than SetWidgetLife.
The system is a Damage over Time/Heal over Time system.
SetWidgetLife will work for healing over time only. As I was specifically explaining the damage over time part, SetWidgetLife will not work for damage over time because it does not do any damage (not reduced, no credit). I do agree that for healing over time SetWidgetLife is the correct one to use since healing is not counted as negative damage. You could also use the appropriate unit life native as well with varying performance results (probably lower).
Game state can only be determined by passing of real time on Harvard/Von Neumann architectures. The only real constant is time. If you have some better way of maintaining game state, please, let me know.
Game states have and always will be advanced by "ticks". This is because time is relative on each system and in order for a game to be deterministic it has to define some standard unit of passing of time such that when executed across any supported system it will produce the same results.
In the old days each tick was coupled to the refresh rate of the output display. This is why Sonic 1 plays slower in Europe than in America as it updated at 60 Hz in the US (since TVs were NTSC so supported 30 and 60 Hz refresh) while in Europe it only updated at 50 Hz (since TVs were PAL so supported 25 and 50 Hz refresh). It was even to such an extent that the music played back slower in Europe than America when playing such games as they consoles were scaled down frame by frame so where as the American console advanced 60 frames per second, the European one only 50 times, meaning that the American system was 1/6 ahead of the European system after 1 second.
Since this was total nonsense, people moved towards decupling refresh rate with game state advancement. However since multi-core processors are a new invention, they often did this my forcing the main thread to wait when ahead of the display so frames were produced at the right but skipping drawing frames if state fell behind.
Now it is a lot more complicated with graphics operating as a separate sub system from the deterministic state as seen in games like StarCraft II. However the fact remains that deterministic state (the actual game state, not your view of the game state which is not deterministic and does not mater) still advances in ticks.
For example StarCraft II (which is actually a pretty good text book example of a pseudo modern game) advances at 16 deterministic ticks per second. If you lower the game speed it simply calls fewer deterministic ticks (such as 12 or 8) per second so the game progresses slower. If you raise game speed it calls more deterministic ticks (such as 20 or 24) per second so the game progresses faster. Even when running slower it still looks smooth as your non-deterministic view interpolates to generate unique graphics for each display refresh (if resources allow, something that can be hard if there are 150 Thor units in view).
As a result of this, fractional timing units in StarCraft II are rounded to the nearest frame to execute. This means that it is impossible to run a timer faster than 16 times per game second. So that missile movers look smooth StarCraft II runs them at 32 times per second with each deterministic frame updating them twice at once and feeding the resulting positional data to the graphic sub system so that they appear more smooth (movement has more frequency information).
Back to physical implementations. Since processors have a non-deterministic interpretation of time (clock rate is unstable, in-exact, varies from model to model etc) you cannot run anything outside of game ticks as there is no way to resolve timing deterministically (so not suitable for multiplayer, competitive play, no replay support etc). As you can probably guess, WC3 must not be using this implementation for sub-frame accuracy, it must be using some other method of determining timer execution (possibly loop decrementing the countdown after every frame advanced).
If you define every game tick as 1/16 of a second you know deterministically that if you are at a certain frame the time is a certain amount. If you want something to run sub-frame the idea is you loop multiple times within a single deterministic tick and then interpolate the results over the output frames (aka SC2 missile movers). Since those are also ticks that means that everything in the simulation of your game ultimately comes down to how fast you advance ticks.
A final way to do time is based on time events. If everything can be interpolated between any quantity of time then you just need to "advance time" until the next time event. The problem with this is that for a useful view of the world at a given time you will need to update the entire state to match the time of the event (or at least be able to supply the results as if it was). I do admit WC3 could use this approach with its timers and it would in theory support any time interval allowed however I would also imagine the performance could be a concern for using this approach. Additionally for determinism the game still needs to update 60 times per second for each frame to be unique and deterministic, since rounding error means that the exact same sequence of time events are required to produce the exact same state at the end.
Frankly I do not know how WC3 works inside. The 60 FPS hard limit for refresh tends to lead me to believe an internal update rate of 60 ticks/second however the support for sub-tick ordered timers with reasonable accuracy leads me to believe a more event orientated approach. I have not tested enough to tell how it works however the fact remains that in theory the time continuum of a game is not continuous or even relative to the real time continuum.
Attached is a trivial example, in diagrammatic form, to help get this through your thick head.
I do not think this is a constructive attitude.