What version [Rakknet]

What is the core back end version of RakNet is in Unity?

The reason why I am asking is this following thread:
http://www.jenkinssoftware.com/raknet/forum/index.php?topic=1803.0

I need to know which code to stick with for my server to your implimentation.

 

Unitys Raknet source code is included with the MasterServer/Facilitator and ConnectionTester source downloads, available here: http://unity3d.com/master-server/index.html

 

Thanks, but I wasn't asking for the source, I just wanted the version. What version are you using? Is it raw 3.0 or a higher version of 3.0? (3.1,- 3.25)

Here is screen shots of version 3.0 working as a headless server with Unity. Source doesn't do me any good if I don't know which version of the source you are using though, thanks ahead of time for the response, but I still have a question, what version of raknet are you using internally?

The two shots I have here, is my code with XCode compilation, I want to upgrade my code to the latest RakNet, but don't want to mess up communication with Unity, thats why I need to know the internal build version of RakNet.

First shot just shows the connection state, second shot just shows the disconnection. This is while the game is in the editor running btw, no problem connecting to a headless server, this is a Mac headless build, not a PC one, I have one of those also.

Edit:
For those of you who are watching this thread, RakNet has a few things you have to understand, with version 3.0, there was the following updates to the code base as in versions:

3.001,3.002,3.004,3.005,3.007,3.009, 3.01,3.02,3.03,3.05,3.06,3.08
All of which was in the 3.0 range, each was code fixes and changes, now, what happens to RakNet at the next major increment to 3.1, is that the data /communication is not backward compatible to the 3.0x series.

From what I have been told, Unity's flavor of RakNet only exposes RPC, and not all engine objects are exposed. So for me to just download the version that Unity uses and compile with that, would be bad since I have other projects that also use the same server at the same time Unity uses it. These projects use components that are not built into the version that Unity uses. But I need to know which core that Unity started out using so I know which base to use to guarantee packet delivery and avoid corruption between Unity and my server.

The change in compatibility also bodes true for each subversion from 3.1, and 3.2

 

Thanks for the info, I think that's very helpful.

Are there plans to support any further features of RakNet, like the auto patcher or voice communication (or even the crash reporter)? Or maybe even the possibility to "link in" to the RakNet implementation that Unity uses (e.g. via some plugin)?

I guess it would be nice to add some of this information to the documentation (in particular the RakNet version number and the information that the relevant source can be found in the master server package).

 

I posted on the RakNet forums about the version 3.0 not being available, then Jenkins let me know that 3.01 was the official "3.0" release. So since they are using the official 3.0 release the actual version they used was 3.01 (well that is my guess based on this thread)

As far as "link in" goes, there are a few changes you have to make for your personal headless server, the master server code that they give works for the RPC setup that exists within Unity, so if you plan on just using RakNet with Unity and nothing beyond that with regards to the same server and what it is doing, just grab the MasterServer code and the test connector code, that will get you up and running.

Your "intro" scene needs an empty game object (or an object that remains constant between scenes). This object should hold your connection script. Now, this connection HAS TO BE kept consistent between scenes, unfortunately I am blind because I do not see in the docs where they talk about how they are keeping the current connection live between scene files (load level)

Remember, we have ZERO control over the instantiation of the engine. typically, what you do with a network engine, is you start the network layer BEFORE you start the game loop. however, Unity starts the game loop then we start the network engine, backwards to say the least.

It should go something like this:
Splash screen
Login screen (2d mapping, or 3d mapping)
Connection state -> network server connection made
game loop begin
game loop end
Connection state -> close
close down app

Instead, here is what we have:
Configuration screen for defaults (resolution etc) <- this might be part of the game loop, I have no clue for sure
Game loop begin
Instantiation of all GO or START within all objects in first scene or first level
Network code instantiate on START within an EGO
NOTE BE CAREFUL HERE!!!
A full game cycle needs to occur before everything else's START, otherwise you will end up with possible packet corruption and incomplete communications.
Start of all other START scripts
Game loop end, auto-terminate of any network connection through forced drop or some other uncontrolled network disconnection.
Close of app

What problems this poses:
1) game objects can have there START begin before the network instantiate and player connect routine. BAD
2) Game can continue before the network returns with unable to connect (verified this multiple times in my code)
3) Late game terminate to login screen
4) possible memory leak could happen, don't know the internal coding of the implementation of the client in Unity

Ways to dance around the listed issues:
1) create a Login scene, this scene then takes the login credentials and attempts the login, that is the ONLY purpose to this scene, user authentication
2) somehow using keep-alive, pass the active network object around between all scenes as a global object to the game
3) do not let the game load to the first level until server authentication has happened and a good unique player ID has been returned
4) using global variables, store in a hash, the user credentials once they are validated, on load of each scene, have an EGO standing by that has the ONLY and I do mean the ONLY Start routine for the scene, this start routine re-authenticates to the game server using the verified information from the login screen. This is really not feasible, btw..

Other than that, I haven't found a clean way to do this yet.
AFAIK Unity looks at a scene, collects all objects, looks for scripts, looks at all START() elements, then in some sequence, runs through them based on some unknown list. This is supposed to happen in the first game loop from what I gather (for all live objects that is)

Cloned objects, once they are created, the very next game loop, the START is triggered. One way I have found around the issues I have listed above, is to painstakingly create a scene, use good old pen and paper, write down coordinates to all objects along with orientation, etc, then clear the scene, I have an EGO that then in its start, if my connection was successful, if and when it comes back as determines good, I then clone all objects that is supposed to exist in the scene and place the clones, as each clone is created, the next game loop the Start on that clones code triggers,

All of this is a hassle at the moment, mainly because the network information should be before the game loop. It is just working within Unity's limitations that makes life fickle. I am sure I will find another simpler way.

 

I haven't tried controlling Unity's networking externally, yet, but from my experiences with networking between a Unity standalone server and multiple clients, I don't see any problems.

I've dropped that "Unity startup screen" because I don't need (and don't like) it. So my game starts, and at first, there is no need to connect. I let the player do his configurations (screen resolution, fullscreen/windowed and all other settings), even practicing game sessions and the like, and then - if he wishes - he can log in, which is when he connects. That works via the MasterServer, and I get the relevant events (connected, disconnected etc.), once the connection is set up, I do quite a bit of initialization and synchronization via RPCs.

To me, having the game loop before starting any networking makes perfect sense, since the whole GUI stuff happens in the game loop. I know when I have a connection, and when I don't have a connection, so I can act accordingly.

My assumption would be that directly using RakNet for a headless server, you'd simply set up a server listening, and pretty much connecting the same way that I do now - only that instead of a Unity based server, you'd have a custom server. Ideally, this should be transparent to the client.

While I'd very much appreciate the flexibility gained through that, I'd miss many of the convenient features that Unity offers: PhysX for free. A very cool and well thought-out scripting engine (including all of .NET 2.0) - for free. Being able to keep "client game world" and "server game world" in sync very easily - for free (I'm not saying I got Unity Pro for free - but now that I have it, using its features is free ;-) ).

I think it would be quite a bit of pain having to implement all this yourself for a headless server. On the other hand, if the headless server could connect a "Unity standalone game server" (or multiple such servers) with the clients, that probably would be a very nice, flexible and efficient set up...

Sunny regards,
Jashan

 

This does bring up an interesting question, though, that I will probably run into in my game.

Is it possible to pass objects through Scenes?

So if I have a NetworkConnection object, I'd rather not destroy and rebuild it when I switch scenes. I'd also rather not just throw everything into one scene, either.

(I am not using RakNet at all, but rather using .NET sockets to talk to my external server.)

 

Looks like this may be the answer to my question:
DontDestroyOnLoad()

 

Actually, since 2.1, you have two possibilities: One is the DontDestroyOnLoad(), which you would use if there's a few specific objects you'd like to keep. The other is using Application.LoadLevelAdditive(...), which you would use if you want to keep most stuff and just "manually" remove specific objects.

Personally, I found it a good practice to have "root game objects" in my level-scenes which are the parent of every game object in the scene. Reason is that I'm loading all scenes into my server at startup, and it would be an incredible mess if I had a lot of objects in the root level of every scene.

If you follow that approach, it's also very easy to destroy the scenes exactly at the point in time when you need it, simply by destroying the scene root-object.