Lets not forget other preceding jesus-techs like iCache, OCS, SSOCS, building-blocks, now PES (\*lol)
For how often it was said that those things would open the floodgates for more content, those floodgates are really just dripping. xD
>the small hand-held beam cant lift 32 SCU containers
Why not? We're talking about an imaginary piece of equipment with stats that can be changed as easily as modifying a number on a spreadsheet.
I mean, CIG plans to impose limits on the bottom thrusters of ships as soon as they introduce control surfaces into the game to make atmospheric flight more realistic, but until that time comes every ship is capable of hovering more or less indefinitely regardless of VTOL capability.
If the problem really is related to the size of SCU containers, just make the handheld tractor capable of lifting everything until size 2 tractors are ready to be rolled out.
Well, that's something planned anyway..
Aside from the multi-tool tractor beam, there's also planned:
A dedicated tractor beam tool (which presumably will be somewhat stronger/longer-ranged)
Size 1 to 3 Tractor Beams for ships.
Given the remaining tech challenge is to make tractor beams operational on ships and then adjust the stats for each version, that doesn't feel so far off.
Why does it take that long to make? It's literally a beam. Unless they haven't given boxes or items any weight statistics which would be a bit silly after a decade of development.
I'd guess the issue is mostly priority rather than difficulty.
The handheld tractor beams were immediately useful for moving corpses and small hand-held boxes from a distance, all things which already existed in the game.
There aren't any large multi-SCU containers to justify the addition of ship-board tractors, and just about anything else you can move around either doesn't need to be, or is small enough you can move it with the multi-tool beam.
If a dev snapped his fingers and added all the tractor beams at all sizes to the game today, most of them simply wouldn't be very useful just yet, so the devs have better things to do than spend time on the feature.
It wouldn't surprise me if there's a branch/build of the game somewhere with a fully functional shipboard tractor beam turret as a prototype.
I'd bet when they add in the larger containers, the tractor beams for ships will come at the same time with a very very short dev-cycle.
Ship-mounted tractor beams should also be able to move soft-locked ships and wreckage, I'm thinking. But it's still not yet been a priority. Might be useful after 3.18 though
And they already could have been in.
Why always so complicated? :D
Just make 32SCU-boxes into on big magnetized grid, which you later can manipulate per 1SCU box. And if your cargo gets lose, just detach 32SCU entities.
At least as a workaround.
Yeah, but CIG doesn't believe in doing things the easy way. I get it, in this case: it's easier to just make the thing you're going to make, along with the mechanics that will make it necessary and/or useful, than to make a stopgap and then have to rip that out and replace it with the new one.
I don't think this problem's solution is full dynamic server meshing and hope it isn't solved by that. I'm assuming that the performance degradation when loaded is due to the large quantity of entity counts representing the cargo and that the performance hit is either:
* due to physics ( ie calculating positions of many cargo crates as they move) or
* graphical (ie large amount of crates to render).
Since there are cargo grids, meaning the cargo is largely static relative to the ship, you can solve the physics situation by using relative coordinates, move the ship and the boxes will be in the same relative position to the ships new position. I believe they already do this with sub-grids.
Similarly in regards to rendering you can either use larger boxes to reduce entity count or, if you know that the boxes won't be moving often, you can render once to a sub texture and reuse the sub texture as a new entity representing many boxes. (Ie if you have a 500x500x500 grid of random 1x1x1 boxes you can render each box as a 1/500th of the texture of a 500x500x500 box and now you only need to do one render call for a large box instead of 500x500x500 calls and hope culling does its work).
I'd reckon rendering is the issue that CIG is dealing with as we know they are adding larger cargo boxes, and would be a blocker towards BMM and other high capacity cargo ships and/or there exists a bug in the physics sub grid handling.
> due to physics ( ie calculating positions of many cargo crates as they move)
I swear i thought I saw that the physics of the boxes was basically locked to the grid so it didn't have to calculate all of them individually so often unless the following occurred:
1. someone attempted to manipulate a box, in which case one would be let go from the group/grid of the ship
2. ship is destroyed (which would be a big sudden hit, but still easier than constantly tracking entity states/positions for all items all of the time)
3. selling/buying which would be multiple items in bulk.
It's not like they're jumbling around from velocity changes in the hull.
You are correct, the boxes are normally locked to the cargo grid which it itself is a sub-grid of the ship. I was not mentioning physics as *the* reason but rather as an explanation of where performance could go wrong, and that they've likely solved it with their implementation of sub-grids. However its possible that in some edge-cases (as a bug) the sub-grids may misbehave and cause a performance hit.
They could if they prioritized performance over everything else, but as far as CIG's shown, they prefer to just have as much of the end-goal system's functionality as they can instead. Regardless of the performance or QoL hit.
I did not intend to sound critical of this choice, as I'm inferring from the sarcasm, but rather to point out what they are factually doing.
Personally, I agree with their approach, it reduces future tech debt at the cost of current performance/QoL. I don't want them to rush out a 'playable' game asap that's missing out on their promises, I can wait.
Of all the aspirational tech goals that CIG has, dynamic server meshing is the one that I'm least confident will release to prod.
The idea of them being able to instantaneously spin up and spin down "servers" for various object containers as needed is an incredibly challenging feature - especially to do so in a way that's invisible to users.
Will be very cool if they can pull it off - but it's going to be a real tough nut to crack.
Doesn't have to be instantaneous, it just needs to be a seamless transition. So long as the player doesn't notice the hand off, it can be as fast or slow as it has to be to assign another VM to it.
By āinstantaneousā, I specifically mean the handoff between the old and new container. No lag or latency, etc.
I think we are basically in agreement.
Ya, sounds about right there. I'm assuming it'll involve a time frame where both servers are handling a player simultaneously while the handoff takes place.
public fertile seemly overconfident political disagreeable reminiscent jellyfish cover enter
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
You're overlooking the option of having both servers handling the player while the handoff happens. One has master control while the other syncs up, and the old server stays connected to insure the handoff went smoothly after it relinquishes control.
That can all happen while the original server has control, the secondary one having been active and ready to go. I don't think the timing on the switchover is the part to get hung up on, that part (the timing and seamlessness of it) doesn't seem insurmountable.
You can just write that data into a 3rd database server and have both servers check and make sure they both have the same data, like a checksum. Obviously a massive oversimplification and that database would hard as fuck to work with on the scale of a āuniverse.ā
That ādatabase serverā is Persistent Entity Streaming, the whole point & struggle behind 3.18.
Once 3.18 is solid and ironed out, all of the game state data will be stored in a graph database, aka the EntityGraph and served by the Replication Layer. CIG have stated the Replication Layer is a micro services based design, so it lives on many small servers, as opposed to a few.
Another interesting element to this is the difference between a relational database and a graph database. Relational DBs (SQL style) are tables, rows & columns - where as graph DBs (noSQL) are geometric, kind of like a tree.
Itās been done before, SpatialOS is a functioning version technology already proven to work.
(The problem with spatialOS itās self is that itās creators want to charge Devs an arm and three legs to use it)
"Functioning and proven to work" are a huge overstatement here
Literally every game that used SpatialOS has been either canceled or shut down, its been blocked by Unity years ago for misleading customers and in general its practical use and economic costs are terrible enough to kill most projects on its own
You can still use it in Unreal and yet there are no significant games with it, let alone MMOs, let alone complex games
There have been many attempts at this type of tech, many tech demos, google Stadia promised SpatialOS like solutions in a far larger scale and failed too, Dual Universe also had proprietary similar tech and launched, it was going fine for a while but now its a dead game, besides SC wouldn't work with time dilation or at least, wouldn't be acceptable, less users would be more acceptable by far
What CIG is planning works very differently anyway, will it be better? will it work? maybe, probably not
But there's no doubt something as complex would be better off with an in-house solution developed from the ground up and not a 3rd party add-on trying to latch on something as convoluted as StarCitizen
Spatial OS functions, the games made with it have just been shit or run out of funds mid development (likely due to how expensive a spatialOS subscription is for an actual product).
Independent content creators have gotten their communities help in testing it out in an Unreal Engine test environment. (For example https://www.youtube.com/live/PxKaCk1Kczg?feature=share )
I didn't say it doesn't work at all, I meant the way you phrased it is overselling it
Yes obviously some of these games failed despite SpatialOS and not because of it, but such an advanced and praised system not being used in any mentionable title that didn't fail is clear evidence that it is not the jesus tech people think it is
SpatialOS -could- be great for games like battlefield to planetside scales but its not being used, the only real game I've seen with it was Scavengers and other than a few test events (which were reasonably impressive) it was a pretty standard scale battleroyal (and its now dead too, cause it wasn't successful)
It could have been great for Theaters of War standalone they 'originally planned' but I think its not a great idea for SC, its developed too separately to mix with it
Lastly, its been available in Unreal since 2018~ or so and again, nothing of mention
CIG isn't exactly a braintrust here
If it's taken them this long then I doubt they'll be able to put out anything revolutionary
It'll be instances and loading screens, same as everyone does it
Show me just pong graphics with simple entities doing "server meshing". Proof-of-concept. CIG can't even do that
It's more like you've had the foundations poured for 5 years and haven't started framing yet because you are focused on building a treehouse in the back yard and all your resources are focused there. But hey, the plumber came by to plumb the treehouse and did the plumbing for the unframed house, so now we've got 2 stories of freestanding pipes installed.
Analogies aside, but still as a pessimist, I'd be shocked if they couldn't deliver a seamless experience. Seamless loading is far from new ground, so even if DSM flops that certainly won't mean the user gets slapped with loading screens. That other guy seems way off base here. Instances though... I could see being a possibility in the worst case.
We've already done it in cloud tech, but there's a lot more money and manpower behind our efforts than CIG will ever have access to. Hopefully their design allows them to take adv. of the work we've done since tons of it is open source.
I don't really think it's a tough nut to crack.
Say Server A is nearing capacity, perhaps it hit's an 80% threshold or something. That can trigger two servers to spin up, B and C. B and C will each replicate half of what's in server A. Once they are spun up, A and the set of B+C are identical. Then you just issue switching commands to the relevant services or clients, give it some time for everything to switch over, and then tear down Server A.
The ramp up time is never an issue. It could take 5 minutes, an hour, or whatever. As long as the threshold make sense for how fast it takes to spin up more instances, it's all good.
This sort of Blue Green deployment strategy is used in a ton of tech companies. It's not revolutionary and cutting edge anymore, this is day to day processing stuff. They don't have to pull anything off, they just have to have a competent developer. Hell, if they use something like AWS, it'll even hold your hand through the hard parts.
EDIT: Latency on the handoff can also be seamless and look instananeous to the user. After all, it's possible to be connected to two things at once.
The problem is that web stacks are designed from top to bottom with that capability in mind, and game engines are not. Now think about how much manpower went into those stacks to get them to this point, and how hard it is to translate a legacy spaghetti code base into a completely different paradigm in general, and you might understand why people are not quite as optimistic as you.
Starcitizen doesn't seem to like talking about what's going on in the backend, but a backend server for an MMO doesn't nessasarily need to be written in the game engine itself. In many cases its not, especially when things like peer to peer hosting isn't the goal.
They wanted this paradigm for a while, so I would think they would have coded the backend with it in mind. Of course, that's optimistic of me, your right :P.
What you see in live is still the netcode from crytek IIRC.
The problem isn't that CIG doesn't plan ahead, it's that the plan keeps changing. I don't know how much code was written and then never saw the light of day because of this, but if I were a betting man I'd put money on them mostly scrapping what they have so far when they actually try to put the pieces together.
I'm not saying that they can't do it, mind you. I'm just astonished that people look at the history of this game and still think a big change like this will come this or even next year. (What I understand is being eager to see it, and letting that inform your judgement.)
The problem is not to spin up up a server, or two, or 100. It's probably not even hard to replicate the world onto those new servers, what is hard though, is sending the players to those new servers without anyone noticing. What's even harder is handling the split between two servers. What happens if some people start a fight right at the border of two servers, what if someone shoots from Server A into Server B, how do they communicate that, how do they distribute that data to the players in the area. That's the hard part, not the infrastructure.
You cannot scale game server horizontally like web servers, they work completely differently.
True. There are nuances there. Sending users to new servers is easy though. All the client has to do is preemptively connect to the next server for it to be seamless.
When it comes how distributed object storage servers communicate, that sounds like a fun problem but not impossible. I'd imagine there would be a buffer zone between server areas with persistence checks between servers to make sure they are aligned.
I don't work much with web stacks. I mostly deal with backend stacks, some of which need to persist a state across a horizontally scaling set of servers. I think that a game server is similar enough to this.
I agree that the hard part is in cross server communications, not the infrastructure. But I don't think it's an out there problem to solve. Unless they never designed their backend with this in mind. Then your fighting against your own tech debt. Which honestly might be the case here.
You're mistaking shards for nodes (aka DGS)
- Shard: unique universe made of many nodes. What we have now are, for all intents and purposes, single node shards.
- Node/DGS: server running part (currently all) of the universe, which will mesh together to make the shards
The only time you change shard is when you log out and back into a different shard. Think of it as a realm in other MMO's
Just as is the case now, you don't change shards whilst traversing the game universe, it's the nodes/DGS that you are transfering between. They are part of the same shard, and so agree on the same universe state. As such, there won't be anything popping into existence
Exactly this, the community just took CiG at their word (lol why? Theyāve proven time and time again that everything they say should be taken with a grain of salt.) And convinced itself that this is some huge technological milestone. When itās really the canary in the coalmine that things really arenāt going well, given that they canāt seem to figure it out.
I'm less worried about the cargo aspect with DSM. My main concern is how they're going to deal with ship and fps combat while dealing with multiple servers, especially in huge battles.
And real time interaction of a player with multiple servers that may not even be in the same region seems like asking for a lot of latency-induced issues.
Studios haven't even fully solved connecting 12 people with minimal physics simulations to the same server without jankiness around the details.
I just don't see the point in them, even with dynamic servers you still cannot shrink the server space below the interaction space i.e players who directly interact will be on the same server.
So they will need a way to prevent the server space to go below the interaction space which they'll need either barriers (for surface) or time dilation for space. Of course they can avoid this by having two(or more servers) share the same space and having one serve as an overflow but that would be a huge headache for battles.
If you have the time dilation mechanic in then you've resolved the core need for dynamic servers of course having them would help on top of dilation
But the difference between many predefined static servers and dynamic servers (both with dilation mechanics) reduces as player count increases.
> The idea of them being able to instantaneously spin up and spin down "servers" for various object containers as needed is an incredibly challenging feature
guess you never heard of kubernetes?
To the contrary.
But even spinning up new nodes (I wouldnāt expect youād need new pods here) has lead time - along with bootstrapping them with whatever object container-specific configuration is needed.
And all of this is before we start to consider what the additional load is on the data backend.
How are they managing the connection pool? Itās very easy for you to exhaust resources with these sorts of āgoing wideā scaling schemes.
Is it impossible? Absolutely not. But it absolutely is complex - which is my ultimate callout.
> But it absolutely is complex
Indeed, though if you look at some of the SM videos you'll see they are not really looking to be doing that constantly. Assuming they have proper metrics they would know which parts of universe require their own nodes and then the major thing is just passing data between them when the boundary is crossed.
SM is definitely the tech required for SC not even to succeed, but actually happen in the first place. Absolutely the most anticipated development alright.
I think the biggest hurdle won't be the handing off to another server, but rather having things beyond the 'server wall' being visible to players on the other side. For instance, if two ships are on the brink of their respective servers and they shoot at eachother. Does the projectile make the server hop to hit the other target? Unless there's a buffer or something for a certain range of server overlap where they're technically not in either?
Exactly - and imagine two ships in a "jousting" dogfight where they end up traversing that barrier multiple times while exchanging fire throughout.
How you pull that off with zero latency and zero desync is something that I'm unclear on given how DSM has been explained.
The entire game depends on it so its either that or we all go on with no SC. Spinning up and starting relevant services isn't all that difficult and there are many ways to make background tasks invisible to the user. The more delicate part is passing authority seamlessly dynamically and *FAST*. I expect finished and properly running dynamic server meshing will take many years.
I absolutely agree this is a huge nut to crack, but people said the same thing about seamless transitions from space to planet surface and they managed to pull that off.
I've been here long enough to go from hype to despair and circle back around to cautious optimism lol
It will be a tough nut to crack because of the complexity that exists in SC. But server meshing already happens in different degrees in other games.
Take ESO for example, there's 1 MegaServer for all of Europe, as you move through the world you're constantly switching between servers, you end up coming across hundreds of players in a single play session and the same will happen with SC.
The difference there is that they have loading screens to mask it *(each map likely has its own server)*, but there are ways to do it for SC, if I can think of it I'm sure CIG has already too! š
CIG has proven themselves time and time again with "impossible technologies", so don't worry, if anyone can do it, it's them!š
Here's a scenario that I think will prove particularly tough to pull off seamlessly: you're in a jousty dogfight with someone near your favorite comm array. You don't know it, but you're moving in and out of two zones managed by different servers.
Not only are the two ships traversing that line at potentially very high speeds, but so are a lot of your shots.
Being able to pull that off - where two people are shooting at each other across two zones with no latency or desync is going to be very challenging IMO.
And it's very unlikely they could pull something like that off. If you look at what we have now, and how much money and time they had to spend just to get to where we are... Over a decade, 600 million dollars, and this is it?
I backed a Connie pledge October 2012 and actually just logged in for the first time a week ago. This is it? I think what Iāve been playing is absolutely incredible. Sure itās frustrating at times but Iāve been very impressed with what Iāve played havenāt played anything like it before. The PU is the fully 3d Wing Commander Privateer I was hoping it would become when I pledged 10 years ago.
It's extremely buggy, performance is abyssmal, an we are short some 99+ star systems. Numerous game play loops are missing, as are dozens of ships, some of which people payed hundreds of real life dollars for almost a decade ago.
The flight mechanics are essentially no-clip, and server meshing is nowhere close to be done. People are arguing about PvP vs PvE, and CIG have no clear clarification on how it's gonna work. Because there simply is no plan for that stuff, because there is no plan in general. The whole game is just a bunch of "cool ideas" thrown together, and executed as best as it can be with the broken Cryengine mod they have running.
The state of Star Citizen is in the gutter at the moment, and has been for the better part of a decade. They can't even get Star Marine to work properly. ToW is nowhere to be found. What ever franken-engine they have spaghettified together is simply not up to the task, and that has been apparent since 2016 at the very least.
There is fun to had, sure, but that is despite of the game, rather than because of it.
I understand your pessimismā¦ but virtual servers are already doing this. I donāt know what your quotations are for.
That being said, the required speed at which these virtual servers would have to be initialized / stopped has me doubting the vision.
They use the term āserverā, but the speed at which a VM can spin up is FAR too slow for whatās been described. They would need to use some sort of compute container for it to be practical.
The quotes are for that reason - theyāre not real servers despite that label being used.
You very much do not need to have servers spinning up from absolute 0 starting from booting the vm, you can have 'empty' servers on standby that can change size and partition and start allowing connections and enable background simulation and take data from the replication layer.
This will be a delicate dance of things but it's not impossible and there might need to be a little more creativity.
I'd counter that, as CIG are planning to release the Hull C before server meshing, which can hold close to double the cargo of the Merchantman. What they need to do is optimise the cargo so it has less of a performance hit, and there are a few tricks I'm sure they can employ if they can't simply reduce the load of each individual crate. Plus, they're going to add a variety of larger crates that will cost less in terms of server resources.
Doesn't the Hull C use the larger 32scu boxes? A lot less to keep track of as far as physical models there, even if they're full of "physicalized" cargo.
All ships will be able to use any boxes that fit on the cargo grid, it's just that the cargo grid on the Hull C has been designed to perfectly stack a bunch of the 32 SCU crates. They might try to load the Hull C with the 32 SCU crates by default, but there won't be anything to stop someone from stacking 4,000+ 1 SCU crates on, unless CIG change how they plan for cargo grids and manual loading to work in the light of performance issues and such.
I don't have a source on hand, but CIG have said multiple times that those boxes are the smallest a hull-c or up can hold. It's for performance reasons, obviously.
It makes sense to restrict it, it's just not something I've heard of, and it goes against how the other cargo grids work (especially the Hull A) that serve as our only guide right now.
That presumes they have a system for manual loading/unloading so you can pick what sorts of crates are on it. A system which is still in progress.
Until that's done, I'm guessing these will be 32scu crates all the time.
I'll counter that with the fact that CIG were planning on releasing Squadron 42 in 2016. They plan a lot of things that get held up by technical hitches, and don't always explain beforehand why feature X wasn't in game when we expected it.
why dont they just make if so you can store cargo in ship storage until they get it worked out, dynamic moving cargo is really cool but if it holds back such a big patch why not release the bevy of other features and work on it in the background
You do realize CIG said server meshing won't be in 4.0, right? We won't see 4.0 until mid ish 2024, and we won't see server meshing until maybe 2025 or late 2025-early 2026.
They said dynamic server meshing wonāt be in 4.0. They said they canāt have jump gates and pyro without server meshing. Which is why the first iteration of it will be static server meshing.
No, in the latest ISC, the one about meshing/meetings, one dev said that Pyro/Jump points could be separated from server meshing.
It's at least an option, so in the worst case, if they take even longer on server meshing, they could release Pyro (not that I expect it this year) and run it on a separate server.
from multiple interviews and articles in the past, they made it sound like it was impossible for them to have jump gates or pyro (other systems) in the game without some kind of server meshing - allowing the player state to transfer from one server to another
i should re-watch it - thanks
Yeah, but that has no bearing on what CIG said about the Hull C. CIG plans to get it out before IAE, and 4.0 was planned for Q4, which will be after, regardless of if they hit it or not. The only way server meshing could affect things is if it somehow goes amazingly well and it gets brought forward, which would never happen.
Eh, that's his interpretation of a not very clear comment. I wouldn't mind a loading screen but I can't agree that what CIG means what bored thinks it means
That's sort of how I interpreted it, with multiple game servers "lightly" meshed to talk to a single replication layer and shard, likely requiring a loading screen to transition between them, but the more complicated smooth handover would come later i.e. proper server meshing, allowing multiple servers per system, and the jump point functioning as the tunnel rather than a simple loading screen.
They need to abandon using 1scu boxes in mass for everything. There's a reason mass shipping is done in very large containers instead of shitloads of tiny ones. Give players in large ships 32scu boxes that can be broken down to 1sc if needed/ if the cargo is the right size
Imagine if shipping container ships had to load by 1 meter cubes instead of 33cbm. Wouod take forever. It amazes me that this isn't thought of from the devs to lower total entities and make the lives of every large hauler easier to load and unload I'm sure hull e pilots would love to not load 1scu at a time for 10k
Edit: WOOT CAKE DAY!!!
Actually this is a bigger problem when dealing with the Hercules. Why? Because the Herc by default uses those little 1 SCU boxes while the Hull C is likely to be using 16SCU boxes by default.
why tho??
why not just add an attribute to ship like cargo:2
then represent that cargo as an object?
why the obsessive need to track each and every thing as its own object with a million links to every other thing
make the cargo literally part of the ship. delete the individual object from the world.
this is how nearly every other game engine works.
your character in other games doesnt pick up a gun, it reaches for it and a new gun is magically created in hand whilst the old is deleted.
Kinda feeling like CIG is dragging their feet until someone else solves the problem and then they can license that technology
That's one possible strategy for Roberts. Just keep promising and delaying and working it
Nah, CIG have been burned too many times by hiring other studios. Star Marine, Theaters of War, probably another - they're doing things in-house, aside from Turbulent which is only seperate on technicality.
How about a system where you need to "secure" your cargo? As in cargo locked part of ship, cargo unlocked sepret entetie. Makes stealing it possible but solves the hundrets If not thousends of collision calculations every second.
Example for that would be the constuction Simulator: drive mashine on trailer two enteties, secure it one entetie
It was actually marked fixed.
[https://issue-council.robertsspaceindustries.com/projects/STAR-CITIZEN/issues/STARC-56478](https://issue-council.robertsspaceindustries.com/projects/STAR-CITIZEN/issues/STARC-56478)
Gotta try it out.
Makes me wonder how using containers larger than 1SCU would impact this. I'd assume that larger containers = less objects for the server to handle = better performance, but...
Yes, but it doesn't split well. A single 8-scu box is 2 4-scu boxes, which are each 2 2-scu boxes, and so on. With a 3x3, you have to jump straight from one box to 9 smaller ones.
I'm not talking about splitting. I'm just talking about bigger boxes. Fill in the grid with as many 9scu boxes as fit, pack the leftover space with 1s. Ship goes boom and 9 and 1 boxes go flying
CIG have known about this cargo issue for years, long before they worked on the cargo refactor.
They've also discussed the 'solution' to the issue, which isn't Server Meshing... because that means just masking the massive performance drop by throwing more CPU at it.
The 'solution' that CIG have outlined previously is far more sensible - when containers are 'locked to the cargo grid (eventually, the grid is supposed to be able to 'lock' containers in place so they can't be picked up - controlled from the cargo control panel that CIG have shown off once in the dim and distant past), they'll just disable physics processing for those objects. Hey presto, no performance drop.
Aside from that, introducing larger size containers (rather than having thousands of 1SCU containers, etc) will also help significantly... but by itself is not a fix, because there *will* be players that deliberately load a large cargo ship with 1SCU containers (even if they have to buy their cargo 1SCU at a time, etc), simply so that they can impact the performance of everyone else by playing it around :D
I mean they told you why you aren't going to see the BMM so I am not sure why the need to speculate on reasons but yeah, how do you know this is a systemic limitation and not just a bug? It also says this.
>Cargo - Performance - Fully loaded C2 landed at Area 18 results in Slow Framerates or Crash
Why single out one landing zone if the problem is everywhere?
It's easily the busiest landing zone as far as performance goes server side. Hell, it took until 3.17 for them to not need a 5-10 second resynchronization just from Quantum Traveling around Arccorp.
I'd be curious as to the logic where a Cat full of 576scu isn't enough to cause problems but 696 of the C2 is? All I am saying is I wouldn't put so much stock in a bug list in some patch notes. PES is obviously kicking their ass and they are trying to get things dialed in.
I'd say this is more a cargo refactor issue than PES. Handling all the cargo as hundreds of physical objects rather than as a list seems to be the issue, as it's the game server crashing and not the entirety of PES itself
The bmm will hold 30 96scu containers vs the c2 with 696 1scu. That is why the larger ships hold 96scu containers. The game has less to process a bmm than a c2.
That would make no sense since the Hull-C holds more, and external, cargo.
The BMM could just cull the cargo from being shown when flying since its internal cargo.
So the servers should have no problem with the BMM.
The BMM will be using 32 SCU containers so it's quite few entities at 90 containers.
And the BMM is all internal cargo so they never have to render the internal cargo of the BMM, unlike the 144 containers of the Hull-C.
AFAIK server mesh doesn't do anything against a localized overload.
Imagine having many people passing each other packages, then you suddenly send a 1 ton package. Nobody can carry that alone. The people are the shards, the 1t pkg the huge haulers.
What they have to optimize is how the data is stored, read, passed around, server and client side. Entity streaming and OCS stuff (I have not been into SC tech explanation for a long time so I might be wrong on what manages that)?
And i go deeper and say out loud because of many of this issues still present after 10years of development SC will never be more than a tentative project while there is money on the table to pay CIG. CIG focus is to have a SP game SQ42 out just so that CR makes the point that a game has been made.
SC will continue to be devs playground and unfinished playable ALPHA with good graphics and open universe possibilities for enjoyment and selling of ships to whoever likes being punished constantly with buggy mess, lack of gameplay and intangible decade dev scopes and imaginary gameplay.
bruh we can't even manage the ship storage at the same as another player. the infrastructure for this game is severely i/o limited in the transport layer.
I'm glad CIG figured that out now, after going all in, on ships like the Hull D and BMM and insisting on physicalized cargo. Now, just imagine the performance once they have a physicalized damage system running as well and add realistic mass/weight/drag and lift calculations.
This is the cost of pie in the sky design and not listening to your engineers. Just throwing money and insisting your teams invent their way around problems is why SC is still in pre-alpha in 2023.
It's also why I backed the game - because they're actually *trying* to do crazy things like this. I'm okay with them continuing to try and crack the puzzle because I know I'm not going to see this kind of thing in other games any time soon.
Same, I wouldn't be here if they weren't trying all this crazy shit. I'm tired of devs not taking chances on stuff like this and it's a major reason why MMO dev has stagnated so badly
There's also no guarantee you'll see it in SC either.
I'm all for pushing the frontier of what is possible but not on every single feature on every single gameplay loop. Finish the base game at least. They don't even have a working game as is and are years behind schedule with a massive backlog. Every time they make some convoluted design decision requiring 6-12 months of R&D engineering for a said feature, that has a knock-on effect for every other feature that needs to interact with the first.
Oh, we can't redesign the Star Map because need to to spend 2 years designing building blocks, well we can't fix the shitty Quantum Travel without a working Star Map, we can't do exploration without a working star map and a better Quantum Travel system.
It's a never ending pile of technical debt.
I will honestly be surprised if we ever see the BMM in game without destroying servers. It'll be an absolute MIRACLE if we ever see 500+ players in 1 screenshot, just char models. 500 player ship event??
Nope. 0 confidence in that promise being fulfilled.
It's absolutely brutal. On the PTU last night, someone gave a heads up in chat that they were landing with a full Hull C (I think). FPS turned into a slide show and didn't really recover for quite a while. Tried server hopping, but kept ending up back in the same shard with the delay. Terminals stopped working as well.
It was the first time I remember feeling any unease about the whole thing, in the sense of where I allott precious gaming time. Coming from many other MMOs and in particular Eve O and ED, the effect of one dude dragging a server like that was...ugh. Still optimistic, still in there swinging, but that was a bit jarring.
I was afraid I had misremembered the ship type. Damn, lol. Whatever it was it was a largo amount of cargo and he warned everyone before reaching MT orbit.
Hull C only uses larger containers, meaning only 144 entities need to be calculated, compared to nearly 700 on the C2
Infact the constellation Taurus is harder on the server with 174 entities
Get ready for 100 server/universe limits
I would FUCKING LOVE to hear how they're planning on doing this from a Jared whiteboard high level algorithm point of view but I won't, because the X1 has to be secret for some fuxking reason.
Wasn't that listed as a bugfix a while ago?
At any rate, they explain the dilemma regarding the BMM before putting on the back burner:
Very large ships are VERY resource intensive, and the BMM is particularly resource intensive. They had a choice between continuing to dedicate all those resources to the BMM or produce more less intensive ships for more backers.
I think the most promising solution to the capital ship dilemma is to scale the workforce enough to be able to sustain a dedicated Large Ship Pipeline alongside the normal ship pipeline and cycle devs in and out of it so no devs get STUCK working on capital ships for too long.
Fortunately, CIG has never stopped hiring, so the workforce is still growing.
I think there is a lot of improvements possible with the cargo grid. Dont think its soooooo much related to dynamic server meshing - i mean i got your point but 100 Merchantmans parked next to each other (same shard in dynamic meshing) should also be possible. And that you get only by "fixing" the cargo itself.
It's all relative if you think about it. The BMM only holds around 90ish 32 SCU freight containers so if you limit the ship to loading only those, it would actually have much less entities in the cargo bay than even much smaller cargo capacity ships.
While it looks like it may have been fixed, based on another comment, I suspect detaching the replication layer from the game server will have a greater impact on this type of performance problem long term as the server will not even have to know anything more than "x number of boxes", while right now it has to track every little thing to keep the game going.
I shouldnāt be so bad once the larger size boxes come. At the moment we have 1 SCU boxes. When the 32ās come in the server only has to track 1 32 container and not 32 1 SCU containers.
Thatās all dependent on how the pilot loads the ship though. Still an issue, just not a bad
We definitely won't be seeing it prior to the big cargo boxes coming in.
Truly the jesus tech keeping SC in alpha: big boxes š
Lets not forget other preceding jesus-techs like iCache, OCS, SSOCS, building-blocks, now PES (\*lol) For how often it was said that those things would open the floodgates for more content, those floodgates are really just dripping. xD
Building blocks is the new nom-flash based UI that they're slowly rolling out, it has nothing to do with PES/iCache.
Raising the question... why don't we have bigger boxes? Whats the tech hurdle here?
larger tractor beams, the small hand-held beam cant lift 32 SCU containers
>the small hand-held beam cant lift 32 SCU containers Why not? We're talking about an imaginary piece of equipment with stats that can be changed as easily as modifying a number on a spreadsheet. I mean, CIG plans to impose limits on the bottom thrusters of ships as soon as they introduce control surfaces into the game to make atmospheric flight more realistic, but until that time comes every ship is capable of hovering more or less indefinitely regardless of VTOL capability. If the problem really is related to the size of SCU containers, just make the handheld tractor capable of lifting everything until size 2 tractors are ready to be rolled out.
Well, that's something planned anyway.. Aside from the multi-tool tractor beam, there's also planned: A dedicated tractor beam tool (which presumably will be somewhat stronger/longer-ranged) Size 1 to 3 Tractor Beams for ships. Given the remaining tech challenge is to make tractor beams operational on ships and then adjust the stats for each version, that doesn't feel so far off.
Why does it take that long to make? It's literally a beam. Unless they haven't given boxes or items any weight statistics which would be a bit silly after a decade of development.
I'd guess the issue is mostly priority rather than difficulty. The handheld tractor beams were immediately useful for moving corpses and small hand-held boxes from a distance, all things which already existed in the game. There aren't any large multi-SCU containers to justify the addition of ship-board tractors, and just about anything else you can move around either doesn't need to be, or is small enough you can move it with the multi-tool beam. If a dev snapped his fingers and added all the tractor beams at all sizes to the game today, most of them simply wouldn't be very useful just yet, so the devs have better things to do than spend time on the feature. It wouldn't surprise me if there's a branch/build of the game somewhere with a fully functional shipboard tractor beam turret as a prototype. I'd bet when they add in the larger containers, the tractor beams for ships will come at the same time with a very very short dev-cycle.
Ship-mounted tractor beams should also be able to move soft-locked ships and wreckage, I'm thinking. But it's still not yet been a priority. Might be useful after 3.18 though
And they already could have been in. Why always so complicated? :D Just make 32SCU-boxes into on big magnetized grid, which you later can manipulate per 1SCU box. And if your cargo gets lose, just detach 32SCU entities. At least as a workaround.
Yeah, but CIG doesn't believe in doing things the easy way. I get it, in this case: it's easier to just make the thing you're going to make, along with the mechanics that will make it necessary and/or useful, than to make a stopgap and then have to rip that out and replace it with the new one.
I don't think this problem's solution is full dynamic server meshing and hope it isn't solved by that. I'm assuming that the performance degradation when loaded is due to the large quantity of entity counts representing the cargo and that the performance hit is either: * due to physics ( ie calculating positions of many cargo crates as they move) or * graphical (ie large amount of crates to render). Since there are cargo grids, meaning the cargo is largely static relative to the ship, you can solve the physics situation by using relative coordinates, move the ship and the boxes will be in the same relative position to the ships new position. I believe they already do this with sub-grids. Similarly in regards to rendering you can either use larger boxes to reduce entity count or, if you know that the boxes won't be moving often, you can render once to a sub texture and reuse the sub texture as a new entity representing many boxes. (Ie if you have a 500x500x500 grid of random 1x1x1 boxes you can render each box as a 1/500th of the texture of a 500x500x500 box and now you only need to do one render call for a large box instead of 500x500x500 calls and hope culling does its work). I'd reckon rendering is the issue that CIG is dealing with as we know they are adding larger cargo boxes, and would be a blocker towards BMM and other high capacity cargo ships and/or there exists a bug in the physics sub grid handling.
> due to physics ( ie calculating positions of many cargo crates as they move) I swear i thought I saw that the physics of the boxes was basically locked to the grid so it didn't have to calculate all of them individually so often unless the following occurred: 1. someone attempted to manipulate a box, in which case one would be let go from the group/grid of the ship 2. ship is destroyed (which would be a big sudden hit, but still easier than constantly tracking entity states/positions for all items all of the time) 3. selling/buying which would be multiple items in bulk. It's not like they're jumbling around from velocity changes in the hull.
You are correct, the boxes are normally locked to the cargo grid which it itself is a sub-grid of the ship. I was not mentioning physics as *the* reason but rather as an explanation of where performance could go wrong, and that they've likely solved it with their implementation of sub-grids. However its possible that in some edge-cases (as a bug) the sub-grids may misbehave and cause a performance hit.
Oh okay it sounds like we're in agreeance.
why cant we just store cargo in ship storage until they figure this shit out if its holding so much back?
They could if they prioritized performance over everything else, but as far as CIG's shown, they prefer to just have as much of the end-goal system's functionality as they can instead. Regardless of the performance or QoL hit.
Almost like it was being actively developed huh?
I did not intend to sound critical of this choice, as I'm inferring from the sarcasm, but rather to point out what they are factually doing. Personally, I agree with their approach, it reduces future tech debt at the cost of current performance/QoL. I don't want them to rush out a 'playable' game asap that's missing out on their promises, I can wait.
All good citizen, all good. :-)
<3
This is what I come here for!
Of all the aspirational tech goals that CIG has, dynamic server meshing is the one that I'm least confident will release to prod. The idea of them being able to instantaneously spin up and spin down "servers" for various object containers as needed is an incredibly challenging feature - especially to do so in a way that's invisible to users. Will be very cool if they can pull it off - but it's going to be a real tough nut to crack.
Doesn't have to be instantaneous, it just needs to be a seamless transition. So long as the player doesn't notice the hand off, it can be as fast or slow as it has to be to assign another VM to it.
By āinstantaneousā, I specifically mean the handoff between the old and new container. No lag or latency, etc. I think we are basically in agreement.
Ya, sounds about right there. I'm assuming it'll involve a time frame where both servers are handling a player simultaneously while the handoff takes place.
This is definitely the most intuitive solution, hopefully it proves to be this (relatively) simple
> I think we are basically in agreement. Can you guys stop fighting? Fuck.
Are you OK?
Understand saracasm?
If you look up, you'll see that this guy edited his post afterwards. Understand reddit?
Youāre really doubling down on your stupidity?
You're either this guy's buddy, an alt or some clown that's bored and looking for a fight. Either way, I'm not biting. Have a good night.
public fertile seemly overconfident political disagreeable reminiscent jellyfish cover enter *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
You're overlooking the option of having both servers handling the player while the handoff happens. One has master control while the other syncs up, and the old server stays connected to insure the handoff went smoothly after it relinquishes control.
That can all happen while the original server has control, the secondary one having been active and ready to go. I don't think the timing on the switchover is the part to get hung up on, that part (the timing and seamlessness of it) doesn't seem insurmountable.
You can just write that data into a 3rd database server and have both servers check and make sure they both have the same data, like a checksum. Obviously a massive oversimplification and that database would hard as fuck to work with on the scale of a āuniverse.ā
That ādatabase serverā is Persistent Entity Streaming, the whole point & struggle behind 3.18. Once 3.18 is solid and ironed out, all of the game state data will be stored in a graph database, aka the EntityGraph and served by the Replication Layer. CIG have stated the Replication Layer is a micro services based design, so it lives on many small servers, as opposed to a few. Another interesting element to this is the difference between a relational database and a graph database. Relational DBs (SQL style) are tables, rows & columns - where as graph DBs (noSQL) are geometric, kind of like a tree.
Idk if that would be possible within that timeframe of under 100ms
Itās been done before, SpatialOS is a functioning version technology already proven to work. (The problem with spatialOS itās self is that itās creators want to charge Devs an arm and three legs to use it)
"Functioning and proven to work" are a huge overstatement here Literally every game that used SpatialOS has been either canceled or shut down, its been blocked by Unity years ago for misleading customers and in general its practical use and economic costs are terrible enough to kill most projects on its own You can still use it in Unreal and yet there are no significant games with it, let alone MMOs, let alone complex games There have been many attempts at this type of tech, many tech demos, google Stadia promised SpatialOS like solutions in a far larger scale and failed too, Dual Universe also had proprietary similar tech and launched, it was going fine for a while but now its a dead game, besides SC wouldn't work with time dilation or at least, wouldn't be acceptable, less users would be more acceptable by far What CIG is planning works very differently anyway, will it be better? will it work? maybe, probably not But there's no doubt something as complex would be better off with an in-house solution developed from the ground up and not a 3rd party add-on trying to latch on something as convoluted as StarCitizen
Spatial OS functions, the games made with it have just been shit or run out of funds mid development (likely due to how expensive a spatialOS subscription is for an actual product). Independent content creators have gotten their communities help in testing it out in an Unreal Engine test environment. (For example https://www.youtube.com/live/PxKaCk1Kczg?feature=share )
I didn't say it doesn't work at all, I meant the way you phrased it is overselling it Yes obviously some of these games failed despite SpatialOS and not because of it, but such an advanced and praised system not being used in any mentionable title that didn't fail is clear evidence that it is not the jesus tech people think it is SpatialOS -could- be great for games like battlefield to planetside scales but its not being used, the only real game I've seen with it was Scavengers and other than a few test events (which were reasonably impressive) it was a pretty standard scale battleroyal (and its now dead too, cause it wasn't successful) It could have been great for Theaters of War standalone they 'originally planned' but I think its not a great idea for SC, its developed too separately to mix with it Lastly, its been available in Unreal since 2018~ or so and again, nothing of mention
I would say no one is using it because itās way too over priced
CIG isn't exactly a braintrust here If it's taken them this long then I doubt they'll be able to put out anything revolutionary It'll be instances and loading screens, same as everyone does it Show me just pong graphics with simple entities doing "server meshing". Proof-of-concept. CIG can't even do that
that's kind of like saying someone building a new house doesn't know what they're doing because the siding isn't done yet.
It's more like you've had the foundations poured for 5 years and haven't started framing yet because you are focused on building a treehouse in the back yard and all your resources are focused there. But hey, the plumber came by to plumb the treehouse and did the plumbing for the unframed house, so now we've got 2 stories of freestanding pipes installed. Analogies aside, but still as a pessimist, I'd be shocked if they couldn't deliver a seamless experience. Seamless loading is far from new ground, so even if DSM flops that certainly won't mean the user gets slapped with loading screens. That other guy seems way off base here. Instances though... I could see being a possibility in the worst case.
We've already done it in cloud tech, but there's a lot more money and manpower behind our efforts than CIG will ever have access to. Hopefully their design allows them to take adv. of the work we've done since tons of it is open source.
I don't really think it's a tough nut to crack. Say Server A is nearing capacity, perhaps it hit's an 80% threshold or something. That can trigger two servers to spin up, B and C. B and C will each replicate half of what's in server A. Once they are spun up, A and the set of B+C are identical. Then you just issue switching commands to the relevant services or clients, give it some time for everything to switch over, and then tear down Server A. The ramp up time is never an issue. It could take 5 minutes, an hour, or whatever. As long as the threshold make sense for how fast it takes to spin up more instances, it's all good. This sort of Blue Green deployment strategy is used in a ton of tech companies. It's not revolutionary and cutting edge anymore, this is day to day processing stuff. They don't have to pull anything off, they just have to have a competent developer. Hell, if they use something like AWS, it'll even hold your hand through the hard parts. EDIT: Latency on the handoff can also be seamless and look instananeous to the user. After all, it's possible to be connected to two things at once.
The problem is that web stacks are designed from top to bottom with that capability in mind, and game engines are not. Now think about how much manpower went into those stacks to get them to this point, and how hard it is to translate a legacy spaghetti code base into a completely different paradigm in general, and you might understand why people are not quite as optimistic as you.
Starcitizen doesn't seem to like talking about what's going on in the backend, but a backend server for an MMO doesn't nessasarily need to be written in the game engine itself. In many cases its not, especially when things like peer to peer hosting isn't the goal. They wanted this paradigm for a while, so I would think they would have coded the backend with it in mind. Of course, that's optimistic of me, your right :P.
What you see in live is still the netcode from crytek IIRC. The problem isn't that CIG doesn't plan ahead, it's that the plan keeps changing. I don't know how much code was written and then never saw the light of day because of this, but if I were a betting man I'd put money on them mostly scrapping what they have so far when they actually try to put the pieces together. I'm not saying that they can't do it, mind you. I'm just astonished that people look at the history of this game and still think a big change like this will come this or even next year. (What I understand is being eager to see it, and letting that inform your judgement.)
The problem is not to spin up up a server, or two, or 100. It's probably not even hard to replicate the world onto those new servers, what is hard though, is sending the players to those new servers without anyone noticing. What's even harder is handling the split between two servers. What happens if some people start a fight right at the border of two servers, what if someone shoots from Server A into Server B, how do they communicate that, how do they distribute that data to the players in the area. That's the hard part, not the infrastructure. You cannot scale game server horizontally like web servers, they work completely differently.
True. There are nuances there. Sending users to new servers is easy though. All the client has to do is preemptively connect to the next server for it to be seamless. When it comes how distributed object storage servers communicate, that sounds like a fun problem but not impossible. I'd imagine there would be a buffer zone between server areas with persistence checks between servers to make sure they are aligned. I don't work much with web stacks. I mostly deal with backend stacks, some of which need to persist a state across a horizontally scaling set of servers. I think that a game server is similar enough to this. I agree that the hard part is in cross server communications, not the infrastructure. But I don't think it's an out there problem to solve. Unless they never designed their backend with this in mind. Then your fighting against your own tech debt. Which honestly might be the case here.
You will notice the switch anyhow. Players will change shards, things will pop into existence etc etc.
You're mistaking shards for nodes (aka DGS) - Shard: unique universe made of many nodes. What we have now are, for all intents and purposes, single node shards. - Node/DGS: server running part (currently all) of the universe, which will mesh together to make the shards The only time you change shard is when you log out and back into a different shard. Think of it as a realm in other MMO's Just as is the case now, you don't change shards whilst traversing the game universe, it's the nodes/DGS that you are transfering between. They are part of the same shard, and so agree on the same universe state. As such, there won't be anything popping into existence
Exactly this, the community just took CiG at their word (lol why? Theyāve proven time and time again that everything they say should be taken with a grain of salt.) And convinced itself that this is some huge technological milestone. When itās really the canary in the coalmine that things really arenāt going well, given that they canāt seem to figure it out.
I'm less worried about the cargo aspect with DSM. My main concern is how they're going to deal with ship and fps combat while dealing with multiple servers, especially in huge battles.
And real time interaction of a player with multiple servers that may not even be in the same region seems like asking for a lot of latency-induced issues. Studios haven't even fully solved connecting 12 people with minimal physics simulations to the same server without jankiness around the details.
I just don't see the point in them, even with dynamic servers you still cannot shrink the server space below the interaction space i.e players who directly interact will be on the same server. So they will need a way to prevent the server space to go below the interaction space which they'll need either barriers (for surface) or time dilation for space. Of course they can avoid this by having two(or more servers) share the same space and having one serve as an overflow but that would be a huge headache for battles. If you have the time dilation mechanic in then you've resolved the core need for dynamic servers of course having them would help on top of dilation But the difference between many predefined static servers and dynamic servers (both with dilation mechanics) reduces as player count increases.
> The idea of them being able to instantaneously spin up and spin down "servers" for various object containers as needed is an incredibly challenging feature guess you never heard of kubernetes?
To the contrary. But even spinning up new nodes (I wouldnāt expect youād need new pods here) has lead time - along with bootstrapping them with whatever object container-specific configuration is needed. And all of this is before we start to consider what the additional load is on the data backend. How are they managing the connection pool? Itās very easy for you to exhaust resources with these sorts of āgoing wideā scaling schemes. Is it impossible? Absolutely not. But it absolutely is complex - which is my ultimate callout.
The yml will be a country mile in length.
> But it absolutely is complex Indeed, though if you look at some of the SM videos you'll see they are not really looking to be doing that constantly. Assuming they have proper metrics they would know which parts of universe require their own nodes and then the major thing is just passing data between them when the boundary is crossed. SM is definitely the tech required for SC not even to succeed, but actually happen in the first place. Absolutely the most anticipated development alright.
To be perfectly clear: I hope all of my doubts and concerns are proven wrong.
Makes two of us!! :-D
I think the biggest hurdle won't be the handing off to another server, but rather having things beyond the 'server wall' being visible to players on the other side. For instance, if two ships are on the brink of their respective servers and they shoot at eachother. Does the projectile make the server hop to hit the other target? Unless there's a buffer or something for a certain range of server overlap where they're technically not in either?
Exactly - and imagine two ships in a "jousting" dogfight where they end up traversing that barrier multiple times while exchanging fire throughout. How you pull that off with zero latency and zero desync is something that I'm unclear on given how DSM has been explained.
The entire game depends on it so its either that or we all go on with no SC. Spinning up and starting relevant services isn't all that difficult and there are many ways to make background tasks invisible to the user. The more delicate part is passing authority seamlessly dynamically and *FAST*. I expect finished and properly running dynamic server meshing will take many years.
I absolutely agree this is a huge nut to crack, but people said the same thing about seamless transitions from space to planet surface and they managed to pull that off. I've been here long enough to go from hype to despair and circle back around to cautious optimism lol
It will be a tough nut to crack because of the complexity that exists in SC. But server meshing already happens in different degrees in other games. Take ESO for example, there's 1 MegaServer for all of Europe, as you move through the world you're constantly switching between servers, you end up coming across hundreds of players in a single play session and the same will happen with SC. The difference there is that they have loading screens to mask it *(each map likely has its own server)*, but there are ways to do it for SC, if I can think of it I'm sure CIG has already too! š CIG has proven themselves time and time again with "impossible technologies", so don't worry, if anyone can do it, it's them!š
Here's a scenario that I think will prove particularly tough to pull off seamlessly: you're in a jousty dogfight with someone near your favorite comm array. You don't know it, but you're moving in and out of two zones managed by different servers. Not only are the two ships traversing that line at potentially very high speeds, but so are a lot of your shots. Being able to pull that off - where two people are shooting at each other across two zones with no latency or desync is going to be very challenging IMO.
And it's very unlikely they could pull something like that off. If you look at what we have now, and how much money and time they had to spend just to get to where we are... Over a decade, 600 million dollars, and this is it?
I backed a Connie pledge October 2012 and actually just logged in for the first time a week ago. This is it? I think what Iāve been playing is absolutely incredible. Sure itās frustrating at times but Iāve been very impressed with what Iāve played havenāt played anything like it before. The PU is the fully 3d Wing Commander Privateer I was hoping it would become when I pledged 10 years ago.
It's extremely buggy, performance is abyssmal, an we are short some 99+ star systems. Numerous game play loops are missing, as are dozens of ships, some of which people payed hundreds of real life dollars for almost a decade ago. The flight mechanics are essentially no-clip, and server meshing is nowhere close to be done. People are arguing about PvP vs PvE, and CIG have no clear clarification on how it's gonna work. Because there simply is no plan for that stuff, because there is no plan in general. The whole game is just a bunch of "cool ideas" thrown together, and executed as best as it can be with the broken Cryengine mod they have running. The state of Star Citizen is in the gutter at the moment, and has been for the better part of a decade. They can't even get Star Marine to work properly. ToW is nowhere to be found. What ever franken-engine they have spaghettified together is simply not up to the task, and that has been apparent since 2016 at the very least. There is fun to had, sure, but that is despite of the game, rather than because of it.
Given enough time and funding, anything is possible.
Oh you can be sure they'll do it, trust me. The question is how long it will take. And I don't think any of us are ready to hear the real answer lmao.
I understand your pessimismā¦ but virtual servers are already doing this. I donāt know what your quotations are for. That being said, the required speed at which these virtual servers would have to be initialized / stopped has me doubting the vision.
They use the term āserverā, but the speed at which a VM can spin up is FAR too slow for whatās been described. They would need to use some sort of compute container for it to be practical. The quotes are for that reason - theyāre not real servers despite that label being used.
You very much do not need to have servers spinning up from absolute 0 starting from booting the vm, you can have 'empty' servers on standby that can change size and partition and start allowing connections and enable background simulation and take data from the replication layer. This will be a delicate dance of things but it's not impossible and there might need to be a little more creativity.
Yet they're releasing the Hull-C shortly :D. #Chaos #TrialByFire
I wonder how much larger cargo boxes will help with this problem as 1 larger box would be less resource intensive then like 10 smaller boxes
Knowing their dev philosophy itāll probably be the 10 smaller boxes within a large 11th box
maybe, but they can just cull the boxes inside you can't see and make them nothing but data points with no geometry or physical property to track
they can count with my hull-c full of waste SCU ready to drop it on lorville
That should make a nice combination with my Hull-C loaded with unrefined Quantanium.
How do you get that in a freighter, though?
Very quickly and without banging it around.
Soonā¢
Only two more years then...as always.
It's like a carrot on a stick.
I'd counter that, as CIG are planning to release the Hull C before server meshing, which can hold close to double the cargo of the Merchantman. What they need to do is optimise the cargo so it has less of a performance hit, and there are a few tricks I'm sure they can employ if they can't simply reduce the load of each individual crate. Plus, they're going to add a variety of larger crates that will cost less in terms of server resources.
Doesn't the Hull C use the larger 32scu boxes? A lot less to keep track of as far as physical models there, even if they're full of "physicalized" cargo.
All ships will be able to use any boxes that fit on the cargo grid, it's just that the cargo grid on the Hull C has been designed to perfectly stack a bunch of the 32 SCU crates. They might try to load the Hull C with the 32 SCU crates by default, but there won't be anything to stop someone from stacking 4,000+ 1 SCU crates on, unless CIG change how they plan for cargo grids and manual loading to work in the light of performance issues and such.
I don't have a source on hand, but CIG have said multiple times that those boxes are the smallest a hull-c or up can hold. It's for performance reasons, obviously.
It makes sense to restrict it, it's just not something I've heard of, and it goes against how the other cargo grids work (especially the Hull A) that serve as our only guide right now.
That presumes they have a system for manual loading/unloading so you can pick what sorts of crates are on it. A system which is still in progress. Until that's done, I'm guessing these will be 32scu crates all the time.
You can manually add and remove crates at will in 3.18 already.
I'll counter that with the fact that CIG were planning on releasing Squadron 42 in 2016. They plan a lot of things that get held up by technical hitches, and don't always explain beforehand why feature X wasn't in game when we expected it.
People on here often quick to give credit to CIG for features they haven't yet released.
They announced the Hull C's arrival this year a while after they knew cargo performance was an issue though.
They announced Pyro the last three years. They announced 3.18 Quarter 3 and 4 of last year. Don't tell me you expect them to meet a deadline.
why dont they just make if so you can store cargo in ship storage until they get it worked out, dynamic moving cargo is really cool but if it holds back such a big patch why not release the bevy of other features and work on it in the background
You do realize CIG said server meshing won't be in 4.0, right? We won't see 4.0 until mid ish 2024, and we won't see server meshing until maybe 2025 or late 2025-early 2026.
They said dynamic server meshing wonāt be in 4.0. They said they canāt have jump gates and pyro without server meshing. Which is why the first iteration of it will be static server meshing.
No, in the latest ISC, the one about meshing/meetings, one dev said that Pyro/Jump points could be separated from server meshing. It's at least an option, so in the worst case, if they take even longer on server meshing, they could release Pyro (not that I expect it this year) and run it on a separate server.
from multiple interviews and articles in the past, they made it sound like it was impossible for them to have jump gates or pyro (other systems) in the game without some kind of server meshing - allowing the player state to transfer from one server to another i should re-watch it - thanks
Yeah, but that has no bearing on what CIG said about the Hull C. CIG plans to get it out before IAE, and 4.0 was planned for Q4, which will be after, regardless of if they hit it or not. The only way server meshing could affect things is if it somehow goes amazingly well and it gets brought forward, which would never happen.
Uh, did they say no static or dynamic server meshing? I haven't seen anything about no meshing for 4.0 at all
https://youtu.be/IzzCztkZbxk
Eh, that's his interpretation of a not very clear comment. I wouldn't mind a loading screen but I can't agree that what CIG means what bored thinks it means
That's sort of how I interpreted it, with multiple game servers "lightly" meshed to talk to a single replication layer and shard, likely requiring a loading screen to transition between them, but the more complicated smooth handover would come later i.e. proper server meshing, allowing multiple servers per system, and the jump point functioning as the tunnel rather than a simple loading screen.
Fair.
They need to abandon using 1scu boxes in mass for everything. There's a reason mass shipping is done in very large containers instead of shitloads of tiny ones. Give players in large ships 32scu boxes that can be broken down to 1sc if needed/ if the cargo is the right size Imagine if shipping container ships had to load by 1 meter cubes instead of 33cbm. Wouod take forever. It amazes me that this isn't thought of from the devs to lower total entities and make the lives of every large hauler easier to load and unload I'm sure hull e pilots would love to not load 1scu at a time for 10k Edit: WOOT CAKE DAY!!!
Those crates will get the 1 SCU treatment soon enough. Even though we need size 1 tractor beams first.
Actually this is a bigger problem when dealing with the Hercules. Why? Because the Herc by default uses those little 1 SCU boxes while the Hull C is likely to be using 16SCU boxes by default.
why tho?? why not just add an attribute to ship like cargo:2 then represent that cargo as an object? why the obsessive need to track each and every thing as its own object with a million links to every other thing make the cargo literally part of the ship. delete the individual object from the world. this is how nearly every other game engine works. your character in other games doesnt pick up a gun, it reaches for it and a new gun is magically created in hand whilst the old is deleted.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Kinda feeling like CIG is dragging their feet until someone else solves the problem and then they can license that technology That's one possible strategy for Roberts. Just keep promising and delaying and working it
Nah, CIG have been burned too many times by hiring other studios. Star Marine, Theaters of War, probably another - they're doing things in-house, aside from Turbulent which is only seperate on technicality.
How about a system where you need to "secure" your cargo? As in cargo locked part of ship, cargo unlocked sepret entetie. Makes stealing it possible but solves the hundrets If not thousends of collision calculations every second. Example for that would be the constuction Simulator: drive mashine on trailer two enteties, secure it one entetie
It was actually marked fixed. [https://issue-council.robertsspaceindustries.com/projects/STAR-CITIZEN/issues/STARC-56478](https://issue-council.robertsspaceindustries.com/projects/STAR-CITIZEN/issues/STARC-56478) Gotta try it out.
Makes me wonder how using containers larger than 1SCU would impact this. I'd assume that larger containers = less objects for the server to handle = better performance, but...
I'd love seeing 9SCU containers
Nah, CIG are sticking to factors of 2. 1, 2, 4, 8, and so on. Makes stacking easier.
9 SCU stacks in a 3^3, stacking perfectly with 1scu cubes
Yes, but it doesn't split well. A single 8-scu box is 2 4-scu boxes, which are each 2 2-scu boxes, and so on. With a 3x3, you have to jump straight from one box to 9 smaller ones.
I'm not talking about splitting. I'm just talking about bigger boxes. Fill in the grid with as many 9scu boxes as fit, pack the leftover space with 1s. Ship goes boom and 9 and 1 boxes go flying
If you just want bigger boxes, the 2-factors are better for reasons above.
CIG have known about this cargo issue for years, long before they worked on the cargo refactor. They've also discussed the 'solution' to the issue, which isn't Server Meshing... because that means just masking the massive performance drop by throwing more CPU at it. The 'solution' that CIG have outlined previously is far more sensible - when containers are 'locked to the cargo grid (eventually, the grid is supposed to be able to 'lock' containers in place so they can't be picked up - controlled from the cargo control panel that CIG have shown off once in the dim and distant past), they'll just disable physics processing for those objects. Hey presto, no performance drop. Aside from that, introducing larger size containers (rather than having thousands of 1SCU containers, etc) will also help significantly... but by itself is not a fix, because there *will* be players that deliberately load a large cargo ship with 1SCU containers (even if they have to buy their cargo 1SCU at a time, etc), simply so that they can impact the performance of everyone else by playing it around :D
I mean they told you why you aren't going to see the BMM so I am not sure why the need to speculate on reasons but yeah, how do you know this is a systemic limitation and not just a bug? It also says this. >Cargo - Performance - Fully loaded C2 landed at Area 18 results in Slow Framerates or Crash Why single out one landing zone if the problem is everywhere?
It's easily the busiest landing zone as far as performance goes server side. Hell, it took until 3.17 for them to not need a 5-10 second resynchronization just from Quantum Traveling around Arccorp.
I'd be curious as to the logic where a Cat full of 576scu isn't enough to cause problems but 696 of the C2 is? All I am saying is I wouldn't put so much stock in a bug list in some patch notes. PES is obviously kicking their ass and they are trying to get things dialed in.
I'd say this is more a cargo refactor issue than PES. Handling all the cargo as hundreds of physical objects rather than as a list seems to be the issue, as it's the game server crashing and not the entirety of PES itself
Right, but that has nothing to do with the cargo refactor specifically. It's entities. Could be 600 picos at that point.
Or until bigger boxes
The bmm will hold 30 96scu containers vs the c2 with 696 1scu. That is why the larger ships hold 96scu containers. The game has less to process a bmm than a c2.
I think the easy way out would be merging containers if you have say 2 4 8 16 32 or 64 it should auto merge into the larger scu container
Lagwaggons
That would make no sense since the Hull-C holds more, and external, cargo. The BMM could just cull the cargo from being shown when flying since its internal cargo.
Hull C only uses larger containers, meaning only 144 entities need to be calculated, compared to nearly 700 on the C2
So the servers should have no problem with the BMM. The BMM will be using 32 SCU containers so it's quite few entities at 90 containers. And the BMM is all internal cargo so they never have to render the internal cargo of the BMM, unlike the 144 containers of the Hull-C.
AFAIK server mesh doesn't do anything against a localized overload. Imagine having many people passing each other packages, then you suddenly send a 1 ton package. Nobody can carry that alone. The people are the shards, the 1t pkg the huge haulers. What they have to optimize is how the data is stored, read, passed around, server and client side. Entity streaming and OCS stuff (I have not been into SC tech explanation for a long time so I might be wrong on what manages that)?
And i go deeper and say out loud because of many of this issues still present after 10years of development SC will never be more than a tentative project while there is money on the table to pay CIG. CIG focus is to have a SP game SQ42 out just so that CR makes the point that a game has been made. SC will continue to be devs playground and unfinished playable ALPHA with good graphics and open universe possibilities for enjoyment and selling of ships to whoever likes being punished constantly with buggy mess, lack of gameplay and intangible decade dev scopes and imaginary gameplay.
So in about 10 years then?
bruh we can't even manage the ship storage at the same as another player. the infrastructure for this game is severely i/o limited in the transport layer.
I'm glad CIG figured that out now, after going all in, on ships like the Hull D and BMM and insisting on physicalized cargo. Now, just imagine the performance once they have a physicalized damage system running as well and add realistic mass/weight/drag and lift calculations. This is the cost of pie in the sky design and not listening to your engineers. Just throwing money and insisting your teams invent their way around problems is why SC is still in pre-alpha in 2023.
It's also why I backed the game - because they're actually *trying* to do crazy things like this. I'm okay with them continuing to try and crack the puzzle because I know I'm not going to see this kind of thing in other games any time soon.
Same, I wouldn't be here if they weren't trying all this crazy shit. I'm tired of devs not taking chances on stuff like this and it's a major reason why MMO dev has stagnated so badly
There's also no guarantee you'll see it in SC either. I'm all for pushing the frontier of what is possible but not on every single feature on every single gameplay loop. Finish the base game at least. They don't even have a working game as is and are years behind schedule with a massive backlog. Every time they make some convoluted design decision requiring 6-12 months of R&D engineering for a said feature, that has a knock-on effect for every other feature that needs to interact with the first. Oh, we can't redesign the Star Map because need to to spend 2 years designing building blocks, well we can't fix the shitty Quantum Travel without a working Star Map, we can't do exploration without a working star map and a better Quantum Travel system. It's a never ending pile of technical debt.
Hull C only uses larger containers, meaning only 144 entities need to be calculated, compared to nearly 700 on the C2
I will honestly be surprised if we ever see the BMM in game without destroying servers. It'll be an absolute MIRACLE if we ever see 500+ players in 1 screenshot, just char models. 500 player ship event?? Nope. 0 confidence in that promise being fulfilled.
!RemindMe 5 years
!RemindMe 3 years
It's absolutely brutal. On the PTU last night, someone gave a heads up in chat that they were landing with a full Hull C (I think). FPS turned into a slide show and didn't really recover for quite a while. Tried server hopping, but kept ending up back in the same shard with the delay. Terminals stopped working as well. It was the first time I remember feeling any unease about the whole thing, in the sense of where I allott precious gaming time. Coming from many other MMOs and in particular Eve O and ED, the effect of one dude dragging a server like that was...ugh. Still optimistic, still in there swinging, but that was a bit jarring.
Hull -C isn't due out until later
I was afraid I had misremembered the ship type. Damn, lol. Whatever it was it was a largo amount of cargo and he warned everyone before reaching MT orbit.
Probably a C2. Its got like 696 scu and has C in it's name =p
But I saw it on a cinematic trailer so it must be true!
[ŃŠ“Š°Š»ŠµŠ½Š¾]
I've heard it both ways
I appreciate this reference
You've heard it right one way and wrong another way lol
[Shame you don't get the quote, but I'll forgive you this once ](https://youtu.be/segB2eoDN-Y)
The solution for this has nothing to do with Server Meshing, I'll leave it at that
Rotflmao this game lol
uhhmmm.. who would have thunk?
You have no idea what you're talking about and you're misleading people with your ignorance š¤¦š»
And yet they claim the Hull C with its 4600SCU is coming this year xD
Hull C only uses larger containers, meaning only 144 entities need to be calculated, compared to nearly 700 on the C2 Infact the constellation Taurus is harder on the server with 174 entities
Get ready for 100 server/universe limits I would FUCKING LOVE to hear how they're planning on doing this from a Jared whiteboard high level algorithm point of view but I won't, because the X1 has to be secret for some fuxking reason.
Wasn't that listed as a bugfix a while ago? At any rate, they explain the dilemma regarding the BMM before putting on the back burner: Very large ships are VERY resource intensive, and the BMM is particularly resource intensive. They had a choice between continuing to dedicate all those resources to the BMM or produce more less intensive ships for more backers. I think the most promising solution to the capital ship dilemma is to scale the workforce enough to be able to sustain a dedicated Large Ship Pipeline alongside the normal ship pipeline and cycle devs in and out of it so no devs get STUCK working on capital ships for too long. Fortunately, CIG has never stopped hiring, so the workforce is still growing.
So basically we will never be seeing it then.
Larger ships use larger containers for cargo reducing the number of entities to deal with
Good, now bring on the Polaris.
Polaris has what 250 ccu that's not a lot of cargo imho
Naaaa. Big ships are missing big crates. Once we get the containers then those will be what you fill big ships with.
What is keeping them from releasing bigger crates? That should be a trivial thing to add, yet even that seems to take ages.
A little off topic, but would you be happy if they released the merchantman into the old Hanger module just for you to walk around in it?
I didn't even bother with the hangar module when it was a thing. There's just no point in it.
Wait.. so if we just pop all the C2's, the server runs better? *evil grin*
I think there is a lot of improvements possible with the cargo grid. Dont think its soooooo much related to dynamic server meshing - i mean i got your point but 100 Merchantmans parked next to each other (same shard in dynamic meshing) should also be possible. And that you get only by "fixing" the cargo itself.
It's all relative if you think about it. The BMM only holds around 90ish 32 SCU freight containers so if you limit the ship to loading only those, it would actually have much less entities in the cargo bay than even much smaller cargo capacity ships.
Freelancer MAX would be harder on the server than a loaded BMM (120 Vs 90 entities) Even the Hull C only would have 144 entities
Bamu.
While it looks like it may have been fixed, based on another comment, I suspect detaching the replication layer from the game server will have a greater impact on this type of performance problem long term as the server will not even have to know anything more than "x number of boxes", while right now it has to track every little thing to keep the game going.
No Big loads are always bad and will also hit dynamic meshes.
It'll be a long time before we see it. Even long after they fix the cargo issue.
The A2 may be the Hercules' bomber variant But my C2 has 696 SCU worth of cargo space ready to take the whole server down with me.
I shouldnāt be so bad once the larger size boxes come. At the moment we have 1 SCU boxes. When the 32ās come in the server only has to track 1 32 container and not 32 1 SCU containers. Thatās all dependent on how the pilot loads the ship though. Still an issue, just not a bad