Game Discussions Star Citizen Discussion Thread v12

Alpha, not finished, not all mechanics in game, etc, etc..., everyone's sticking to their guns.


The famous "zero gameplay".
I will describe precisely one old mission of SC and you will say me if you does not see at least one once of gameplay in it. The mission is the Covalex one.
I wake in my bed, got to my ship, call it, open my mission tab and chose the Covalex mission.
The mission giver describe by audio+text the mission, I must find why her husband is dead in a station because the insurance company doesn't want to pay her.
I go to the station, find a broken bay and EVA through it. I check all computers to find infos and audio logs.To find all computers, you must go in EVA in a simple maze with floating objects. There is a closed door in the station, if you find the good computer, you will get the code to unlock the door. The main audio log with evidence is behind this closed door. At the end of this little maze, you will find a one way door which permit to exit the maze by a shortcut. If you find all evidences, the widow give you 8000 aUEC.

This mission in video, the guy know it well you can easily get a little lost the first time you do it.

If you want more action, you can do the Claimjumper mission, a bounty one, etc. If you want to trade you can buy and sell with cargo run. You can investigate a cave to find missing persons, etc.
That Covalex private investigator mission has been part of SC since 2.5 or 2.6. Ci¬G used the original audio logs from the 2.6 version and declared it fixed. Unfortunately, it used to be a bit more immersive and exciting than it is currently...used to be one of my favourites outside of the ICC missions with the lovely sounding Tessa :)

As an aside...I really hate watching M/KB fliers flying in 3rd person view in SC or any game...reminds me of the so-called ace pilots I met in War Thunder who have no idea of spacial awareness from inside a cockpit. It's almost as annoying as the Mario kart racers driving in Project cars from 3rd person...gets my goat.
 
Last edited:
I'll correct this a bit. As far as I know, once upon a time CI (back then still G) had very clever minds on the team. One of them was John Pritchett, very solid mind who majored in engineering physics and had been in game development for close to 15 years before CIG work.
He supposedly wrote a fairly solid physics and flight engine for Star Citizen, called IFCS, which - again, supposedly - works very nicely.

The problem came when this mode was applied on already existing ships, which - as you'd expect from looking at some of them - don't like flying by physics. Stuff like having the engine in the axis while the ship is asymetrical, meaning it would always yaw to the side. Inability to fly in most atmospheres. And so on.

So John was asked to fix his engine. The people from ships will give him numbers about how the ship should fly and the engine will calculate it for them to "fit".

But of course, this throws the whole IFCS engine out of the window. If the engine says you can't turn this hard because of physics, and you allow backdoors which say: "Just do it somehow, we don't care", you could as well have no engine in the first place, just assign arbitrary numbers.

The legend has it that after implementing this backdoor that allows for any value to destroy the physics engine's quality, John Pritchett left CI in 2018. The official reason given was: "He couldn't relocate to finish IFCS" - which of course didn't matter the five years before and it's eerily similar to an excuse used to dump few other big names in the CI's past.

The Glassdoor review from him is likely fake, though - but his post on FB in which he says this is standard corporate speak "as to not get sued by ex-employer".
Nah. That's mostly a post-fact rationalisation.

The IFCS was always all about the goal times, and those goal times were always stupid. Long before Pritchett wrote his book on the IFCS, it had been thoroughly pulled apart by people desperate to actually try to contribute and create a working and sensible flight model — they even offered up a selection of tweaked numbers that CI¬G ran with for a while in an official capacity. His departure just made it all public in a way that it hadn't been before.

There's no indication to suggest that it first worked one way, and then got “adjusted” to work another way using various shortcuts. Much like the idiotic camera smoothing implementation they choose, it was there to counteract an underlying system (in this case the CE physics engine) to make up for the ridiculous mix of artists' inability to understand physics and CRobber's inability to understand that gameplay cheats exist for a reason. Pritchett was indeed clever, and consequently eventually had to leave the company, but his work was always done in pursuit of a stupid end goal.

Or, if not always, then with enough margin that it makes no difference. He didn't leave after implementing some kind of backdoor — that code was in place at least a good three years before he left. Legend has it that the reason he left was that, having long since implemented a “physics-” and animation-controlling engine, and with the predictable outcome that everything was horrible, he got the classic pointy-haired-boss task of creating a system where everything was still ruled by a single parameter, but which somehow still recreated more realistic physics when the whole point of having that single-parameter system was that it removed the need to worry about physics. The apocrypha of that legend was that it was meant to be yet another layer of idiocy to really double down on the methodology used for the camera smoothing: put a counteracting system in place to tone down the effects of a having a counteracting system in place to tone down the effects of having a solid physics engine, all to replicate the feel of having a solid physics engine. Because adding more systems to compete with and counteract each other is definitely the best way of doing that.
 
You owe me a new iphone that doesn't have coffee splattered all over it to a catastrophic end :D
I fired my last and only ever iPhone out of clay pidgeon trap and shot it full of size 7 birdshot because it didn't have a 'back' button. I claimed on the insurance and replaced it with a proper phone that did have a 'back' button...so far, I've not found reason to shoot at it ;)
 
Last edited:
Nah. That's mostly a post-fact rationalisation.
(...)

I don't think so, because of two points:
  • You usually don't start off doing a "do anything backwards" engine. Even the headbob thing was first done there and then backwards. Which makes it likely that there was some engine first, which then got reversed. We don't know how good such engine was, of course, but I believe it was at least decent - after all if you are thorough and have experience, it's not that hard to write a piece-by-piece physics engine.
  • JP worked distantly, meaning he had no Chris supervising his work and breaking it as he went. Which - to me - means that he likely finished at least some working prototype. Only after that prototype was applied, Chris could see its results and say: "I don't like it, fix it", because I sure as hell don't believe Chris could analyze physics engine's code in a modern language.
 
A few pages ago you said you were not trying to shift the blame to another game in order to defend CiG, but here you are doing just that.
I wont comment on the "simpler" whatever (it's wrong, btw)
Simpler is better. I've never said that the flight model of FDev was worse than the flight model of CIG. Only that the flight model of CIG has to handle more datas than the flight model of FDev.

I've never touched SC, can someone confirm SC has wind and a legit atmospheric flight model?
SC has wind and an atmos flight model separate from the space one. The atmos flight is not a legit one if by so you talk about a real atmos flight model like in flight simulator.
Hard to show the wind effect, can be seen easily when the wind was coded too strong some patch ago

I'm pretty sure it doesn't have an internal physics grid, from all the stories of falling through ships, implying at least gravity in ships still sues global setting. Someone could test by putting a box in a ship and then fly it in atmosphere upside down and see if the box moved.
Doesn't know if we talk about the same physic grid here. Some details : everything in a ship is in a gravity zone tied to the floor of the ship. You put a box on the floor it will not move on the floor even if you get -10g. The physic grid I talk about relate to all object contained in objects contained in objects, etc. You can put a box in a rover and put this rover in a ship. Everything will be tied to the physic grid of the ship. If you open the door of the ship and move the rover out during flight, the rover will fall with some intertia when leaving the grid of the ship. But the box in the rover will not move (tied to the grid of the rover).
A video of rover's drop from a ship.

Why do you (LittleAnt) think that CIG can achieve what you would consider a good flight model if after 8 years they couldn't even decide on one?
I don't know if they will achieve this. I am not a good pilot and I have no solid experience in flight game to analyse what CIG is doing. They had stated last year that they will test and tweak flight model regularly during the alpha. The next big change will be in the next patch (3.10). They will add jerk to the flight model, and the wind will be better modeled. The actual structure of the ship will also have effect now, if a ship lost a wing it will not fly straight.
 
Don't give them ideas... "Windows just isn't good enough for our grand vision! Presenting..."

CIBoot v0.3.9f starting...
DRAM: 32768 MiB
Setting up zImage...
Transferring control to CIOS...

[0.000000] Starting...
[0.000055] Hardware detection in progress
[0.000210] - 8 CPUs @ 3400 MHz
[0.000405] - RAM: 32768 MiB
[0.000406] WARNING: memory is below minimum recommended, you may crash to d- uh, to somewhere
[0.000427] - GPU: NVIDIA GeForce GTX 1060
[0.000428] LOL: good luck
[0.000502] - NIC: Intel e1000 10/100/1000
[0.008605] - Network connectivity established

No Idris detected.
Abort, Rebuy, Fail?

That's already too much good will on them.

"Windows just isn't good enough for our grand vision! Presenting..."

The DOS4GW runtime "RSI Starlauncher", hand coded in the late hours of night by the Genius himself.
 
That wind thing showed that ships have no mass, or really random values (as some were affected, some not). This all stems from the totally backwards flight model. Thruster power values were also completely ludicrous for the same reasons, and not related to any physical reality or even their size (as some mav thrusters were actually as powerful as main engines..).

Simpler is better. I've never said that the flight model of FDev was worse than the flight model of CIG. Only that the flight model of CIG has to handle more datas than the flight model of FDev.
It doesnt. That's what i said, you are wrong on your assumption here. Ships are solid bodies with those vector thrusters dotted all around in both games, and huge main engines pointing at the back. Some do have reverse thrusters that are bigger (obvious on some ships in both games). Simulating that should be a no-brainer for anyone worth a salary...
 
We don't know how CIG will handle the loading. It will depend of what they can achieve in their prototype. The simplest solution would be to hide the loading in a closed dock but it can't be with the actual infos we have. Hull cannot land or lift off when full so they must be loaded in space. And they are too big to enter the actual space stations. So the loading will be visible. A simple one can be big drones getting containers in dock and attaching them to the Hull in space. The Hull need also to be docked to the station and the docking engine is not here yet. Another problem CIG had tell us is that the grid engine has to be adapted to handle the Hull folding mechanism. It doesn't work well in their prototype atm. So we will not see them in game for a long time (as usually with CIG).

I can understand that, cargo loading and unloading is extremely hard to tackle on both a technical and gameplay level, even with a team of hundreds of people and a 300m $ budget...it would be neat to see something implemented to such a level of detail as to see individual drones actually moving cargo to and from ships based on the actual amount of wares to be transferred, or drones flying about to build and repair things in space in real time, but that's not the kind of stuff that a dozen people could make with a few millions in a few years, let alone 400 people in 8 years with hundreds of mil-oh, wait:

Source: https://youtu.be/Oq53mBjZy2U


(But seriously, that's just what happens when you know what you are doing, you know what you want to achieve and know how to lay out plans to achieve it. No amount of people, dollars or years will ever compensate for the lack of those things.)

On second thought, no one here actually plays SC..... So yeah, should have just gone with QED. 🤠

Well, I don't play it but I played it! 😀 And I liked much of what I saw. The problem is that I liked far less of what I played.
(TL;DR, I'll repeat myself, but I'll keep saying that imho there's definitely a game hidden under all the mess, just waiting for someone actually knowing his business to come out and be actually enjoyed for its merits)
 
Last edited:
I don't think so, because of two points:
  • You usually don't start off doing a "do anything backwards" engine. Even the headbob thing was first done there and then backwards. Which makes it likely that there was some engine first, which then got reversed. We don't know how good such engine was, of course, but I believe it was at least decent - after all if you are thorough and have experience, it's not that hard to write a piece-by-piece physics engine.
  • JP worked distantly, meaning he had no Chris supervising his work and breaking it as he went. Which - to me - means that he likely finished at least some working prototype. Only after that prototype was applied, Chris could see its results and say: "I don't like it, fix it", because I sure as hell don't believe Chris could analyze physics engine's code in a modern language.
I think so mainly because the first time I heard about the IFCS backwardness was some time in 2016, and that was long after the community had picked it apart and started trying to salvage it with more sensible parameters. By 2017, one of the chief disassemblers were openly discussing the nightmare over on SA.

In addition, they had a straight-forward engine: base CE. It was too complicated (you had to understand things like masses and forces and accelerations) and the IFCS was something they had touted even back in the kickstarter. So at a very early stage, they killed two no birds in one stone: fulfil the input simplification offered by (a visual representation of) a FBW:esque control system, and also abstract away all that difficult physics:y stuff that no-one at the company understood. They've been fighting a losing battle to reclaim any feeling of non-noclip physics ever since…

Only that the flight model of CIG has to handle more datas than the flight model of FDev.
No, it doesn't. In fact, that's the whole point of it all: it is purposefully designed to abstract away all such things, and underneath that abstraction is the simple rigid-body simulation built into CE. The “more datas” is just a matter of: input → [calculate physical parameters based on goal times] → [feed parameters into physics engine] → output = predetermined manoeuvre. It's the same data, fed to the same kind of system, based on the same kind of input, just reverse-calculated to make all the intervening steps disappear.

SC has wind and an atmos flight model separate from the space one.
It's not a flight model — it's just a different set of goal times that are activated by being inside the appropriate zone. It's kind of curious how that video doesn't show how wind supposedly affects the flight physics, isn't it? Oh, and last time they tried to explain “jerk”, what it amounted to was thruster lag, as if to vaguely replicate fuel flow delays — not something that actually relates to any kind of flight modelling.


In fact, let's post some good old stuff…
What I decided to comment on is much smaller and much more telling about CIGs way of thinking in my opinion. The buggy. Well not exactly buggy but that 6 wheeled Apc they archered from Alien 2.

We all know that cry engine has a class for vehicles with okay-ish functionality. Indeed they used that for the grey cat for example (that buggy thing for the hangar)
But that's not what the APC or any of the levitation vehicles run on.

Now before we go into what these new fidelitious star citizen vehicles run on, we should go into how stuff like wheeled or tracked vehicles actually work and how they are simulated in video games. Because that's quite the ample topic with many possible handwaving I'll just break it down to the absolute core. The MVP for driving so to speak. That's the chassis and suspension technology. No matter if you use engines, rockets, muscle force or horses, the suspension and chassis setup and/or its simulation is the critical factor for driving behavior in real life and accuracy of a simulated system in virtual worlds.

In real life, a chassis is a volumetric elastic body with varying mass and varying center of gravity. In real life, suspensions are made of several linear and non linear elastic components, all with non linear dampening characteristics. Depending on the suspension type, you have a non linear varying roll axis, pitch axis and yaw axis, as well as non linear movement of the wheel, resulting in changes of camber, caster and the like.We can simulate them to a highly accurate degree virtually, but that takes days of calculations for a single second of run time.

In video games and especially racing simulations, a few general short cuts are taken.

The chassis is at least a volumetric rigid body with a set mass.

The suspension per wheel is an ideal spring and dampener at least. The suspension geometry is rigid. There is almost always a change of camber and caster and they often influence the force that can be transmitted by the tire. Most games, even simple driving models, simulate anti roll bars. All simulate pitch and roll of the chassis as a result of the mechanical forces on the elastic suspension during dynamic driving.

In short, although a simpler mechanic, all driving simulations from GTA over flat out to asetto corsa have in common that they use a mechanical model with clearly defined mechanical parameters and apply forces to it to simulate a realistic behavior of the chassis under dynamic driving. The behavior here is the result of the mechanics. This is important.

Now for star citizen.
As I said cry engine has a little package for simple vehicles like the grey cat which is a rudimentary mechanical driving model. But the apc had nothing to do with it. What the apc does is it completely splits the chassis from the wheels. The chassis runs on it's own behavior and the wheels have an independent code to "look like they guide it on the surface"
This becomes very clear when you look at what the chassis does when the vehicle runs over an obstacle for example. It does something no chassis of a wheeled vehicle ever does in real life or simulation. It stays still. There is a ton more indicators for this lack of actual mechanical connection between the wheels and the chassis too, like the lack of harmonics, the lack of feedback into the chassis etc. But the most telling thing is really that the chassis doesn't care if a wheel is fully compressing it's suspension.

I asked myself what would result in such behavior and what keeps the chassis in it's vertical position and the answer is as disappointing as funny. It's the same IFCS monstrosity that keeps the ships and the hover vehicles going.

IFCS is a strictly high order system. This means it doesn't care for details like mechanical parameters. You tell the ifcs "how something moves" not what keeps it moving that way. This means the entire mechanical simulation is floating. It's parameters don't matter. What matters is how you envision something to look like and the IFCS will use whatever it has available to achieve that movement pattern. This means that a spring might force 10 kilonewton between its ends at a certain compression, but when it gets compressed more it suddenly goes down to 0.1 kilonewton. This behavior is impossible for a spring, it goes against what a mechanical spring would ever do. But it is what the IFCS tells the spring to do in order to achieve a certain movement pattern.
This focus on the movement instead of mechanics is very similar to how a drone like a quadrocopter works, or a robotic arm. This kind of aproach to a full on vehicle simulation though, apart from the very strictly limited realm of zero G spaceflight, will always result in nightmarish and unsatisfying driving and flight behavior.

This use of a high order IFCS system is why the chassis doesn't give anything about the position of the individual wheel. And this is why the Rover can just gtfo into low earth orbit occasionally like the nox does when something goes haywire.

But you have to understand what this means for a gameplay versus cinematic design side. For gameplay, this is disastrous. It means that the player is unabled to predict what a vehicle is gonna do because we humans don't have a feeling for movement parameters, we have a feeling for repeatable mechanics. At the same time it's a blessing to the cinematics, because you can now go and tell a live simulation of a vehicle "how to look like" instead of going the route of actually finding a mechanical tune to support that visual appeal (which is likely impossible, because what looks good usually doesn't drive good) and now that you read this about the vehicle suspension, you should all take a good look at the ships landing gear too.

This whole train of thought behind this system, the tons of work that must have went into it and the horror that this system made it through a whole 400+ employees company without anyone of the "experienced game designers" asking "why the are we doing this instead of using something that works guaranteed and is easy to do" is what's the most telling about this whole project.
So people seemed to like the technical story about the desync, good thing I got more of those.

Let me tell you about missiles shall I?

In most games, missiles are rather simple constructs since you have to factor in the possibility that players will spam them when their supplies are full. Generally the more realistic a simulation gets, the more complexity you also find in the missiles. All the way up to for example a DCS where the missiles are pretty much equal in simulation depth to the planes itself. The game can afford that because even in a harsh engagement, missile use is complex and you won't find 2 digit numbers of them in air usually.

Cig, visionary company, again thought it would be mighty cool to inject high complexity missile simulation into what's basically intended as an arcade combat design (this isn't a judgement, it's just a design philosophy)

Now before we go into the details of how they screwed it all up, please take the time and go Google star citizen DB and check out just how much crap gets calculated for a single missile launch and engagement

Here I just copy pasted the headers of the component data that a missile inherits in star citizen
[…]
As you can see from these data headers, missiles are fully simulated IFCS objects, which means they have a complex multi order flight model instead of a simple speed and direction one.

Now I said before hit detection and hit recognition are all client side. This doesn't go for missiles. Missiles are essentially AI ships and they are server controlled.
Now remember the servers already themselves with the least bit of load from single digit client numbers (10 people on server becomes a hindrance to good gameplay already) and now you have ships like the gladiator which can fire 8 missiles in short order, or the constellation with over 20 missiles.

But not enough. This is still not completely horrible. For that we need the cig factor.

Goons and goonettes, I present you, the rattler missile.

Gaze your eyes upon Roberts wet dream from wing commander times. A missile that fires 8 other missiles. And it's the best missile in game to and comes with a hardpoint size that almost any ship can carry.


Now imagine 2 people fire 2 missiles at each other. That's suddenly 32 physics enables ifcs controlled warheads on a server that's on last inch life support already. Absolute carnage.

You wanna know why you don't see people rattler spamming anymore nowadays? Because this has been Un touched for almost a year. Cig knew about this just as long as well. Just nobody did anything about it. So even the numbest missile spammer couldn't keep a straight face anymore after bringing the server down a fith time a night after all these months. The problem so to speak, has been solved by not touching it for so long that everybody just stopped playing.

Oh and guess what Roberts decided to put into 2.6?

Missile pickups...
The physics do not take into account player inputs. Why would they? The player inputs do not have any influence on the actual speed, acceleration and jerk of the vehicle. They are just factors on the target data for the IFCS. that's why the network is synching IFCS and physics data instead of player inputs. For how spaceflight works in star citizen, other player inputs are a rather meaningless addition to know about actually. The meat of the calculations is what happens inside the ifcs, on the thruster model and on the vehicle dynamics side.

Edit :

As to why your client has to do the work

The reason for that also sits within the IFCS. when you predict the vehicle dynamics just based on current values you will not reach enough "fidelity" to accurately represent other players ships at the Update rates in star citizen (which can be as low as or even lower than 1 Hz in PU) when you hook into the ifcs you get a lot more leeway to play with. You now not only know how the ship currently moves but you will know how it continues to move as long as Player inputs are unchanged because you know the ifcs limiters and the ifcs targets. And if the player inputs change you still get more precision with the ifcs data because it's limiters slow down the rate at which player inputs change the actual vehicle dynamics.
The interface between physics and inputs is the IFCS layer.

The IFCS layer is also the backbone of the networking of the spaceflight part. The network doesn't communicate inputs, it communicates flight controller states and physics which are validated synced and send back to server for all player ships (AI ships do not fly physics based)
:ROFLMAO:
 
Last edited:
I don't know if they will achieve this. I am not a good pilot and I have no solid experience in flight game to analyse what CIG is doing. They had stated last year that they will test and tweak flight model regularly during the alpha. The next big change will be in the next patch (3.10). They will add jerk to the flight model, and the wind will be better modeled. The actual structure of the ship will also have effect now, if a ship lost a wing it will not fly straight.
My question was towards your trust in CIG after 8 years of failing to develop a competitive flight model. I wanted to know why, despite "I don't know if they will achieve this" you still show a lot of faith in CIG?
 
The poorly functional flight model has serious ramifications for the rest of the project. Look at its influence on SQ56. Distances, weapon balance, opponent numbers, scale and sizing...all these things hinge on the FM for balance and play purposes. And that's just the tip.

If sq42 releases in the foreseeable future with what we have now it's going to be panned, and that will be a death sentence for the studio.

I'm legitimately surprised that more people aren't screaming about this on spectrum.

To sum it up: "This is fine".
 
Top Bottom