Mark Ivey <[EMAIL PROTECTED]> writes: > The proportion argument to advance_time() goes down within a round > sometimes. Is that a bug or am I doing something wrong? (This is with > 9.1 so maybe this is fixed in newer versions. I can't get 10.1 to run,
> begin round > 0.671195983887 > 0.328804016113 > end round > begin round > 0.338235527277 > 0.661764442921 > end round > begin round > 0.0112355547026 > 0.691962242126 > 0.296802192926 > end round The following is from basic-2.py: The advance_time method is called repeatedly by the Idler, for all object in the scene. In Soya, the time unit is the "round" ; one round is 30 milliseconds (default value). The proportion argument of advance_time is the proportion of a round that has occured: e.g. 0.3 means that 30% of a round has occured since last call, i.e. 9 milliseconds. Notice the phrase "since last call"; I suspect the proportion argument has the following properties: 1) When called for the first time in a round, proportion is the time-proportion of the round thus far (or the proportion of time since begin_round was called?) 2) When called for the second or later times, proportion is the proportion of time passed since the last call to advance_time The usage of proportion in the tutorials seems to agree with this interpretation. The values you print all sum more-or-less to 1 for each round, which is also in agreement. The documentation for advance_time is somewhat ambiguous: Called (by the Idler) when a piece of a round is achieved; default implementation does nothing. PROPORTION is the proportion of the current round's time that has passed (1.0 for an entire round). If I am correct, perhaps that should be updated to read implementation does nothing. PROPORTION is the proportion of the current round's time that has passed since the last call to advance_time, or since the last call to begin_round if this is the first call to advance_time. I think the comment "(1.0 for an entire round)" is a little confusing in this context. I am curious to know if there are any guarantees for the calling of advance_time --- for instance, will it always be called at least once in a round? Regards, Rory
