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 13 February 2013 - 08:48 AM

I do care about the time spent checking attributes for changed values etc, because that shouldn't be the largest limiting factor. 

 

Also, I am a little perplexed after checking the UT3 source unrealscripts. I am looking at WorldInfo.uc and it has a replication block. Until now I assumed replication was for actors only. As this seems not to be the case, I was wondering how it is so seamlessly consistent between different class types.

  1. Specifically, I wish to know how it distinguishes between already instanced and non-instanced classes. Take Actors. I would imagine that when receiving a replication packet on the client for an actor would simply be directed to the actor manager, and if the id wasn't instantiated already it would create the actor. However, this cannot apply to non-actors such as WorldInfo which don't inherently have an ID.
  2. To achieve automatic replication, would it be the case that every time something inherits from the Replication base class, it registers the channel ID to a special mapping; so that every time something is instantiated of that type it adds its network ID to that map? This means that replication would actually interface with replicated classes by itself, without needing to be performed explicitly for each class.

Continuing on. The main issue that I face is that UnrealScript is built on top of the engine, and so it doesn't need to define entry points to certain functions like collisions and physics updates. Therefore I believe I need to create an interface layer between the various aspects of my Game Engine and the networked "game" that exists separately to this. For example, defining a network role as Simulated will not be implemented as any functional movement code. Therefore I have to define that myself. This means that I will need to keep a history of "states" of the actors for each game tick to allow for extrapolation using EPIC

 

I was reading into Unreal and I realised that they send the inputs, and expected outcome and predict between confirmation. At the moment I just send the inputs and skew the time so that it matches closely to when the inputs are received. I think that the first method would be better because then it allows me to avoid guessing and get fewer prediction errors, but at the cost sending three floats every network tick to the server. Does anyone have any ideas if this is a better method? It seems like I've been thinking about movement code wrongly and this is actually how most people do this. I would also send the time taken to process the inputs, but this of course opens the possibility for speedhacking. Are there better solutions?

 

Also, some other questions about Unreal network attributes.

  1. There is bNetDirty which I believe is a simple attribute stored on each actor instance and changes when any networked values are changed. If this is the case how do they stop position and orientation from setting it as it seems to suggest it's optionally triggered? As well as this, It doesn't seem to handle specific attributes, instead it seems that if any attributes change, all would be sent if the replication block checks for bNetDirty only. I assume that the system only sends the changed attributes, so is that caught after the replication block?
  2. There is also bNetOwner and bNetInitial. These are only available inside the replication block according to the documentation, and so I assume that bNetDirty is available outside. My hunch is that because attributes are reliably transmitted, if they are told to be replicated because they are dirty, they will eventually get to the other side. Why is it then that bNetInitial is only set False when it receives an ACK? Because if its reliable, the initial attributes will eventually get to the other side? It seems contradictory to me. 

#3Angus Hollands

Posted 13 February 2013 - 08:20 AM

I do care about the time spent checking attributes for changed values etc, because that shouldn't be the largest limiting factor. 

 

Also, I am a little perplexed after checking the UT3 source unrealscripts. I am looking at WorldInfo.uc and it has a replication block. Until now I assumed replication was for actors only. As this seems not to be the case, I was wondering how it is so seamlessly consistent between different class types.

 

  1. Specifically, I wish to know how it distinguishes between already instanced and non-instanced classes. Take Actors. I would imagine that when receiving a replication packet on the client for an actor would simply be directed to the actor manager, and if the id wasn't instantiated already it would create the actor. However, this cannot apply to non-actors such as worldInfo which don't inherently have an ID.
  2. Therefore, developing a guess, In order to implement some similar behaviour with my system, would it be the case that every time something inherits from the Replication base class which adds the functionality to the class, it registers the channel ID to a special mapping so that every time something is instantiated of that type it adds the network ID it is created with to that map? This means that replication would actually interface with replicated classes by itself, without needing to be tied into a loop for each class. However, I then do not know how to tie this into the game part of the system which handles actor creation etc.
  3. Continuing on. The main issue that I face is that UnrealScript is built on top of the engine, and so it doesn't need to define entry points to certain functions like collisions and physics updates. Therefore I believe I need to create an interface layer between the various aspects of my Game Engine and the networked "game" that exists separately to this. For example, defining a network role as Simulated will not be implemented as any functional movement code. Therefore I have to define that myself. This means that I will need to keep a history of "states" of the actors for each game tick

I was reading into Unreal and I realised that they send the inputs, and expected outcome and predict between confirmation. At the moment I just send the inputs and skew the time so that it matches closely to when the inputs are received. I think that the first method would be better because then it allows me to avoid guessing and get fewer prediction errors, but at the cost sending three floats every network tick to the server. Does anyone have any ideas if this is a better method? It seems like I've been thinking about movement code wrongly and this is actually how most people do this. I would also send the time taken to process the inputs, but this of course opens the possibility for speedhacking. Are there better solutions?

 

Also, the bnetdirty attribute. I read that that is changed if any value is changed. I therefore assume that means that If I have three values and all three are set to replicate if the bnetdirty attribute is True, changing any one of them will send to the other side?


#2Angus Hollands

Posted 13 February 2013 - 07:56 AM

I do care about the time spent checking attributes for changed values etc, because that shouldn't be the largest limiting factor. 

 

Also, I am a little perplexed after checking the UT3 source unrealscripts. I am looking at WorldInfo.uc and it has a replication block. Until now I assumed replication was for actors only. As this seems not to be the case, I was wondering how it is so seamlessly consistent between different class types.

 

  1. Specifically, I wish to know how it distinguishes between already instanced and non-instanced classes. Take Actors. I would imagine that when receiving a replication packet on the client for an actor would simply be directed to the actor manager, and if the id wasn't instantiated already it would create the actor. However, this cannot apply to non-actors such as worldInfo which don't inherently have an ID.
  2. Therefore, developing a guess, In order to implement some similar behaviour with my system, would it be the case that every time something inherits from the Replication base class which adds the functionality to the class, it registers the channel ID to a special mapping so that every time something is instantiated of that type it adds the network ID it is created with to that map? This means that replication would actually interface with replicated classes by itself, without needing to be tied into a loop for each class. However, I then do not know how to tie this into the game part of the system which handles actor creation etc.
  3. Continuing on. The main issue that I face is that UnrealScript is built on top of the engine, and so it doesn't need to define entry points to certain functions like collisions and physics updates. Therefore I believe I need to create an interface layer between the various aspects of my Game Engine and the networked "game" that exists separately to this. For example, defining a network role as Simulated will not be implemented as any functional movement code. Therefore I have to define that myself. This means that I will need to keep a history of "states" of the actors for each game tick

I was reading into Unreal and I realised that they send the inputs, and expected outcome and predict between confirmation. At the moment I just send the inputs and skew the time so that it matches closely to when the inputs are received. I think that the first method would be better because then it allows me to avoid guessing and get fewer prediction errors, but at the cost sending three floats every network tick to the server. Does anyone have any ideas if this is a better method? It seems like I've been thinking about movement code wrongly and this is actually how most people do this. I would also send the time taken to process the inputs, but this of course opens the possibility for speedhacking. Are there better solutions?


#1Angus Hollands

Posted 13 February 2013 - 06:02 AM

I do care about the time spent checking attributes for changed values etc, because that shouldn't be the largest limiting factor. 

 

Also, I am a little perplexed after checking the UT3 source unrealscripts. I am looking at WorldInfo.uc and it has a replication block. Until now I assumed replication was for actors only. As this seems not to be the case, I was wondering how it is so seamlessly consistent between different class types.

Specifically, I wish to know how it distinguishes between already instanced and non-instanced classes. Take Actors. I would imagine that when receiving a replication packet on the client for an actor would simply be directed to the actor manager, and if the id wasn't instantiated already it would create the actor. However, this cannot apply to non-actors such as worldInfo which don't inherently have an ID.

 

Therefore, developing a guess, In order to implement some similar behaviour with my system, would it be the case that every time something inherits from the Replication base class which adds the functionality to the class, it registers the channel ID to a special mapping so that every time something is instantiated of that type it adds the network ID it is created with to that map? 

This means that replication would actually interface with replicated classes by itself, without needing to be tied into a loop for each class. However, I then do not know how to tie this into the game part of the system which handles actor creation etc. 


PARTNERS