A few questions

[AlexTurpin]

Hey all,

I have been using this Library and I absolutely love it. However, I
seem to have a few issues / things I'm not sure about.

First of all, is there any important difference between NetServer/
NetClient's CreateBuffer and just using new Buffer()?

Second of all, when accepting connections in a Server, there is the
possibility to send "Local hail data". How do I retrieve such data on
the client and when is it safe to do so?

Finally, does anyone know of any good article about multiplayer game
architecture? I keep on trying to figure out new ways to code things,
but my code always ends up like spaghetti.

Thanks.

--
You received this message because you are subscribed to the Google Groups "lidgren-network" group.
To post to this group, send email to lidgren...@googlegroups.com.
To unsubscribe from this group, send email to lidgren-netwo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/lidgren-network?hl=en.

[Matthew Overall]

First: I can't say for sure, but like I said before, CreateBuffer is how I establish my single buffer reader used throughout the solution.

Second: You can send back haildata upon accepting a connection. That is read on the recievers end by i think Client.Server.LocalHailData or something like that... not sure about safe...?

Finally: LOL I know exactly what you mean by spaghetti, I searched for networked game standards for a while but found nothing, so through trial and error I finally came up with something that worked for me. Maybe you could post some more information about what you are trying to accomplish. 

[lidgren]

CreateBuffer should pretty much always be used; if available, it will
recycle an old (if recycling is enabled) buffer instead of allocating
a new one.

LocalHailData is read on the remote end as RemoteHailData.

Both these are an unintuitive mess that's been solved in gen3; there
you cannot create new outgoing messages explicitly, you must use the
CreateMessage() method, and local/remote hail data does not exist -
only data which you can pass to the Connect() method and retrieve in
the ConnectionApproval message on the remote side.

--michael

> > lidgren-netwo...@googlegroups.com<lidgren-network%2Bunsubscribe@ googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/lidgren-network?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "lidgren-network" group.
> To post to this group, send email to lidgren...@googlegroups.com.
> To unsubscribe from this group, send email to lidgren-netwo...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/lidgren-network?hl=en.

[AlexTurpin]

Thanks for the answers fellas. May I ask what the difference between
Gen3 and regular code base is? Is it worth using right now?

[lidgren]

Gen3 is a complete rewrite of the library. Most things work almost
like this version, but there are subtle changes everywhere and a few
bigger ones too; most notably the NetBuffer class has disappeared and
is replaced by NetIncomingMessage and NetOutgoingMessage. Gen3 is
almost feature complete (well, apart from future features such as
encryption) and i've done alot of testing, but there are still more
testing needed of course.
If you're starting a new project I would recommend using gen3; if
you've already done alot of code in the current version I'd probably
stick with it a little longer. Migrating from this version to gen3
won't be a lot of work, but they're different enough so they can't be
just a slot-in replacement.

--michael

[Chris Cowherd]

Ouch.  I use the hail data extensively outside of ConnectionApproval and my classes are abstracted to the point where I don't have access to the ConnectionApproval callback.  It would be awkward to pass the hail data around. I store public keys, other identification and service capability info in the hail data.

Also because of the same abstractions, I don't have access to the access to the original NetClient/NetServer to create buffers so I just allocate them as needed and I've never had any allocation or GC overhead that has shown up in my instrumentation.

Hmmm... I'm going to have to rethink this or stick to Gen2.  I can see why you are making those changes for the general case though.

[lidgren]

Just changing the constructor access modifier to public for the
NetOutgoingMessage class would enable instantiating, but I think
leaving it private in the main distribution is a good idea - forcing
people to use CreateMessage() will enable recycling and better memory
management.

The hail data is more difficult; altho storing it with the connection
is slightly more flexible the simplicity of the new hail data scheme
makes it less prone to misunderstanding and easier, more bulletproof
code in the engine. Maybe you can store a data object in the
connection Tag property which can keep track of the hail data (and
other stuff)?

OTOH if you've invested in gen2, sticking to it might be a good option
- it's well-tested code and altho gen3 has some incremental
improvements there's no groundbreaking new feature that is not in
gen2.

--michael