I can't seem to understand what the title means. Could you please elaborate? I thought it was something to do with the Timer Block but can't see anything that resembles this.
Kind Regards
Laura, QA Department
Hello, Charlie!
I can't seem to understand what the title means. Could you please elaborate? I thought it was something to do with the Timer Block but can't see anything that resembles this.
What Charlie said in uncompromisingly efficient English and with no further elaboration usually appropriate for something even remotely supposed to be a bug report is that a timer set to a delay with a non-zero decimal fraction component loses that component when it is copied and pasted, or otherwise reproduced.
More specifically, if you check the blueprint taken from such a timer and inspect that blueprint file in an editor, you'll find that the delay time is rounded down to the nearest thousand milliseconds.
STR:
Load into any world.
Spawn a timer.
Set the timer's delay to any time with a decimal fraction, such as 2.5 seconds.
Reopen the delay time field with Ctrl+Click on the slider and observe it still shows 2.5 seconds
Copy and paste the timer.
Check the pasted timer's delay.
Note it's set to 2.0 seconds, not the 2.5 seconds it should be.
But this is moot, anyways, as timers already appear to ignore decimal fractions, something that can be observed by having two timers start at the same time, both retriggering themselves, one after 2.999 seconds (as specified) and one after 3.000 seconds. One would expect them to stay largely in sync for quite a while, but observation shows that even after the very first cycle they are out of sync by about a whole second already. As if the .999 was completely ignored … which it apparently is.
So, perhaps the bug should rather be about decimal fractions remaining on display even when they are not observed in the first place.
Ah, I get it.
What Charlie said in uncompromisingly efficient English and with no further elaboration usually appropriate for something even remotely supposed to be a bug report is that a timer set to a delay with a non-zero decimal fraction component loses that component when it is copied and pasted, or otherwise reproduced.
More specifically, if you check the blueprint taken from such a timer and inspect that blueprint file in an editor, you'll find that the delay time is rounded down to the nearest thousand milliseconds.
STR:
Load into any world.
Spawn a timer.
Set the timer's delay to any time with a decimal fraction, such as 2.5 seconds.
Reopen the delay time field with Ctrl+Click on the slider and observe it still shows 2.5 seconds
Copy and paste the timer.
Check the pasted timer's delay.
Note it's set to 2.0 seconds, not the 2.5 seconds it should be.
But this is moot, anyways, as timers already appear to ignore decimal fractions, something that can be observed by having two timers start at the same time, both retriggering themselves, one after 2.999 seconds (as specified) and one after 3.000 seconds. One would expect them to stay largely in sync for quite a while, but observation shows that even after the very first cycle they are out of sync by about a whole second already. As if the .999 was completely ignored … which it apparently is.
So, perhaps the bug should rather be about decimal fractions remaining on display even when they are not observed in the first place.
Thank you so much for the explanation. As you mentioned in your final sentence, I'm not sure what the issue is, but they conflict certainly. I have reproduced this and reported it internally. :)
Kind Regards
Laura QA Department
Hello, andersenman!
Thank you so much for the explanation. As you mentioned in your final sentence, I'm not sure what the issue is, but they conflict certainly. I have reproduced this and reported it internally. :)
I have the same bug
wat
wat
Hello, Charlie!
I can't seem to understand what the title means. Could you please elaborate? I thought it was something to do with the Timer Block but can't see anything that resembles this.
Kind Regards
Laura, QA Department
Hello, Charlie!
I can't seem to understand what the title means. Could you please elaborate? I thought it was something to do with the Timer Block but can't see anything that resembles this.
Kind Regards
Laura, QA Department
Ah, I get it.
What Charlie said in uncompromisingly efficient English and with no further elaboration usually appropriate for something even remotely supposed to be a bug report is that a timer set to a delay with a non-zero decimal fraction component loses that component when it is copied and pasted, or otherwise reproduced.
More specifically, if you check the blueprint taken from such a timer and inspect that blueprint file in an editor, you'll find that the delay time is rounded down to the nearest thousand milliseconds.
STR:
But this is moot, anyways, as timers already appear to ignore decimal fractions, something that can be observed by having two timers start at the same time, both retriggering themselves, one after 2.999 seconds (as specified) and one after 3.000 seconds. One would expect them to stay largely in sync for quite a while, but observation shows that even after the very first cycle they are out of sync by about a whole second already. As if the .999 was completely ignored … which it apparently is.
So, perhaps the bug should rather be about decimal fractions remaining on display even when they are not observed in the first place.
Ah, I get it.
What Charlie said in uncompromisingly efficient English and with no further elaboration usually appropriate for something even remotely supposed to be a bug report is that a timer set to a delay with a non-zero decimal fraction component loses that component when it is copied and pasted, or otherwise reproduced.
More specifically, if you check the blueprint taken from such a timer and inspect that blueprint file in an editor, you'll find that the delay time is rounded down to the nearest thousand milliseconds.
STR:
But this is moot, anyways, as timers already appear to ignore decimal fractions, something that can be observed by having two timers start at the same time, both retriggering themselves, one after 2.999 seconds (as specified) and one after 3.000 seconds. One would expect them to stay largely in sync for quite a while, but observation shows that even after the very first cycle they are out of sync by about a whole second already. As if the .999 was completely ignored … which it apparently is.
So, perhaps the bug should rather be about decimal fractions remaining on display even when they are not observed in the first place.
Hello, andersenman!
Thank you so much for the explanation. As you mentioned in your final sentence, I'm not sure what the issue is, but they conflict certainly. I have reproduced this and reported it internally. :)
Kind Regards
Laura QA Department
Hello, andersenman!
Thank you so much for the explanation. As you mentioned in your final sentence, I'm not sure what the issue is, but they conflict certainly. I have reproduced this and reported it internally. :)
Kind Regards
Laura QA Department
Appears to be, by extension, a duplicate of the ancient https://support.keenswh.com/spaceengineers/pc/topic/timers-dont-work-at-fractions-of-a-second, or at least a side effect or a consequence of it.
Appears to be, by extension, a duplicate of the ancient https://support.keenswh.com/spaceengineers/pc/topic/timers-dont-work-at-fractions-of-a-second, or at least a side effect or a consequence of it.
Replies have been locked on this page!