Developers discuss procedural markup for vaulting and mantling, including landing on uneven terrain, and motion warping prototyped on that system. They also cover the cruise decoupling bug, atmospheric versus space flight tuning (drag, IFCS), and planned quantum travel trail detection and interdiction.
So not currently, because this would basically be mantling. We have a vaulting and mantling system, being able to jump up and over things or jump up onto things. But currently everything is manually set up, so we've got a lot of manual markup. Something that we do want to look into is procedural markup for vaulting and mantling. So the scenario that you've just described, basically, if the height requirement for the surface that you want to jump onto, so the lift, is high enough to justify having to mantle up onto it, then in the scenario where we have the procedural markup, you'd be able to do so. If it's low enough, obviously, you can just jump onto it. That's something that would hopefully be covered with this procedural method.
TL;DRYes, vaulting and mantling were used to prototype motion warping, which extends animation sections to fit different obstacle sizes and gives smoother transitions.
Yeah. So the last ATV we covered, we basically used our current vaulting and mantling system to prototype motion warping. So what that is, is it's extending animations for periods of time so that you can extend whatever animation that it is that you want. This can only work for animation-driven motion, by the way. So it's anything that, once the animation is playing, it's going to move the player somewhere whilst the animation is playing. So what we did was, because all of our animations for vaulting and mantling were kind of specific to specific metrics, to be able to jump over a specific wall, a specific depth, that kind of thing, now what we can do is have one animation that has every part of that. So the part where you climb the wall, going across the top of it and then the exit. And then what we can do is mark this up now to extend it. So we can say this wall is two times the length of what the animation would have been, but that section of the animation where you're climbing over the top can kind of be extended for this new depth. So that's what motion warping is basically, and we use that for vaulting and mantling. It's a lot smoother, because previously the segments of the animation were all separate. So now we're able to stitch them all together and it's a very nice, smooth transition from one to the next.
TL;DRLosing speed when decoupling from cruise is a bug that will hopefully be fixed, and the longer-term aim is to stop cruise from kicking players out at all, with no roadmap commitment.
So that's a bug, plain and simple. It's not the intention. In fact, the whole kicking you out of cruise is really not ideal and we're going to move toward a variation of cruise where that's not the case. So I know there are situations not only where you get kicked out of cruise because you're in decoupled, but you get kicked out of cruise because you're, say, using a dual stick setup and you slightly move your left stick or whatever and then you get kicked out, which is really frustrating. So the end goal is that you actually don't get kicked out at all and you can cruise and move around slowly, because you're going really fast. But that was the intention. And right now, decoupled kicking you out of cruise is absolutely a bug. That's definitely not what we want. So we'll just try and fix it, and you will hopefully be able to do that, and in future you will not get kicked out of cruise at all, which I think will feel a lot nicer.
That experience is a bit frustrating at the moment, because I think the way that cruise was designed as it is now is that you need to be traveling forward to get into cruise speeds. But that means if you're using a dual stick setup and you slightly move your stick to the left, you're not strictly traveling forward, so it kicks you out. It's just annoying. So we'll get that fixed.
TL;DRAtmospheric flight is not expected to change much for the first Hurston release, a basic implementation, though they say they intend to work on making atmospheric and space flight feel different.
I mean, they are very different states for the ships to be in, and I think there's a lot more to do. And I know we're kind of not happy with where things are at the moment. I know community backers aren't happy with the differences between the two states, between space flight and atmospheric flight. A lot of that comes down to the tuning of the ships. We've got two very different systems in place. The tuning of the ship is very different; it's just that it's not different enough. Drag, for instance, is the obvious one that is affecting ships. It wasn't so noticeable before, I think, 3.2. The last big batch of IFCS improvements that John made really made it a lot more noticeable. It's really just, as I say, it comes down to the performance of the ships and allowing the atmospheric differences to affect the ships more. And that's what we're working towards. For 3.3, it's looking unlikely that there will be that much difference, but we are working towards updates and improvements to it.
Now, when you say it's not likely to be that much updates, that's because the Hurston that we intend to roll out with 3.3 is what we commonly refer to as a tier zero implementation. 3.3 is more about getting the planet itself in, and the object container streaming and all the assets and stuff like that. The current moons we have, like Yela and Cellin and whatnot, don't have a whole lot of atmosphere at the moment, so the big atmospheric changes haven't been absolutely necessary up until this point. With Hurston, we do intend Hurston to have a breathable atmosphere. I was asking around on this, so forgive me for jumping in with this, but our first 3.3 implementation won't have the full atmospheric flight changes that we're intending. But we are intending them. I think that's the more valuable part of that.
IFCS isn't done by any means. We're still working on it. We're forever talking about how it should work and what we're going to do next. Atmospheric flight, we need to come back to it, especially from the design point of view, just making sure those ships are different enough. And as you say, the density of the atmosphere is going to be much higher on Hurston than the moons we have already. So we need to really notice that. It needs to be a considerable consideration for the pilots.
So not something that folks should expect for 3.3, although maybe we'll be surprised, but I wouldn't expect it for 3.3 in the rollout. But it is something that we want to work on. It is something that I know I've heard Chris talk about in the past. He wants that tangible difference, that sense of difference between flight in space and in atmosphere. As for the details and how that will present itself, I'm going to say stay tuned. We've got some stuff in the works for you as far as getting that information to you.
TL;DRPursuing or evading ships through quantum travel hasn't been designed or implemented yet; they want to let players detect quantum trails and later decide on evasion ways like masking.
So we haven't actually gotten to designing or implementing that. I know what we want to do is we want to be able to have a system with which you can scan, or just somehow be able to detect, the quantum travel trails that people leave, so that you should be able to see that a ship has taken that particular QT course. And now that we have curved QT trails, the paths, you should be able to determine where that course had led them to. I think we've got to do things like be able to detect maybe ship type, other things, like depending on what we do for our evasion or stealth skills, we might be able to detect things like the owner of the ship or the pilot, the faction of the ship, maybe where its last known destination was and when it traveled. So you know generally the snapshot in time of when that ship had actually traveled that course and whether it's worth pursuing them. I think once we get that system in, then we'll determine what we're going to do for evasion. So ways in which you can mask that data or mask the trail itself, maybe have it tied into the quantum drive itself, or some kind of technique in which they actually do their quantum travel, the calibration for it, could be tied to it. But we haven't quite got to that point yet.
TL;DRItem grade and quality could affect signal strength for detecting quantum trails, with ideas like interdiction nets on busy routes, hiding in traffic, and smugglers' bins, though nothing is committed.
So the grade of them and the quality can determine maybe the signal strength level. There should be a minimum level so that you can detect these things. I think something that would be interesting would be if there are really common routes that people take for trading, and you see a whole bunch of very, very close together quantum travel trails, it might be a good place to put some kind of quantum interdiction net. It might be like, catch the next guy that's doing some cargo transport and catch him in the spider web.
If it's a commonly traveled lane, that might even be a way for you to mask yourself. In some cases, it would be dangerous because that's where people would put interdiction fields. But in other cases, if you're trying to hide in plain sight, you might choose to do something illicit in a commonly traveled lane so that your trail masks in with all the others.
Right, we were talking about some ways in which we could have smugglers' bins inside of the interiors of some of the ships, so you can put cargo in there that you don't want to be detected, either by scan or, I suppose, by this quantum travel trail detection. So even if you do get interdicted, get boarded and scanned, they don't find your salacious cargo.
There might even be something coming up in the near future that might take some advantage of some of that. And that's all I'm going to say at this point.