Properties

Dec 18, 2007 at 6:09 PM
Im trying to get some properties to work correctly. Ive used the following:

public Stack<IMessage> localMessages
{
get { return this.localMessages; }
}

Yet when I try to set it ( = new etc.) in the constructor it returns with:

Property or indexer QuickStart.Network.SubSystems.LocalSubSystem.localMessages' cannot be assigned to -- it is read only

How can I solve this? On a side note, Ideally I want localMessages to be private yet cant as I cant force it to be private as its in the Interface. Does anyone know a workaround?
Dec 18, 2007 at 6:19 PM
You need a set property as well if you want to assign to it:

public Stack<IMessage> localMessages
{
    get { return this.localMessages; }
    set { this.localMessages = value; }
}

Interface methods have to be public as an interface defines all properties/methods/events accessible from a client of any derived classes. If you need to encapsulate private/protected functionality, consider using an abstract class.
Dec 18, 2007 at 6:21 PM
I considered using set, but isnt that available to anyone then? I will consider an abstract class, as this is just awkward at the minute.
Dec 18, 2007 at 6:29 PM
Yes in the above set is public to all, you can get around this by using:

public Stack<IMessage> localMessages
{
    get { return this.localMessages; }
    protected set { this.localMessages = value; }
} 
Which would only make the setting protected visible, you can also use internal/private if needed.

Though I would reconsider the scenario you are trying to cover, there might be other patterns you can use to solve this issue.
Dec 18, 2007 at 6:30 PM
It would be available to anyone, else. Why do you need set functionality anyway? The stack should be instantiated by the class.
Dec 18, 2007 at 6:37 PM
Im tying to get it to be, but it wont let me. I have now tried to do it using an abstract class, but now its a StackOverflowException, and this is when setting it! Am i being stupid??
Dec 18, 2007 at 6:46 PM
A stack overflow in this case means you have infinite recursion. Come to think of it, that sample code can't possibly work:

public Stack<IMessage> localMessages
{
    get { return this.localMessages; }
    set { this.localMessages = value; }
}

When setting, you're assigning a new value to this.localMessages, which points to the property, which points to this.localMessages, which points to the property, ..., stack overflow :)

The property name must be different from the local variable name.
Dec 18, 2007 at 7:03 PM
Edited Dec 18, 2007 at 7:03 PM
LOL, didn't even notice :) Yup and the naming sceme dictates PascalCase for properties and camelCase for fields, so the final code would look like:

public Stack<IMessage> LocalMessages
{
    get { return this.localMessages; }
    protected set { this.localMessages = value; }
} 

(See proper coding guidelines does prevent coding errors :) )
Dec 18, 2007 at 7:11 PM
On a side node can you post the interface, I would like to see how it looks.
Dec 18, 2007 at 7:42 PM
Edited Dec 18, 2007 at 7:48 PM


shawmishrak wrote:
A stack overflow in this case means you have infinite recursion. Come to think of it, that sample code can't possibly work:

public Stack<IMessage> localMessages
{
    get { return this.localMessages; }
    set { this.localMessages = value; }
}

When setting, you're assigning a new value to this.localMessages, which points to the property, which points to this.localMessages, which points to the property, ..., stack overflow :)

The property name must be different from the local variable name.


your sample will not compile. you will recieve someting like this - Error: The type 'YourType' already contains a definition for 'localMessages'.
class fields can`t points to the properties. C# compiler will not allow this.

and BTW: stack overflow is a little bit different thing than type memeber names collisions...
Dec 18, 2007 at 7:56 PM
What he was saying is that get { return this.localmessages; } points to public Stack<IMessage> localMessages which then points back to this.localmessages. It's an infinte loop or in other words a stack overflow. It never points to a class field.
Dec 18, 2007 at 8:03 PM
Edited Dec 18, 2007 at 8:03 PM

raxxla wrote:

your sample will not compile. you will recieve someting like this - Error: The type 'YourType' already contains a definition for 'localMessages'.
class fields can`t points to the properties. C# compiler will not allow this.

and BTW: stack overflow is a little bit different thing than type memeber names collisions...


Correct, it will not compile if a local variable localMessages exists. I just stuck a setter into mikelid109's code to show how to allow client code to assign to the property. I did not verify the variable names.

I realize stack overflow is not the same thing as name collision. In this case, the recursive nature of this particular property definition causes a stack overflow through infinite recursion, like I mentioned.
Dec 18, 2007 at 8:22 PM
Thats sorted, but my code runs very fast, and the sample game gets stuck in a loop I believe. I need to debug it, and find the gltich. Once ive done that, Ill probably upload the class for you. Its now an abstract class, as I will implement some methods that will be common to all subsystems. Cheers for the help guys.
Dec 18, 2007 at 8:33 PM
Can't wait to see it!
Coordinator
Dec 18, 2007 at 8:42 PM
Edited Dec 18, 2007 at 8:43 PM
Sample game gets stuck in a loop when there is nothing to render. It doesn't actually freeze completely, it just becomes hard to move the camera. I need to fix this.

Of course, this may be a separate issue from your stuff.

Edit: I guess I can elaborate a little bit. When there is so little in view that the framerate goes up by a lot, then it causes issues.
Dec 18, 2007 at 8:45 PM
At excessively high frame-rates, the elapsed time between frames falls to zero due to timer resolution so time-based movement fails to work.
Coordinator
Dec 18, 2007 at 8:55 PM
Yeah, I tried to compensate by checking if elasped time was zero then set it to 5. That didn't do much. You might see that code in there, feel free to toy with it if you'd like.
Dec 18, 2007 at 9:21 PM
I need to think more (plus its late in the UK). My code was passing any messages it recieved straight back to the engine, to be caught and resent again, etc. This meant the same message was going round 100+ times. Its hopefully fixed now, and it happened because I didnt think through my local coding. Ah well, live and learn!
Coordinator
Dec 19, 2007 at 6:00 AM
Edited Dec 19, 2007 at 6:00 AM
Mike, Shawn has been posting regular amounts of good networking advice for XNA and Live networking, I highly recommend it.

http://blogs.msdn.com/shawnhar/archive/2007/12/14/network-latency.aspx
Dec 19, 2007 at 5:15 PM
Cheers, Ill add it to my reader.
Dec 19, 2007 at 5:27 PM
Flicking thorugh the blog, I was reminded about prediction algorhitims. Were in the engine would this go? Is the network meant to do it, physics, or even SceneManager?
Coordinator
Dec 19, 2007 at 5:43 PM
The client would need to handle it somehow. I've never done prediction before unforuntately, so your guess is as good as mine.
Dec 19, 2007 at 6:00 PM
Edited Dec 19, 2007 at 6:01 PM
I would average out the last 3 updates or so, to predict the next one. Rough, but simple and relatively quick. I was wondering if it was going to be an engine feature or a client one. I would probably suggest engine
Dec 19, 2007 at 6:08 PM
Ive ported my fisrt patch's local code to a proper SubSytem, and changed the interface. I will post this as a patch for comment if requested, but id like to get the system link section done first.
Coordinator
Dec 19, 2007 at 7:25 PM
Edited Dec 19, 2007 at 7:25 PM
I don't think we have dependancy on the networking just yet, so no rush.

I'd say prediction should be part of the engine. I'd hate to make someone code that themselves to use the networking properly (assuming their game type requires prediction).
Dec 19, 2007 at 7:35 PM
Physics can do most of the prediction for the world. I think the only prediction the network system should do is player movement.
Dec 19, 2007 at 7:45 PM

shawmishrak wrote:
Physics can do most of the prediction for the world. I think the only prediction the network system should do is player movement.


SImply put the network is dumb. It makes no differentiation between players and (for example) a tree, as to it there just messages for other parts to handle. When I was designing there did not seem to much support for a player class so I left it out. I think either the network should do all prediction, or none.
Dec 19, 2007 at 7:56 PM
Then maybe SceneManager should handle it.
Dec 20, 2007 at 4:26 PM
Couldn't physics just handle all predictions? I don't see what it has to do with the scene manager...
Dec 20, 2007 at 5:29 PM
The physics simulator will handle all prediction that is not directly tied to player input. Player input prediction, like player movement and events, is best left to some AI logic. For instance, say the game receives two messages saying player B is firing a machine gun. The game logic should continue to predict that the player will continue firing until told otherwise. This is not something that the physics simulator should handle.
Dec 20, 2007 at 11:00 PM
Alright I get it. But what happens if player B kills player A through prediction because there was a lag spike and the last message that said he had stopped firing got there late or not at all? I am sure there is a solution, I just want to know what it is.
Dec 20, 2007 at 11:03 PM
Major events like player deaths will not occur until the server verifies it. So, while a client may render player B as shooting at player A (incorrectly), player A will not "die" until the server tells the clients that player A is dead.
Dec 21, 2007 at 2:23 PM
This is not something the network will inherently support, as its very game specific, but Its coded to allow it to be custom coded through extension.