If someone asks you "is this apple red?" and you answered "yes! bananas are yellow" you would only not be incorrect in the sense that the correctness of irrelevant, misleading information doesn't have ontological status.
That example makes no sense and is totally irrelevant...
It is more like asking "What colour is my apple?" with the response "I saw an apple before and it was red so your apple is likely to be red."
In this case the apple was green so the guess was incorrect. However the apple could have turned out to be red in which case the guess would be right. This is called making an educated guess for knowledge you do not have based on knowledge you do have. Ultimately it is still a guess so could be right or wrong. I made a guess and provided all the facts I based it on however it turned out wrong.
What I do not understand is why you are even making a fuss out of this? I even said at the time that it was quite a wild guess (not the sort one would want to put money on).
Not all simulations are invariant on real time. Consider for example a game which is desirable to run at 300 FPS, so that a screen capture of the output could be slowed down. (for purposes of this scenario, the simulation can't be re-played)
Except they are invariant with regards to real time since computers cannot precicely gauge the exact passing of time, only the realitive passing of time. If you ran two games consoles such as the SEGA Megadrive in parallel with the same state and same realitive input started at the same time you will find that after some extended time period one is a few frames ahead of the other.
In your example what you would do is specify the tick frequency with respect to game time as 300 Hz. Each tick you then push out a rendered frame to be stored. Even if this is made to operate in real time you might find that it is operating within some error of real time (such as 299.9 Hz or 300.1 Hz). This sort of error even affects displays.
In the end, time is a highly relative quantity. Physicists have proof that time progresses at different rates throughout the universe. As such for determinism you need to define your own time progression.
You keep talking about starcraft 2 missile movers, but all I read is "sc2 made an optimization decision by defining their clock period to Z" (where Z can be anything, since such an optimization is necessary in any context). This is the same thing I said a number of days ago. Either you don't understand what I'm talking about; you're discussing tangential, undisputed information; or you're oblivious.
Well stop saying you do not understand it then?
do you see how that's illogical? I provided a link, giving at least one *general case, well accepted* context where dealing damage without credit or reduction is useful.
Except the fact is almost always it is not desirable. You do not want your DoT effects bypassing reductions, mana shield, triggers etc. At one stage abilities that failed to properly credit kills were out right rejected from the spells section. Sure some times it makes for interesting mechanics however so do lots of not very useful stuff at times.
need I remind you that Warcraft 3 uses last-hitting mechanics?
Kill denying was actually an oversight. In most RTS games it makes little difference who lands the final blow and many do not even allow easy friendly fire. However since units give some form of reward when killed (exp, resources etc) in WC3 you can deny your enemies that reward by a friendly unit getting the last hit. This was once considered a bug in DotA Allstars however it eventually made it as a feature (even if it is a rather stupid one).
Right, but that's how the native works. There's no point in talking about why the performance difference is there when the discussion is about whether it's there or not.
The discussion is about timer periods and not the performance of natives. You may want to recap what has been said as I do agree this thread has run on far longer than it needs to.
1) It still won't perform better (JASS has no pipelining)
What does pipelining have to do with this topic or even JASS for that matter?
You're arguing that we shouldn't increase the clock rate for a DPS system, since *if* the game is multiplayer, there will be some latency associated with state synchronization.
No I am not? I was arguing that it is a waste of time to do so since players only care about what they can see.
That statement was to explain to you that games cannot couple to real time since the interpretation of time will vary from system to system. Instead they advance time in a vaguely synchronized to real time way.
1) It's stupid to say we shouldn't increase the clock rate, if the *baseline* for the clock isn't established.
Except the baseline is already established. Most WC3 installations run at 60 Hz refresh rate. Doing something like damage or movement faster than that frame rate will not appear any more smooth and in-fact can potentially introduce aliasing artefacts which will produce weird movement patterns.
For example take a timer with an update rate of 0.01 (100 Hz). Since the game outputs at 60 Hz what will happen is that most frames the result of 2 ticks will be shown except some frames (1/5?) will instead show the result of only 1 tick passing. If this was a movement system you subject the player to a unit moving at a non-constant velocity since some times it will appear to move less for one frame than it mostly does. If people will notice this in real time is another question however it will show up in screen captures.