Angus Hollands

How would one compensate for the scenario when physics are deliberately omitted from the replication (e.g when the object isn't moving)?
The two solutions I foresee would be a boolean "isIdle" that is replicated with the physics, or just sending it every replication regardless (or just reading the velocity value).

Furthermore, have you any suggestions on how to create the buffer? Because my attempts haven't been altogether succesful.

Here I'm wondering how Unreal does it. By default, the replication statements are applied as soon as they're received. This would include physics. However the physics system scrapes the replicated data so It may choose to implement a jitter buffer. Would it then be sensible for the Physics "system" (that which iterates over the actors and scrapes the data) to implement the jitter buffer; sending a timestamp with the attributes? 

So, for the sake of ease it is best to treat the latest incoming data as the current data.

How would one run a jitter buffer for this without doing something involving clock sync?

The predictions I send to the server will be the results of the inputs, therefore I'd only need to timestamp them to help prevent speed-hacking (I'd only need to know how long the inputs were processed for.)

In light of the fact that I'd need to re-simulate physics, I've decided to temporarily switch to another Python-based engine which gives me this ability, so that I can get the foundations working. Does this look like a permissible gameloop?

1. Receive network data.
2. Apply any corrections to physics data - there would have to be "real" positions and "render" positions, although this would make things more complex so I may just use interpolated positions for non-authority gameobjects.
3. Tick physics (perhaps a number of times if there are a number of saved moves).
4. Run simulation from inputs.
5. Tick Physics 
6. Send results to server (with timestamp) -> delta = last_timestamp - current timestamp

I am basing my own system off Unreal's architecture. I've decided that the networking aspect should be as separated from the objects themselves. Firstly, it is important to make a distinction between "objects" and networked class instances. My concept; and thus that of unreal is to have network class instances that may have physical meshes etc.

Anyway, They way I manage data for different clients is to have "ReplicationChannels". Here's my document https://docs.google.com/document/d/1nRE29bgGW0cJwmn1t3-e92dVmZG4HZqOkHubssWfWms/edit

Essentially there is a channel created on the server and client for every object that exists multiplied by the number of connected peers. Then we can save the state of networked attributes on the channel. I use a form of hashing to determine if the value has changed, to avoid issues with muteable types. I use descriptors in python to set a dirty flag when an attribute is changed but that's part of the bIsDirty variable that Unreal uses and so I still compare the custom hash of each value when I ask the channels to replicate data.

I'm happy to tell you more about what I'm doing. It's interesting as I am coming from the other end; adding a component framework after creating a replication system. However, in my situation I shall be using a more system-based approach. (it's sort of a hybrid, as attributes (things that are sent over the network) can be instances of classes and therefore treated like components or they may be fundamental data types.. 

At the moment It won't be the case. Actors are just replicated instances with methods and data. They can hold a reference to a child object as part of their data but the object isn't itself the actor.

I'm a little unnerved by a dependancy that I've introduced. Allow me to explain.

Nearly everything is replicated using the actor replication methods. This includes the worldinfo class. However, there is a problem. The WorldInfo class is needed by the replication system to know whether to call variable replication methods that pipe the serialised variables to the peer (only servers should be able to replicate variables) and it is also needed for function replication.

I planned on making the static (already instantiated) worldinfo class available by using a class attribute (__actors__) which can store all actors that inherit the replicable base class. This avoids the need for a handler to store the actors, and we can take the base class and read the registered actors from it. 

Anyway, regardless of how I map the worldinfo client instance to the server instance, does anyone see any qualms with this. In some ways, it makes sense because replication can still occur to the peer, just not from it, and that would ensure that nothing was invoked until the client knew it was a client...like a setup routine. But if anyone can offer a nicer idea, please, by all means!

definition: game-object = Physical Game-Engine object; mesh, objects can also run gamelogic but I don't like it over python

Going back to the local game-objects, How would someone else handle them?

The method that I am considering is a Physics component. Essentially, it's an optimised way of packing and unpacking position, velocity and rotation (see here http://www.pasteall.org/39896/python) that I could have controlling the mesh. For example, instantiating the physics component as a network attribute like this:

physics = ReplicatedVariable("ObjName")

and this would create an instance of that GameObject for this actor's physics component. When the actor is replicated, it will do the same for the other side of course. Then when you need to have the object update its position you can call various methods on the physics component. (Component probably isn't the best name for it). Whenever the component is updated through replication the gameobject can be updated at the same time.

Unreal has a lot of behind the scenes work that can serialise references to actors, and so forth. I was considering doing this; converting to and from network IDs (it may be more hassle than its worth, but I was thinking that this may be useful for replicated weapons). Do you think that it would be better to recreate actor relationships automatically (which wouldn't take a whole lot of work) or force the user to handle the network id? I think it's a bit of a no-brainer but I may as well ask.