It's come to my attention that there is a lot of concern in the community about the direction of my Gravlev simulation. I can certainly understand this considering that it went out in 3.0 in a completely broken state. Many people have questioned my approach for the system without having the opportunity to see how it behaves when functioning as intended. And until 3.2 comes out (unless we can get it into a 3.1 patch), most people won't have an opportunity to experience a fully functional Gravlev. So until that time, I'd like to take the opportunity to discuss how Gravlev is expected to function and also answer any questions and hear concerns that people might have. In general, my expectation for Gravlev is that it will function somewhere in the region between "ridiculous bouncy balloon" and a faked, collision-driven vehicle, preferably closer to the latter than the former. Whether I'm using "hidden wheels" or the system I created, the vehicle is essentially traveling on a spring-based suspension. The main difference between my model and a traditional suspension between the vehicle and the wheels, or essentially between the vehicle and the ground, is that I'm actively driving the spring's properties to elevate the vehicle to a goal elevation, rather than merely relying on a static damped spring system to allow the vehicle to ride on a cushion over the terrain. Because of this, my model has a component to it that most hover sims don't, which is determining what elevation we want the vehicle to take. I use raycasts to gather data about the ground under the vehicle, and also oncoming terrain, but I could just as easily use a physics collision mesh to gather this data. I felt that the raycast approach could be more efficient, but if it can't provide a sufficient resolution of data for the Gravlev to function properly, of course I'll adapt. But this question is entirely about how I get data about the terrain, not about how the model uses that data to elevate the vehicle. So as you're hovering along, there is a designated hover height that the Gravlev control system wants to maintain. This is set per bike by the tuners. The Nox wants to sit very low, because it's basically a street bike. The Dragonfly is a bit higher because it's more of an off-roader. But based on this desired elevation and the reading of the terrain under the vehicle, the Gravlev control system will attempt to maintain a given height above ground. It does so with the same kind of spring you'd have on a wheeled suspension, only this is a more stable and adaptive spring simulation than a static mass-spring-damper system. At any moment I can indicate what elevation I want, how long I want to take getting to that elevation, what I want my maximum rising velocity to be, as well as what I want my maximum rising acceleration to be. This allows designers to tune a hover vehicle for a wide range of capabilities, from a street bike that struggles on rough terrain, to a cruising bike that's meant to hover mostly over moderately rough terrain, to an offroader that's meant to feel every bump. In the first and second modes, it will feel very much like a Star Wars hover bike, which you generally only see over reasonably flat terrain. For the last case, it's going to feel more like a small boat or jetski, and it should because my model shares a lot in common with buoyancy in water. But again it's highly configurable so designers can hopefully get a lot of different behaviors out of it, depending on the goals for a particular bike or other hover vehicle. Using this system, I have a lot more control over the hovering behavior than I would with a traditional damped spring system. For example, if the bike is falling from a high elevation, I can calculate at which point I need to turn on the hover (spring) in order for it to arrest the falling velocity and return to the desired hover height, just avoiding a hard collision with the ground. A more traditional spring-based system would just rely on the spring having reached its limits and you bounce up with a hard collision. Traditional spring simulations aren't this adaptable and predictable. Because of this approach I've taken of maintaining a goal elevation and driving the hover vehicle up to that elevation, or allowing it to settle back down to it if it's too high, the sense that the vehicle is too floaty or bouncy depends a lot on the logic that's used to set that elevation. And that's still a work in progress. The latest Evocati test build feels like it's coming along well. But the choice of elevation in no way determines how well the vehicle can react to changes in elevation. The system is very stable and adaptive and can achieve the goal motion very well. The key is defining the best goal elevation to take as the vehicle moves along at potentially very high speeds over unpredictable terrain. And that's an important consideration for a system like this. It isn't limited to designated tracks in the game. It can go anywhere. So it needs to be able to handle a very diverse set of conditions. It makes no assumptions about the terrain it will be flying over. Something else to keep in mind with SC Gravlev vehicles is that they are hybrid space/hover vehicles. They do have thrusters that allow the vehicle to fly in space or in atmosphere. Just because you enter hover doesn't mean those thrusters are unusable. The goal is for hover to be more efficient because you're not expending thrust to stay aloft. If tuned and balanced properly, I expect this to make hover mode a useful option relative to atmospheric flight. Otherwise, hover will be nothing more than a novelty that will wear off quickly. But aside from just supporting atmospheric and space flight, Gravlev vehicles use thrusters while in hover mode. Gravlev hover doesn't provide any side, forward/back or downward force. It only provides upward force, and only along the vector of gravity. All other control comes from thrusters. So when you're turning, it's thrusters that are holding you in that turn. Also, since Gravlev doesn't generate any downward force, and only gravity will keep the vehicle down, designers can specify a minimum amount of gravity that they want the vehicle to operate under, and if the vehicle is on a lower gravity planet, the system will generate downward thrust to compensate for the lack of gravity to keep the vehicle down. This will guarantee that the vehicle will always perform as if it's in a heavy gravity environment, depending on designer settings. Dragonfly and Nox are tuned for 1 Earth gravity. The Gravlev control system is not meant to have perfect information. It's supposed to be a skills-based experience. Depending how the vehicle is tuned, some will be easier to manage than others. But you have control over the goal elevation of the vehicle, either by using strafe up/down or by using pitch up/down while in hover. This means that as you're cruising along, if you think you might collide with an obstacle or a sudden steep rise in elevation, you can increase your elevation to help the vehicle avoid the collision. This not only gives you an increase in elevation to clear an obstacle, but also improves your ability to climb a slope. All vehicles will have a limit to their ability to climb slopes, but using strafe up or pitch up will improve a vehicle's ability to climb. To break out of hover into atmospheric flight, you can use strafe up and hold it for a couple of seconds at max elevation. To avoid breaking out into SCM when climbing a steep slope, use pitch up to increase elevation instead. To drop back into hover from atmospheric flight, either strafe down toward the surface until you begin to drop into hover, or else slowly decrease your altitude as you fly until you are near enough to ground that you drop back into hover. There currently isn't a manual command for switching between modes. In order to make Grevlev control more tactical, my model includes a zone of elevation within which the vehicle experiences nearly zero drag, the result of a sort of Gravlev ground effect. So as long as you're keeping the bike down on flat terrain, you can drop into a very high-speed groove. This is only really noticeable in AB where you're able to reach top AB speed when tight to the ground, but when in the air, drag will pull you back down to lower speeds due to terminal velocity. This makes it important that you choose the optimal path to avoid unnecessary jumps when you're trying to make good time. Especially in a race, the path you choose and your ability to navigate through obstacles will have a significant impact on your overall speed. I have found this to be more interesting than just allowing the Gravlev control system to elevate you over whatever obstacles are in your path, without much need for thought or planning. Ok, I think this covers everything about how this system is intended to work. It's working very well in single player, demonstrating that the model is sound. It's still suffering from heavy load in mp, though, so I still need to work on making it more robust and stable under expected server loads. To optimize, the system can delay processing of the control system update and also raycasts, so I need to determine which of those (maybe both) are making the sim less stable under heavy loads. But what we had in 3.0, and has been seen in some leaked video of the current Evocati test builds, those are major bugs, not just instabilities due to load. I am definitely making progress resolving those bugs and the experience is getting much closer to the intended behavior. Thanks for taking the time to read about how this system is designed and expected to work. At this point, I'm open to any questions. JP