Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Multiplayer development (features, status updates)
(12-15-2016, 02:02 PM)only_a_ptr Wrote: BUMP!

The current serverlist receives criticism for not recognizing restarted servers:

I checked old sources (both server and `` serverlist by TDev) and I'm under impression it always worked this way. Can anyone with actual experience comment on this?

Additionally, if I were to implement this "restart tolerance", there are 2 ways:
A. Make the serverlist recognize restarted server by name+IP+port. Not bulletproof, but simple to code.
B. Make the gameserver save it's serverlist-token locally and re-send it on restart (if present). More work, but bulletproof. The token storage could be a tiny JSON file (one per server) with name: "token_[sanitized servername]_[IP]_[port].JSON"

From my experience, the old way just registered your server as a 'new' server every time. Sometimes it would even show your server multiple times if you restarted it too often (you could see 5 of the same server on the old server list). Then after about 60 seconds, the old entries would go away (not always). However, it would not stop you from registering it again.

I also think option B would be better. Smile
I'm working on getting the multiplayer back in a workable state.

The masterserver at is currently not operational because the masterserver is on virtual hosting and rorserver isn't able to register there. More specifically, the registration itself works, but the subsequent masterserver->rorserver verification routine is failing. I'm checking whether I can make it work under current conditions. If not, I'll make a temporary solution with masterserver hosted elsewhere.

First I checked the serverlist. There was a bug in heartbeat processing - some servers may be discarded as offline although they live. I fixed it and made a couple other improvements. I also added a stub portal page:

I also checked the rorserver. It's been reported not to unregister correctly on shutdown. I discovered that, on Windows, the only way to shut down cleanly is to press Ctrl+C with the console open. Pressing Ctrl+Break or simply closing the console window would cause abrupt termination and the server won't be unregistered. Fix is in progress: Techy note: I'm actually refactoring the whole signal handling because it doesn't meet Microsoft's limitations on signal handlers: Also the code had duplicate shutdown logic (messy).

Thanks for your patience.
[-] The following 6 users say Thank You to only_a_ptr for this post:
  • DevoutRain2500, DirtGamer301, Disloyalpick, Michael10055, Ton03, Vido

I have some progress:

Techy details: Dealing with shutdown on Windows gave me hard time. Traditional un*x signals are limited to uselessness: It took me a while to find the working approach:

Anyway, with this out of the way, I can hopefully start debugging all the MP crashes tomorrow.

Stay tuned.
[-] The following 7 users say Thank You to only_a_ptr for this post:
  • Crewdz, DevoutRain2500, Disloyalpick, Michael10055, Sean, Strykr, Vido

RoRnet protocol version jumped to number 2.40:

Reason: before I started debugging the MP crashes, I took a close look on the RoRnet source and I discovered it's not coded right: The format of network packets may slightly but signifficantly vary depending on platform/compiler/compiler version it was built with. There are 2 causes:
  • in C++ language, not all data-types have fixed binary size. Some are defined by compiler(+version)
  • C++ compilers may insert padding bytes in data structures for performance. This can be controlled both in code and in compiler options, but the defaults vary.
Fix: I used only data types with explicitly defined sizes , and I enforced packing of data structures (no padding is inserted)

I didn't have time to test yet.
[-] The following 5 users say Thank You to only_a_ptr for this post:
  • DevoutRain2500, Disloyalpick, Michael10055, RoR_Boy_940, Vido

Yesterday I tested MP and soon crashed on reconnect with message like "Animation 'Idle_sway' somehow doesn't work". It turned out to be a quite messy matter - characters are not properly deleted when disconnecting from MP. It's a historical problem - when RoR had no menu, there were no disconnects, and thus no cleanups. Later it was added, but it's dirty code. I'm not sure if the problem is in character code (doesn't clean up properly) or networking (doesn't disconnect properly) - probably both. Also, the character has it's own network messages, and they're as flawed as RoRnet 2.38 was (see my last post).

Solution: my favorite kind... a refactor! Work in progress: The characters will all load when user enters simulation (be it single or multiplayer) and unload when user exits simulation. Simple and straightforward. And while I'm at it, I'm coding it the NextSim way: separate game logic and OGRE objects. I'm not touching networking at this time... if the problem is there, it'll become obvious later.
[-] The following 3 users say Thank You to only_a_ptr for this post:
  • Michael10055, Sean, Vido
(01-06-2017, 11:10 AM)only_a_ptr Wrote: Clip

I know this a bit stupid of a question... but if you've ever played games like Garry's mod or something after a while it cleans up (there is a command) of like broken objects and etc... would this be possible to introduce to MP so after lets say 3 hours it cleans/restarts the server with a given warning?
What Nvidia wants us too see: "NVIDIA, The way its meant to be played"
What we actually see: "NVIDIA, The way we want you to play"

(01-06-2017, 07:08 PM)Sean Wrote: ...Garry's mod ... so after lets say 3 hours it cleans/restarts the server with a given warning?

I know Garry's mod, but never played it.

Anyway, what you're suggesting makes sense and it should be doable via scripting. I can't give you more info right now - the scripting interface in rorserver isn't documented ATM and I'm not sure it can restart the server this way. But it can be added.

And never be afraid to ask questions, that's what this thread is for.

---- Status update ----

I got bogged down in code refactoring. We got a lot cleaner bootstrap/main menu/game pause/shutdown code. Ulteq's going to love it when he comes around, he suggested it a while ago already: But my rewrite of player characters was a fail (damn code-rewrite enthusiasm!), so the "Idle_sway" crash is still there ATM. Blush Starting over at 20:00 UTC today.
[-] The following 2 users say Thank You to only_a_ptr for this post:
  • Sean, tritonas00

As promised, I took another shot at fixing the multiplayer. So far so good, the "Idle_sway" crash on reconnect is gone:

Tomorrow I'll start crash-testing the new code.
(01-09-2017, 12:20 PM)only_a_ptr Wrote:  Starting over at 20:00 UTC today.

Great news I was thinking for a moment that "idle_sway" have samething to do with animation itself but Im not that lucky. Cheers and good luck Smile

Forum Jump:

Users browsing this thread: 1 Guest(s)