You wouldn't be so sure of what? I am not sure which of my statements you are responding to.
Network synchronization is a separate (and much more complicated) problem. This library won't help with that. On Mon, Nov 21, 2016 at 11:40 AM, Gaëtan André <[email protected]> wrote: > I wouldn't be so sure. For example, in networking games where one might > need to keep clocks synced. > > Le dimanche 20 novembre 2016 21:08:37 UTC+1, Nick H adn écrit : >> >> The purpose of the Clock is to relate the passage of time in the "real" >> world to the passage of time in the simulated world. So the Clock is >> fundamentally something that exists outside of the simulation... there is >> no need for the simulation to know about it. >> >> Having said that, I feel more confident that the Clock doesn't need to >> keep track of the total elapsed time. A lot of the time, that number won't >> be needed. And if it is, the simulation can easily keep track of that >> number itself, given the period. >> >> >> >> On Sun, Nov 20, 2016 at 1:40 AM, Gaëtan André <[email protected]> >> wrote: >> >>> Passing Clock.period would be indeed more useful in the example's use >>> case. >>> >>> Could we imagine update functions where the total elapsed time is needed? >>> >>> Wouldn't it be more flexible to pass the Clock object? >>> >>> Le samedi 19 novembre 2016 18:59:02 UTC+1, Nick H a écrit : >>>> >>>> Great questions. >>>> >>>> I am wondering why you don't pass Clock.period to the update method and >>>>> use the global delta instead >>>> >>>> >>>> Reasons why period doesn't get passed directly to the update function: >>>> >>>> 1. The function would need 5 arguments, and that is too many. >>>> >>>> 2. The period is unlikely to change. The Clock needs a period, so we >>>> may as well set the period on the clock once, and then not worry about it. >>>> >>>> (The same could be said of the physicsUpdate function... we're unlikely >>>> to ever pass a different function to Clock.update. So why isn't that >>>> attached to the Clock record too? Because then Clock's type definition >>>> would need a parameter. Parametrized types are fine. But in this case, I >>>> thought it was better to add complexity to the function rather than the >>>> type.) >>>> >>>> is this counter really useful for a physical update? Wouldn't we need >>>>> more the real time (Clock.time*Clock.period)? >>>>> >>>> >>>> You're absolutely right. >>>> >>>> Actually, I think more useful than either Clock.time or >>>> (Clock.time*Clock.period) might be to just pass Clock.period. That way, we >>>> wouldn't need that global delta value any more. What do you think about >>>> that? >>>> >>>> Thanks for taking a look! >>>> ~Nick >>>> >>>> On Sat, Nov 19, 2016 at 6:01 AM, Gaëtan André <[email protected]> >>>> wrote: >>>> >>>>> Hi Nick, >>>>> >>>>> great effort. >>>>> >>>>> I have been looking for your code and example and I am wondering why >>>>> you don't pass Clock.period to the update method and use the global delta >>>>> instead. You also pass Clock.time a step counter, but this is not used in >>>>> the example, is this counter really useful for a physical update? Wouldn't >>>>> we need more the real time (Clock.time*Clock.period)? >>>>> >>>>> Le mercredi 16 novembre 2016 22:42:37 UTC+1, Nick H a écrit : >>>>>> >>>>>> Sorry about that. Thanks for taking proper credit! >>>>>> >>>>>> On Wed, Nov 16, 2016 at 9:23 AM, Rex van der Spuy <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> Wow, that's absolutely brilliant!!! >>>>>>> (My username was `d13` by the way - so that was me!) >>>>>>> Congratulations!!! >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Elm Discuss" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Elm Discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
