Author Topic: Star Citizen General BS  (Read 2174352 times)

Spunky Munkee

  • Sr. Member
  • ****
  • Posts: 253
Re: Star Citizen - General
« Reply #1860 on: February 24, 2018, 11:58:56 PM »
The house of smoke and mirrors is crumbling around them. Even their grinning idiot supporters are watching in horror as they realize that this is all bullshit and they have entrusted couintless millions to an imbecile. This is glorious. It's like being at Mount  Vesuvius and getting a frame by frame breakdown of the shitizens trying to outrun the pyroiclastic flow. Thyey are now realizing that it's too late and they cannot escape...

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen - General
« Reply #1861 on: February 25, 2018, 07:32:06 AM »
Clive has responded on Spectrum

Quote
We decided it was necessary to push Bind Culling back for the following reasons:

1) Progress has been slower than we had hoped, partly due to taking longer than anticipated to convert the last few places in the code that were using old-style Aspects and RMIs to Serialized Variables and Remote Methods, and then completely strip those legacy systems from the network code. That was a necessary step because we didn't want to have to implement Bind Culling for both the old and new systems. I'm not embarrassed to tell you there was some dancing and a few air-punches on my part when the last line of that old code was deleted.

2) There wouldn't have been enough time left before 3.1 for the network and gameplay programmers to deal with the issues we’re expecting the introduction of Bind Culling to cause.

3) Bind Culling would result in clients streaming entities in and out based on distance, but without asynchronous Object Container Streaming it was always a gamble whether the resulting synchronous loading stalls would be worse or better than what players experience now. The plan was to get Bind Culling working, see what the impact on player experience was and then make the call whether to turn it on for 3.1.

4) Range-based Serialized Variable Culling was our backup plan in case Bind Culling didn't make it into 3.1. You may remember that we were working on SV Culling for 3.0 but that it wasn't quite ready in time. Well, it was the first thing we tackled when we came back at the start of the year, and has been working in our development branch for several weeks now (not the branch 3.0.1 was taken from). SV Culling already gives us a lot of the performance gain we would expect from Bind Culling so the urgency for the later has dropped significantly.

5) The network team is needed for other tasks that have increased in priority since they were first added to our schedule.

And this was less than 24hrs after I posted this scoop

https://twitter.com/dsmart/status/967575127587262464

Quote
Star Citizen 3.1 was due out end of March. I am hearing that it's way behind schedule.

Also, they can't get network traffic culling working - at all. So don't expect it anytime soon - if ever.

They also sent out Evocati notice that they may increase it to 2000 invites.
« Last Edit: February 25, 2018, 09:51:49 AM by dsmart »
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

N0mad

  • Hero Member
  • *****
  • Posts: 597
Re: Star Citizen - General
« Reply #1862 on: February 25, 2018, 08:51:57 AM »
I'm sure this has been dealt with already, but... WTF is Bind Culling meant to be? Or Range-based Serialised Variable Culling for that matter?  Is it even a networking term? Because if I Google Bind Culling all I get is articles from Reddit all asking what Bind Culling is.

I get that it's meant to be some form of network data culling so that distant objects are updated less frequently - much like the sort of thing Dual Universe is trying to achieve (although they also incorporate server meshing). However I can't help but feel that it's the latest in a long line of bullshit technical terms from CIG to disguise the fact that they can't do it and to give the zealots something to talk about and be hopeful for.

PS. whilst Culling may be helpful for the client, isn't the server still having to cope with updates for a horrendous number of entities and then keep track of which client needs to know about them - so no performance gains on the server side and a slow sim speed (which is why Dual Universe does it with server meshes)?
« Last Edit: February 25, 2018, 08:57:28 AM by N0mad »

David-2

  • Full Member
  • ***
  • Posts: 152
Re: Star Citizen - General
« Reply #1863 on: February 25, 2018, 12:26:28 PM »
I don't understand how 3.1 can possibly be behind schedule.  I thought the whole revamp of the schedule for this year was that they're going to drop on calendar dates come hell or high water - and what's in the build is in the build and what isn't isn't.  No?  So the schedule is set by the motion of the Earth around the Sun and that hasn't been late in 4 billion years ...

On the other hand it is totally believable (i.e., totally expected) that what's in the build on March 31st isn't anything like what they said was going to be in the build ...


N0mad

  • Hero Member
  • *****
  • Posts: 597
Re: Star Citizen - General
« Reply #1864 on: February 25, 2018, 04:00:13 PM »
I suspect that we'll get everything promised for 3.1 delivered in four quarterly releases over the year, and not much else.

krylite

  • Full Member
  • ***
  • Posts: 197
Re: Star Citizen - General
« Reply #1865 on: February 25, 2018, 06:52:34 PM »
SQ42 update! I can't believe these guys:


It's a space sim, so what do they spend all their time doing? Trying to make a real life simulator for all the NPCs on the ship. They pre-script all the tech demos, but when it comes to the game Chris Roberts needs it to be like The Sims. Just look at the debug info at 32.00 - each NPC has stats like morale, reliability, virtue, hygiene, sustenance and fatigue. No wonder they haven't released the game yet if they're making everything this complicated.

Also pushing the ship sales hard at the end I noticed.

I hope ED ends up doing some form of mmo-rpg for eventual spacelegs for pcs and npcs. Of course the big difference is ED already has a well working space & FTL spaceship simulator already where they've been careful to gradually add on what they can over time with chapter 1 Beyond dropping on Tuesday cleaned of gamestopping bugs despite the trollish naysayers on the ED forum.

cig-arretts just needs to fold, go bankrupt or go away. This farce has gone on long enough. Sickening to see the guy next to Sandi doing the "pledge" pitch again in that ATV at the end. It's like cig/CR pretending to keep "pace" with ED promising new features that long time ED players dream of, yet they haven't made it past the first lap on the track overlapped by ED several times over. History has long passed SC by and it's only the shitizens keeping this leaking lifeboat afloat.
« Last Edit: February 25, 2018, 06:59:46 PM by krylite »

Kyrt

  • Full Member
  • ***
  • Posts: 176
Re: Star Citizen - General
« Reply #1866 on: February 25, 2018, 08:17:19 PM »
I hope ED ends up doing some form of mmo-rpg for eventual spacelegs for pcs and npcs. Of course the big difference is ED already has a well working space & FTL spaceship simulator already where they've been careful to gradually add on what they can over time with chapter 1 Beyond dropping on Tuesday cleaned of gamestopping bugs despite the trollish naysayers on the ED forum.

I can't see that happening.

There is simply no need for it. FD is well aware of the limitations of a life simulator, and it (like other games) puts in shortcuts to avoid certain aspects of reality that don't enhance the game.

Space Legs is something I think will happen within Elite. In many ways, it is easy to do. The problem is having the content and mechanics necessary to make it worthwhile. To justify adding it. I don't think CIG has done that with SC. There is a lot of makework style content put in simply so CIG can justify the effort used in spacelegs.

FD is not likely to pout the same focus on Space legs, or the same level of resources, because space legs isn't going to have the same degree of importance to ED as it does for SC. So while SC will force you into travelling to the bar, ED will let you use HoloMe or a phone call. ED won't make you spend 30 minutes walking through corridors to get to your ship - it'll let you step there immediately.

Thing is - while Space Legs has value, and is worth adding, we just need to look at games like EVE and even SC to show the limitations of the system and how it doesn't really work all that well. As FD stated, it'll be like developing an entirely different game, with different requirements and balancing concerns and gameplay mechanics and more. Space Les ha a lot to offer.....but it's also important to realise it cannot offer everything people seem to want.


David-2

  • Full Member
  • ***
  • Posts: 152
Re: Star Citizen - General
« Reply #1867 on: February 25, 2018, 08:41:42 PM »
Just look at the debug info at 32.00 - each NPC has stats like morale, reliability, virtue, hygiene, sustenance and fatigue.

You know what?  This is an actual sign that they attempted at one point to actually implement a subsumption AI.  This is the kind of thing you'd need for that. 

Not that I believe for a New York minute that we'll ever see it ... but they did have dreams!

DemonInvestor

  • Full Member
  • ***
  • Posts: 162
Re: Star Citizen - General
« Reply #1868 on: February 25, 2018, 11:39:04 PM »
You know what?  This is an actual sign that they attempted at one point to actually implement a subsumption AI.  This is the kind of thing you'd need for that. 

Not that I believe for a New York minute that we'll ever see it ... but they did have dreams!

My impression still is that CRoberts is a lot like Peter Molyneux, though he doesn't feel any business constraints.
And as always i'm baffled as to them realizing computers won't be able to handle all those physics objects, while not backpedaling on the physical simulation of trade good crates and such.

Bubba

  • Jr. Member
  • **
  • Posts: 90
Re: Star Citizen - General
« Reply #1869 on: February 26, 2018, 12:16:33 AM »
You know, I think Clive said everything with #5: new tasks were added and given higher priority. Having a boss incapable of distinguishing between the visionary and the hallucinatory, I've had to write that line myself. It's a coded cry for help, for relief from an oppressively incompetent management.

N0mad

  • Hero Member
  • *****
  • Posts: 597
Re: Star Citizen - General
« Reply #1870 on: February 26, 2018, 01:22:33 AM »
My impression still is that CRoberts is a lot like Peter Molyneux, though he doesn't feel any business constraints.
And as always i'm baffled as to them realizing computers won't be able to handle all those physics objects, while not backpedaling on the physical simulation of trade good crates and such.

Molyneux made original games, often because nobody else was crazy enough to give those sorts of things a go, but he still made it work. Chris Roberts has never had an original idea in his life - everything he does is a pretty basic rip off of something else.

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen - General
« Reply #1871 on: February 26, 2018, 11:05:52 AM »
You know, I think Clive said everything with #5: new tasks were added and given higher priority. Having a boss incapable of distinguishing between the visionary and the hallucinatory, I've had to write that line myself. It's a coded cry for help, for relief from an oppressively incompetent management.

Yes, pretty much.

This whole culling thing isn't clear to a lot of backers. There are two parts.

One is culling of render target entities.

The other is culling of network traffic entities which happen to be within the render target entities also.

To wit:

- don't render anything the client/player can't see or interact with. e.g. > 5km away

- don't send network traffic to any client/player if they can't see or interact with entities within that < 5km packet

The sad reality is that these two features are so rudimentary and the mainstay of ALL 3D graphics & multiplayer games, that CIG even making them a big deal (serialized variables was the Red flag, right off the bat) is testament to the difficulty (I don't want to say incompetence, as that would be unfair to the devs) they are facing building this game.

To me, the surprising thing is that they have the "ex-Crytek Gods" at F42-GER, and somehow for the 3+ years those guys have been there, they somehow didn't think this was a big deal. Now they're trying to shoehorn it into their Frankengine.

It's ironic that Crytek's latest game, Hunt, which uses the current version of the engine, still has sub-par multiplayer.

The lols will come when backers see that both serialized variables and network traffic culling get implemented (LOL!) and they still have piss-poor network performance. In fact, I have to believe that the engineers KNOW that it won't make much difference, and that's why they keep kicking the can down the road. The day they release a build with that stuff in there, and it's "meh", we're looking at 3.1 lols like we did when 3.0 Jesus Patch landed. And we're still loling at that one.

The hilarious part is that, Lumberyard doesn't support what they are looking to doing because Amazon are apparently focused on achievable session based games which is why they advise NOT to develop an MMO with it or be ready to change a ton of things.

I have written about Gridmate before, but one of the Lumberyard devs wrote this book which was released back in Nov 2017. Multiplayer Programming in Amazon Lumberyard using Gridmate

Quote
GridMate is Lumberyard's networking subsystem. GridMate is designed for efficient bandwidth usage and low-latency communications. You can synchronize objects over the network with GridMate's replica framework. GridMate's session management integrates with major online console services and lets you handle peer-to-peer and client-server topologies with host migration. GridMate also supports in-game achievements, leaderboards, and cloud-based saved games through third-party social services such as Steam.

Sure, you don't have to use Gridmate, but for a multiplayer game, that's like buying a Ferrari and taking out the engine, replacing it with the engine from a BMW.

I said this right through 2017, across several articles, it doesn't matter if/when they implement all this "new" tech they're calling serialized variables, network bind culling etc - the difference won't be noticeable because they're building an MMO. Good luck with that server mesh.
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen - General
« Reply #1872 on: February 26, 2018, 01:35:54 PM »
So I made this post on SA, in response to Shitizen dreamweaving...

Quote from: Preen Dog
Quote
D_Smart posted:
The lols will come when backers see that both serialized variables and network traffic culling get implemented (LOL!) and they still have piss-poor network performance. In fact, I have to believe that the engineers KNOW that it won't make much difference, and that's why they keep kicking the can down the road. The day they release a build with that stuff in there, and it's "meh", we're looking at 3.1 lols like we did when 3.0 Jesus Patch landed. And we're still loling at that one.

It could be even worse than that.  They could be genuinely trying to cull traffic, and it could help, but the lack of concrete design makes the task impossible.  The same reason why nothing else works.

For example, lets say you wanted to do something simple, and not update a player about other ships that are > 5km away.

Quote
Network lead: Hey Chris, we're putting in distance culling and we need to know how the long range scanning system will work. What rules decide if a ship can be detected in a scan? How often must these updates happen? What information shows up in the long range scan; position, rotation, shields, energy signatures, what? Is the scan continuous or is it a one-shot thing? By the way, you told us last week that you wanted long range torpedoes. Does the player need to see ships that can fire these? Also, should the Acme Indefatigator particle beam show up past 5 km?

CR: (Handwaving commences)The long range sensor shows you the location and the general composition of other ships and asteroids if you want more information you can focus on one area to get higher resolution but other ships might pick up these emissions you also have passive sensors that might see a spike in energy readings from weapons fire or ships exploding far away but this depends on your own heat and RF output and objects that are blocking your scan the torpedos are cloaked but if you have a SMXGT-17 military sensor you can see them in your frontal arc whenever the torpedo makes a turn but if your wingman has a transponder you can see his ship anywhere a data-link signal can reach which relays all the information about his contacts to your sensor display remember the datalink is blocked by hydrogen clouds unless they have the dish array get it done by next week because we need it for the anniversary sale of the... (handwaving intensifies until airborne. CR tumbles down the hall bouncing off the walls and ceiling)

Network lead: Right away.

First of all, let me offer this emote to you for bringing up something that I keep forgetting about.

:perfect:

Now to the fun (dev) part.

Even though my 5km range was hypothetical, it serves to highlight precisely how they have fucked up this whole thing by - you guessed it - doing a 64-Bit precision hack.

I wrote about that, amid much derision by our Shitizen friends.

09/26/2017: Ben Parry

11/22-2015: my article

11-20-2015: Here on SA

Now they've got huge numbers. And it's space.

Because ANY implementation of a radar scan HAS to know the position of an entity being scanned, that location data not only needs to be obtained, stored, and updated - in real time - but that CANNOT be done without actually having accurate position data for the entity being scanned.

You can't have an object that is 6km away, not show up on scanners that have a range of 5km. Sure, the object may exist, but the scanner has to not only cull out that info, but it HAS to rely on ACCURATE position and state changes for that object - REGARDLESS - of whether or not it is "in scope".

Why?

Fucking :lol: ....because, consider this. ObjectX (target in the world that's likely to be scanned)

pos1.client1: 4km from ObjectX // receives data

pos2.client2: 5km from ObjectX // receives data

pos3.client3: 6km from ObjectX // receives no data

Now imagine that there are 8 clients at pos1 and 8 at pos2; all those clowns in their chariots are going to need info about ObjectX.

It doesn't matter that another 8 clients at pos3 aren't going to get anything; and the performance is negligible to the extent that it's not even noticeable - at all.

The fact remains that in a situation where you have to plan for your max clients (e.g. 24 clients in a capped Star Citizen instance) to ALWAYS be within range of EVERYTHING at ANY TIME, you haven't actually solved the problem with serialized variables or network traffic culling. No. All you've done is mitigated the issue to the extent that you are hoping that your clients remain spread out over time.

And that is why these games have instances. Which are client-capped.

And that is why, even in games with the best multiplayer, when you have a group of clients in generally the same place, doing all kinds of shit, there are performance issues from both rendering and networking aspects.

So imagine a group of SC clients in their chariots doing combat with less clients within their "bubble". Then something (combat, trade run etc) forces them all to be within a 5km range of each other - and the radar has to be accurate etc. If it's not, guess what happens. Yes, you guessed it. They would not see objects on radar, they would go to a last known location and nothing be there etc.

Trust me when I tell you this: The minute those devs enabled this, EVERYTHING is going to break.

And here you were concerned that they can't do ramps or functional doors.

Like I said, I have to believe that the devs KNOW what's going to happen and that it's going to break more things and then NOT solve the problem. That's why they keep kicking this crucial can down the road.

ps: object container streaming is the same bullshit.

Then I was reminded of this...trust me, it's hilarious AF

Quote
Quote from: Virtual Captain
Back in 2014 when Chris and backers were figuratively intoxicated with dreams they thought they would be able to code all of this in non-Speed of light communications. I of course heard about it was after the fact but that still stands out to me as one of the most absurd dreams.

2014 Chris: "in our universe there is no FTL communication. Basically communication happens at the speed the ship can travel or a radio wave can travel in system."

2014 Chris: "The way that the communications are gonna work is that it travels our in-fiction communication's speed. Which means that when you're in-system and someone beams a message, it gets beamed at the speed of light, and it gets beamed to a relay station, or a message station. This is in the structured universe where the UEE runs it and there's a lot of infrastructure. So one of these stations is right by a jump point so it gets all the information and then it will launch out a message drone or a messenger ship. It goes through the jump point to the other side, where there's probably another relay station, it's collected, then the data gets beamed across to another relay station and so-on and so-forth if it has to go multiple systems."

Not surprisingly that didn't work out, I think a dev said something or all the talk about Spectrum made it clear. Communications were going to be instant even across long distances.
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

jwh1701

  • Guest
Re: Star Citizen - General
« Reply #1873 on: February 26, 2018, 02:45:10 PM »
Great write up Derek its enjoying to see the how engines work. If CR did poach top notch crytek devs, would they not know long before hand the engine is unworkable for the stretch goals? Why move to ly as I believe they had to of know before switching the goal as unattainable. CR and the inner circle know they are scamming but what about f42 and supposedly all the devs? Many times during my life and reported back to management the development plan was not possible in the time allotted with out major concessions.  I cannot help but wonder what if any feedback is coming from development are they just saying yes to everything to keep their jobs and pulling a scam as well?

dsmart

  • Supreme Cmdr
  • Administrator
  • Hero Member
  • *****
  • Posts: 4915
    • Smart Speak Blog
Re: Star Citizen - General
« Reply #1874 on: February 26, 2018, 02:48:01 PM »
Great write up Derek its enjoying to see the how engines work. If CR did poach top notch crytek devs, would they not know long before hand the engine is unworkable for the stretch goals? Why move to ly as I believe they had to of know before switching the goal as unattainable. CR and the inner circle know they are scamming but what about f42 and supposedly all the devs? Many times during my life and reported back to management the development plan was not possible in the time allotted with out major concessions.  I cannot help but wonder what if any feedback is coming from development are they just saying yes to everything to keep their jobs and pulling a scam as well?

Because Chris didn't start out building an MMO.
Star Citizen isn't a game. It's a TV show about a bunch of characters making a game. It's basically "This is Spinal Tap" - except people think the band is real.

 

SMF spam blocked by CleanTalk