Calling All Devs - Everything Flight Control and More

Yeah, so it's actually very similar to what we've been doing with the Items and Ships 2.0, and it's essentially making things easier for us going forward, making everything a lot more efficient, especially code side as well. And in the case of weapons, making bespoke setup much more of a thing of the past. So previously we were using our old XMLs; we're now moving over to DataForge. I'll give a little shout out to Torsten in Frankfurt, who's been working very hard on this for months. He's the coder who's been working on the system with me a lot.

Basically, we're avoiding bespoke setup on weapons now because there were cases where we wanted to make some really, really cool weapons for you guys, but we were really hampered by what we could do with our existing system. So we were very limited to: is it rapid fire, is it burst fire, is it single shot? And if we wanted to do something special, we would have to get a coder involved to jump in and do a bunch of work for us. Whereas now, as we go further down the line and we might start investigating some damage types and things that start to get a little bit more weird, we might want to have a lot more interesting behaviors on there.

The new setup, it's difficult for me to formulate how much it actually does into words. Now we can combine different fire modes in different ways. So the Custodian, as an example, is a weapon we've got live at the moment. And I think a lot of people know that in 3.1, a second fire mode might have slipped in. And that was because we were testing ready for Weapons 2.0, which is it always was planned to have a charged burst on the weapon. That was something we could never do previously, but now we can use a charge fire mode with a burst inside and we can do what we need to with the charge to make the burst better. So that's just an example of how robust the system is, in that we can do all of these strange things without needing code support anymore.

Specifically on FPS weapons, we're also looking at recoil. So we've been using our reasonably simple recoil system that we've got in our Mannequin editor at the moment. That's all being moved to DataForge as well. So it's a lot easier for people like me to use and edit live while I'm actually playing the game, so I can do a lot more fine tuning on there. And we're getting a lot more camera movement involved and everything to make the weapons feel a lot more punchy, because we've been listening to you guys and a lot of people think that we're not rough enough with the weapons. They don't feel punchy enough. So that was one of the things we took on board when we were redeveloping this stuff.

And one of the very big things for FPS is the attachment system. We really want to start pushing on that, and I'm not saying it's going to be coming anytime soon, but we've allowed for all of the stats on the weapons to be modifiable. So we can start to think about adding things like silencers, compensators, different scopes, and all this kind of thing that you can change in and out in your PMA, and you'll be able to see your weapon stats change and feel an effect on the weapon overall. So yeah, we're really leaving it open on the FPS side, basically for all of our systems going forward, so we've really future-proofed our system here.

Ship weapons specifically as well, we can do some new interesting things on there now that we've got Ship and Item 2.0, or it's currently in process like you say. We can now tie weapon behaviors a lot more into the heat and power system than they've ever been before. Previously we pretty much only really had: is the weapon on or off, or is it overheated. We can now take a look at how much power it's receiving and then curve the stats a certain amount. Like, oh, if it's only receiving half power, then it fires half as fast, it's only half as damaging and stuff like that. So we can even start investigating something like the hotter the weapon's running, the more damage it does or the faster it fires. So you're kind of skirting that line between overheating and reaching your max firepower.

So yeah, those are the main points that I really wanted to cover. I'm pretty excited about this going forwards and actually getting it into game, but I can't say when it's actually coming yet.

Well, that's an interesting question. I'm just going to put this out there as an idea that I've been batting around and something that I'd really like to come to fruition one day. We have the Ark in game. I would very much like that to be a destination where players can go, not only to explore a really cool museum-like space, but to actually access the Galactapedia through it. There are other ways too that I would like players to be able to access the Galactapedia, like through your mobiGlas. That's one of the biggest goals that I really, really want to see realized, so that players can access the Galactapedia both through their browser, through some kind of app we have on the website, or through your mobiGlas in game.

And what is the Galactapedia itself, for anybody that might not know what it is?

Well, the Galactapedia is the in-progress in-game encyclopedia documenting the history and lore of the Star Citizen universe.

Oh, I imagine that probably takes up a fair amount of time.

It does. But we're doing active work on it right now. We've had a couple of meetings with Turbulent to talk about it. So it's in the works on the tech side. And on the lore side, it's been in the works for quite some time now.

Yeah, it does. The reason why it's like this is actually a combination of some optimizations in code. One of them has to do with the fact that we don't want to do a long raycast, which is how we figure out if something is within a certain distance of something else in physics. Doing that over cosmic scales can utterly crush your computer. So we do some smart optimizations to only do intersection testing against celestial bodies for quantum travel. So this skips smaller things upscale. We do a near-field raycast check against something that you're directly in front of or close enough to be in front of. There's actually another optimization that prevents this from working, which is that the asteroids themselves aren't physicalized at a distance anyway. So even if they were, it wouldn't work.

Long story short, the game is more efficient because of some optimizations we put in. However, this is not an unsolvable problem. We just haven't spent the time yet to come up with a good methodology to include the intersection testing for the asteroids in the case of quantum travel. That is a solvable problem, and it's something that we do want to do in the relative near term. It's not on a schedule that I have seen for this particular release, but we know about the problem and we know that we want to fix it. So it will happen.

Well, first of all, when it came out in 3.0, obviously, it was completely broken. I haven't really seen much evidence from the live version that it's doing anything that I wanted it to do. So we did our best, crunched all the way down to the end, and I think we had it working pretty well up to about a day before release, but it still didn't make it out there in good condition.

Now you're talking about one of those things where you've got the individual system working, and then when you start pulling all these other systems together for a big patch... When you say you had it working the day before, it's when you start putting all the pieces together, that's where the overwhelming majority of bugs come from.

Right. So yeah, and really, if you've played the game, you know IFCS itself has been in pretty bad shape since 3.0 came out. There were just so many changes to the engine, and there wasn't time to really do a proper fix. So a lot of those things affect Gravlev as well as general IFCS. There are some greater issues really with Gravlev. So yeah, if you can get it to hover at all, you're lucky right now. But the changes that I've made, the work I've been doing on it since the start of the year, it's really coming along, and we've got it up for testing on PTU, and I'm getting good results, good testing, good feedback with that. And we're hoping to... I don't know if it's going to be something we can get into a 3.1 patch, maybe it'll get a little late for that, but certainly 3.2 is definitely what we're aiming for.

Okay. Well, one of the real challenges for a system like this is I don't want to implement a very specific hover behavior. I want it to be a very generalized system and then turn that over to the designers and give them a lot of flexibility for them to decide this is a bike or this is a tank or whatever, and get a lot of variation out of that. So there are some specific approaches that I've taken for how you can implement or tune hover for all these different vehicles.

So for the Dragonfly and the Nox, really not a lot of variation there. I kind of see the Dragonfly as being more of an off-roader and the Nox being more like a road bike, a street bike. So you tend to want the Nox to hover fairly low and require fairly flat terrain, not a lot of variation, without it starting to bottom out and things like that. Unfortunately, right now there are a few issues with the Nox. It's not even behaving as well as I would expect it to. Even on straight flat ground, it's dragging. But the Dragonfly, you'd want to be able to get out on a little bit more rough terrain and feel the bumps and have a little bit more control over rough terrain.

And so really to achieve that, I have a system where the hover vehicle control system is basically determining, based on the terrain that you're over and also the terrain that it sees coming, what it wants its elevation to be. And so it's constantly saying, okay, I need to be 10 meters off the ground right now, or five meters off the ground or whatever. If you're on a nice flat cruise, then it can be right down there, half a meter off the ground. So it sets a goal elevation. And then the physics of the system, essentially a spring simulation, is going to determine the rise and fall. Well, not actually the fall; the fall is generally going to come from gravity, but pushing it up to achieve whatever elevation the control system is looking for. So I think what we're seeing as the main issue is that the control system isn't getting enough data really to be able to make good decisions about its elevation, as opposed to the system not being able to achieve the elevation that's desired.

So anyway, getting back to your question, you're asking how I've implemented it in order to achieve the vision that we had for hover vehicles?

I was just asking what your vision was.

Yeah, well, so that's basically it. I just wanted it to essentially be as close to a physically realistic, acceleration-driven hover, being very, very careful that the Gravlev itself is only ever really pushing you up. So then if you go up, the gravity is going to pull you back down. So you feel like you're kind of catching air. It feels like you're jumping, as opposed to a system that's managing your full elevation up and down. And then of course Gravlev is really frictionless when it comes to lateral. So when you're turning and things, that's when thrusters from the vehicle are going to come into play. And that's, I think, something different that we do than you see with a lot of hover bikes in games: it's a hybrid atmosphere/space vehicle. So it has full thruster control when it needs it. We go into hover mode really, I think, more as a matter of efficiency, because then you're not having to burn thrusters to stay aloft and you can save on fuel and all that. But you're still using those thrusters for a lot of your maneuvering.

Well, the thing that's really holding it up is I'm fixing a lot of things: IFCS itself, the atmospheric flight model, Gravlev. I have to have all that done before any of it can be checked in. So I actually have made significant progress on the atmospheric model. I talked in a recent ATV about where I wanted to go with that. And the main thing was I wanted the control system to actually utilize drag and gravity as part of its control, as opposed to the initial implementation, which was just that it would compensate for those things. And then its control system was essentially the same as it is in space. The compensation gets you to the point where it's basically zero drag and zero gravity, and then the control system is similar to space, except then you have less thrust available because those things are being used for compensation.

So at this point, you have that, right? So if you're pushing into drag, of course, you have less thrust available for accelerating forward because you're expending a lot of that thrust just to overcome drag. But the part that was missing was that when you start to slow down, it's actually using the drag that's pushing against the vehicle as part of your slowing-down force, as opposed to nullifying that out and then using thrusters to slow you down. So now when you turn and you bank into a turn, you'll feel a much stronger stopping motion on that slide than if you were just doing a straight yawing turn and not bringing as much of the surface area of your ship into the drag. And of course when you're falling, you're going to have a lot more acceleration to drop down because gravity is helping you. And as you're going back up, it's going to work against you. And so all that variability that you expect from atmosphere is going to come into play. And that's all in there now and seems to be working very well.

Well, it's still evolving. Right now, what I plan to check in for this version is that for vehicles that have VTOL, those thrusters will be utilized strictly for countering gravity. That's their primary role. And so that leaves your maneuvering thrusters free to give you as much acceleration as you would normally have, because essentially the VTOLs have nullified the gravity. As opposed to if you don't have VTOLs, then you're taking at least one G, depending on the planet, out of your upward thrust, and then whatever's left you can have for maneuverability. So with a vehicle that has VTOLs, you would expect that its plus-Z maneuverability would be close to what you have in space. But without VTOLs, it would be significantly less.

And I know other developers have said that if you're flying in a ship that doesn't have VTOL and you're using your maneuvering thrusters to hover, when the wear and tear comes in for ship components, that's going to wear a lot more on maneuvering thrusters trying to hold your ship in place.

Right. And heat. That'll hopefully be a factor as well.

So while you may be able to float like a butterfly in a Hornet or whatnot in the atmosphere, you're going to burn those thrusters out a lot quicker than if you have a dedicated ship with VTOL, like a Terrapin.

Yeah. Well, the plan we've talked about, and I haven't had a chance to really bring that in yet, is that your thrusters are going to really have two modes. One's going to be: how do you generate sustained thrust, like you would need for gravity, for a long period of time, versus what thrust can you generate in a quick hit, a quick delta-V, to get from zero to max SCM velocity or whatever. Those are going to be two different acceleration levels. Basically call it sustained thrust versus impulse thrust. So the thrust that you have available for combat maneuvers, which are quick impulses to change velocities, is not going to be the same acceleration that's available for staying up in gravity. So yeah, that'll make a big difference, even without VTOLs, because a lot of our fighters aren't necessarily going to have dedicated VTOLs.

Okay, well, if you've flown the ships in 3.0, you know that IFCS basically has been drunk for a while. It's really unstable. A lot of the changes in the engine, optimizations and things, hit it pretty hard, and it just wasn't something we could do a quick fix on. So it wasn't until after 3.0 that I could really take the time and dig in and fix these things right.

So the main thing I had to do... One of the optimizations we did was moving a lot of things off the main thread, or in my case, the physics thread. It was a big blocker on the physics thread to do all the processing for IFCS. So we moved basically the entire IFCS off the physics thread into a lazy batch update, which depending on load will get called more or less frequently. And unfortunately that puts IFCS out of sync with the physics simulation. The physics tick could run two or three times before IFCS gets an update. And you just can't have a stable simulation that way.

So basically my solution to that is I had to go in and separate IFCS into two parts. One is the control system logic, which is really where all the load is. And the other is strictly the physics simulation part, where the control logic says this is what I want the ship to do, based on player input and all these things. And it can update that state as quickly as we can get it. But then the actual physics processing, generating the accelerations and everything, that's working every physics step in order to achieve whatever the requested goal is from IFCS. And so that can remain as smooth and stable as possible. So yeah, I've done that at this point, and that's working very well. I'm still working on trying to get ESP to work properly with the new system. That's why in the PTU right now, combat is terrible. So hopefully I'll get that cleaned up here pretty quickly.