RPCs are always guaranteed to be reliable, independent of the network view mode.
The network view mode only impacts the component that it is observing.
does the behavior for your game change if you set the network view to delta compression (that could rule out potential message routing / dropping issues).
Also, are you using Network.Instantiate or an own network viewid alloc setup?
And most important: I assume that all prefabs that contain network code are the same between client and server so you have both in the same project but with distinct monobehaviours or isServer / isClient switches? (I’m asking because otherwise the network ids wouldn’t be the same and it would fail but I guess you would have seen and fixed this as it paints the editor console red basically. None the less I think its important to mention it.)
Don’t remember seeing any lidgren based games, but thats nothing that really surprises me, as the amount of non-unity networking games that are released or close to release can be counted with one or two hands, that includes projects with all 5 potential options.
I altered Mars Explorer from utilizing Network.Instantiate to utilizing custom network installation routines a couple months ago due to Unity’s extremely poor internal RPC buffer handling, and the NetworkView problem existed before and after the change. Misconfigured NetworkViewIDs are definitely not the issue with this serialization bug - I have never experienced any difficulty sending or receiving RPCs on the NetworkViews that refused to serialize data between the server and other connected clients.
I hope to release a new Mars Explorer version today or tomorrow that will be able to switch between RPCs, unreliable BitStreams, and reliable BitStreams in game to directly compare the performance of each.
RPCs actually can not fail without the whole network connection failing as they are reliable UDP.
They are sent until they succeed or the application goes down.
Will be interesting to hear about any potential change from the modifications.
After experimenting with a test Mars Explorer build that can switch between reliable serialization, unreliable serialization, and RPC calls, I have two interesting new developments to report.
First of all: on my dedicated server (which I hadn’t changed any code on for a couple weeks prior to my testing today), my Mars Explorer dedicated servers reliability has been getting worse and worse - and it’s now to the point where NetworkViews NEVER serialize under any circumstances in games that are hosted by a dedicated server. Today I uploaded a new version of my dedicated server code and restarted the server - and it didn’t help the problem at all. If I host a dedicated server on my computer, it seems to work great. If I host the exact same code on my dedicated server, the NetworkViews of connected players DO NOT serialize. I have no idea why the problem has been getting so much worse of late - but I will be experimenting further.
Secondly - and even more pathetic: The NetworkMessageInfo.Timestamp of RPCs sent from one client to another through any of my dedicated servers hosted on my dedicated server is always completely messed up. In all the RPCs my game client receives, Network.time - info.timestamp is equal to a number in the negative thousands. There is no explanation for this that I could imagine other than yet another fundamental bug in Unity, and I somehow feel that it is related to all the other bugs that have been plaguing my networking endeavors.
I am building a system to compensate for the RPC time bug, and will then post a link to my test Mars Explorer build so that everyone can experience what I am discussing firsthand.
It’s relatively easy to set up. Encoding and Decoding messages is only slightly more effort.
I even went so far as to create a basic lidgren master server that does NAT introductions. UDP punch-through appeared to work well on the test environments I had available to me.
Although you might have a bit more initial coding, in the long run I think you will have more control with lidgren based networking.
Allright - my latest Mars Explorer build is online, but it isn’t perfect as I haven’t yet been able to reliably determine the time each positional update RPC spends in transit from one client to another (so my interpolation logic is currently assuming that players have no latency when the game is in RPC networking mode). For those who are interested, here is Mars Explorer 2.13. The "Host Game >> " button will connect you to a dedicated server by default - you can host a game directly from your client by disabling the “Utilize dedicated Servers for hosting games” option in the Server Settings at the bottom of the lobby window. When in a game, the “Active Players” panel will show you a bunch of diagnostic info on each player in the game. When you are the game’s Host, you can adjust the game’s networking settings in the Server Settings panel. The settings should be self explanatory for networking experts, but I will be glad to answer any questions. Of particular interest is the complete inability of Unity to serialize the player’s NetworkViews in UDP (unreliable) or RDC (reliable) networking modes when the game is connected to a dedicated server. Interestingly enough, the packet serialization works intermittently and the RPC timestamps aren’t completely messed up when Mars Explorer game clients are connected to a dedicated server running my dev computer and not my dedicated server. I would be glad to share the source of my dedicated server implementation if anyone (especially Unity) would like to investigate it.
I am baffled by all the bugs that I find at every turn, and by Unity’s complete lack of support. Does Unity systematically ignore anyone who attempts to build anything using their networking? They have been such a great company in every other aspect that I keep expecting them to at least officially respond - but where are they?
2.13 is an alpha build that is packed with minor bugs and isn’t anywhere near release quality yet, but I am on track for a final release on Christmas day that will include much more than you see now.
The “Sea” is based on Unity’s Island water, with a bunch of tricks that I may get a chance to include in the Sea object of the Whirld 3 release. It currently includes “tropic” and “lava” modes, is easily customizable to any desired look, and it is packed in the game and not individual worlds - so I will be able to keep improving it as technology marches on. The sea physics are really simple - I just assign a bunch of points on each vehicle, then check if each point is submerged and add some forces to it accordingly.
My latest networking code sends a “ping” rpc between clients every 5 seconds or so, divides the round trip time by two (it doesn’t know what the time is on the other client - but it can at least compare the time it receives the return RPC ping with the time it sent the request RPC ping), and then feeds the resulting time to my interpolation code as an estimated player lag. If anyone has a better idea for determining the actual lag of each positional update RPC, I would love to hear it!
Again it is amazing! You should add a better AI script. But by better you should add AI that can do all the things the player can do like with the buggy, how it has the glider, you should have the AI able to use that. And have the AI be able to switch their vehicle. Or at least have the vehicle be randomized.
Dude the sea piece rocks, although I haven’t seen anyone yet get a real feel for the tires on any surface in Unity, always get that sliding on ice effect in every game ever made with Unity, no real “grip” feel.
I know exactly what you mean Zumwalt - my high speed offroad tire physics are decent, but at low speeds, the buggy has a tendency to drift sideways much more than it should. I will work on that in future releases. I have been experimenting, and I think the problem can be addressed by fine tuning the distinction between my “static” and “dynamic” tire friction modes, and significantly increasing the friction available in the static mode.
I have AI enhancements planned Freeland, but you have to remember - Mars Explorer is all about having fun with your friends. There are 30 or so players on the release version right now, and they are much more fun to play with than any bot ever could be
I’m only saying it would be more challenging if the bots were different. Ya know, mix 'em up a little. But I love the multiplayer thing and I understand the fun with friends and that’s one of the only things I did yesterday. But my friends and I really wanted to have a “Human vs. CPU Match” kinda thing. Ya know?
HiggyB has promised to send a Unity networking developer in the direction of this thread any day now, and we may have the opportunity to get all the issues discussed here isolated and resolved.
I have been hard at work on Mars Explorer, and the latest version hosts it’s dedicated servers on Amazon’s Elastic Compute Cloud and includes the capability for server hosts to specify whether player positions are transmitted via unreliable bitStreams, reliable bitStreams, or RPCs.
When in RPC mode, everything works but the lag is just about unbearable.
When in BitStream mode, the lag is still higher than I would like - but everything works pretty nicely 'till the non serialization bug surfaces after a random amount of time and destroys the game for everyone.
Unity: I have clear demonstrations of several issues in Unity’s networking, and thousands of players who are suffering from them in my game and would love to help get them resolved. I can’t wait to share my networking code with you, and anything else I can provide to help isolate these issues. You owe it to yourselves to either stop advertising that Unity provides full featured integrated networking, or to spend a little time to fix it’s bugs and make it usable.
Unfortunately - another week has gone by and Unity’s unresponsive tendencies have continued to be demonstrated.
I have now despaired of trusting Unity to support any aspect of their engine, and have officially given up on Unity’s builtin networking library.
If you are thinking of building something real with Unity’s networking, think again. It will almost work in many different ways - but the more popular your game will become, the more spectacularly it will fail - and the less support (or even acknowledgment) you will receive from the company who advertised the system as fully functional and who you trusted.
I don’t want to sound bitter - it’s just that Unity has been such a wonderful company in all other areas I have observed that I am honestly baffled by their behavior in regards to these issues.
Thanks to all of you who have encouraged and aided me.
I have been experimenting a bit with Photon - but although it does look pretty slick, it’s design principles weren’t quite what I had expected. (After being accustomed to the likes of OnSerializeNetworkView and BitStream.Serialize, NPeer.opRaiseEvent just sounds so foreign ).
Lidgren looks like it may be a perfect solution for me, and I have just begun writing a dedicated server in c# using MonoDevelop that will be deployed on Amazon’s cloud, and which will launch and maintain multiple Lidgren server threads to host each game in Mars Explorer. I even plan to have a “lobby” server thread, which will provide a global chat and master server functionality for players who haven’t joined an active game.
I am looking forward to rewriting Mars Explorer to utilize lidgren, and will keep everyone posted on my progress!
Just so you know you’re not alone in the dark, Robur…
I corresponded with Higgy on this issue last month around the 22nd. He stated that he was aware of the various threads and concerns, that he had asked for the dev team to join the discussion. In his words, “asked them to step in post-haste.”
That was obviously a little bit before you made your post, declaring you had a similar conversation and a similar claim of ‘help is on the way.’
At this point, I’m starting to wonder what ‘post-haste’ translates to in Danish. :roll:
Just to let you know, I’ve requested a visit from a UT tech person to this thread and I’m now authorised to press it until it happens. You should get a response soon.
