Star Citizen - The E.L.E.

[J How]

What can't be held in memory? Millions of kilometres of nothing with some POI markers and a few low LOD images of planets and a star? I think you're wrong. The 2.5 alpha which does exactly that, only over a smaller space, (which is still around five factors of ten larger than current maximum CryEngine map), thinks that you're wrong, Elite Dangerous, that does exactly that, thinks that you're wrong.

Source: Star Ctien alpha 2.5 and Elite Dangerous, both showing that it would, and does, fit in memory.

You're trying to tell me that the 2.0 SC alpha never happened. Well I'm sorry but it did.

Elite Dangerous streams data, procedurally generates using triggers and some other tricks to minimise memory usage in the client. There are many objects in 3d space of any kind, references, pointers, players, bases, triggers all carry metadata and properties of that object which multiple the size of the map, along with the engine, AI, graphics, sound, input which all has to be held somewhere. It's merely not just a "map".

I can only speak as a cloud architect who works on MMOs and online games, whilst Derek's responses are a lot more direct, they are indeed factually correct.

You seem to think the Star Citizen engine can generate large maps, whilst they may have expanded limits of the maps it does come at a cost to both engine performance and efficiency. You may of course think I'm wrong of course, that is your choice.

[Kyrt]

I'd offer/suggest... consider those 'demos' to be vaporware until such time as whatever they claim 'exists' in those 'demos' is actually patched to the live 'server'.   

I do.

I am in the position where I hope the game is released, because I like the concept, because I like this style of game, because I like what Chris Roberts has promised and his vision.

My monetary investment in the game to date, however, is zero.

I am not 100% convinced that Star Citizen will ever launch. And they SHOULD have more than enough money to develop the game - again, I look at other similar games such as Elite and NMS and EVE to see what other have done in less time with less resources. In short, I don't need to contribute.

I have played the free weekends...frankly, I'm not impressed by the game play or animations, but this is apparently an Alpha release so I can live with it. I can hope that such aspects will be improved.
I have seen the tech demos. They look nice and give me an idea of what CIG are aiming towards. I don't know if they were scripted, freeform, created specifically for the cons or are decent representations of the game. But assuming they are decent representations - which I will barring evidence otherwise - they give me an idea at last of the type of game CIG are trying to develop and they show that CIG are continuing to develop and work towards that vision.

Having said that...I am not blind to the way CIG has been operating. I think their ships sales are a clever idea. They have a continuing stream of investment of about $3 million a month from a group of investors who are happy to hand over their money for no control, no share of the profits and the promise of an in game ship that CIG likely were going to develop anyway.

I have no complaint so long as such investors are happy with that ship instead of the usual RoI on such investments but I do think it slightly underhanded. I do see the problem in that it removes any incentive to actually finish and release the game and I think it can...maybe has...created an atmosphere where CIG are perhaps a little spendthrift with the cash they have received,

I am also not ignorant of the issues Derek Smart has brought up and while I am not a professional programmer, I believe I understand enough of what he is saying to agree with him, at least to a degree. But, as with CIG, I do not agree with him 100%. I do not think CIG are deliberately scamming their people, I do think they are working on the game, I do think there has been mismanagement and that lots of money has been wasted and that decisions which might have been reasonable at the time have proven themselves to be wrong several years later once feature creep arrived.

As I said before, I also think that his assertions of 100% certainty that he is right shouldn't be taken literally as I think it quite feasible for CIG developers to have solved issues in ways that he might not have anticipated and I think he can be his own worst enemy at times. Though I understand he is quite charming and pleasant in real life, he can be a bit abrasive online ;)

No offence meant.

I think Star Citizen has problems. But while I think Derek Smart is right about many of the issues he raises, I think he is exaggerating some of them.
And I also think that CIG are having more problems than they are letting on. In other words, I think the truth about Star Citizens development lies somewhere in the middle.
 
Now...we've seen flight and combat in AC. We've seen FPS. We've seen the social side. Granted - incomplete and less than impressive in many ways, but it at least hints that the technology CIG are implementing is viable.

Will this all result in a finished game? Eventually. If the funding holds up. This year has shown some signs of discontent even amongst the loyalists. But unless CIGs funding situation is dire - it might very well be as a rule of thumb projection by me suggests they might be burning through anything from $2m -$4.5m a month but bringing in only $3m (I don't know enough to make a more accurate guess so I have to settle for 'its plausible') - they should be able to last long enough to release something. Chris Roberts Minimum Viable Product.

I am not putting my life on hold for this game to be released.
I am not going to say it will be released.
I do not think it will be released soon and I think even SQ42 is not going to be out until late 2017 at the earliest. The main Star Citizen game will likely be at least 2 or 3 years after that.

And while I think Derek Smart is correct to say we won't get the game promised in the Kickstarter, CIG moved away from that vision towards their "Life Simulator" a long time ago.

I hope CIG can deliver their vision - but I do not believe they will. And they can't deliver the game they promised at Kickstarter because their vision much bigger since then.
But while I think there has been mismanagement and wasted money by CIG, I think it very possible that they will release a decent game. One that will be fun to play even if it isn't the epic Chris Roberts wants it to be. I hope that it will be close to his vision...but I suspect we'll see something closer to a Minimum Viable Product followed by patches which expand the game.

But yes - Derek Smart, alongside aspects such as the Kotaku report AND the problems and communication style of CIG have left me fairly certain the game is having a number of problems - technical and financial. I think the renewed and aggressive drive on sales is their way of fixing the financial problems, but they also are backed into a corner in that seeking out investors is something that Roberts won't want to do, given past experiences with games such as Freelancer but it would also anger backers as CIG supposedly don't need backers or investors - people who might want to know when they can expect a ROI. The technical problems...require time and effort by the developers. There probably isn't anything that can't be overcome, though I do question the viability of ships that require more crew than the instance limit as even with an improved Netcode I can't help but feel that will affect the number of ships per instance.

Will CIG release SQ42? I expect they will...in 2017. They likely need to secure another revenue stream
Will SQ42 be available on console? It'd be a good idea as they need to maximise return and console gamers represent an untapped income stream...albeit one burnt by NMS.
Will CIG release SC? If funding keeps up...I believe it will. I just think it'll take more money and time to deliver the product Robert wants and we can expect more delays. I would expect a MVP to be released late 2018 or more likely 2019, earliest.

But that is pure guesswork on my part. And it may very well be the games never come out, especially if the funding situation is worse than I suspect.

[dsmart]

That was a very good post. And all your points were well constructed.

While I don't share anyone's optimisms about the game, as an old school gamedev, I haven't seen any indication that they will ever ship a "game". To me, the whole dev process is like giving a lump of play dough to a child. You never know what they're going to mold. Though we haven't even seen any gameplay in SQ42, going by what has been shown of the PU, coupled with what they are working on, it's easy to see that they are focused on showing new things in order to continue winding up the whales who keep giving them money. And they've been doing this since 2014; then stepped up their game in 2016. e.g. A dev would ask why they're even focusing on planetary terrain tech, when - for a space combat game - they still haven't fleshed out any of the intrinsic gameplay mechanics, let alone the game world. And if they ever get to including a planet somewhere in Stanton, it's going to bring its own slew of bugs on top of what they already have - and that's going to slow down the dev of the game even more.

Needless to say, 2017 is going to be very interesting indeed.

[somedude]

Hmm, D.Smart u gotta admit that every sign of a SQ42 release is there atm. It will be buggy, it will be boring, it will be repetitive, but its comming. They'll release SQ42 within 1 system as u already said and call it a day. Then the shitstorm will begin.

[dsmart]

oh, I have no doubt that they will eventually release something of SQ42.


Sent from my iPhone using Tapatalk

[Kyrt]

Hmm, D.Smart u gotta admit that every sign of a SQ42 release is there atm. It will be buggy, it will be boring, it will be repetitive, but its comming. They'll release SQ42 within 1 system as u already said and call it a day. Then the shitstorm will begin.

I don't know what will happen with S42.

They say it needs polishing, and is "almost" ready.
However...I haven't seen any marketing for it, and they are still playing around with the flight model. I assume it would be using the same system as SC goven the linkage and desireability of cutting costs.

I also think it likely they need to release it soon so as to reassure backers and to generate a new revenus stream. But by the same token, that means S42 really needs to be good and deliver what has been promised. It'd almost certainly be better to gave no release than a bad release

[somedude]

Hmm, D.Smart u gotta admit that every sign of a SQ42 release is there atm. It will be buggy, it will be boring, it will be repetitive, but its comming. They'll release SQ42 within 1 system as u already said and call it a day. Then the shitstorm will begin.

I don't know what will happen with S42.

They say it needs polishing, and is "almost" ready.
However...I haven't seen any marketing for it, and they are still playing around with the flight model. I assume it would be using the same system as SC goven the linkage and desireability of cutting costs.

I also think it likely they need to release it soon so as to reassure backers and to generate a new revenus stream. But by the same token, that means S42 really needs to be good and deliver what has been promised. It'd almost certainly be better to gave no release than a bad release

When the funds are depleted they'll have no choice. I am 100% confidend they'll release SQ42 and i am 90% confidend it will suck.

[ConfusedMonkeh]

Monkeh, you probably want to read this. Pay close attention to Ben's statement. For context, read this first.

It's amazing to me that you guys will argue - and look foolish doing it - just to defend a position because it's inconceivable that the "other" guy (especially Derek Smart), could possibly be right, or know more than you do.

This not my MO. I like to discuss and I like to debate. Whatever you do, in whatever walk of life, someone, somewhere, will think you look foolish. That doesn't concern me. I'm sensible enough to know when other people know more about a subject than I do, that happens a lot. Not really relevant though.

NOTHING you wrote makes ANY sense. NONE.

It does. Maybe we're arguing different things. Try again further down there. I'm only talking about the 2.5 alpha Crusader map. Nothing about the Starmap has any relevance to any point I've been making.

So what exactly are you arguing about then?

I'm arguing about the 2.5 Crusader map being a true, single scene, no loading screens via quantum drive, hundreds of thousands of km wide CryEngine map and your claims that CIG have 'cheated' by stitching together smaller scenes via quantum drive loading screens.

Brian's missive bears NO relevant to this discussion

The guy's name is Sean. It's in the title of the video.

It's there to be played, right now, in 2.5. A CryEngine map, hundreds of thousands of km wide. In the engine that can only create 8x8 or so.

You can't possibly be arguing that they've already built the entire starmap, that it is one contiguous map - so everything I stated is rubbish. Try not to change the subject. Stay focused.

How does my talking about a 'A CryEngine map, hundreds of thousands of km wide' indicate I'm arguing 'they've already built the entire starmap'? How does that make any sense at all? Come on man, please stay focused.

All I've ever been talking about is what is currently available to play, right now, in the 2.5 Crusader map. An approx, one third of a whole system, at least, hundreds of thousands, if not millions, of kilometres wide. I'm not nerd enough to know exact numbers. You are the one who mentioned the Starmap, which has absolutely no relevance to the conversation we've been having regarding your documented statements proclaiming CIG have 'faked' the large world, 64 bit *techno babble* Crusader map, that allows CryEngine to have a single map of that kind of size. Even a factor of ten larger again, should they so desire.

You've said they are 'cheating' and stitching together 32 bit *techno babble* scenes via quantum drive loading screens.

You are the one who isn't staying focused with all your tubthumping declarations of superiority and mentions of the irrelevant Starmap. We've been discussing your claims CIG haven't created a way to give players millions of square kilometres of CryEngine to fly spaceships in and have, in fact, been lying about it whilst stitching together individual scenes via quantum drive loading screens.

In fact, there is a known backer (Monkeh), right now in the thread I linked above, having trouble understanding why it is that in QD, there is a set transition path from which you can't exit; and which requires a committed target end-point.

This comment on the Frontier forums shows exactly how disassociated you are from the reality of the 2.5 alpha. It's wrong. Very wrong.

Quantum drive propulsion absolutely, emphatically and demonstrably, does not require a 'commited target end-point'. You can aim anywhere, empty space or point of interest, initiate the quantum drive and come out of it at any time and any point. At any point within the HUGE, large world, 64bit *techno babble*, CryEngine, single scene, no loading screens, no stitching of scenes, map, with only travel and the loading of objects as you approach them.

All I've talked about is what's available right now, in the 2.5 alpha. Please, stay focused.

Have a look at this video, where a player quantum drives away from Port Olisar, in a random direction, for a random length of time, (which turns out to be around twenty six thousand kilometres), turns around, and seamlessly travels back to port with the 1000 m/s cruise mode. No loading screens. No quantum drive. No stitching. No scenes to stitch. Just a ridiculously large map with points of interest that load in on approach, and the freedom to fly wherever you like. It's all there. Emphatic proof that you're wrong. Undeniable.

If you're right and we can only QD to a 'a committed target end-point' and they are stitching 32 bit scenes together, via quantum drive loading screens, to create the illusion of a 'large world' map, can you please explain how that video is possible. Then, can you show me any other example of any other CryEngine game with a similar demonstration of world expanse?

You don't have to accept or like it, but there it is, Monkeh. You're in my house now; and here (unlike Reddit or the RSI forums where you mobs tend to shout/vote people down when you don't agree with them), we're going to engage you in a manner that not only completely strips you of any semblance of "group think", but also puts you on a platform that serves to illustrate to you exactly where your "place" is; because clearly you've forgotten.

I haven't forgotten anything. I came here on my own free will. I engaged in discourse. I don't subscribe to 'group think'. Not my way at all. Do you not want reasonable discourse with opposing views on your forum? I don't have an online footprint to speak of. I'm not here for internet fame or upvotes on reddit. Just having a chat.

Your infantile jab, is just that - infantile.
*Snipped-Calm down dear*

Oh come one, this is the internet. My effort at flame was feeble at best. Proclaiming I hate you off the back of that little jibe is a little explosive wouldn't you say? What ever happened to the Derek who loved a bit of banter and has a great sense of humour?

[dsmart]

*snip*

This comment on the Frontier forums shows exactly how disassociated you are from the reality of the 2.5 alpha. It's wrong. Very wrong.

Quantum drive propulsion absolutely, emphatically and demonstrably, does not require a 'commited target end-point'. You can aim anywhere, empty space or point of interest, initiate the quantum drive and come out of it at any time and any point. At any point within the HUGE, large world, 64bit *techno babble*, CryEngine, single scene, no loading screens, no stitching of scenes, map, with only travel and the loading of objects as you approach them.

All I've talked about is what's available right now, in the 2.5 alpha. Please, stay focused.

That comment just clearly shows that you guys keep theory-crafting shit that even the devs haven't uttered, let alone implemented.

And you don't know what a "target end point" means. Because if you did, you'd immediately understand why you are - again - pissing up a tree while making circular arguments.

If you're right and we can only QD to a 'a committed target end-point' and they are stitching 32 bit scenes together, via quantum drive loading screens, to create the illusion of a 'large world' map, can you please explain how that video is possible. Then, can you show me any other example of any other CryEngine game with a similar demonstration of world expanse?

Go back and read everything I've written, as I'm simply not going to repeat it. Also, try reading Ben's comments (his responses to me here and here) while you're at it.

And he's a graphics programmer. You on the other hand are making stuff up even though you have no clue how it's actually implemented - or why. All you're doing is what you guys do: theory-craft, due to the fact that CIG has a long-standing habit of obfuscating the simplest of things, thus leaving backers to theory-craft and play guessing games.

Bonus: See where Ben mentions the target end point issue I pointed out?

"The thing where you pick a specific target point is a design decision, I think. But to be totally clear, your destination point is just some coordinates (in 64 bit, yes) you just move over there really fast. I can't disprove this idea that there's a new "scene" or whatever, with words, how could I? Sufficiently advanced fakery is indistinguishable from just doing the thing. But really complicated fakery would have been exciting and AtV would have just done a show about that instead."

Oh come one, this is the internet. My effort at flame was feeble at best. Proclaiming I hate you off the back of that little jibe is a little explosive wouldn't you say? What ever happened to the Derek who loved a bit of banter and has a great sense of humour?

OK I grant you that. However, you have to admit that the hostilities between both sides (especially with those we've fondly dubbed Shitizens) of this discourse, is at an all-time high. So naturally everyone has a "shoot first, ask questions later" attitude.

This is not Reddit. All are welcome here, as long as they follow the posted rules, and engage in good faith discourse; because Strawman and circular arguments aren't going to cut it. We're not going to argue just for the sake of arguing. Solid points have to be made. And those points can then get debated and discussed based on merit. That's the key to meaningful discourse, without all of the baggage of useless noise (we have Reddit for that).

[Kyrt]

I'm arguing about the 2.5 Crusader map being a true, single scene, no loading screens via quantum drive, hundreds of thousands of km wide CryEngine map and your claims that CIG have 'cheated' by stitching together smaller scenes via quantum drive loading screens.

As I understand what Derek Smart is saying, "stitching" - as he calls it - doesn't necessarily refer to loading screens. It's simply his shorthand to transition from one "scene" to another. From his S1 to his S2.

He has already mentioned streaming the data to the client as one way of doing this. As I understand it, Elite Dangerous takes a similar approach as a way to minimise the workload on the client.

So - within your CryEngine map that is hundreds of thousands of km wide, there might be millions (well, thousands) of objects, NPCs and PCs which are loaded in only as the player needs them. That also seem to be what Ben Parry is referring to when he says "Seamless loading of the stuff in the world is totall

Stitching occurs - but it occurs within the map you are talking of. Whether it is loading in new assets, loading in a players crossing your view or generating a battle instance

It's there to be played, right now, in 2.5. A CryEngine map, hundreds of thousands of km wide. In the engine that can only create 8x8 or so.

No - they modified the engine. Now it can create bigger maps. That upgrade needed to be done regardless of the engine, but given the apparent work involved in that upgrade I still wonder if moving to a custom engine, especially given their additional funding and feature creep, might not have been a better idea. I understand the desire not to throw work away - but CIG did just that when they cancelled Ilfonics Star Marine.

which has absolutely no relevance to the conversation we've been having regarding your documented statements proclaiming CIG have 'faked' the large world, 64 bit *techno babble* Crusader map, that allows CryEngine to have a single map of that kind of size. Even a factor of ten larger again, should they so desire.

I think the issue is that having a single map for the system doesn't mean stitching isn't happening.  Also...if CryEngine is only capable of rendering a "third of the system" or has a map size of "hundreds of thousands of km" then the game WILL need to stitch such maps together for the full system. We're talking about a need to cover not hundreds of thousands of km...but BILLIONS of km. A map of SOL would need to be about 20 Billion km wide for example. OF course, I don't know what sort of scale CIG will eventually use but I did find:

"Just to give you an idea," Roberts said, fumbling for a way to communicate the sheer massive size of the upcoming release, "the playable area on the large world map that we're currently using is one million kilometers by one million kilometers by 200 kilometers high."

(Although it turns out the area is actually 400,000km high)

"I do realize that a full solar system is much bigger than a million kilometers wide," Roberts said. "Though on some level we will do some compression of play spaces because you don't want to be even at point-two speed of light you don't want to be sitting there for 3 hours. You want quantum travel.

Now - that is just the area around Crusader.....but a map size that small means that even within a single system many such maps will be needed.

And we have "SC's engine suppports maps up to 1,000,000,000 by 1,000,000,000 by 500,000 km."

So - the engine would allow seamless travel within the map, but even then, there will be transitions as objects and instances are loaded in. But there will also be transitions to different maps as players travel to different planets within the system.

We've been discussing your claims CIG haven't created a way to give players millions of square kilometres of CryEngine to fly spaceships in and have, in fact, been lying about it whilst stitching together individual scenes via quantum drive loading screens.

Sorry to say this - but at this point in time, Derek Smarts argument appears to be correct. Maybe not in the specifics, but at least in the broad strokes

Have a look at this video, where a player quantum drives away from Port Olisar, in a random direction, for a random length of time, (which turns out to be around twenty six thousand kilometres), turns around, and seamlessly travels back to port with the 1000 m/s cruise mode. No loading screens. No quantum drive. No stitching. No scenes to stitch. Just a ridiculously large map with points of interest that load in on approach, and the freedom to fly wherever you like. It's all there. Emphatic proof that you're wrong. Undeniable.

You were expecting a loading screen? Seamless travel doesn't indicate a lack of stitching.

If you're right and we can only QD to a 'a committed target end-point' and they are stitching 32 bit scenes together, via quantum drive loading screens, to create the illusion of a 'large world' map, can you please explain how that video is possible.

I would assume that if the player had gone beyond the boundary of his world map, that data would be streamed in as needed, allowing the map to be generated before he accesses it and enabling a smooth handover. However...the player appears to have only travelled 26000km and that is within the map boundaries. There might have been a transition to the Orbit Instance at the end but I couldn't say if that happened or not.

The point is - I don't see why your idea of "seamless" negates Derek Smarts assertion that Star Citizen requires maps and instances and zones to be stitched together even within a system. CIG has already stated it will be using instances and zones and has provided us the size of the player area - a size which almost certainly requires stitching to map an entire system, even if CIG compresses it.

Now, I suppose CIG and Chris Roberts could be wrong about he size of the map, or hiding it. But, at least from a real life perspective, it isn't ten times too small for a system map, it is 10 thousand times too small. What this shows is not that there is seamless travel within a system...as you seem to mean it anyway...but seamless travel within a planets orbital space. I would expect the transition between maps to be seamless as far as the player is concerned regardless. But that seamless experience does not mean there isn't some type of stitching taking place in the background.

And being blunt - I don't think it matters. So long as the player isn't aware of such stitching, why care how it happens? Success in this will be measured by how little players mention it but Elite and other games already show us such a seamless system is possible.

[dsmart]

And being blunt - I don't think it matters. So long as the player isn't aware of such stitching, why care how it happens? Success in this will be measured by how little players mention it but Elite and other games already show us such a seamless system is possible.

And there it is. Even though this has been echoed time and time again, in some form or another, they're still arguing. Why? Heck, look no further than Ben Parry's (though he is only a rendering programmer, he has an idea of these things) own recent statements previously quoted.

And that's part of the arguing for arguing sake; as is there is no rhyme, reason or good faith in it because there is nothing that you can you can say to these guys to make them agree to, or which goes against either what CIG tells (or doesn't) them or what they believe. This despite the fact that, by all accounts, CIG has zero credibility when it comes to this project, what they're doing, how etc.

The hilarious thing is that even Elite - which now has the largest game world in existence - is using tricks to stitch regions together in order to give the illusion of expanse.

Even when I illustrate that it absolutely needs to be done, and for various reasons - even using a video of my own Universal Combat game which, until ED, had the largest game world in gaming, they still ignore it.

And even so, in my BC/UC games, if you want to travel long distances without wasting time, you can jump from point A to point B within S1 using the available jump anomaly (jump gate) within S1. And that uses a hyperjump (same as Star Citizen's QD) sequence though you are actually travelling through space, not cheating (via stitching areas within S1 or cutscenes). Which is why you can drop out of hyperdrive at any time and you will be in the same space.

In that video @ 8:34, you can see the region scene for the Earth "space" region, and all the elements (including the planet) within it. And from there you can see other AI entities travelling through the region; some in normal space, others in hyperspace. And even though there are edges (the map is square) used to show the scene extents, if you go off the edge, you are still in the game world, but in "null" space, which goes on to infinity, but which has a jump gate to bring you back into "normal" space.

And as shown in my previous post, the Earth space region is connected to other nearby regions (e.g. Mars) via jump gates. And since the game world is all data driven, the whole thing is loaded when you start the game. Which is why there are no loading screens - at all. So, going from Earth (R1) to Mars (R2) via a jump gate, is instantaneous. Going from one nearby system e.g. Sol (S1) to another e.g. Alpha Centauri (S2) via Pluto - also instantaneous - uses a wormhole due to the greater distance. Again, no cutscene, no load time delay - because it's already in memory.

This color (see B&W version also) map which gives you all the jump links, shows how the enter game galaxy is constructed - with no stitching required. You can see the jump gate lines (Yellow) connecting all the regions (R)



Excerpt from Section 4.1 of the UCCE 2.x and 3.x (both currently on Steam; so anyone can go try it themselves) game manual:

4.1   NAVITRON

All astrogation and long distance navigation route plotting are done here.

The galaxy is divided into four quadrants which are linked via jump anomalies known as jump gates, wormholes and fluxfields.  Each quadrant contains a number of starsystems which are further divided into four regions named TERRAN, CREDIAN, GAMMULAN, SYRION.

When activated, the section of the galaxy where you are currently located as well as the currently programmed route destinations are displayed.

You can scroll the map by using the arrow keys or you can right-click anywhere in the display, and while still holding down the button, drag the mouse slowly in the desired scroll direction and the auto-scroll will activate. Once you find the desired location, release the mouse button.

INTRA-STELLAR COURSE PLOTTING

To plot a course to another space region, click on the desired starsystem from the map display to program it into the ship’s auto-navigation system. The name of the region you have selected and the starsystem in which it is located will then be displayed.  Now logoff. You will notice that the WTS tab of the NID is now displayed and indicates all the programmed waypoints. To fly to the destination, activate the autopilot.

During the transition, if you wish to temporarily cancel, just deactivate the autopilot. Later, you can reactivate it and it will resume the waypoints. If you wish to cancel the transition and clear all programmed waypoints, click on the WTS tab and select the CLEAR NAVIGATION ROUTE option. You can also use SHIFT+X keys.

If the main computer is damaged or destroyed, this system will not function. Similarly, if the NAVITRON computer is 100% functional and the main computer is destroyed, NAVITRON will not function.

Select LOGOFF from the drop-down menu or press the ESCAPE key to exit.

GALACTIC CARTOGRAPHY

Starsystems are linked by wormholes and in some cases by flux fields. In order to travel from a region within a starsystem to another region within another starsystem, you have to locate a region with a wormhole which will provide the link to the destination.
For example, you can only go from the Sol system to Alpha Centauri via a wormhole located in the Pluto region in Sol.

The regions within the starsystems are linked via jump gates; therefore, you can jump from Earth to Pluto region using a jump gate and from Pluto to the Centris region in the Alpha Centauri starsystem using a wormhole.

JUMP ANOMALIES

JUMP GATES

Due to the vast expanse of the galaxy, advanced technology was used to create jump gates.  These transport the ship through hyperspace to emerge at the other end of the jump gate.  These devices are reasonably safe to use and have only one entry point and one exit point.  Jump gate links are displayed as connecting blue lines. 
If you call up the Sol system map, you will notice that the Saturn region is linked to the Earth region by a jump gate.

FLUX FIELDS

Flux fields are natural phenomenon that effectively function as jump gates but some have multiple entry and exit points.  Once you enter a flux field you have no way of knowing where your ship will emerge.  Flux fields are displayed as connecting yellow lines extending from the planetary region to the boundaries of the system map.  This means that the exit point is outside the currently displayed system.  If you call up the Sol system map, you will see a flux field originating in Mars, another in Jupiter and a third in Mercury.  Flux fields can have one or more exit points that link several regions.  In a flux field, the ship takes no damage and will emerge safely.  The entry point of a flux field includes the originating point itself.  This means that sometimes it would seem that entering a flux field did not work.  It may have simply deposited you back at the point at which you entered.  Some flux fields have end points in black holes that make them dangerous.  Flux fields can link both regions and starsystems making it possible to hop across the entire galaxy.  For example, the flux field in Sygan (Barnard's Star) will take you across the galaxy to Majoris (Alpha Majora).

WORMHOLES

These anomalies are natural phenomenon that exist in various parts of the galaxy.  Wormholes are the gateway to other star systems within the galaxy.  They are highly unstable and will likely cause some damage to a ship as it passes through.  Wormholes only have a single entry and exit point and are displayed as connecting red lines.  Unlike flux fields, you can always tell from what system a wormhole originates.  This is displayed at the end of the wormhole line.  If you call up the Sol system map you will see a wormhole originating from the Jupiter region and another from the Pluto region.  The names at the end of the wormhole lines indicate that one connects to Alpha Centauri and the other in Sirius.  Since you know that wormholes always connect star systems together, you can deduce that those two wormholes link the Sol system to the Sirius and Alpha Centauri systems.  The wormhole paths are shown as Grey lines on the full screen galactic map linking the starsystems. 

There is no way on this God's Earth that Star Citizen can - or will be able to - do this. Especially not with any custom version of CE 3.x. Just look at their starmap compared to the one in UC. Touting 64-Bit positioning or 64-Bit sized maps, is irrelevant in this context because it doesn't matter how big it is, the key is to give the gamer the illusion of expanse by using a variety of tricks (some better than others) due to the limitations of current tech. Not to mention the fact that comparing the SC world to the one in BC/UC, may as well be comparing a football field (BC/UC) to a basketball court (SC).

The most recent hilarity of this sort of nonsense, is some of them saw in a recent AtV, an artist manipulating the Sun in the editor. Right away, these clowns start theory-crafting all manner of astronomical rubbish, though it's just a light source attached to a 3D object within the scene; allowing it to be manipulated. Meanwhile, they still can't figure out why the rings on Port Olisar, let alone the texture decal, can't work right. But yeah, they're going to be modeling actual celestial objects; instead of just cheating like we all do. It's amazing to me. Then again, these are the guys buying JPEGs for thousands of dollars for a game which, by all accounts, has very little chance of being completed.

[J How]

As I understand what Derek Smart is saying, "stitching" - as he calls it - doesn't necessarily refer to loading screens. It's simply his shorthand to transition from one "scene" to another. From his S1 to his S2.

He has already mentioned streaming the data to the client as one way of doing this. As I understand it, Elite Dangerous takes a similar approach as a way to minimise the workload on the client.

So - within your CryEngine map that is hundreds of thousands of km wide, there might be millions (well, thousands) of objects, NPCs and PCs which are loaded in only as the player needs them. That also seem to be what Ben Parry is referring to when he says "Seamless loading of the stuff in the world is totall

Stitching occurs - but it occurs within the map you are talking of. Whether it is loading in new assets, loading in a players crossing your view or generating a battle instance

I think the issue is that having a single map for the system doesn't mean stitching isn't happening.  Also...if CryEngine is only capable of rendering a "third of the system" or has a map size of "hundreds of thousands of km" then the game WILL need to stitch such maps together for the full system. We're talking about a need to cover not hundreds of thousands of km...but BILLIONS of km. A map of SOL would need to be about 20 Billion km wide for example. OF course, I don't know what sort of scale CIG will eventually use but I did find:

"Just to give you an idea," Roberts said, fumbling for a way to communicate the sheer massive size of the upcoming release, "the playable area on the large world map that we're currently using is one million kilometers by one million kilometers by 200 kilometers high."

(Although it turns out the area is actually 400,000km high)

"I do realize that a full solar system is much bigger than a million kilometers wide," Roberts said. "Though on some level we will do some compression of play spaces because you don't want to be even at point-two speed of light you don't want to be sitting there for 3 hours. You want quantum travel.

Now - that is just the area around Crusader.....but a map size that small means that even within a single system many such maps will be needed.

And we have "SC's engine suppports maps up to 1,000,000,000 by 1,000,000,000 by 500,000 km."

So - the engine would allow seamless travel within the map, but even then, there will be transitions as objects and instances are loaded in. But there will also be transitions to different maps as players travel to different planets within the system.

Sorry to say this - but at this point in time, Derek Smarts argument appears to be correct. Maybe not in the specifics, but at least in the broad strokes

You were expecting a loading screen? Seamless travel doesn't indicate a lack of stitching.

I would assume that if the player had gone beyond the boundary of his world map, that data would be streamed in as needed, allowing the map to be generated before he accesses it and enabling a smooth handover. However...the player appears to have only travelled 26000km and that is within the map boundaries. There might have been a transition to the Orbit Instance at the end but I couldn't say if that happened or not.

The point is - I don't see why your idea of "seamless" negates Derek Smarts assertion that Star Citizen requires maps and instances and zones to be stitched together even within a system. CIG has already stated it will be using instances and zones and has provided us the size of the player area - a size which almost certainly requires stitching to map an entire system, even if CIG compresses it.

Now, I suppose CIG and Chris Roberts could be wrong about he size of the map, or hiding it. But, at least from a real life perspective, it isn't ten times too small for a system map, it is 10 thousand times too small. What this shows is not that there is seamless travel within a system...as you seem to mean it anyway...but seamless travel within a planets orbital space. I would expect the transition between maps to be seamless as far as the player is concerned regardless. But that seamless experience does not mean there isn't some type of stitching taking place in the background.

You are understanding this which is great. Technically correct, the best kind of correct. Nail hit head.

Put simply, the dynamics of streaming data to clients from servers always come at a cost to the engine, whether that be networking latency or stress applied to the client or the server being overloaded. Too large and it takes a larger amount of data to populate, too small and you are sending chunks of data more quickly unless you have the client procedurally generate data which comes with it's own drawbacks.

It's a very tough balancing act which is why it takes several iterations to get it right, which is why it's best to share knowledge on this to other teams so they are all signing from the same hymn sheet. Practically every game or engine goes through reiteration cycle of determining what way works best or trying to work out what the most efficient way to achieve the goals they have in mind.

Star Citizen is different because of the massive scope creep that it has went through and it's never really had the chance to mature code wise. There is a multitude of changes to their customised engine (frankenengine / Star Engine), it's never really had a chance to keep up with the scope. Networking wise this is very bad considering it's stage in development, you can't just decide one day the networking stack built into the engine is not working and to "refactor" (really hate when CIG use that word). Touching lower level networking code when you have already built parts of the game around it leads to breakage, bugs, even potentially code conflicts which is why it's usually defined at an early planning stage. I personally dread to think what the code looks like or how much technical debt the project has.

How does this relate to the above? Basically the larger the networking components are changed or altered, the longer it will take to fix. More underlying network / engine changes = more breakage.

The tougher question is whether or not the technical debt is that severe that when they say "refactor netcode" or "work on netcode" if they really mean stripping it out and starting again at this phase? As mentioned earlier changing the core engine or network code leads to breakage, it's not unheard of that at some point a project will go through this cycle but it ALWAYS takes a lot longer.

Personally I don't see this as an overnight quickfix or even an intensive three month sprint, they are working on a largely bespoke customised earlier version of cryEngine which has had large code changes, more iterations than you can shake a stick at and suffered from massive scope creep as mentioned earlier.

With this all in mind how would CIG salvage this? I can only give the idea that in an ideal scenario that all the promises are scaled back to focus on the core mechanics only without the stretch goals, release a code only release of the engine and get less people working on the core and focus on what they really want the end result to look like. It's completely fine to have a "vision" but if you constantly change the "vision" you're effectively negating the code already written because it wasn't designed for the updated "vision".

Focus equals quality. The more elements, features, requirements you add the weaker the source.

[Kyrt]

You are understanding this which is great. Technically correct, the best kind of correct. Nail hit head.

That's good. I think

The tougher question is whether or not the technical debt is that severe that when they say "refactor netcode" or "work on netcode" if they really mean stripping it out and starting again at this phase? As mentioned earlier changing the core engine or network code leads to breakage, it's not unheard of that at some point a project will go through this cycle but it ALWAYS takes a lot longer.

Personally I don't see this as an overnight quickfix or even an intensive three month sprint, they are working on a largely bespoke customised earlier version of cryEngine which has had large code changes, more iterations than you can shake a stick at and suffered from massive scope creep as mentioned earlier.

That comment makes me wonder about how they will be doing instancing wrt ship or player limits. I've seen comments that suggest they are looking for up to 200 players in an instance. Indeed, it appears some of their ships require more crew than the current instances can currently support....though I have no first hand knowledge of that.

I know that the current netcode is subpar... unsurprising as CE3 wasn't designed for the scale being sought...and that they are working to improve it for release in 3.0. But your analysis here makes it sound like this will be  major undertaking for CIG.

[Scruffpuff]

I know that the current netcode is subpar... unsurprising as CE3 wasn't designed for the scale being sought...and that they are working to improve it for release in 3.0. But your analysis here makes it sound like this will be  major undertaking for CIG.

It's more than a major undertaking.  I'm going to simplify with an analogy.

Let's say you're asked to make a sandcastle - one story high.  So you go to the beach and make a small sandcastle.

Now the boss comes around and says "I've changed my mind, make it two stories high."  So you manage the nearly impossible feat of making a two-story sandcastle.  It's inherently unstable, but if you don't poke it too much, it'll stay up.  Mostly.

Now the boss comes around again and says he's got a bigger vision - make it 20 stories high.  Reality is not his field, he just reiterates that he's the boss, you're the expert, make it work or you're incompetent.

Now you're in some shit.  Not because the vision is inherently flawed, but because you can't make a 20-story sandcastle due to the construction material being inadequate and unstable for use beyond its current capacity.  You have some options - you could mix the sand with another material to make it more like concrete.  You could change the location and build it out of stronger materials, like wood, or steel.  All of these are workable, but they require starting the project over again.

Unfortunately, your boss has already invited people to move into the 2-story sandcastle, and he's promised that what they're seeing is what the finished product will be, only BETTER.  You have to make it grow to 20 stories without damaging the parts that are already there, because then it will look to the people who are living there that progress is going backwards, and we can't have that, can we?  They might lose faith.  So you are now faced with the task of building an impossible building on an unstable foundation without the appearance of backward progress or the revelation that the original design was a mistake, because that would discourage people from paying for this prime, sandy real estate.  Get to it, expert!

This is what it's like not just for the netcode, but the entire project.  The very foundation is deeply flawed for what the project grew to be.  It could have supported the original vision.  It can't support the new one.  "Working on it" won't work, for the reasons I described above - it needs to be scrapped and redone.  But for that to happen, the PTU as it stands needs to be replaced completely.

The best-case scenario here is that CIG is working on a completely new, parallel build, which they will deploy as yet another 30 GB "patch" which will actually be a complete rewrite of everything from the ground up.  Backers won't know because they'll just call it 2.x or 3.x giving the illusion of constant iterative progress.  Of course that's nonsense, since many project in the early stages have things like that happen, but when you're relying on appearance alone for your income, you can actually shoot yourself in the foot if people feel you're failing at something.

CIG always brags about how their crowdfunding model frees them from the reins of publishers and allows them to do what they want, but it's actually the opposite.  A publisher can choose to scrap some or all of a project and start over, doing it better.  CIG does not have that freedom - they can't show weakness.  Everything they show has to make it appear as if things are going great, or the money dries up.  The constrains their creativity, their technical ability, and their overall agility to respond to problems as they arise.

They're locked into their mistakes.

TL;DR - you can't fix something that's unfit for purpose.  You need to replace it with something that is.

[dsmart]

That comment makes me wonder about how they will be doing instancing wrt ship or player limits. I've seen comments that suggest they are looking for up to 200 players in an instance. Indeed, it appears some of their ships require more crew than the current instances can currently support....though I have no first hand knowledge of that

Since those ship professions are not likely to ever be implemented, the point is moot I think. For one thing, they'd have to get around the 16 client limit they currently have, before they even start thinking about 200 clients in a single ship. Imagine the hilarity of just having two capital ships with 16 clients each, being in the same instance, with weapons fire and all that going on.

They're never going to get there; so this is just fun to chat about the hilarity of dreams.

I know that the current netcode is subpar... unsurprising as CE3 wasn't designed for the scale being sought...and that they are working to improve it for release in 3.0. But your analysis here makes it sound like this will be  major undertaking for CIG.

It's more than a major undertaking.  I'm going to simplify with an analogy.

Let's say you're asked to make a sandcastle - one story high.  So you go to the beach and make a small sandcastle.

Now the boss comes around and says "I've changed my mind, make it two stories high."  So you manage the nearly impossible feat of making a two-story sandcastle.  It's inherently unstable, but if you don't poke it too much, it'll stay up.  Mostly.

Now the boss comes around again and says he's got a bigger vision - make it 20 stories high.  Reality is not his field, he just reiterates that he's the boss, you're the expert, make it work or you're incompetent.

Now you're in some shit.  Not because the vision is inherently flawed, but because you can't make a 20-story sandcastle due to the construction material being inadequate and unstable for use beyond its current capacity.  You have some options - you could mix the sand with another material to make it more like concrete.  You could change the location and build it out of stronger materials, like wood, or steel.  All of these are workable, but they require starting the project over again.

Unfortunately, your boss has already invited people to move into the 2-story sandcastle, and he's promised that what they're seeing is what the finished product will be, only BETTER.  You have to make it grow to 20 stories without damaging the parts that are already there, because then it will look to the people who are living there that progress is going backwards, and we can't have that, can we?  They might lose faith.  So you are now faced with the task of building an impossible building on an unstable foundation without the appearance of backward progress or the revelation that the original design was a mistake, because that would discourage people from paying for this prime, sandy real estate.  Get to it, expert!

That's a fantastic analogy. It's even better than my architecture/construction analogy I've been using.