PU 3.5 Available

Started by Jamoe, April 18, 2019, 12:50:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Galatoni

"Forewarned is forearmed"

Jamoe

So seems my launcher had cached some old details and was showing an older version of SC was installed. If you get that try the following.

QuoteGo into C:\Users\YOUR_USERNAME\AppData\Roaming and delete the rsilauncher folder, then start the launcher again. That did it for me.

albert

Same happened with me, thanks for the suggestion. I spent a little time in the game on Saturday and I'm happier with the reliability and performance. I had a couple of niggly issues, loading bay door refused to close and I couldn't get out the pilot seat, so rather game breaking but I think the game is looking really nice.
Cheers, Bert

Lysander

Great to see you folks getting into 3.5 :)

Obsydian

Quote from: albert;437464Same happened with me, thanks for the suggestion. I spent a little time in the game on Saturday and I'm happier with the reliability and performance. I had a couple of niggly issues, loading bay door refused to close and I couldn't get out the pilot seat, so rather game breaking but I think the game is looking really nice.
Yeah the game is still quite a bug fest, but it's probably the most playable it's ever been.

There was a live patch drop earlier this week which fixed quite a number of things, but I'm not sure if any of the items you mentioned were among them.

Britizencon was held this last weekend, and Bored Gamer got to speak with some of the devs and, more importantly, Brian Chambers, and apparently server meshing is now becoming CIG's most urgent feature...

Currently the entire PU is being hosted on a single server, and they have reached the performance limits of that server, which is why they haven't increased the player cap for a while and the AI glitches out so badly so often.  This poses a problem for them as they need to squeeze another planet and two moons in by the end of the year, so they're planning on temporarily using 'static' server meshing.  This involves splitting the system across several servers, with perhaps one server per planet.  The 'borders' for each server will be in remote space, and entities (i.e. ships) will pass between servers as they cross those borders.  This ought to improve performance, and also allow the player cap to be increased significantly.  Although it's not on the roadmap, they're working on this right now, so with any luck we should have this in by the end of the year.

'Dynamic' server meshing should follow later next year, and should allow all of us to finally play in what appears to be a single PU.

albert

I'm trying to work out the difference between static and dynamic. I would think static is what Atlas have with a set set of Islands and Sea in set area. Dynamic is where the same location on many servers and the server population is based on interaction and proximity.

To be honest if they simply had a little delay whilst transitioning between servers then the feeling of scale would be achieved. Elite manages it by having a jump effect where the player can only interact with the ship h controls but not actually influence movement.
Cheers, Bert

Obsydian

Quote from: albert;437556I'm trying to work out the difference between static and dynamic. I would think static is what Atlas have with a set set of Islands and Sea in set area. Dynamic is where the same location on many servers and the server population is based on interaction and proximity.
Static, in the sense I have used it, means that there would be a group of, say 3 (could be more), servers serving a single instance of the PU - like it currently does, only instead of there being only one server (as at present) there will be a separate server for each 'area' (maybe planet and its locale?).  As players quantum between planets and stations, they are handed off from their starting server to the destination server.  Player cap would probably be around 150, so the instance you get assigned to will still be as at present, based on your party and/or location.

Dynamic - the final phase - would be where there would only be the one instance, so everybody will be playing in the same PU, and servers will be spun up as player concentration increased, or spun down as player concentration decreased.
E.g.
 
  • A group of 5 players are in a remote asteroid field that is being managed by its own server.
  • Another group of 5 enemy players quantum in, joining them in their server.
  • A call goes out and the original group's friends arrive mob-handed, with 50 additional ships - a second server spins up to handle the additional ships, and the two servers communicate between each other as to the location of the ships and other objects so that all the players can see those objects (that are in visual range) regardless of which server they are on.
  • A group of 25 ships breaks off and flies towards the 5 interlopers - as they do so, they are 'handed off' from the second server to the first.
  • The 5 interlopers make a run for it in all directions, each followed by 10 ships.
  • As the groups of ships spread further and further apart, 4 more servers are spun up to cater for each group, and each group is handed off to its own server.
  • The now-empty server that the 50 came in on is spun down.
  • The original server with the original 5 friendly ships is left untouched.

This is how they plan to allow almost unlimited numbers of players/ships in a given area: the area is subdivided again and again as player count increases, and then merged again as player count decreases.  So a room could be a single server and as more and more players entered the room, it could be split into 2, 3 or more as required in order to keep the server ticks high enough; and as the room empties out, the servers would be merged and the redundant ones spun down.

Between the 'Static' and the 'Dynamic' stages mentioned above, I fully expect them to have a half-way house version, i.e. the instanced model that we have now, but with each instance using dynamic server meshing; this would also have a much higher player cap - say 500 - to test out the tech and get it singing smoothly before unleashing the full 'one PU' version.

albert

Nicely explained. It seems like a very good approach not just for user experience but for their financial efficience in AWS. Spinning down unused instances will save a load of money.
Cheers, Bert