SnpM / LockstepFramework

Framework for lockstep RTS, TD, and MOBA games.
MIT License
1.41k stars 351 forks source link

Why is the default saver used vs objects self initializing? #79

Closed erebuswolf closed 8 years ago

erebuswolf commented 8 years ago

I have been pulling the code apart for this project. I'd like to make a reasonable fighting game with it (using a different network structure than what is currently setup for rts). I am trying to make a simple scene as a prototype that is just a 2d world with a bouncing ball on a flat surface. There seems to be some system of registering objects in the scene with a saver object. I want to know why this is the preferred method. I don't understand why I can't edit objects in the scene and have the objects self register on wakeup and to set up their initial positions based on their transforms. Why is the default approach using a saver object and clicking save for the scene in the editor to load all the lsbodies into the saver, then on game start only acknowledging objects that were loaded from the saver and not any that are in the level at game start. The only reasons I can think of are for network synchronization or because the other manager objects aren't guaranteed to be initialized before the lsbody objects but those seem like solvable problems without using the saver mechanism.

SnpM commented 8 years ago

Network sync is the reason. A saver is used because the order of object initiation isn't deterministic. I.e. if every object registered itself via Start (), they wouldn't register in the same order so things like the physics loop would run through the objects in a different order on 2 clients.

On Tue, Jul 5, 2016 at 2:04 PM, Jesse Fish notifications@github.com wrote:

I have been pulling the code apart for this project. I'd like to make a reasonable fighting game with it (using a different network structure than what is currently setup for rts). I am trying to make a simple scene as a prototype that is just a 2d world with a bouncing ball on a flat surface. There seems to be some system of registering objects in the scene with a saver object. I want to know why this is the preferred method. I don't understand why I can't edit objects in the scene and have the objects self register on wakeup and to set up their initial positions based on their transforms. Why is the default approach using a saver object and clicking save for the scene in the editor to load all the lsbodies into the saver, then on game start only acknowledging objects that were loaded from the saver and not any that are in the level at game start. The only reasons I can think of are for network synchronization or because the other manager objects aren't guaranteed to be initialized before the lsbody objects but those seem like solvable problems without using the saver mechanism.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79, or mute the thread https://github.com/notifications/unsubscribe/AHXqp2bqSv5gydbKYmg_03GfdKrdb_Dbks5qSriwgaJpZM4JFeff .

erebuswolf commented 8 years ago

Hmm interesting. I wonder if there is a solution to that which can be automated so it is opaque to the user and they can just set up their level/scene and not worry about saving/loading. I'll look into it.

On Tue, Jul 5, 2016 at 3:16 PM, John Pan notifications@github.com wrote:

Network sync is the reason. A saver is used because the order of object initiation isn't deterministic. I.e. if every object registered itself via Start (), they wouldn't register in the same order so things like the physics loop would run through the objects in a different order on 2 clients.

On Tue, Jul 5, 2016 at 2:04 PM, Jesse Fish notifications@github.com wrote:

I have been pulling the code apart for this project. I'd like to make a reasonable fighting game with it (using a different network structure than what is currently setup for rts). I am trying to make a simple scene as a prototype that is just a 2d world with a bouncing ball on a flat surface. There seems to be some system of registering objects in the scene with a saver object. I want to know why this is the preferred method. I don't understand why I can't edit objects in the scene and have the objects self register on wakeup and to set up their initial positions based on their transforms. Why is the default approach using a saver object and clicking save for the scene in the editor to load all the lsbodies into the saver, then on game start only acknowledging objects that were loaded from the saver and not any that are in the level at game start. The only reasons I can think of are for network synchronization or because the other manager objects aren't guaranteed to be initialized before the lsbody objects but those seem like solvable problems without using the saver mechanism.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79, or mute the thread < https://github.com/notifications/unsubscribe/AHXqp2bqSv5gydbKYmg_03GfdKrdb_Dbks5qSriwgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230619199, or mute the thread https://github.com/notifications/unsubscribe/AATf7D9n1S1Tvwq8mifT7aCSZRDilFG4ks5qStfSgaJpZM4JFeff .

Jesse

erebuswolf commented 8 years ago

Follow up question. What parts of the physics engine are not deterministic between frames when varying the update order of the objects? It seems like a deterministic physics engine should give you the same outcome for objects A,B,C when updating in either order A,C,B or C,B,A.

SnpM commented 8 years ago

An example:

A and B are located on the same point. C and D are located on a different same point. To resolve the collision naturally, a random number is used. The random number generator is deterministic given a seed so that the first number it gives is 85 and the 2nd number is 36.

If A and B are resolved first, they will use 85 to determine who goes in which direction and C and D will use 36. If C and D are resolved first, they will use 85 and A and B will use 36. The order of resolving collisions has to be guaranteed or the outcomes of collisions will be different. Not only that, if C and D were resolved first and the outcome resulted in C colliding with B, the collision between C and B would have to be guaranteed to occur before or after A and B. If A and B happened before C and D, C will probably touch B in a different area or may never even touch B.

On Wed, Jul 6, 2016 at 2:18 AM, Jesse Fish notifications@github.com wrote:

Follow up question. What parts of the physics engine are not deterministic between frames when varying the update order of the objects? It seems like a deterministic physics engine should give you the same outcome for objects A,B,C when updating in either order A,C,B or C,B,A.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230708041, or mute the thread https://github.com/notifications/unsubscribe/AHXqp6C8gkLdg0lmrT39uz-79xVOr-zWks5qS2TcgaJpZM4JFeff .

erebuswolf commented 8 years ago

Hm I see. Whats wrong with just giving every object in your scene a monotonically increasing ID and resolving it that way (Assigning in editor either programmatically or manually)? Later spawned objects can have ids assigned as well or just be added deterministically. But assigning unique IDs and then sorting objects in a list once on level load seems preferable to the save/scan model now. It just seems like a really confusing thing to have to do currently.

On Wed, Jul 6, 2016 at 7:47 AM, John Pan notifications@github.com wrote:

An example:

A and B are located on the same point. C and D are located on a different same point. To resolve the collision naturally, a random number is used. The random number generator is deterministic given a seed so that the first number it gives is 85 and the 2nd number is 36.

If A and B are resolved first, they will use 85 to determine who goes in which direction and C and D will use 36. If C and D are resolved first, they will use 85 and A and B will use 36. The order of resolving collisions has to be guaranteed or the outcomes of collisions will be different. Not only that, if C and D were resolved first and the outcome resulted in C colliding with B, the collision between C and B would have to be guaranteed to occur before or after A and B. If A and B happened before C and D, C will probably touch B in a different area or may never even touch B.

On Wed, Jul 6, 2016 at 2:18 AM, Jesse Fish notifications@github.com wrote:

Follow up question. What parts of the physics engine are not deterministic between frames when varying the update order of the objects? It seems like a deterministic physics engine should give you the same outcome for objects A,B,C when updating in either order A,C,B or C,B,A.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230708041 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp6C8gkLdg0lmrT39uz-79xVOr-zWks5qS2TcgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230795237, or mute the thread https://github.com/notifications/unsubscribe/AATf7MyklA3DSQoj1HYdRQFPsfIhboxAks5qS8AegaJpZM4JFeff .

Jesse

SnpM commented 8 years ago

That's a great idea! I'll get it in.

On Wed, Jul 6, 2016 at 8:53 AM, Jesse Fish notifications@github.com wrote:

Hm I see. Whats wrong with just giving every object in your scene a monotonically increasing ID and resolving it that way (Assigning in editor either programmatically or manually)? Later spawned objects can have ids assigned as well or just be added deterministically. But assigning unique IDs and then sorting objects in a list once on level load seems preferable to the save/scan model now. It just seems like a really confusing thing to have to do currently.

On Wed, Jul 6, 2016 at 7:47 AM, John Pan notifications@github.com wrote:

An example:

A and B are located on the same point. C and D are located on a different same point. To resolve the collision naturally, a random number is used. The random number generator is deterministic given a seed so that the first number it gives is 85 and the 2nd number is 36.

If A and B are resolved first, they will use 85 to determine who goes in which direction and C and D will use 36. If C and D are resolved first, they will use 85 and A and B will use 36. The order of resolving collisions has to be guaranteed or the outcomes of collisions will be different. Not only that, if C and D were resolved first and the outcome resulted in C colliding with B, the collision between C and B would have to be guaranteed to occur before or after A and B. If A and B happened before C and D, C will probably touch B in a different area or may never even touch B.

On Wed, Jul 6, 2016 at 2:18 AM, Jesse Fish notifications@github.com wrote:

Follow up question. What parts of the physics engine are not deterministic between frames when varying the update order of the objects? It seems like a deterministic physics engine should give you the same outcome for objects A,B,C when updating in either order A,C,B or C,B,A.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230708041

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp6C8gkLdg0lmrT39uz-79xVOr-zWks5qS2TcgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230795237 , or mute the thread < https://github.com/notifications/unsubscribe/AATf7MyklA3DSQoj1HYdRQFPsfIhboxAks5qS8AegaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230797267, or mute the thread https://github.com/notifications/unsubscribe/AHXqp4gHQ9iSf_tswU7-XkkU-4CxxEGeks5qS8F2gaJpZM4JFeff .

erebuswolf commented 8 years ago

Ok, I was happy to work on it as well. If you are going to I'll concentrate on my network stuff. Would also be nice if there was a way to just attach a physics body to a game object, and a series of colliders at various offsets. The main things I need out of this engine are being able to roll forward and back time via my own snapshotting system and detect collisions across multiple updates in a single unity update. This would basically be me calling load on a snapshot for the world as it was for example 3 frames ago, changing something about the world state in that frame, and then calling simulate 3 times in a single frame update to bring the simulation back to present with the new information backfilled in. Unity's current colliders can't support this, but your engine can though modifications need to be made.

On Wed, Jul 6, 2016 at 8:19 AM, John Pan notifications@github.com wrote:

That's a great idea! I'll get it in.

On Wed, Jul 6, 2016 at 8:53 AM, Jesse Fish notifications@github.com wrote:

Hm I see. Whats wrong with just giving every object in your scene a monotonically increasing ID and resolving it that way (Assigning in editor either programmatically or manually)? Later spawned objects can have ids assigned as well or just be added deterministically. But assigning unique IDs and then sorting objects in a list once on level load seems preferable to the save/scan model now. It just seems like a really confusing thing to have to do currently.

On Wed, Jul 6, 2016 at 7:47 AM, John Pan notifications@github.com wrote:

An example:

A and B are located on the same point. C and D are located on a different same point. To resolve the collision naturally, a random number is used. The random number generator is deterministic given a seed so that the first number it gives is 85 and the 2nd number is 36.

If A and B are resolved first, they will use 85 to determine who goes in which direction and C and D will use 36. If C and D are resolved first, they will use 85 and A and B will use 36. The order of resolving collisions has to be guaranteed or the outcomes of collisions will be different. Not only that, if C and D were resolved first and the outcome resulted in C colliding with B, the collision between C and B would have to be guaranteed to occur before or after A and B. If A and B happened before C and D, C will probably touch B in a different area or may never even touch B.

On Wed, Jul 6, 2016 at 2:18 AM, Jesse Fish notifications@github.com wrote:

Follow up question. What parts of the physics engine are not deterministic between frames when varying the update order of the objects? It seems like a deterministic physics engine should give you the same outcome for objects A,B,C when updating in either order A,C,B or C,B,A.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230708041

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp6C8gkLdg0lmrT39uz-79xVOr-zWks5qS2TcgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230795237

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7MyklA3DSQoj1HYdRQFPsfIhboxAks5qS8AegaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230797267 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp4gHQ9iSf_tswU7-XkkU-4CxxEGeks5qS8F2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230805289, or mute the thread https://github.com/notifications/unsubscribe/AATf7M8elCfC_c7RLVEKrln8l8hEFCrXks5qS8eIgaJpZM4JFeff .

Jesse

SnpM commented 8 years ago

I played with the idea a bit but at the end of the day, the user still has to press a Save button. It'd essentially be the same thing with the order data stored non-centrally.

The engine wasn't made for snapshotting in mind and there's a high possibility that that would break determinism. If you run into problems, I might be able to help but there's no guarantee that snapshotting will work in the end.

On Wed, Jul 6, 2016 at 9:19 AM, John Pan jpthek9@gmail.com wrote:

That's a great idea! I'll get it in.

On Wed, Jul 6, 2016 at 8:53 AM, Jesse Fish notifications@github.com wrote:

Hm I see. Whats wrong with just giving every object in your scene a monotonically increasing ID and resolving it that way (Assigning in editor either programmatically or manually)? Later spawned objects can have ids assigned as well or just be added deterministically. But assigning unique IDs and then sorting objects in a list once on level load seems preferable to the save/scan model now. It just seems like a really confusing thing to have to do currently.

On Wed, Jul 6, 2016 at 7:47 AM, John Pan notifications@github.com wrote:

An example:

A and B are located on the same point. C and D are located on a different same point. To resolve the collision naturally, a random number is used. The random number generator is deterministic given a seed so that the first number it gives is 85 and the 2nd number is 36.

If A and B are resolved first, they will use 85 to determine who goes in which direction and C and D will use 36. If C and D are resolved first, they will use 85 and A and B will use 36. The order of resolving collisions has to be guaranteed or the outcomes of collisions will be different. Not only that, if C and D were resolved first and the outcome resulted in C colliding with B, the collision between C and B would have to be guaranteed to occur before or after A and B. If A and B happened before C and D, C will probably touch B in a different area or may never even touch B.

On Wed, Jul 6, 2016 at 2:18 AM, Jesse Fish notifications@github.com wrote:

Follow up question. What parts of the physics engine are not deterministic between frames when varying the update order of the objects? It seems like a deterministic physics engine should give you the same outcome for objects A,B,C when updating in either order A,C,B or C,B,A.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230708041

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp6C8gkLdg0lmrT39uz-79xVOr-zWks5qS2TcgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230795237 , or mute the thread < https://github.com/notifications/unsubscribe/AATf7MyklA3DSQoj1HYdRQFPsfIhboxAks5qS8AegaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230797267, or mute the thread https://github.com/notifications/unsubscribe/AHXqp4gHQ9iSf_tswU7-XkkU-4CxxEGeks5qS8F2gaJpZM4JFeff .

erebuswolf commented 8 years ago

If every object maintains a history over the past n frames of the state, as long as everything stays registered rolling backwards shouldn't cause issues. I'll try my hand at it. I did something similar when assigning player IDs in a different project. I think is a way to automatically assign the values in the level without hitting a save button. To me it was very unintuitive to add objects to the scene and rotate them and have them show up that way but not have the physics react that way. If I can't get it working your way is still fine.

On Wed, Jul 6, 2016 at 9:12 AM, John Pan notifications@github.com wrote:

I played with the idea a bit but at the end of the day, the user still has to press a Save button. It'd essentially be the same thing with the order data stored non-centrally.

The engine wasn't made for snapshotting in mind and there's a high possibility that that would break determinism. If you run into problems, I might be able to help but there's no guarantee that snapshotting will work in the end.

On Wed, Jul 6, 2016 at 9:19 AM, John Pan jpthek9@gmail.com wrote:

That's a great idea! I'll get it in.

On Wed, Jul 6, 2016 at 8:53 AM, Jesse Fish notifications@github.com wrote:

Hm I see. Whats wrong with just giving every object in your scene a monotonically increasing ID and resolving it that way (Assigning in editor either programmatically or manually)? Later spawned objects can have ids assigned as well or just be added deterministically. But assigning unique IDs and then sorting objects in a list once on level load seems preferable to the save/scan model now. It just seems like a really confusing thing to have to do currently.

On Wed, Jul 6, 2016 at 7:47 AM, John Pan notifications@github.com wrote:

An example:

A and B are located on the same point. C and D are located on a different same point. To resolve the collision naturally, a random number is used. The random number generator is deterministic given a seed so that the first number it gives is 85 and the 2nd number is 36.

If A and B are resolved first, they will use 85 to determine who goes in which direction and C and D will use 36. If C and D are resolved first, they will use 85 and A and B will use 36. The order of resolving collisions has to be guaranteed or the outcomes of collisions will be different. Not only that, if C and D were resolved first and the outcome resulted in C colliding with B, the collision between C and B would have to be guaranteed to occur before or after A and B. If A and B happened before C and D, C will probably touch B in a different area or may never even touch B.

On Wed, Jul 6, 2016 at 2:18 AM, Jesse Fish notifications@github.com wrote:

Follow up question. What parts of the physics engine are not deterministic between frames when varying the update order of the objects? It seems like a deterministic physics engine should give you the same outcome for objects A,B,C when updating in either order A,C,B or C,B,A.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230708041

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp6C8gkLdg0lmrT39uz-79xVOr-zWks5qS2TcgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230795237

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7MyklA3DSQoj1HYdRQFPsfIhboxAks5qS8AegaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230797267 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp4gHQ9iSf_tswU7-XkkU-4CxxEGeks5qS8F2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-230822401, or mute the thread https://github.com/notifications/unsubscribe/AATf7GJEKrwMx1VDMF02ayApN0FSzZFrks5qS9PdgaJpZM4JFeff .

Jesse

erebuswolf commented 8 years ago

I prototyped a working solution.

https://github.com/erebuswolf/DNET

Checkout that repo and just put it in a folder in an existing Unity Project. You can add TestIds to any object and they will automatically get assigned on creation and are not editable fields in the editor (though they are in the code this could easily be changed). I just use a custom editor for the object and have it auto assign ids. Because this changes the actual serialized values of the objects once the ID is set it is stable. It's similar to manually assigning an id to every object in your level but it just does it for you. The only edge case where this fails is that the assignments for all IDs only happen when a single ID is selected in the editor for inspection. If you select multiple IDs and copy paste them to create duplicates (With initially duplicated ID values) the values don't correct themselves until you inspect a single ID. This could easily be fixed by adding a call to the manager start that calls the static init function from the editor when running the application in an editor. This will ensure it is never run in an actual build. The chances of a person misusing this I think are less than the chances of them forgetting to his the save button on the save module before building an exe.

Anyway give it a look, tell me what you think. The idea would be adding an ID to lsbody and editing the custom editor for ls body to do the same thing that is being done in my example.

SnpM commented 8 years ago

Awesome. I'll check it out.

On Thu, Jul 7, 2016 at 2:11 AM, Jesse Fish notifications@github.com wrote:

I prototyped a working solution.

https://github.com/erebuswolf/DNET

Checkout that repo and just put it in a folder in an existing Unity Project. You can add TestIds to any object and they will automatically get assigned on creation and are not editable fields in the editor (though they are in the code this could easily be changed). I just use a custom editor for the object and have it auto assign ids. Because this changes the actual serialized values of the objects once the ID is set it is stable. It's similar to manually assigning an id to every object in your level but it just does it for you. The only edge case where this fails is that the assignments for all IDs only happen when a single ID is selected in the editor for inspection. If you select multiple IDs and copy paste them to create duplicates (With initially duplicated ID values) the values don't correct themselves until you inspect a single ID. This could easily be fixed by adding a call to the manager start that calls the static init function from the editor when running the application in an editor. This will ensure it is never run in an actual build. The chances of a person misusing this I think are less than the chances of them forgetting to his the save button on the save module before building an exe.

Anyway give it a look, tell me what you think. The idea would be adding an ID to lsbody and editing the custom editor for ls body to do the same thing that is being done in my example.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-231011781, or mute the thread https://github.com/notifications/unsubscribe/AHXqp4j3F5npY3I1QQHK4Z_y2JIRxD88ks5qTLSzgaJpZM4JFeff .

erebuswolf commented 8 years ago

What's the status of this? Should I move forward and try to implement this system and remove the saver?

SnpM commented 8 years ago

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish notifications@github.com wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567, or mute the thread https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff .

erebuswolf commented 8 years ago

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan notifications@github.com wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish notifications@github.com wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106, or mute the thread https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff .

Jesse

SnpM commented 8 years ago

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish notifications@github.com wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan notifications@github.com wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish notifications@github.com wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106 , or mute the thread < https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039, or mute the thread https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff .

erebuswolf commented 8 years ago

Yes I do understand that. But you could use it as the starting position and convert it to a non float value like you already do when you save the scene using saver. I am not suggesting using it for all values during simulation but to have LSbodies in the scene have the option to read there scene position as their start position automatically.

On Wed, Jul 13, 2016 at 12:03 PM, John Pan notifications@github.com wrote:

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish notifications@github.com wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan notifications@github.com wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish <notifications@github.com

wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232437718, or mute the thread https://github.com/notifications/unsubscribe/AATf7Nr0FLPd1MrTOa6xZS6rStu5m2WFks5qVShlgaJpZM4JFeff .

Jesse

SnpM commented 8 years ago

Would the system still have the user press the Save button or look for an OnSaveScene event?

On Wed, Jul 13, 2016 at 12:05 PM, Jesse Fish notifications@github.com wrote:

Yes I do understand that. But you could use it as the starting position and convert it to a non float value like you already do when you save the scene using saver. I am not suggesting using it for all values during simulation but to have LSbodies in the scene have the option to read there scene position as their start position automatically.

On Wed, Jul 13, 2016 at 12:03 PM, John Pan notifications@github.com wrote:

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish notifications@github.com wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan notifications@github.com wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish < notifications@github.com

wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232437718 , or mute the thread < https://github.com/notifications/unsubscribe/AATf7Nr0FLPd1MrTOa6xZS6rStu5m2WFks5qVShlgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232438425, or mute the thread https://github.com/notifications/unsubscribe/AHXqp0t9dYAUvR-zSO1FDJPxk9mwTof4ks5qVSj7gaJpZM4JFeff .

erebuswolf commented 8 years ago

Neither. The system would automatically assign IDs to all LSbodies in the scene such that there is a deterministic order to them that is physically saved in the level so 2 different executions of the game have the same ordering. And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position and then they would register themselves with the correct game managers component, I am not as familiar with the code I think physics manager, or whatever registration the current Saver is doing. This means every time I add new objects to the scene or edit the scene in any way. I just hit play and everything automatically works without needing to add a saver or press a save button.

On Wed, Jul 13, 2016 at 12:38 PM, John Pan notifications@github.com wrote:

Would the system still have the user press the Save button or look for an OnSaveScene event?

On Wed, Jul 13, 2016 at 12:05 PM, Jesse Fish notifications@github.com

wrote:

Yes I do understand that. But you could use it as the starting position and convert it to a non float value like you already do when you save the scene using saver. I am not suggesting using it for all values during simulation but to have LSbodies in the scene have the option to read there scene position as their start position automatically.

On Wed, Jul 13, 2016 at 12:03 PM, John Pan notifications@github.com wrote:

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish <notifications@github.com

wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan notifications@github.com wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish < notifications@github.com

wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232437718

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7Nr0FLPd1MrTOa6xZS6rStu5m2WFks5qVShlgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232438425 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp0t9dYAUvR-zSO1FDJPxk9mwTof4ks5qVSj7gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232447801, or mute the thread https://github.com/notifications/unsubscribe/AATf7I77RBj3XaumqoKEFA9xEecI4pTqks5qVTCxgaJpZM4JFeff .

Jesse

erebuswolf commented 8 years ago

The part I may be failing to mention is that the objects are registered out of order randomly but after all objects are registered the manager sorts the objects by ID to order them deterministically.

On Wed, Jul 13, 2016 at 12:42 PM, Jesse F jesfish@gmail.com wrote:

Neither. The system would automatically assign IDs to all LSbodies in the scene such that there is a deterministic order to them that is physically saved in the level so 2 different executions of the game have the same ordering. And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position and then they would register themselves with the correct game managers component, I am not as familiar with the code I think physics manager, or whatever registration the current Saver is doing. This means every time I add new objects to the scene or edit the scene in any way. I just hit play and everything automatically works without needing to add a saver or press a save button.

On Wed, Jul 13, 2016 at 12:38 PM, John Pan notifications@github.com wrote:

Would the system still have the user press the Save button or look for an OnSaveScene event?

On Wed, Jul 13, 2016 at 12:05 PM, Jesse Fish notifications@github.com

wrote:

Yes I do understand that. But you could use it as the starting position and convert it to a non float value like you already do when you save the scene using saver. I am not suggesting using it for all values during simulation but to have LSbodies in the scene have the option to read there scene position as their start position automatically.

On Wed, Jul 13, 2016 at 12:03 PM, John Pan notifications@github.com wrote:

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish < notifications@github.com> wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan <notifications@github.com

wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish < notifications@github.com

wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232437718

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7Nr0FLPd1MrTOa6xZS6rStu5m2WFks5qVShlgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232438425 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp0t9dYAUvR-zSO1FDJPxk9mwTof4ks5qVSj7gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232447801, or mute the thread https://github.com/notifications/unsubscribe/AATf7I77RBj3XaumqoKEFA9xEecI4pTqks5qVTCxgaJpZM4JFeff .

Jesse

Jesse

SnpM commented 8 years ago

"And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position"

This is where things will go awry. Float conversion fixed-point number is non-deterministic as it uses float operations and rounding. On different computers, if you convert an X position like 5.5001 from float to fixed-point, you might get different results.

On Wed, Jul 13, 2016 at 12:44 PM, Jesse Fish notifications@github.com wrote:

The part I may be failing to mention is that the objects are registered out of order randomly but after all objects are registered the manager sorts the objects by ID to order them deterministically.

On Wed, Jul 13, 2016 at 12:42 PM, Jesse F jesfish@gmail.com wrote:

Neither. The system would automatically assign IDs to all LSbodies in the scene such that there is a deterministic order to them that is physically saved in the level so 2 different executions of the game have the same ordering. And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position and then they would register themselves with the correct game managers component, I am not as familiar with the code I think physics manager, or whatever registration the current Saver is doing. This means every time I add new objects to the scene or edit the scene in any way. I just hit play and everything automatically works without needing to add a saver or press a save button.

On Wed, Jul 13, 2016 at 12:38 PM, John Pan notifications@github.com wrote:

Would the system still have the user press the Save button or look for an OnSaveScene event?

On Wed, Jul 13, 2016 at 12:05 PM, Jesse Fish notifications@github.com

wrote:

Yes I do understand that. But you could use it as the starting position and convert it to a non float value like you already do when you save the scene using saver. I am not suggesting using it for all values during simulation but to have LSbodies in the scene have the option to read there scene position as their start position automatically.

On Wed, Jul 13, 2016 at 12:03 PM, John Pan notifications@github.com wrote:

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish < notifications@github.com> wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan < notifications@github.com

wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish < notifications@github.com

wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232437718

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7Nr0FLPd1MrTOa6xZS6rStu5m2WFks5qVShlgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232438425

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp0t9dYAUvR-zSO1FDJPxk9mwTof4ks5qVSj7gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232447801 , or mute the thread < https://github.com/notifications/unsubscribe/AATf7I77RBj3XaumqoKEFA9xEecI4pTqks5qVTCxgaJpZM4JFeff

.

Jesse

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232449321, or mute the thread https://github.com/notifications/unsubscribe/AHXqp1B-yUe1Q5v_Hbv3BSaKWyuoP6V0ks5qVTIAgaJpZM4JFeff .

erebuswolf commented 8 years ago

So you are saying this equation

return (long)((double)singleFloat * One);

Is not something you should ever do at runtime ever because on two computers it may give different answers? I don't agree that it is impossible to write a floating point converter for different x86 or 64 bit processors. But I don't find this very well documented that this code should never be called ever ever ever during game execution if what you are saying is true.

One could easily write a deterministic floating point conversion that simply has a limited precision (only 3-4 decimal places should be fine for all scene location values.

http://stackoverflow.com/questions/11542299/how-to-convert-ieee754-float-to-fixed-point-in-deterministic-way

second answer in that link.

On Wed, Jul 13, 2016 at 3:06 PM, John Pan notifications@github.com wrote:

"And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position"

This is where things will go awry. Float conversion fixed-point number is non-deterministic as it uses float operations and rounding. On different computers, if you convert an X position like 5.5001 from float to fixed-point, you might get different results.

On Wed, Jul 13, 2016 at 12:44 PM, Jesse Fish notifications@github.com

wrote:

The part I may be failing to mention is that the objects are registered out of order randomly but after all objects are registered the manager sorts the objects by ID to order them deterministically.

On Wed, Jul 13, 2016 at 12:42 PM, Jesse F jesfish@gmail.com wrote:

Neither. The system would automatically assign IDs to all LSbodies in the scene such that there is a deterministic order to them that is physically saved in the level so 2 different executions of the game have the same ordering. And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position and then they would register themselves with the correct game managers component, I am not as familiar with the code I think physics manager, or whatever registration the current Saver is doing. This means every time I add new objects to the scene or edit the scene in any way. I just hit play and everything automatically works without needing to add a saver or press a save button.

On Wed, Jul 13, 2016 at 12:38 PM, John Pan notifications@github.com wrote:

Would the system still have the user press the Save button or look for an OnSaveScene event?

On Wed, Jul 13, 2016 at 12:05 PM, Jesse Fish < notifications@github.com>

wrote:

Yes I do understand that. But you could use it as the starting position and convert it to a non float value like you already do when you save the scene using saver. I am not suggesting using it for all values during simulation but to have LSbodies in the scene have the option to read there scene position as their start position automatically.

On Wed, Jul 13, 2016 at 12:03 PM, John Pan < notifications@github.com> wrote:

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish < notifications@github.com> wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan < notifications@github.com

wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish < notifications@github.com

wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232437718

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7Nr0FLPd1MrTOa6xZS6rStu5m2WFks5qVShlgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232438425

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp0t9dYAUvR-zSO1FDJPxk9mwTof4ks5qVSj7gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232447801

,

or mute the thread <

https://github.com/notifications/unsubscribe/AATf7I77RBj3XaumqoKEFA9xEecI4pTqks5qVTCxgaJpZM4JFeff

.

Jesse

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232449321 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp1B-yUe1Q5v_Hbv3BSaKWyuoP6V0ks5qVTIAgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232501074, or mute the thread https://github.com/notifications/unsubscribe/AATf7FdkcLG9JBux398tukiQwGzynbFWks5qVWFYgaJpZM4JFeff .

Jesse

erebuswolf commented 8 years ago

After reading up on floating point precision ( http://www.yosoygames.com.ar/wp/2013/07/on-floating-point-determinism/ and https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/) I have determined that the conversion from a float to a fixed point number with return (long)((double)singleFloat * One); is deterministic across systems. I wrote some unit tests for FixedMath.cs and did some formatting fixes to FixedMath.cs which I will provide in a pull request shortly. I also, played around with the previously linked alternative floating-point -> fixed-point conversion method. But after reading up on floating point determinism there is nothing wrong with the function you already have. The only thing I would say is there is a need for overflow checks in that library that are currently missing.

On Wed, Jul 13, 2016 at 3:52 PM, Jesse F jesfish@gmail.com wrote:

So you are saying this equation

return (long)((double)singleFloat * One);

Is not something you should ever do at runtime ever because on two computers it may give different answers? I don't agree that it is impossible to write a floating point converter for different x86 or 64 bit processors. But I don't find this very well documented that this code should never be called ever ever ever during game execution if what you are saying is true.

One could easily write a deterministic floating point conversion that simply has a limited precision (only 3-4 decimal places should be fine for all scene location values.

http://stackoverflow.com/questions/11542299/how-to-convert-ieee754-float-to-fixed-point-in-deterministic-way

second answer in that link.

On Wed, Jul 13, 2016 at 3:06 PM, John Pan notifications@github.com wrote:

"And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position"

This is where things will go awry. Float conversion fixed-point number is non-deterministic as it uses float operations and rounding. On different computers, if you convert an X position like 5.5001 from float to fixed-point, you might get different results.

On Wed, Jul 13, 2016 at 12:44 PM, Jesse Fish notifications@github.com

wrote:

The part I may be failing to mention is that the objects are registered out of order randomly but after all objects are registered the manager sorts the objects by ID to order them deterministically.

On Wed, Jul 13, 2016 at 12:42 PM, Jesse F jesfish@gmail.com wrote:

Neither. The system would automatically assign IDs to all LSbodies in the scene such that there is a deterministic order to them that is physically saved in the level so 2 different executions of the game have the same ordering. And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position and then they would register themselves with the correct game managers component, I am not as familiar with the code I think physics manager, or whatever registration the current Saver is doing. This means every time I add new objects to the scene or edit the scene in any way. I just hit play and everything automatically works without needing to add a saver or press a save button.

On Wed, Jul 13, 2016 at 12:38 PM, John Pan notifications@github.com wrote:

Would the system still have the user press the Save button or look for an OnSaveScene event?

On Wed, Jul 13, 2016 at 12:05 PM, Jesse Fish < notifications@github.com>

wrote:

Yes I do understand that. But you could use it as the starting position and convert it to a non float value like you already do when you save the scene using saver. I am not suggesting using it for all values during simulation but to have LSbodies in the scene have the option to read there scene position as their start position automatically.

On Wed, Jul 13, 2016 at 12:03 PM, John Pan < notifications@github.com> wrote:

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish < notifications@github.com> wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan < notifications@github.com

wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish < notifications@github.com

wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232437718

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7Nr0FLPd1MrTOa6xZS6rStu5m2WFks5qVShlgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232438425

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp0t9dYAUvR-zSO1FDJPxk9mwTof4ks5qVSj7gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232447801

,

or mute the thread <

https://github.com/notifications/unsubscribe/AATf7I77RBj3XaumqoKEFA9xEecI4pTqks5qVTCxgaJpZM4JFeff

.

Jesse

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232449321 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp1B-yUe1Q5v_Hbv3BSaKWyuoP6V0ks5qVTIAgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232501074, or mute the thread https://github.com/notifications/unsubscribe/AATf7FdkcLG9JBux398tukiQwGzynbFWks5qVWFYgaJpZM4JFeff .

Jesse

Jesse

erebuswolf commented 8 years ago

Also, I'm unclear what

define HIGH_ACCURACy

was for, and I added some documentation for how the actual fixed point system works since that isn't explained anywhere.

On Thu, Jul 14, 2016 at 5:29 PM, Jesse F jesfish@gmail.com wrote:

After reading up on floating point precision ( http://www.yosoygames.com.ar/wp/2013/07/on-floating-point-determinism/ and https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/) I have determined that the conversion from a float to a fixed point number with return (long)((double)singleFloat * One); is deterministic across systems. I wrote some unit tests for FixedMath.cs and did some formatting fixes to FixedMath.cs which I will provide in a pull request shortly. I also, played around with the previously linked alternative floating-point -> fixed-point conversion method. But after reading up on floating point determinism there is nothing wrong with the function you already have. The only thing I would say is there is a need for overflow checks in that library that are currently missing.

On Wed, Jul 13, 2016 at 3:52 PM, Jesse F jesfish@gmail.com wrote:

So you are saying this equation

return (long)((double)singleFloat * One);

Is not something you should ever do at runtime ever because on two computers it may give different answers? I don't agree that it is impossible to write a floating point converter for different x86 or 64 bit processors. But I don't find this very well documented that this code should never be called ever ever ever during game execution if what you are saying is true.

One could easily write a deterministic floating point conversion that simply has a limited precision (only 3-4 decimal places should be fine for all scene location values.

http://stackoverflow.com/questions/11542299/how-to-convert-ieee754-float-to-fixed-point-in-deterministic-way

second answer in that link.

On Wed, Jul 13, 2016 at 3:06 PM, John Pan notifications@github.com wrote:

"And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position"

This is where things will go awry. Float conversion fixed-point number is non-deterministic as it uses float operations and rounding. On different computers, if you convert an X position like 5.5001 from float to fixed-point, you might get different results.

On Wed, Jul 13, 2016 at 12:44 PM, Jesse Fish notifications@github.com

wrote:

The part I may be failing to mention is that the objects are registered out of order randomly but after all objects are registered the manager sorts the objects by ID to order them deterministically.

On Wed, Jul 13, 2016 at 12:42 PM, Jesse F jesfish@gmail.com wrote:

Neither. The system would automatically assign IDs to all LSbodies in the scene such that there is a deterministic order to them that is physically saved in the level so 2 different executions of the game have the same ordering. And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position and then they would register themselves with the correct game managers component, I am not as familiar with the code I think physics manager, or whatever registration the current Saver is doing. This means every time I add new objects to the scene or edit the scene in any way. I just hit play and everything automatically works without needing to add a saver or press a save button.

On Wed, Jul 13, 2016 at 12:38 PM, John Pan <notifications@github.com

wrote:

Would the system still have the user press the Save button or look for an OnSaveScene event?

On Wed, Jul 13, 2016 at 12:05 PM, Jesse Fish < notifications@github.com>

wrote:

Yes I do understand that. But you could use it as the starting position and convert it to a non float value like you already do when you save the scene using saver. I am not suggesting using it for all values during simulation but to have LSbodies in the scene have the option to read there scene position as their start position automatically.

On Wed, Jul 13, 2016 at 12:03 PM, John Pan < notifications@github.com> wrote:

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish < notifications@github.com> wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan < notifications@github.com

wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish < notifications@github.com

wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232437718

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7Nr0FLPd1MrTOa6xZS6rStu5m2WFks5qVShlgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232438425

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp0t9dYAUvR-zSO1FDJPxk9mwTof4ks5qVSj7gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232447801

,

or mute the thread <

https://github.com/notifications/unsubscribe/AATf7I77RBj3XaumqoKEFA9xEecI4pTqks5qVTCxgaJpZM4JFeff

.

Jesse

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232449321 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp1B-yUe1Q5v_Hbv3BSaKWyuoP6V0ks5qVTIAgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232501074, or mute the thread https://github.com/notifications/unsubscribe/AATf7FdkcLG9JBux398tukiQwGzynbFWks5qVWFYgaJpZM4JFeff .

Jesse

Jesse

Jesse

erebuswolf commented 8 years ago

Sorry 1 more thing. Also I strongly suggest a typedef to long for the fixed point type so that people don't accidentally pass normal longs into functions expecting fixed point longs.

On Thu, Jul 14, 2016 at 5:34 PM, Jesse F jesfish@gmail.com wrote:

Also, I'm unclear what

define HIGH_ACCURACy

was for, and I added some documentation for how the actual fixed point system works since that isn't explained anywhere.

On Thu, Jul 14, 2016 at 5:29 PM, Jesse F jesfish@gmail.com wrote:

After reading up on floating point precision ( http://www.yosoygames.com.ar/wp/2013/07/on-floating-point-determinism/ and https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/) I have determined that the conversion from a float to a fixed point number with return (long)((double)singleFloat * One); is deterministic across systems. I wrote some unit tests for FixedMath.cs and did some formatting fixes to FixedMath.cs which I will provide in a pull request shortly. I also, played around with the previously linked alternative floating-point -> fixed-point conversion method. But after reading up on floating point determinism there is nothing wrong with the function you already have. The only thing I would say is there is a need for overflow checks in that library that are currently missing.

On Wed, Jul 13, 2016 at 3:52 PM, Jesse F jesfish@gmail.com wrote:

So you are saying this equation

return (long)((double)singleFloat * One);

Is not something you should ever do at runtime ever because on two computers it may give different answers? I don't agree that it is impossible to write a floating point converter for different x86 or 64 bit processors. But I don't find this very well documented that this code should never be called ever ever ever during game execution if what you are saying is true.

One could easily write a deterministic floating point conversion that simply has a limited precision (only 3-4 decimal places should be fine for all scene location values.

http://stackoverflow.com/questions/11542299/how-to-convert-ieee754-float-to-fixed-point-in-deterministic-way

second answer in that link.

On Wed, Jul 13, 2016 at 3:06 PM, John Pan notifications@github.com wrote:

"And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position"

This is where things will go awry. Float conversion fixed-point number is non-deterministic as it uses float operations and rounding. On different computers, if you convert an X position like 5.5001 from float to fixed-point, you might get different results.

On Wed, Jul 13, 2016 at 12:44 PM, Jesse Fish notifications@github.com

wrote:

The part I may be failing to mention is that the objects are registered out of order randomly but after all objects are registered the manager sorts the objects by ID to order them deterministically.

On Wed, Jul 13, 2016 at 12:42 PM, Jesse F jesfish@gmail.com wrote:

Neither. The system would automatically assign IDs to all LSbodies in the scene such that there is a deterministic order to them that is physically saved in the level so 2 different executions of the game have the same ordering. And then at runtime onstart all the lsbodies in the scene would read their transforms and convert those to vector2ds as their position and then they would register themselves with the correct game managers component, I am not as familiar with the code I think physics manager, or whatever registration the current Saver is doing. This means every time I add new objects to the scene or edit the scene in any way. I just hit play and everything automatically works without needing to add a saver or press a save button.

On Wed, Jul 13, 2016 at 12:38 PM, John Pan < notifications@github.com> wrote:

Would the system still have the user press the Save button or look for an OnSaveScene event?

On Wed, Jul 13, 2016 at 12:05 PM, Jesse Fish < notifications@github.com>

wrote:

Yes I do understand that. But you could use it as the starting position and convert it to a non float value like you already do when you save the scene using saver. I am not suggesting using it for all values during simulation but to have LSbodies in the scene have the option to read there scene position as their start position automatically.

On Wed, Jul 13, 2016 at 12:03 PM, John Pan < notifications@github.com> wrote:

Ah. Keep in mind transform.position uses floats and is not deterministic. You can't use it during runtime to affect simulation. You'd still need to save a Vector2d from the transform.position.

On Tue, Jul 12, 2016 at 11:11 PM, Jesse Fish < notifications@github.com> wrote:

The trade off is you can then load the transforms of the objects from the level directly. Every time you move something in the level to change the way it looks and want to test it you are adding an extra step to select a separate object and click a save button. This is completely unnecessary. For objects in the scene you can have the LSbodies load their own object transforms instead of loading their start position out of a save script. The save script from what I can tell is needless data duplication when the problem it is trying to solve is ordered object identification and physics simulation. To your other question, any objects dynamically loaded at runtime do not need an ID as whatever system currently loads them in order should continue to load them in order if all the scene objects are always loaded before or after the dynamic objects and in order of object IDs.

On Tue, Jul 12, 2016 at 8:17 PM, John Pan < notifications@github.com

wrote:

No, the saver's staying because it works and I don't see significant advantages in the alternative system. Automatic saving (i.e. when the user saves the scene) can be implemented but it's not efficient forcing LS to find all the references at runtime when it can just store them in 1 script.

Actually, I might not understand completely the purpose of assigning scene agents IDs. Let me know if that's the case. Are the ID used for every object including those spawned at runtime?

On Tue, Jul 12, 2016 at 11:52 AM, Jesse Fish < notifications@github.com

wrote:

What's the status of this? Should I move forward and try to implement this system and remove the saver?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232125567

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp3udaRx18XpJlk5NkRB1t_iLO6QEks5qU9RrgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232236106

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7EDhYtI2TQ-d6bS9MS1TfmyO2Xocks5qVErVgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232258039

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp4C6ybU277bCibtPCtu16Clrqi5Dks5qVHN2gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232437718

, or mute the thread <

https://github.com/notifications/unsubscribe/AATf7Nr0FLPd1MrTOa6xZS6rStu5m2WFks5qVShlgaJpZM4JFeff

.

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232438425

, or mute the thread <

https://github.com/notifications/unsubscribe/AHXqp0t9dYAUvR-zSO1FDJPxk9mwTof4ks5qVSj7gaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <

https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232447801

,

or mute the thread <

https://github.com/notifications/unsubscribe/AATf7I77RBj3XaumqoKEFA9xEecI4pTqks5qVTCxgaJpZM4JFeff

.

Jesse

Jesse

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232449321 , or mute the thread < https://github.com/notifications/unsubscribe/AHXqp1B-yUe1Q5v_Hbv3BSaKWyuoP6V0ks5qVTIAgaJpZM4JFeff

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SnpM/LockstepFramework/issues/79#issuecomment-232501074, or mute the thread https://github.com/notifications/unsubscribe/AATf7FdkcLG9JBux398tukiQwGzynbFWks5qVWFYgaJpZM4JFeff .

Jesse

Jesse

Jesse

Jesse