I’m curious to hear your opinion about the use of the ‘time’ parameter in addObject() or the Add Object Actuator. I recently learned that this parameter (since the beginning) assumes that the logic tic rate is 50 per second. So if your game runs at 50fps than there’s no problem, but if it runs at 60fps, two major problems will occur:
You’ll never be able to use the ‘time’ parameter to end the object after one logic tic, because with 1 as the lowest value (0=infinite), the object’s life will be dimished by 0.8333 (=50/60), leaving a float value of 0.1666.
You’ll never be able to be exact. For example, if you need the object to end after 3 seconds (respectively 180 tics), you cannot. A value of 150 results in 181 and a value of 149 results in 179.
I reported this bug to the tracker: T40402 addObject() ‘time’ parameter inconsistent. And the remark was made that a fix would actually brake existing games, where game developers purposely used other values to work around this limitation. For example, by setting time to 50 so the object is removed after one second, even when the logic tic rate is 60. If such a developer would like to run/export his (old) game with a Blender version without this limitation, indeed he would be forced to change time to 60. But if you ask me, I think he would gladly do so, because he’ll never have to deal with this limitation ever again, when working on future projects.
So here’s my question. What do you think? Do you think this should be fixed with the downside older games would have to be adjusted in order to run correctly in the upcoming Blender versions? Or should we leave it as it is, accepting that the ‘time’ parameter is not fully compatible with games running at a frame rate other then 50fps?
Thanks for your participation on the matter!
Edit: Besides, even if you’re game runs at 50fps, value 50 will result in 51. So in any case this should be fixed by rounding the life value, to the 4th decimal.
I’d rather change it to 60fps. I haven’t looked at the code, but to maintain backwards compatibility, I’d detect the version used and adjust the conversion factor (0.02):
CValue *fval = new CFloatValue(lifespan*0.02);
However, I’m not sure what the proper protocol is.
With all the maintaining backwards compatibility and deprecation warnings, I hope one day we can do a major refactor of the game engine to start a clean slate, similar to what happened with Blender 2.49. Hmm, maybe with Blender 3.0?
How about changing it to the logic tic rate at hand? This value could be determined at initialization. This way it doesn’t matter if you run at 50fps or at 60fps or at 100fps for that matter, because the ‘time’ value will always represent the actual time.
CValue *fval = new CFloatValue(lifespan/logicTicRate);
I always set it to 0 and then manually remove the object later using a counter if I want it to last an exact time. otherwise I just make it a little longer than the required number of tics. I knew it was wrong, but not by how much.
My old games won’t run on newer versions of BGE anyway, because single texture has been removed. Also there have been changes to matrices and other changes which would break most old games, this is just one more thing you’d have to factor in when updating an old game.
Who came up with the idea of 50 tics a second anyway? BGE has always been 60tics per second for as long as I’ve used it, perhaps 5 or 6 years. It must have been set a long time ago and never changed.
It should be according to system time, really, as should everything else in the engine. Logic should NOT be dependent on frame-rate. Someone with a 120Hz monitor shouldn’t be forced to play at 60fps, and someone with a PC that can only run 30fps shouldn’t be playing at half speed.
In Java you can use NanoTime to be really, really accurate. Not sure if Python has that. I’m sure you can probably use time.time()
Developers shouldn’t need to consider any concept of “ticks” really. Be aware that they exist perhaps, but it should not influence how they develop their games. For this reason there are a number of areas within the BGE that need addressing, this being one of them.
What should be done is to change the function to accept seconds. This should be modified wherever the life property is used by the BGE internals, rather than just converting it to ticks in the function.