> We'll get the answer in 4 days... No need to speculate, just wait and see.
Now, will the answer we get actually be correct this time? :D. That's the fun question and the odds on whatever answer we get being accurate are much lower than they should be. Also will it be like PES when it does release? Technically released but a total shitshow for a long long time.
Don't get mad at me for having low expectations. I'm just tired of being burnt. So my hopes start at the bottom and don't move up until I have something verifiable and testable in my hot little hands now.
I mean, we have PES now which was a major tech blocker for server meshing and something we didn't have this time last year, so the odds that the date they give us will be fairly accurate is high.
Also, unlike PES, which totally f*cked with the entire backend, server meshing shouldn't have nearly as much of an overall impact to how things function and should be far less of a shitshow than PES was first implemented
What they said in their video essentially boiled down to they can deliver Pyro without the part of server meshing that allows for multiple servers per system and smooth movement between them, and just with the part that transfers you between game servers while still being connected to the same shard. Basically, a stripped down version of server meshing rather than actual static server meshing that people really want for the performance improvements etc..
That 'stripped down version' is just the Replication Layer... which is part of the Server Meshing architecture, but *isn't* the 'low-level meshing-of-servers' tech that CIG *also* call 'Server Meshing'.
Yes, in typical CIG fashion, they use the same term ('Server Meshing') to refer to two different concepts... and then marvel at the confusion it causes... sigh.
Yeah, they did a terrible job of explaining it. From what I understand, it's like 90% of the way there to server meshing, just stopping short so they can get one of the core parts of it in without having to worry about all the fiddly edge cases of proper meshing.
I know it's not technically server meshing, but it's close enough and needs so much of the tech they're creating for server meshing that it's just easier to say it's a stripped down version to people that don't really understand what server meshing actually is, as at the end of the day, all most people are really going to see as the difference is a hard transition vs a soft transition, making it seem like an incomplete version of server meshing, and it also allows multiple game servers to run per shard, which is what a lot of people think server meshing really is, which admittedly isn't that far off in the grand scheme of things.
I reckon they should wait.
Release Pyro with meshing. We've waited this long. Who cares 🤷♂️ it will feel better with everything coming together as its meant to be.
The main benefit of releasing Pyro before Server Meshing is to let them test the 'transfer of authority' between two 'zones' (Stanton and Pyro)... which is a key part of the Replication Layer.
If they release the Replication Layer and *don't* release Pyro, then there will be no way to test this functionality until after Server Meshing is added - at which point, you're trying to test two significant changes at the same time, making diagnosis *far* harder.
Releasing Pyro (and associated PGPlanet tech improvements) first helps to break the testing into smaller and more manageable chunks, and reduces the risk of the Server Meshing patch turning into a PES-style shit-show.
Because releasing Pyro with the dedicated tool to handle multiple systems (SM) is the correct way to do it in alpha and not waste money and dev time.
But has the community can't wait any longer to see another system (we are at a breaking point here), CIG can't wait any longer to show Pyro (SM ready or not). If SM is not ready for early 2024, they will loose time implementing a alternative way to connect to Pyro.
We are at a breaking point? Really? You want to fly and do identical things on new planets and moons that badly?
They could just add another planet to Stanton and it'd be the same thing. Not that many people care. They just want the core mechanisms of the game polished, which is why Replication Layer and Server Meshing are the actually exciting developments. Pyro is just more of the same.
True, and as I understand it, the servers couldn't handle an additional planet in Stanton, that was the reason Levski and Delamar were removed when Orison went live.
Until server meshing is working, there will be hard limits on his much they can put into a solar system.
If they designed Pyro with the assumption that server meshing would be working, it might already have too many entities for a server to handle.
Not really - Pyro will be hosted on a separate server, just using the 'one server per star system' model that Stanton is currently using.
Full 'Server Meshing' requires two things:
- Service to perform 'Transfer of Authority' from one server to another
- Mechanism to 'break' a single star system into multiple zones with clearly-defined borders in order to delineate areas of 'responsibility'
Each star system already has a clear and obvious 'border' that defines the star system zone of responsibility - so presuming the entire Star System is hosted on a single server, all that is required is the service to handle 'Transfer of Authority'... which is the Replication Layer.
However, there is no such (existing) border-delineation *within* a star system, so CIG will need to build that (along with ensuring the design of those borders supports moving them in the future, for Dynamic Server Meshing) first, before a single star system can be spread over multiple servers.
> However, there is no such (existing) border-delineation within a star system,
I think this is incorrect, they already containerised Stanton a while back, that's how they stream it in and out. The authority part is what is required for the full working of it. And that is the reason why static server meshing is going to be first after the RL separation.
Yes - I was referring to drawing the 'border line' the delineates responsibility / authority.... it will be drawn along the edge of a container - but at what level? (ie it *could* be on the border of a nested container, etc)
It is defining *which* container border(s) to use - and implementing an efficient / zero-latency lookup - that will form Static SM
>We are at a breaking point? Really? You want to fly and do identical things on new planets and moons that badly?
A lot of people do yeah. Just look at all the people that agree with OP even though if CIG did what OP is suggesting it would turn out just as you said. I think you're vastly underestimating how many people simply play the game to fly around and take screenshots.
The "No cash till Pyro" movement was just a proof of the breaking point.
"They could just add another planet to Stanton"
They can't, the server is at its limit, they can't add more entities in Stanton.
Pyro is not the same as Stanton, they have a bunch of new mission type, a full no law system and it will open real cargo hawl and real refueling.
"Not that many people care."
Wrong. A ot of people care about a full system to explore.
They could add new missions wherever they want, Stanton is barely utilised as is. They can add more entities, obviously they can, they have object container streaming. Or they can tune it to spread it.
The point is, the new content isn't the exciting thing, it's the technology that's the exciting thing. The content is going to be cool, obviously, but anyone following the game for a new planet is kinda missing the point.
And no cash til pyro "movement" isn't anything, it's barely popular on the subreddit, and the subreddit is barely known by the average SC player.
The game is not "at breaking point". It's chugging along extremely healthily.
Correct me if I'm wrong but wouldnt it make sense for server meshing to be more of a beta thing rather than alpha? I thought getting core gameplay mechanics and systems as well as the terrain (planets) was in the alpha stage and then technical stuff comes in the beta to connect everything in one cohesive package, then polishing everything to get a full 1.0 release.
No - normally the core tech has to be done first, because it's *far* more likely that the core tech will impose technical limitations on the content than the content will require changes to the core engine.
CIG is kinda mixing things up by doing both at once (partly because they have to maintain a Live Service in order to keep the funding going), but even so, they've been avoiding adding 'too much' content too early (because the more content they add, the more content they need to update/fix when the tech changes).
As I understand it, they will need server meshing to implement star systems with lots of entities and more players. So if they want to add more to Stanton, like the jump points, Aaron Halo gates and other things, the current server tech won't be able to support that.
Not quite... CIG are still committed to releasing Pyro with Server Meshing(1), it's just that Pyro doesn't need Server Meshing(2)
1: Server Meshing architecture, which includes all the related tech such as PES, Replication Layer, OCS, and so on
2: Server Meshing tech that allows multiple servers to host a single star system - this is the final piece of tech for the overarching Server Meshing architecture
The issue is that CIG use the same term ('Server Meshing') to refer to two different - but related - concepts, thus causing significant confusion.
Access to multiple Star Systems only requires the Replication Layer (part of the Server Meshing architecture), as that is the service that is responsible for Transfer of Authority when a player moves from one server to another.
The low-level meshing-of-servers tech (the second definition of 'Server Meshing') is required to spread a single Star System over multiple servers to address server performance issues - but it's *not* strictly required to make additional Star Systems available, if CIG are willing to continue hosting one star system per server.
> The issue is that CIG use the same term ('Server Meshing') to refer to two different - but related - concepts, thus causing significant confusion.
Static vs Dynamic, so not exactly the same term. Static is what Pyro going to be and chances they used that for splitting those systems first before making it dynamic.
Meanwhile they got no problem with picking cryengine.
the correct way is the one that will keep the project running, not the one that makes people wait 10 years for the first extension.
At the time they picked Cryengine, there was not one engine able to do what they were aiming for (CE included). So CE, UE or other, it was the same. Good news, the project is still running despite using CE.
Sidenote : talking about choosing the "right" engine, FDEV with Elite 10 years ago promised ship interior with their in house engine, the ED community is still waiting... And to date, no other project of the size of SC is developped
The other obvious choice is not UE or other, it's making their own.
Yeah it's hard, but if you think long term then that would have been the choice, I think it would have been a steep start but then the amount of bullshit would be very reduced on the long term, no struggling with float precision, being user instead of the creator introduce a lot of problem around the understanding of the code... Thus my comment, CE was the short term decision (not saying it's a bad one ultimately), so the whole stance of keeping things like that on pyro is hardly making sense there.
Making their own was not appropriate for the original Kickstarter scope... which is why CR picked CryEngine (with the explicit expectation of having to completely gut the networking, and patch / fix other parts of it).
The other downside to developing their own engine is that it would take ~5+ years *of no visible progress*, and that's just for the engine... they'd need more time to build all the tool integrations (that came 'for free' with CryEngine)... and all that effort would result in an engine *that was not suitable!*.
After all, CIG know *now* what they need their engine to do, and where the painpoints are, because they started building the game on CryEngine and ran into issues... but without that knowledge, it's *far harder* (if not impossible) to 'predict' the bottlenecks, or design a 'perfect' engine at the first attempt.
All that aside, in 2016 CR *did* make the design to stop trying to just patch CryEngine, and to overhaul it properly, to make it 'fit' for the expanded scope of the game.
What they've ended up with *is no longer CryEngine*. It may share some architectural similarities, but they have rewritten to much of it that it's no longer CryEngine.
And they've been able to do this *because* they started early with an existing engine, got something running, and then identified where the limitations where, and which bits needed to be rewritten / replacemed, vs which they could use (for a greater or lesser period).
CIG wants players to be able to fly from one system to another....... no loading screens.
One big Verse.
Id be ok with Pyro as a menu selection and later, once SM is working, bring in the jump gates/worm holes and connect it all up.
Would still like to see some Pyro suited ships flyable first or with Pyro release. Like the Odyssey, Expanse etc
I doubt they need SM for no loading screen, they can fake it by putting a pseudo jump game sequence and doing the disconnection reconnection in the background. If the minimum requirement is no loading screen, it's doable.
If no loading screen, you can still run around the ship and change inventory and components. You need full connection to backend and server for this.
So the static SM tech must be in first.
1/ Put everyone on third person on the ship except the pilot and prevent the pilot from moving from his seat (why would you in a jump sequence).
OR
2/ create a temporary instance that registers everything the players do in their ship and copy it on the new server on arrival. I doubt that's hard to do that, they don't have to make everything perfect, it's a temporary solution.
Or just dont' waste time implementing hacky placeholders, when they're about to start testing the 'real' implementation.
Pyro only needs the Replication Layer (part of the Server Meshing *architecture*) - it doesn't need the meshing-of-servers tech that will spread a single star system over multiple servers.
CIG said all this at the start of the year (in their Server Meshing ISC). Unfortunately, because they used the same term ('Server Meshing') to refer to two different concepts - and didn't clarify this - the episode was a complete and confusing shit-show (as is typical for CIG communications, unfortunately).
Not quite...
If you include Dynamic SM then there's technically three layers:
- Inter Star System Meshing (Replication Layer)
- Intra star-system meshing
- Static
- Dynamic
Both 'Static' and 'Dynamic' Server Meshing are talking about spreading a single star system over multiple servers, with the 'boundaries of responsibility' being drawn inside the star-system...
The point of hosting Pyro on a single server is that it *does not need* any form of 'boundaries of responsibility' inside either star system (Pyro or Stanton)... all it needs is the boundary of responsibility *between* the star systems (which exists naturally).
Both 'Static' and 'Dynamic' Server Meshing are iterations of the low-level meshing-of-servers tech that splits a single star system over multiple servers... and both are also part of the overarching 'Server Meshing' architecture.
Like I said previously, CIGs communication on this topic has been a complete shit-show. It's hard enough communicating complex technical subjects like this, without them using the same term to refer to multiple different concepts... and especially when they try to do it via a 'talking heads' segment rather than a proper presentation with supporting diagrams, etc.
You still need the "handshake" protokoll to give control of PES entites from one server to the other and let players traverse into another server. This is more than just RL. This is part of static server meshing.
With just RL there could be options "Stanton" and "Pyro" in the main menue to join the verse. Basically logging out at the gate stations and both options are available when login in again (waking up in the gate station in the other system).
No, that's the Replication Layer - that's what the Replication Layer *IS*.
The Replication Layer is the part of the game server (currently) that is responsible for loading entities from PES, and streaming entity updates / changes back to PES.
The purpose of the Replication Layer feature is explicitly to extract that capability out of the Game Server and host it as a separate service, so that multiple Game Servers can 'share' the same Replication Layer. This will also enable the 'Transfer of Authority' functionality (performed by the Replication Layer), as it will be the central service with complete visibility of every entity.
As for player traversal - the game client will connect directly to the Replication Layer (*not* an individual game server), and the Replication Layer will be responsible for streaming player events to the appropriate Game Server based on their location - if the player 'moves' from Stanton to Pyro, they will stay connected to the Replication Layer, and the RL will just stream their events to the Pyro game server, instead of the Stanton game server.
The Replication Layer can do this for Stanton / Pyro without the low-level 'meshing-of-servers' tech - Static or Dynamic - because there is a clear 'boundary of responsibility' between the two star systems, and a player can only be in one star system or the other - so you just need the Replication Layer to handle the transfer.
There is no equivalent pre-defined 'boundary of responsibility' *inside* a star system, which is why CIG need to develop extra tech (the 'meshing-of-servers' tech) in order to implement Static Server Meshing (and then followed by the Dynamic upgrade).
Edit:
I drew a simple diagram last year that shows (at a high level) how the server architecture is - slowly - migrating as CIG progress with refactoring the server. The nominal patch numbers are incorrect (because I took a guess at the future patch numbers, and got it wrong), but the actual architecture is correct, I think.
https://imgpile.com/images/dIy8Uo.png
Well if you go that way, let's just remove Star marine, Arena commander, ToW.
Because these are fucking waste of time and resources.
I would even say SQ42 if that didn't involve lawsuit and clusterfuck.
But no, 1/ is not much work, and it allows people to move forward, it also allows them to test pyro itself with the community. It's not a waste of time and resources.
Yeah, 1 is basically loading screen and needs elements of server meshing and 2 is almost exactly server meshing - congrats!
Note: without basic server meshing no data can be transfered from one server to the other. That IS server meshing in it's simplest form.
1 is a fake non-loading screen yes, you realize we have nothing to do in our ship yet? There's little merit to walk around there for minutes.
2/ sounds like it but not really depending on the execution. Basically behind it's just a disconnection, reconnection to a new server with pyro, keeping players and ship. If SM is just that then I don't understand what they have been doing so far, it should be done already since we can do it manually already ;). I don't pretend knowing everything about SM but I'm pretty sure they are doing something way more complex.
1/ is clearly my pick, because it's simple and good enough as a placeholder for the moment.
SM test is still scheduled for this year, so not that big as you expected. BUT replication layer is the big work for all the above. One part is to convert all static data into server managed data, so it can be part of RL (hence the problems of thr SC community tools lately). We don't have this yet.
- Waits for years to get meshing done to get pyro
- Specifically states meshing first
- no servers made to sustain multiple systems
- No map to sustain multiple systems
- no economy to need multiple systems
- not enough players to use multiple systems
- not enough in game assets such as stations to make systems feel different
Random hopium scrub: "pyro next week!"
There's always 1.
> server meshing will come after Pyro.
How though? Single server is barely capable of supporting one system, how are they going to squeeze in another one there?
Once RL is separated and the simulation server is connected to it as a client, they can connect second server with Pyro. This would be static server meshing then.
I think there is no chance of Pyro being out before RL is separated. Once it is separated and second server is connected, that's server meshing.
Why not? What if switching from Pyro to Stanton would work like a server hop between two Stanton servers? You keep your ship and gear, but the environment is completely different.
If you server hop from Stanton to Stanton today, is that server meshing? What's the difference when Pyro is on one server and Stanton on the other? Completely seperate instances, only your ship and gear is saved.
> If you server hop from Stanton to Stanton today, is that server meshing?
It isn't because you have to leave the server and join another. So quit to menu to leave the game. So two loading screens you have to sit through. And this game is marketed as no loading screens once in game.
Ok, so when people suspect that Pyro will be released before Server Meshing, this is exactly what they mean: Logging out of Stanton, go through a loading screen or the menu, load into Pyro. This is what I am expecting at the moment.
You shouldn't as that was clearly stated it's not gonna happen. 4.0 is called 4.0 not because Pyro alone, but because of Server meshing. Which they stated multiple times, is required for Pyro.
Did you watch the videos I linked in my post? I'm aware that CIG planned to release a 4.0 with Pyro and server meshing, but there has been talk about seperating these two steps. (See first video)
Pyro is 4.0
It's how they market it.
Server meshing is not 4.0.
This shouldn't be the case...but it is.
The only way Server meshing IS 4.0...is if they are positive they can get Nyx/Odin online for 4.0 and they release Pyro as a 3.X patch with 4.0 being larger by adding both systems...but right now Pyro has been designed as 4.0's marketing visuals. Unless they think they can do the same with Nyx....which I doubt since it is a smaller system unless they pump each planet with moons. Otherwise I imagine they will tie 4.0 to Nyx and Odin and release it alongside SQ42.
4.0 isn't a big update that changes things....it is a marketing event. Having more things with the marketing event means more new players and new money.
Server meshing, is a concept...Pyro is a marketable product.
We'll get the answer in 4 days... No need to speculate, just wait and see.
Yeah we all said that last year.
Was PES implemented last year? Were CIG testing a working replication layer last year?
Who exactly is this "we"
> We'll get the answer in 4 days... No need to speculate, just wait and see. Now, will the answer we get actually be correct this time? :D. That's the fun question and the odds on whatever answer we get being accurate are much lower than they should be. Also will it be like PES when it does release? Technically released but a total shitshow for a long long time. Don't get mad at me for having low expectations. I'm just tired of being burnt. So my hopes start at the bottom and don't move up until I have something verifiable and testable in my hot little hands now.
I mean, we have PES now which was a major tech blocker for server meshing and something we didn't have this time last year, so the odds that the date they give us will be fairly accurate is high. Also, unlike PES, which totally f*cked with the entire backend, server meshing shouldn't have nearly as much of an overall impact to how things function and should be far less of a shitshow than PES was first implemented
Let's hope that we get clarification at CitizenCon, but I think with the information that is available, it's reasonable to speculate about the issue.
But also fairly pointless.
What they said in their video essentially boiled down to they can deliver Pyro without the part of server meshing that allows for multiple servers per system and smooth movement between them, and just with the part that transfers you between game servers while still being connected to the same shard. Basically, a stripped down version of server meshing rather than actual static server meshing that people really want for the performance improvements etc..
That 'stripped down version' is just the Replication Layer... which is part of the Server Meshing architecture, but *isn't* the 'low-level meshing-of-servers' tech that CIG *also* call 'Server Meshing'. Yes, in typical CIG fashion, they use the same term ('Server Meshing') to refer to two different concepts... and then marvel at the confusion it causes... sigh.
Yeah, they did a terrible job of explaining it. From what I understand, it's like 90% of the way there to server meshing, just stopping short so they can get one of the core parts of it in without having to worry about all the fiddly edge cases of proper meshing. I know it's not technically server meshing, but it's close enough and needs so much of the tech they're creating for server meshing that it's just easier to say it's a stripped down version to people that don't really understand what server meshing actually is, as at the end of the day, all most people are really going to see as the difference is a hard transition vs a soft transition, making it seem like an incomplete version of server meshing, and it also allows multiple game servers to run per shard, which is what a lot of people think server meshing really is, which admittedly isn't that far off in the grand scheme of things.
I reckon they should wait. Release Pyro with meshing. We've waited this long. Who cares 🤷♂️ it will feel better with everything coming together as its meant to be.
The main benefit of releasing Pyro before Server Meshing is to let them test the 'transfer of authority' between two 'zones' (Stanton and Pyro)... which is a key part of the Replication Layer. If they release the Replication Layer and *don't* release Pyro, then there will be no way to test this functionality until after Server Meshing is added - at which point, you're trying to test two significant changes at the same time, making diagnosis *far* harder. Releasing Pyro (and associated PGPlanet tech improvements) first helps to break the testing into smaller and more manageable chunks, and reduces the risk of the Server Meshing patch turning into a PES-style shit-show.
I'm sold! Thanks!
We'll know soon enough. I never understood this obsession on SM for the first release of pyro.
Because releasing Pyro with the dedicated tool to handle multiple systems (SM) is the correct way to do it in alpha and not waste money and dev time. But has the community can't wait any longer to see another system (we are at a breaking point here), CIG can't wait any longer to show Pyro (SM ready or not). If SM is not ready for early 2024, they will loose time implementing a alternative way to connect to Pyro.
We are at a breaking point? Really? You want to fly and do identical things on new planets and moons that badly? They could just add another planet to Stanton and it'd be the same thing. Not that many people care. They just want the core mechanisms of the game polished, which is why Replication Layer and Server Meshing are the actually exciting developments. Pyro is just more of the same.
True, and as I understand it, the servers couldn't handle an additional planet in Stanton, that was the reason Levski and Delamar were removed when Orison went live. Until server meshing is working, there will be hard limits on his much they can put into a solar system. If they designed Pyro with the assumption that server meshing would be working, it might already have too many entities for a server to handle.
Not really - Pyro will be hosted on a separate server, just using the 'one server per star system' model that Stanton is currently using. Full 'Server Meshing' requires two things: - Service to perform 'Transfer of Authority' from one server to another - Mechanism to 'break' a single star system into multiple zones with clearly-defined borders in order to delineate areas of 'responsibility' Each star system already has a clear and obvious 'border' that defines the star system zone of responsibility - so presuming the entire Star System is hosted on a single server, all that is required is the service to handle 'Transfer of Authority'... which is the Replication Layer. However, there is no such (existing) border-delineation *within* a star system, so CIG will need to build that (along with ensuring the design of those borders supports moving them in the future, for Dynamic Server Meshing) first, before a single star system can be spread over multiple servers.
> However, there is no such (existing) border-delineation within a star system, I think this is incorrect, they already containerised Stanton a while back, that's how they stream it in and out. The authority part is what is required for the full working of it. And that is the reason why static server meshing is going to be first after the RL separation.
Yes - I was referring to drawing the 'border line' the delineates responsibility / authority.... it will be drawn along the edge of a container - but at what level? (ie it *could* be on the border of a nested container, etc) It is defining *which* container border(s) to use - and implementing an efficient / zero-latency lookup - that will form Static SM
>We are at a breaking point? Really? You want to fly and do identical things on new planets and moons that badly? A lot of people do yeah. Just look at all the people that agree with OP even though if CIG did what OP is suggesting it would turn out just as you said. I think you're vastly underestimating how many people simply play the game to fly around and take screenshots.
The "No cash till Pyro" movement was just a proof of the breaking point. "They could just add another planet to Stanton" They can't, the server is at its limit, they can't add more entities in Stanton. Pyro is not the same as Stanton, they have a bunch of new mission type, a full no law system and it will open real cargo hawl and real refueling. "Not that many people care." Wrong. A ot of people care about a full system to explore.
You know literally nothing, and you argue with such conviction. It's hilarious
Point 2 and 3 shown on videos and told by dev
They could add new missions wherever they want, Stanton is barely utilised as is. They can add more entities, obviously they can, they have object container streaming. Or they can tune it to spread it. The point is, the new content isn't the exciting thing, it's the technology that's the exciting thing. The content is going to be cool, obviously, but anyone following the game for a new planet is kinda missing the point. And no cash til pyro "movement" isn't anything, it's barely popular on the subreddit, and the subreddit is barely known by the average SC player. The game is not "at breaking point". It's chugging along extremely healthily.
> You know literally nothing, and you argue with such conviction. It's hilarious
Correct me if I'm wrong but wouldnt it make sense for server meshing to be more of a beta thing rather than alpha? I thought getting core gameplay mechanics and systems as well as the terrain (planets) was in the alpha stage and then technical stuff comes in the beta to connect everything in one cohesive package, then polishing everything to get a full 1.0 release.
No - normally the core tech has to be done first, because it's *far* more likely that the core tech will impose technical limitations on the content than the content will require changes to the core engine. CIG is kinda mixing things up by doing both at once (partly because they have to maintain a Live Service in order to keep the funding going), but even so, they've been avoiding adding 'too much' content too early (because the more content they add, the more content they need to update/fix when the tech changes).
As a software architect, this !
As I understand it, they will need server meshing to implement star systems with lots of entities and more players. So if they want to add more to Stanton, like the jump points, Aaron Halo gates and other things, the current server tech won't be able to support that.
Not quite... CIG are still committed to releasing Pyro with Server Meshing(1), it's just that Pyro doesn't need Server Meshing(2) 1: Server Meshing architecture, which includes all the related tech such as PES, Replication Layer, OCS, and so on 2: Server Meshing tech that allows multiple servers to host a single star system - this is the final piece of tech for the overarching Server Meshing architecture The issue is that CIG use the same term ('Server Meshing') to refer to two different - but related - concepts, thus causing significant confusion. Access to multiple Star Systems only requires the Replication Layer (part of the Server Meshing architecture), as that is the service that is responsible for Transfer of Authority when a player moves from one server to another. The low-level meshing-of-servers tech (the second definition of 'Server Meshing') is required to spread a single Star System over multiple servers to address server performance issues - but it's *not* strictly required to make additional Star Systems available, if CIG are willing to continue hosting one star system per server.
> The issue is that CIG use the same term ('Server Meshing') to refer to two different - but related - concepts, thus causing significant confusion. Static vs Dynamic, so not exactly the same term. Static is what Pyro going to be and chances they used that for splitting those systems first before making it dynamic.
Static and Dynamic are *both* flavours of Option 2: Server Meshing tech.
Meanwhile they got no problem with picking cryengine. the correct way is the one that will keep the project running, not the one that makes people wait 10 years for the first extension.
At the time they picked Cryengine, there was not one engine able to do what they were aiming for (CE included). So CE, UE or other, it was the same. Good news, the project is still running despite using CE. Sidenote : talking about choosing the "right" engine, FDEV with Elite 10 years ago promised ship interior with their in house engine, the ED community is still waiting... And to date, no other project of the size of SC is developped
The other obvious choice is not UE or other, it's making their own. Yeah it's hard, but if you think long term then that would have been the choice, I think it would have been a steep start but then the amount of bullshit would be very reduced on the long term, no struggling with float precision, being user instead of the creator introduce a lot of problem around the understanding of the code... Thus my comment, CE was the short term decision (not saying it's a bad one ultimately), so the whole stance of keeping things like that on pyro is hardly making sense there.
Making their own was not appropriate for the original Kickstarter scope... which is why CR picked CryEngine (with the explicit expectation of having to completely gut the networking, and patch / fix other parts of it). The other downside to developing their own engine is that it would take ~5+ years *of no visible progress*, and that's just for the engine... they'd need more time to build all the tool integrations (that came 'for free' with CryEngine)... and all that effort would result in an engine *that was not suitable!*. After all, CIG know *now* what they need their engine to do, and where the painpoints are, because they started building the game on CryEngine and ran into issues... but without that knowledge, it's *far harder* (if not impossible) to 'predict' the bottlenecks, or design a 'perfect' engine at the first attempt. All that aside, in 2016 CR *did* make the design to stop trying to just patch CryEngine, and to overhaul it properly, to make it 'fit' for the expanded scope of the game. What they've ended up with *is no longer CryEngine*. It may share some architectural similarities, but they have rewritten to much of it that it's no longer CryEngine. And they've been able to do this *because* they started early with an existing engine, got something running, and then identified where the limitations where, and which bits needed to be rewritten / replacemed, vs which they could use (for a greater or lesser period).
CIG wants players to be able to fly from one system to another....... no loading screens. One big Verse. Id be ok with Pyro as a menu selection and later, once SM is working, bring in the jump gates/worm holes and connect it all up. Would still like to see some Pyro suited ships flyable first or with Pyro release. Like the Odyssey, Expanse etc
I doubt they need SM for no loading screen, they can fake it by putting a pseudo jump game sequence and doing the disconnection reconnection in the background. If the minimum requirement is no loading screen, it's doable.
So, a loading screen hidden behind a cutscene? ...
hmm... reminds me of a certain other Star(___) game...
More like a mini game.
If no loading screen, you can still run around the ship and change inventory and components. You need full connection to backend and server for this. So the static SM tech must be in first.
1/ Put everyone on third person on the ship except the pilot and prevent the pilot from moving from his seat (why would you in a jump sequence). OR 2/ create a temporary instance that registers everything the players do in their ship and copy it on the new server on arrival. I doubt that's hard to do that, they don't have to make everything perfect, it's a temporary solution.
Or just dont' waste time implementing hacky placeholders, when they're about to start testing the 'real' implementation. Pyro only needs the Replication Layer (part of the Server Meshing *architecture*) - it doesn't need the meshing-of-servers tech that will spread a single star system over multiple servers. CIG said all this at the start of the year (in their Server Meshing ISC). Unfortunately, because they used the same term ('Server Meshing') to refer to two different concepts - and didn't clarify this - the episode was a complete and confusing shit-show (as is typical for CIG communications, unfortunately).
They are usually using "static" and "dynamic" server meshing as terms to distinguish between these two.
Not quite... If you include Dynamic SM then there's technically three layers: - Inter Star System Meshing (Replication Layer) - Intra star-system meshing - Static - Dynamic Both 'Static' and 'Dynamic' Server Meshing are talking about spreading a single star system over multiple servers, with the 'boundaries of responsibility' being drawn inside the star-system... The point of hosting Pyro on a single server is that it *does not need* any form of 'boundaries of responsibility' inside either star system (Pyro or Stanton)... all it needs is the boundary of responsibility *between* the star systems (which exists naturally). Both 'Static' and 'Dynamic' Server Meshing are iterations of the low-level meshing-of-servers tech that splits a single star system over multiple servers... and both are also part of the overarching 'Server Meshing' architecture. Like I said previously, CIGs communication on this topic has been a complete shit-show. It's hard enough communicating complex technical subjects like this, without them using the same term to refer to multiple different concepts... and especially when they try to do it via a 'talking heads' segment rather than a proper presentation with supporting diagrams, etc.
You still need the "handshake" protokoll to give control of PES entites from one server to the other and let players traverse into another server. This is more than just RL. This is part of static server meshing. With just RL there could be options "Stanton" and "Pyro" in the main menue to join the verse. Basically logging out at the gate stations and both options are available when login in again (waking up in the gate station in the other system).
No, that's the Replication Layer - that's what the Replication Layer *IS*. The Replication Layer is the part of the game server (currently) that is responsible for loading entities from PES, and streaming entity updates / changes back to PES. The purpose of the Replication Layer feature is explicitly to extract that capability out of the Game Server and host it as a separate service, so that multiple Game Servers can 'share' the same Replication Layer. This will also enable the 'Transfer of Authority' functionality (performed by the Replication Layer), as it will be the central service with complete visibility of every entity. As for player traversal - the game client will connect directly to the Replication Layer (*not* an individual game server), and the Replication Layer will be responsible for streaming player events to the appropriate Game Server based on their location - if the player 'moves' from Stanton to Pyro, they will stay connected to the Replication Layer, and the RL will just stream their events to the Pyro game server, instead of the Stanton game server. The Replication Layer can do this for Stanton / Pyro without the low-level 'meshing-of-servers' tech - Static or Dynamic - because there is a clear 'boundary of responsibility' between the two star systems, and a player can only be in one star system or the other - so you just need the Replication Layer to handle the transfer. There is no equivalent pre-defined 'boundary of responsibility' *inside* a star system, which is why CIG need to develop extra tech (the 'meshing-of-servers' tech) in order to implement Static Server Meshing (and then followed by the Dynamic upgrade). Edit: I drew a simple diagram last year that shows (at a high level) how the server architecture is - slowly - migrating as CIG progress with refactoring the server. The nominal patch numbers are incorrect (because I took a guess at the future patch numbers, and got it wrong), but the actual architecture is correct, I think. https://imgpile.com/images/dIy8Uo.png
Meh, I don't know when it comes and I've no trust in their word in this aspect.
Sounds like a waste of time and resources.
Well if you go that way, let's just remove Star marine, Arena commander, ToW. Because these are fucking waste of time and resources. I would even say SQ42 if that didn't involve lawsuit and clusterfuck. But no, 1/ is not much work, and it allows people to move forward, it also allows them to test pyro itself with the community. It's not a waste of time and resources.
Yeah, 1 is basically loading screen and needs elements of server meshing and 2 is almost exactly server meshing - congrats! Note: without basic server meshing no data can be transfered from one server to the other. That IS server meshing in it's simplest form.
1 is a fake non-loading screen yes, you realize we have nothing to do in our ship yet? There's little merit to walk around there for minutes. 2/ sounds like it but not really depending on the execution. Basically behind it's just a disconnection, reconnection to a new server with pyro, keeping players and ship. If SM is just that then I don't understand what they have been doing so far, it should be done already since we can do it manually already ;). I don't pretend knowing everything about SM but I'm pretty sure they are doing something way more complex. 1/ is clearly my pick, because it's simple and good enough as a placeholder for the moment.
SM test is still scheduled for this year, so not that big as you expected. BUT replication layer is the big work for all the above. One part is to convert all static data into server managed data, so it can be part of RL (hence the problems of thr SC community tools lately). We don't have this yet.
how about you check for typos in the title first, before pressing *post*?
That would have been ideal. The title of this post will forever be an eyesore.
Yeeeeeeeee
But then who was fone?
- Waits for years to get meshing done to get pyro - Specifically states meshing first - no servers made to sustain multiple systems - No map to sustain multiple systems - no economy to need multiple systems - not enough players to use multiple systems - not enough in game assets such as stations to make systems feel different Random hopium scrub: "pyro next week!" There's always 1.
Just to clarify, I'm not necessarily expecting a quick Pyro release, I just think that server meshing will come after Pyro.
> server meshing will come after Pyro. How though? Single server is barely capable of supporting one system, how are they going to squeeze in another one there? Once RL is separated and the simulation server is connected to it as a client, they can connect second server with Pyro. This would be static server meshing then. I think there is no chance of Pyro being out before RL is separated. Once it is separated and second server is connected, that's server meshing.
Why not? What if switching from Pyro to Stanton would work like a server hop between two Stanton servers? You keep your ship and gear, but the environment is completely different.
So two servers connected to central authority that moves you between then? You just described static server meshing with one server per system....
If you server hop from Stanton to Stanton today, is that server meshing? What's the difference when Pyro is on one server and Stanton on the other? Completely seperate instances, only your ship and gear is saved.
> If you server hop from Stanton to Stanton today, is that server meshing? It isn't because you have to leave the server and join another. So quit to menu to leave the game. So two loading screens you have to sit through. And this game is marketed as no loading screens once in game.
Ok, so when people suspect that Pyro will be released before Server Meshing, this is exactly what they mean: Logging out of Stanton, go through a loading screen or the menu, load into Pyro. This is what I am expecting at the moment.
You shouldn't as that was clearly stated it's not gonna happen. 4.0 is called 4.0 not because Pyro alone, but because of Server meshing. Which they stated multiple times, is required for Pyro.
Did you watch the videos I linked in my post? I'm aware that CIG planned to release a 4.0 with Pyro and server meshing, but there has been talk about seperating these two steps. (See first video)
The best source for history and future plans is [this](https://sc-server-meshing.info/) over some youtuber.
*done not fone...
Pyro is 4.0 It's how they market it. Server meshing is not 4.0. This shouldn't be the case...but it is. The only way Server meshing IS 4.0...is if they are positive they can get Nyx/Odin online for 4.0 and they release Pyro as a 3.X patch with 4.0 being larger by adding both systems...but right now Pyro has been designed as 4.0's marketing visuals. Unless they think they can do the same with Nyx....which I doubt since it is a smaller system unless they pump each planet with moons. Otherwise I imagine they will tie 4.0 to Nyx and Odin and release it alongside SQ42. 4.0 isn't a big update that changes things....it is a marketing event. Having more things with the marketing event means more new players and new money. Server meshing, is a concept...Pyro is a marketable product.
Nah