Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualAngus Hollands

Posted 21 February 2013 - 09:23 AM

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.


#1Angus Hollands

Posted 21 February 2013 - 09:22 AM

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). 


PARTNERS