John Pritchett

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.