Making a Mesh - [Server Meshing 2015-2022]
Вставка
- Опубліковано 3 жов 2024
- Persistence needed its own video...
• Gotta Cache Them All -...
This isn't an attempt to delve into the technical blockers of any of the above. Just a broader look at CIG's messaging and roadmapping for the same.
---
'Blast from the Past' playlist here:
• Gotta Cache Them All -...
Daft stuff here:
• If I Had A Tractor Beam
Patreon here:
/ golgot100
(If you fancy giving me coffee money to power through Tony Z monologues ;))
---
Video sources - CIG:
2015
• 10 for the Chairman: E...
• 10 for the Chairman: E...
2016
• Star Citizen: Ausführl...
• 10 for the Chairman: E...
• Star Citizen: Reverse ...
• Star Citizen: Around t...
2017
• Star Citizen: Live fro...
2018
• Star Citizen: Reverse ...
• Star Citizen: Reverse ...
• CitizenCon 2948 - Road...
2019
• Star Citizen: Reverse ...
• Star Citizen: Reverse ...
• Star Citizen: CitizenC...
2020
• Star Citizen - Calling...
2021
• Star Citizen Live: Dyn...
• Star Citizen Live: Rad...
Video sources - Other:
• Star Citizen Roadmap: ...
• Star Citizen Roadmap i...
Text sources:
2018
robertsspacein...
venturebeat.co...
2019
nymag.com/inte...
2020
robertsspacein...
2021
robertsspacein...
2022
robertsspacein...
robertsspacein...
Sounds used:
freesound.org/...
freesound.org/...
freesound.org/...
They put it as "scheduled" for 2018, and then got angry because people didn't understand that things scheduled for 2018 actually come out in 2023+.
Very understandable from their perspective, though.
"Answer the call 2016" also not coming out 2023, so minimum 7 years delayed is their usual, you cant complain when its only 5.
@@googleoperationcyclone *whoosh*
@@BB-848-VAC The delete of shame.
@@1aatlas 😂 probably down voted to shit lol
I remember when I scheduled my hair cut Christmas back in 1995. Hoping that my hairdresser will be able to finally cut my hair next week (hopes and prayers).
Imagine being a programmer on this, and when applying for your next job having to say that "yeah, I worked on server meshing and a few other things for the last 7 years, and no, we didn't deliver any of them."
So then we started doing a single patch for the year. Lmao
The years still count for something, but it's true it's not a great look.
The staff better be getting paid well because you could work at cloud imperium for over 5 years and have nothing to show a new employer.
They don't need a new employer, they can ride the gravytrain at CIG for the rest of their lives.
@@mariopenulli1395 pray they don't ever need to move
Server meshing is a pipe dream, it will never happen the way it was sold by CR.
but is it possible if it works?
@pekpik5053 Depends which version right? 'Static Server Meshing' really isn't that distinct from most standard server handovers between locations. That could certainly work. But it wouldn't fulfil on any of Chris's big pillar claims for 'Dynamic Server Meshing'. The really meshy bit...
I think, right here is the reason for all the delays: ua-cam.com/video/bU13Ko8qGyc/v-deo.html
And maybe also the solution.
I'm guessing here, that they had "something" running years ago, but ran into the showstopper being mentioned at that section of the video.
Then they tried to fix that problem until they finally realized that it's unfixable and went back to the drawing-board. Basically starting again from nothing.
I think, the idea with the replication-layer between the servrers and the clients could work. The Servers are basically the computing-elements, while the replication-layer is the shared memory. If they can get a few Engineers who worked on Machine Learning (which faces the same problem of exponentially rising amount of connections between nodes), I think it's possible that they finally can crack this thing.
@@SaabFAN86 The timestamp didn't work but did you mean this bit? 9:00
It definitely seems to be a key roadblock they hit. But there's probably still an open question over whether the replication layer itself will introduce 'lag' of its own as it's essentially still another data-transition stage. (And there's a secondary question over whether it will scale up to allow the full blown 'dynamic' format). Guess we'll see ¯\_(ツ)_/¯
I think two main things strike me on it: It's not ideal that they're still R&Ding solutions to such a core
structural component as networking in their 10th year. (That flux acts as a huge blocker to gameplay engineering and design). And there's no point getting excited about it until it's providing the exciting game play we hope it would ;). (SC is the epitome of 'wake me when it's in the game' ;))
@@Golgot100 "It's not ideal that they're still R&Ding solutions to such a core structural component as networking in their 10th year."
I still have not understood that argument. But maybe I am coming from too a niece viewpoint on this.
I am still convienced that for the longest time, they werent actively working on Server Meshing, because they were still busy with an entire engine rework, OCS and then PES (although SM work overlapped there already).
But the obvious question here is: Why waste time on these things, when Server Meshing was the primary goal?
For that I propose a counter question: How would Server Meshing perform, if we didnt have the engine rework, OCS or PES? Well, the engine rework was required to build OCS in the first place. So why OCS/PES then? What does it do?
In short: Optimize memory, simulation and networking to a necessary minimum on a per client and per server basis.
How would SM look like if we didnt have that? Well, every game server and client in the mesh would have to load the entire level, the entire game world. That eventually will be too much memory. And based on the data structures used, it will likely also impact performance negatively. So having only the minimum necessary game objects loaded is required. The same goes for simulation and networking. If game servers were to simulate all loaded game objects, independent if a player is nearby or not, and if each game server were to sent all data to all clients and other game servers, then each machine will very quickly be overloaded.
Therefore, SM without OCS/PES would result in very small meshes. Even two servers might already be too much. And if it is that bad at providing any benefits, why have a mesh at all? So developing OCS/PES first is vital to have SM be performant as possible to make it feasible in the first place. So what would have been the point of working on Server Meshing, when you are still ironing out these vital memory, simulation and networking optimizations?
Could all of this been better if it was developed faster? Of course. That would have been nice.
What I cant get behind is this idea that it is inherently bad that they are only now tackling Server Meshing related functionality. They had to tackle other fundamental and vital stuff first. Them prioritizing this is important and the right decision. That's also why I cant get behind the idea of major mismanagement. Quite the opposite: CIG had some great high-level planning and forsight when it comes to SM. They knew exactly what to tackle first and in which order. And imho the devs dont get enough props for it.
Something so essential to the game still being in R&D 11 years in is absolutely unfathomable.
dude i almost spend 850 usd for hull e but videos like these saved me from doing so
It's deep fake because Chris would never lie to us!
This is an awesome video. I don't know if it needs to be an annual thing because it might get repetitive, but there should be one of these every 3 to 5 years to keep people up to date over the decades.
Server meshing is next year, every year.
2015-2023 that's alot of wavey hand jesus tech.
Cig show casing storm trooper development and not hitting a single target....
Only 5 more Jesus techs until server meshing!
Funny to see them age and talk about same shit for almost a decade, while getting nowhere.
They are going grey and sometimes fat and bald. It is very funny. They have the money we have at least the fun watching some talented guy mismanaged so badly they doing the same shit for a decade. :)
Let's see tomorrow
But this time for sure guys! For realz!!!
They started planning today. It's just around the corner now.
Quick note, if each server needs to talk to each server, the connections scale quadratically not exponentially. 9:15
I am saying this to be a smartass, but it could also mean they spend more time on the excuse, rather than trying to solve the problem.
Im sorry.
Don't be sorry. A lot of people haven't thought things through on this project, both devs and backers, and it's never a bad idea to drag them into the sunlight for a moment.
The entire concept behind server meshing was flawed from the start. If a single server can only support 100 connections, then it can only support 100 connections. Whether or not those connections are to other servers or to clients is irrelevant, a connection is a connection and there IS a hard cap of how many can exist at once.
Given this, logically, every new server you connect to the mesh eats up another connection. Worse, it eats up another connection on EVERY server in the mesh. So if your hard server cap is 100 connections, then you cannot mesh more than 99 servers no matter what you do, ever, period, AND you would have 100 servers each with a single user connected, i.e. 100 players, the same as the current cap with unmeshed servers.
The best math happens at the midpoint, where you have 50 servers connected with 50 players each, which is 2,500 players. That's very, very low for a MMO in a single shared universe. And of course none of this takes the replication layer into account, which eats another connection to each and every server, so that's actually 2450 max.
Now, of course, what CIG is trying to do is have every server connect back to the replication later, and have it relay all of the data for every server between every other server. That is to say they aren't trying to actually make a mesh, and never were. This is an old school client-server model and it was from the very beginning.
The problem with that is that it requires that the replication layer talk to thousands of servers AND send data to each of those servers equivalent to all the data from every other server combined. So, even if it's only using a single connection, that single connection is passing the data of hundreds to thousands of users around. That's going to eat a TON of bandwidth.
They should've just copied WoW's shard model. Except...that's basically what they're doing now anyway. The "replication layer" is a fancy way of saying "item database" lol. 8 years of work just to copy the homework of the 20 year old MMO because IT WORKS.
Hopefully, they eventually decide to copy Elite's flight model too so we get a game before I turn 50.
@@austinm5630 Whoa, WoW has indefinite item persistence?
@@billywashere6965 Literally has nothing to do with server meshing.
So no, it doesn't, but that's equivalent to saying "Woah, so there's tea in China?"
EDIT: Also SC's persistence will not be indefinite, either. CIG has stated many times that they will be putting systems in place to immersively despawn entities, i.e. ship wrecks, water bottles, etc. The only indefinite persistence in SC will be things like player characters and functional ships, and yes, WoW persists player characters. The only real difference is that NPC corpses fade away unimmersively after about a minute instead of using some sort of immersive system to handle the despawning.
@@austinm5630
"The entire concept behind server meshing was flawed from the start. If a single server can only support 100 connections, then it can only support 100 connections. Whether or not those connections are to other servers or to clients is irrelevant, a connection is a connection and there IS a hard cap of how many can exist at once."
Well, a hard limit on connections sounds too simple. An open, idle connection doesnt require any CPU time. The limitation arises from having to simulate and collision check players and entities and sending that data out over the network. If you optimize what needs to be simulated and sent out, you can increase the number of players and entities again. You can indirectly equate that to a rough number of connections, but the connections themselves are not the root cause.
When it comes to simulation and networking optimizations, that was what OCS was able to help with. I remember having 24 players in the old 2.x PU (maybe even still in the pre-CSOCS 3.x releases, but cant remember exactly). So that already helped a ton. If you take a look at what Unreal Engine devs said about UE's ReplicationGraph feature for Fortnite (reducing the sent data on a per-client/connection basis, similar to CSOCS), they also said it allowed them to have many more players in a match with better performance. Many hundreds, theoretically at least.
Then we also had the multithreading simulation improvements (a game server being able to use more CPU cores) and the netcode and animation improvements in 3.17.2 which allowed us to increase connections from 50 up to 150 currently (still same low server tickrate tho). The same thing is essentially happening again with Server Meshing, where one can put more cores on the task of simulating and sending data again (although using the cores of multiple CPUs on different machines, rather than more cores of the one CPU, requiring additional complexity).
"Given this, logically, every new server you connect to the mesh eats up another connection. Worse, it eats up another connection on EVERY server in the mesh. So if your hard server cap is 100 connections, then you cannot mesh more than 99 servers no matter what you do, ever, period, AND you would have 100 servers each with a single user connected, i.e. 100 players, the same as the current cap with unmeshed servers."
"And of course none of this takes the replication layer into account, which eats another connection to each and every server, so that's actually 2450 max."
As explained above, establishing connections shouldnt require a performance cost. The connection wont use up CPU instructions to do nothing.
Additionally, we know from CIG that each game server will likely only establishes a single connection to the Replication Layer. Not between each other directly. Therefore, game servers are not directly connected with each other, but rather receive data indirectly via the Replication Layer.
"The problem with that is that it requires that the replication layer talk to thousands of servers AND send data to each of those servers equivalent to all the data from every other server combined."
No, data sent to the Replication Layer, is not sent to all game servers nor all clients connected to the Replication Layer. Only those that need it (thanks to OCS and PES). If you were to have 5000 clients and 50 servers, then one of those clients most of the time will still only get SOME of data sent from the one game server that simulates that client. But NOT ALL data of that game server. Sometimes, a client may receive SOME of the data from one or a few of the other game servers as well. But never all of them, nor all of the data. The same goes for game servers. They to dont receive constant updates about what goes on in other game servers. That would be silly and goa gainst the idea of being able to divide and distribute the game world and its simulation onto multiple game servers.
"The "replication layer" is a fancy way of saying "item database" lol."
It isnt a database and even if it was, it is much more than that. It will be acting as the load balancer for the mesh. It also houses the entire OCS logic, both in terms what each game server and client loads, as well as which data each game server and client receives from other game servers and clients. This way game servers and clients will only receive and simulate what is important to them, reducing the load to a minimum. You could ha
"They should've just copied WoW's shard model. Except...that's basically what they're doing now anyway."
Not really. More like Dual Universe shard model. And that is different to WoWs.
"That is to say they aren't trying to actually make a mesh, and never were. This is an old school client-server model and it was from the very beginning."
Even if we were to not consider a mesh of game servers anymore when game servers dont exchange data directly (but indirectly via the Replication Layer services instead), it it will still behave the same way as it was planned under a mesh. We still are able to look into and intact with what goes on in those other game servers connected to the same Replication Layer. We will seamlessly be handed off. So whats the difference really? Does it really matter to you that much that it isnt an actual mesh of connections? I dont know about you, but that sounds extremely petty to me.
"A lot of people haven't thought things through on this project"
With all of that said, I respectfully recommend including yourself in that statement and having another look at how CIG describes their architecture and maybe even how computers in general work. Server Meshing is definitely a feature with many moving parts that make it complex and can lead to many causes for issues. But the idea that connections are the main issue is definitely not one. There are definitely going to be limitations. But I doubt it is as simple as that.
@@austinm5630 Sorry to thread necro your comment so hard, but connections be damned, the part that has always given me heartburn is how meshing does worse than nothing to address latency and state resolution when you have spread out players talking to multiple servers. On a single server this leads to rubberbanding, teleportation, and other jank stuff. What happens when that's going on within each server then they need to talk to each other more to resolve state? Nothing good is the answer. Meanwhile back in reality since this project started, each CPU in a server has almost 50x the throughput that the ones did at the start of 2012. Imagine if they had just focused on scalability on a single node where we could be by now rather than wasting it chasing this weird dream of having distributed servers.
Man who's never made a server based game telling everyone else the best way to make server based games better.
I'm So happy I lived to see the storm trooper project methodology created by CIG
I'm glad it took until 2020 for them to try getting two servers talking to each other. The other 8 years prior they must have been working up the confidence with monthly pep talks I guess?
@The Star Economist yeah 100 star systems no loading screens we have the tech, back in 2012
@@Jaya365 LoL yea and then I answered the call in 2016 but no reply yet! :D
@The Star Economist one the pipelines must be blocked
Dont worrytony z is just getting his plunger out
Hoo boy, been waiting for this montage.
well I know what I'm doing tomorrow :)
Woot :)
Nice collection of sources. Very good 👍
Hey unobtanium, glad you liked :)
Fricking gold.
love this series
Someone imagine with me... CIG stops everyone making jpegs to sell, and uses them to make baseline functionality promised 7 years ago come to fruition... the blasphemy, right? The worst part is the amount of people that continue throwing the money at them. I get it, there's nothing like it. It's amazing. But... the only reason I ever take breaks from it, is because there are so many issues that you can't even enjoy the stuff that is next-level awesome without literally hundreds of bugs. How I wish people would stop giving them money for ideas, and only gave it for products.
If they did that their revenue would dry up extremely quickly and they would have nothing that they could actually sell for at least 2-3 years. Average gamers are idiots - you dangle some fancy cool looking ships in front of them, sell it to them, and then promise "some time in the next 10 years you can fly this ship", and it actually works. On the other hand, try spending 2-3 years on actual hardcore tech development and try asking for "donations" for said tech development instead? Average gamer wouldn't give a shit and would likely give peanuts compared to now.
The majority of people dropping $$ on this game are paying for early "cheaper" access to ships in a dream world they think will *eventually* come, for 100% selfish reasons. If the model was switched to asking for $$ based on "helping the project", SC would be dead in the water by next year.
Sad, but true. People are dumb.
@@mavor101 True. People are dumb and selfish and sadly all of them have the right to vote.
Computer games are dying because of the unholy trinity. The game publishers, the game developers and the gamers killing it. The only difference is the gamers continously complaining about the other two.
What you said is 100% true and is very important. Star Citizen can not be finished, it will grow to a point where it will collapse because of their own weight. Nothing can stop it because there is only one way for them for continue and that way is not the way they can develop a game.
If they wanted to build a game developer company they failed, they built a money making company.
So where's the MMO part? lol
LOVE how this channel tracks EVERYTHING!
dude i almost spend 850 usd for hull e but videos like these saved me from doing so
8:02 It's getting so ridiculous that Jared is trying not to laugh
Just a bunch of random features, and a nice render engine for ten years ago... PREDICTION: never gonna gel, or 'be a thing' that some team can balance and refine.
It could be. If CIG went under and some other company bought up the assets, they could probably turn the PU into a decent single player game. A single player game would remove server issues, they could segment the system and use QT as a loading screen which would mean they'd only need to have the location you're in active freeing up resources for adding some NPC's. Put some god level guns around stations to keep you from interacting with most NPC ships and they could be on rails coming and going to add life to the universe. Pre scripted NPC's on stations and in cities for the same purpose.
Star Citizen has some very pretty assets and there's a lot about it that already works. They just need to take it away from Chris and crew and put it in the hands of someone that can make something of it.
Possibly maybe someday could have probably will might eventually. 🤣
Personally, I’d gladly take a few loading screens if it means we finally get to explore some star systems that aren’t Stanton, and I’m sure I’m not the only one.
Especially since jump gates are just interactive loading screens
Well, Stanton works like shit too) FPS part is just a mess
Who cares if it's just the same shit in Stanton but different color?
You will play the same old boring laughable missions, retarded teleporting AI, same old rocky barren planets, same old fetching missions. No fauna or proper flora...
People hyped for Pyro is kind of funny when Stanton has like 1 hour of content except the time sink like walking around, waiting for metro / elevator / leaving atmosphere / QTing around.
Thank you for all the work to create this compilation :)
Testing server meshing next year this is solid gold 3:23 here we are in 2024 and they finally they have it maybe working for 200-400 player shards maybe as it hasn't been load / time tested yet.
Yep, around 7 years later than intended, the tests have begun :D
What an absolute joke, this is why I've been jaded with SC for a while now and this video illustrates it's even worse than I was aware of.
wonderful job of compiling this by the way, the community needs this kind of transparency to kill funding for this game and force them to finalize instead of indefinitely keep developing
The word makes the man otherwise the man is worth nothing.....
Please stop making this videos. The memories creeping back to my brain and squish it hard.
Good work again. ;)
...still... early days yeah......
YES
You do such a good job on these videos. How you can dig through 10 years of videos spouting the same old BS and not punch your screen - that I’ll never know tho 😂😂
P.s. also love the slow walking pan of the egregious “micropenis….er rather macrotransactions” in your other vids ❤
Cheers! (I definitely have to detox after each vid ;))
TIL that they didn't have people competent enough to predict the big problems with server meshing and didn't try out a mockup until 3Q 2020. Neat. Also, I'm suuuure they thought well ahead about how they are going to resolve state across the replication layer.
Replication V2 is already on the roadmap. Under 'Future'...
robertsspaceindustries.com/i/79f247336caf1bd45f9fa47b9b071ceecc6dfdc2/4PYjjVwJ1UdtiiccNqwwbDWUnrYF7jLZthNebwnpQ5sZ6gfq7aeKks7v6xqhfexJFcXg5dt7vV7JwaEZiEkUM2ywRfGp8dY5edNhAVgJ5Xt/road-to-pes.webp
I guess that's planning ;)
seems legit
This is why I am not upset about CIG focusing on Squadron 42, something that has clear boundaries and can be 'good enough'.
Yeah, the only problem is that all the ongoing R&D flux for 'Server Meshing' still has effects on SQ42. They've talked about how iCache (then presumably Entity Graph) would be used for save state etc, and how PES work has involved mission reworks in some cases, for example:
www.reddit.com/r/starcitizen/comments/hme4mo/will_server_meshing_and_ocs_be_used_in_sq42_dev/fx57rc7/
mailchi.mp/cloudimperiumgames/squadron-42-update-147292
SQ42 is somewhat affected by the shared networking code as it is. SOCS needs tailoring for the single player game, IE:
robertsspaceindustries.com/spectrum/community/SC/forum/50259/thread/server-meshing-ocs-and-squadron-42/3203050
robertsspaceindustries.com/comm-link/transmission/18580-Squadron-42-Monthly-Report-February-2022
Throw in the general refactoring a bunch of teams from audio to AI had to do for PES, and any overt gameplay changes involved (such as any alterations to inventory & related UI due to the underlying data changing), and SQ42 is still impacted by work (and delays) for the PU.
@@Golgot100 yes I can see how the design is dependent upon how the underlying loading of gaming assets works since they share the same codebase. In the case of a server mesh it's divided the loading of assets across systems that needs to be functioning in a software layer at the minimum even though it's running on one single machine.
Until such time these fundamental technologies are not done, there's no SQ42 release.
@Cenot4ph Yeah it's all kinds of ironic that they've spent so long wrestling Cryengine's hacky 'client spoofed as server' multiplayer code into this... And then having to unpick it all again for single player ;)
The painful thing is that even still, every time one of the "We scrapped it and started over again to make sure it's ahead of other games in the genre" bullshit things happen to the PU, they put SQ42 on hold again so they can implement it there. It's not 'feature' creep, it's more like trying too hard to turn it into a 'tech race' with other games and nobody really should care about it.
Just one more Year and we will have tousends of players per server...
In the meantime just buy the newest ship
I have been following development since 2012 and all I see is *they kept stripping features away from development and add something stupid like space coffee and toilet sim*
Look, they didnt even deliver 70% of their promises... Lets look at the simple promise like star system and planet
I did the math, which came to
The average number of planets per system (of the systems whose planet count we know) is 4.34 with 110 systems that’d give us 478 estimated number of total planets. Currently there are 4 planets in-game. Suggesting that the number of in-production system are in fact ready and awaiting server meshing that gives us now 16 completed planets (12 in-production plus the 4 already in-game).
* They have 0.84% of the planets in-game
* They have 3.35% of the planets in-game and in-production
I also decided to do it for ships, not based on number as ships vary in size and since they have yet to complete most capital ships numbers skew the result. I opted for volume, area, and length.
* Linear: 17.5%, 23.1%, 23.5%
* Squared: 4.04% or 4.11%
* Cubic:0.95%
At most based of length they are a quarter done, at worst with volume they are 0.95% done. Obviously volumetric estimation is a huge under estimation but it doesn't paint of good picture with regards to how much work CIG have left to do.
6:17
Why are people applauding that.
Because if Chris isn't rushing (or hitting dates) then he must be doing things right...
(It's amazing how many daft coping memes SC has spawned around itself ;))
true...
So basically…. VMWare with VMotion and HA (High Availability)…. Lol.
It is now 2024. Server meshing is not in the game.
But the Replication Layer tests are going great ;)
clips.twitch.tv/ClearSneakyCheesePeoplesChamp-5jb5tOX0rCUFEnql
Even government works faster. 🤣
fyi your vid didn't show up in my subscriber feed :(
Oh yep I never do the subscriber alert option because I'm never sure if it sends out a ping too. (I always find those annoying :/)
I figure it'll just show up in general browse feeds / suggestions anyway ¯\_(ツ)_/¯
(Is that how you found it?)
Same. It didn't show up in my sub feed. And yes, I found it through the recommendations.
@@Golgot100 showed up in recomended
0:30 Which 10 for the Chairman is this? Do you have a link still? It does not seem to be part of the sources :c
Found it. It is 10 for the Chairman: Episode 77 from 29 Feb 2016
@@SETHthegodofchaos Yep whoops, that link's missing. Here it is for anyone else:
ua-cam.com/video/DFkTG9YungQ/v-deo.html
(Added to the sources list)
@@Golgot100 Thanks, much appreciated.
I found that one the most insightful, because it confirms that at that point they replaced their instancing approach from 2012 ("Chris Roberts on Multiplayer, Single Player and Instancing") in favor of Server Meshing.
@@SETHthegodofchaos Yep, 2016 was when they tilted in earnest towards the shinier 'mesh' approach. (Only 2 years after their initial launch date ;))
@@Golgot100 Well, initial _estimated_ release date ;)
Weird! Almost as if it’s just a giant scam or something?!?
Wash your mouth out with hopium!
Might need a little help here to verify something which I think to remember them saying about SM.
SM was required for Pyro to happen, right?
But did they ever say that the folks working on SM are currently busy with work on Squadron, so work on SM can't progress further?
I don't remember anything precisely like that (and the 'Progress Tracker' shows plenty of engineers working on SM etc)
John Crewe did seem to talk about a specific team getting shuffled to SM, then SQ42, at one point though:
ua-cam.com/video/6vkDdMwEuj8/v-deo.html
One day they will be right.
I hope.
They did the live demo
Yes indeed. We still await such functionality in the game though.
In the meantime the demo's glitches are worth a gander:
ua-cam.com/video/KLlREqobgj0/v-deo.html
(As are Citcon's prior demos for features which still haven't ended up in the game yet ;))
ua-cam.com/channels/3Yq1YRGZ2ZEDi7EgnQuZ4A.html
And even on local host it didnt work. But the Seals clapped as usual.
@@heru_ur6017 what? It worked actually, they also tested it with players
Of all the things they're late on, server tech is the one I feel I can forgive them since there is incredibly complex rnd going on...however it doesn't excuse their terrible communication on the matter.
The only issue is that it's such a blocker for so many other facets of the game. Hitting your 10th anniversary without even a test case functioning, and still having such a long road of further R&D stretching afterwards (Replication Layer V2, 'Dynamic Server Meshing' etc) means years more of that level of disruption.
There's no easy solution. But I'd definitely question how long they can have such a core part the game be in this degree of flux. (In terms of actually nailing down final tech and design on top of it).
@@Golgot100 yeah I know what you mean and I think the fundamental issue here is that they want to make 2 games at once and the lack of focus they had in the first 5 years. That split of attention really makes the entire project suffer and I'm pretty sure if they'd ditched sq42 and spent their funds on SC development alone we'd already have meshing by now.
Yeah if SQ42 wasn't a thing they'd definitely be further ahead. The two projects doubtless slow each other down. But there's still a big question mark for me over whether the end objectives are even achievable. (1000s of players in a shared vicinity + single shard + large populated ships + single-player-quality assets & interactions, etc).
Even at an accelerated pace I suspect they'd have hit plenty more walls along the way.
That doesn't mean they might not arrive at something that's way less than that, but still cool. (It just calls into question the decision-makers who thought they could do so much, relatively quickly. And doubly so given it was a scope creep that emerged years deep into project.)
@@Golgot100 I think we'll learn whether all this is possible or not within the next 12 to 18 months. If we still don't have pyro by mid 2024 it's pretty clear that meshing didn't work outand then it's up to CIG to find alternative solutions. Tho even if this may sound cynical... if they just wait long enough, such technology will probably become available at some point anyway and they can just implement it ;)
It's always one more year with SM ;)
(Wouldn't hold out too much hope on a third party solution though. They'd have to go back and reimplement the data cache system again for a start :S. Just coming up with a new name for it could take a whole year ;))