The developers cover 3.10 flight model changes: slower large ships in atmosphere, landing splines and restricted zones, targeting, high-speed combat and proximity assist. They also discuss bartenders, delivery missions, prisons, the M50 rework and the 3.10 delay.
TL;DRShips are large, heavy and made for both space and atmosphere, so speed depends on altitude and conditions; low down they can be slower than Cold War jets, higher up faster.
Well, our ships fly in atmosphere, they fly in space, so you can't really directly compare them to Cold War jets, which just fly in atmosphere. They don't have to worry about going to space. So we were talking about this the other day, and our ships are much larger than they appear to be. They're much larger than modern day fighter jets. They're much heavier. They're often four to five times heavier than a fighter jet. So they aren't designed to be super fast in atmosphere. Ultimately, we'll make them go whatever speed makes sense for the game. I'm not going to put an exact speed on that because there was just a huge variety of scenarios. All the planets have different gravity, different atmosphere. It varies like real life depending on how close you are to sea level. You go faster the higher you are in atmosphere. So as to why are they slower than a Cold War jet, I would say maybe they are in some scenarios, but they're also not in the other. I went and dug out some stats. So the Gladius in 3.10 PTU, not using afterburner, goes at 450 meters a second roughly at sort of maximum speed before you need to actively do any injection of pace, which is about 1600 kilometers an hour. So yes, that is slower than a Cold War jet flying at altitude, but that's it flying as low on Daymar as I could dare go. I then took it up to 5000 meters and it was going 900 odd meters a second, which is 3,300 kilometers an hour, which is much faster than a Cold War jet.
Yes, it's completely driven by the atmospherics. If you go low to the ground, it's going to be slower than if you go a few thousand meters up, just like real world aircraft. If you want to grab hold of a Tomcat and go full Top Gun one meter off the deck, I'm not sure you'll get the flight stats for that speed.
There's the atmospheric things and there's also the weather effects. Whatever the weather is like at the time that you're flying will impact the speed. The SR-71 didn't break speed records flying 100 meters over the ground. It did it as high up in the atmosphere as it could. So faster the higher you go up, slower the lower you go.
It's always something we're looking at. If there's one ship that's clearly well outside of what feels right, then there could be a bug there and we'll look at it.
TL;DRMissions are being made modular and scalable, rewards are still being tuned and will keep changing, with risk and reward modifiers also considered.
Well, we're changing the way that the actual missions work and making them more modularized so we can actually scale them and be able to plop them into different locations very, very quickly. And then also just adjusting them so that we've got missions that are local based versus interplanetary or interstellar. So with that, we look at the overall... We also have a rough idea of, hey, we want the average player to be earning around this much per hour. Review it. We do constant adjustments to the rewards and how much we're paid out. And basically, we do a lot of that tuning when we're actually in wave two, wave three, and wave four. So I fully expect us to still be looking at the payouts and adjusting them as we go before we go live.
And then, of course, as the economy continues to develop, as more gameplay systems come online and the ecosystem grows bigger, there may be continuing changes.
Oh, I can guarantee that. There will always be changes. And then the other aspect that we'll look into is basically how much risk reward? Are there any other modifiers that we added to it? Are you delivering plutonium versus you're delivering a pizza? That should have different rewards. But it would be the same kind of basic gameplay, taking something from A to B.
TL;DRLanding splines have improved since that feedback: gates stay visible from farther away, tolerances are doubled, and icons now guide players through the tunnel on entry and exit.
I don't know when the thread went up, but certainly at the point that went up, it was in a much worse state than it is with the latest PTU patch. Between then and now, we've done some improvements to it. The actual visuals of the... presuming we're talking about the restricted area, the landing splines, I think. The gate visuals clamp to a minimum size on screen when they're rendered, so you can see them at further distance. The actual tolerances on them are double what they were. Also, the landing icon for your designated landing pad no longer displays immediately, it displays at the start of the tunnel. You're not tricked into going direct to the landing pad versus going through the tunnel. Then we breadcrumb you through the tunnel with the icons, then give you the landing pad icon. It's the same now in reverse. When you call ATC to get out of the hangar, you have an icon with the off-screen indication that's at the start of the tunnel to guide you back out. Because there was a lot of usability there that wasn't quite right in the first release of it.
TL;DRSplines for stations have been considered, but they suit restricted zones less well elsewhere; the team thinks better markers and location identification should come first.
It's something we have considered. Basically, the way that the restricted zones work though is that you've got kind of a no-fly zone and then you've got a zone that's underneath there that's basically a safe zone, and that spline is connecting those two or letting you travel safely through that passage. I think no matter what, we need to look at our markers and the way that we identify and lead players around the space stations. So this is one way of doing it. But in Grim HEX, for example, I think we've got like nine or ten hangars that are right next to each other. And so if we did a spline there, it would be just a spline saying, okay, you need to fly over to this one, over to here and then make your way in. But that really only works from a certain angle. We're evaluating; I think it works better on ships, which John can talk about, but from a location standpoint, I think we need to do a better job in saying, for example, with Area18, right now we have the marker that says Area18, but we should have a marker that says Area18 Spaceport, and that's where you actually need to go. I think us fixing those fundamental problems would actually allow it so that ideally we don't need this extra hand holding for the player.
The issue that we have right now is the way that we have two landing zones that are fully enclosed, and then we've got two major landing zones that are open. And one of the ones that is open is Area18, and the spaceport is very far away from where the city is. The other one is Lorville. ... Do we adjust the restricted zones completely to actually get rid of the autopilot? These are all things that are in discussion right now, and we just need to evaluate what works best for the game. But it's something that's on Chris's mind, it's on John's mind, it's on mine, as well as the team's.
TL;DRA bug puts wind inside hangars, making the deliberately small Carrack harder to land; it's logged and being looked at, but there's no word on whether it's fixed for 3.10.
So there's definitely a bug at the moment in that the wind is in the hangars when it should not be in the hangars. So the Carrack is a tight fit. We made it as small as we could. We've talked about this lots in previous shows, about the problems of all the things that are supposed to go in the Carrack versus the size of the Carrack. If we made the Carrack bigger, then it can only land in the huge hangars and you can't spawn everywhere, which is sort of not good for an exploration ship. So we crunched it down as much as we could to keep the true intent of the ship, which means it is a tight fit. It fits in our metrics. The hangars are to metric. When you have a bug like there being the winds outside inside, it can cause havoc with that. That's a big problem there that we need to fix, and also just be very, very slow and careful taking it out.
The short answer is yes and no. So yes, we will be able to do that, and basically we're looking at different ways that we can do... The mobiGlas actually needs to be switched over to Building Blocks, and from there we will be doing a revamp on just the overall visuals of it and making sure that it's up to snuff. At that point, that's when I think a lot of the stuff that Zane and Bone have been working on, where we can actually switch out different styles. So it really is just almost like changing fonts in a word processing program. So at that point in time, we should be able to have different styles, and then that will also affect the text.
We've talked about the upcoming mobiGlas revamp for a while now, just converting it over to Building Blocks, and then that's where all the customizations come in.
TL;DRWind interaction is being investigated, but large ships are intentionally slower and harder to maneuver in atmosphere in 3.10 as a design trade-off, and their handling is nearly where intended.
There's two things there. There's some things we're looking at with how wind interacts with ships that's causing some peculiar behavior, but that's affecting all ships. Well, not equally, but relative to their size. So the big ships are probably less affected by it. And also big ships are intentionally slower and harder to maneuver in atmosphere in 3.10. And that's a conscious design choice. Big ships shouldn't be as good at getting everywhere as smaller ships. It gives you that trade-off as, say, a cargo runner with your big Caterpillar. Do I just go to the orbital stops and dump my cargo there and then run it with a smaller ship? That's one way of doing it. Or do I take the risk and the time to go down to the surface, burn the extra fuel? There's trade-offs for both. The larger ship handling is definitely getting towards the point where that's where we want it to be.
TL;DRTodd Papy is happy with prisons and says 3.10 eased some laws, such as accidental bumping no longer being a full crime, though some bugs remain to be fixed.
Well, we'll start with the adjustments for 3.10. So we've adjusted some of the laws and kind of how punishing certain laws could be. So, for example, accidentally bumping somebody or something like that, that shouldn't be a full crime anymore. So we've done those types of fixes. And then I'm happy with prisons as far as what kind of aspects of gameplay it's introducing, where now there's punishment. If you want to do this, there's repercussions. And obviously, once we open a different system like Pyro or something like that, then the laws there will be different. So it allows different types of gameplay in Pyro. Short answer, yes. I've been happy with the changes that have been there. And then even just watching people do the escape runs and those types of things. There's still a lot more bugs that we've been dealing with and fixing on basically the spawning of containers, as well as the changing of loadouts when you spawn and all of that stuff. So we still have bugs that we need to fix, but the overall feature, the mentality behind it, yeah, I'm happy with it.
So it sounds more like the adjustments are to the law system, to the things that get you into prison, making you less likely to go to prison for silly things.
TL;DRVisual-only targeting simplified selection but removed a cycling crutch players relied on, so cycling is returning as a full option alongside look, lock and pin, after much iteration.
Yes. The new targeting thing caused a lot of debate and feedback. We knew it would be a divisive change. When we engineered the system, the guys working on it did a great job of just putting in options for everything, and over the last two, three weeks or so, we've been trialing out different combinations of all the options that we had available to us. So maybe at the time this question was written, it wasn't the case, but it probably was in the options menu, but unbound by default. And with either the build that went to PTU last night or the next one, it will be back in as a fully fledged option. The idea for it was really to just try and simplify the selection behavior. But the sort of unintended consequence of that was the less than ideal ability of selection on the 3D radar and the feedback that gave you. Because moving everything to just being visual selection, and using it from your head look to select everything, and the removal of the contact markers meant that people had been using the cycling keys as a sort of crutch. And once those were all gone, it was very clear how much they were in use. So it was bringing back our desire for that purely visual selection mode to work with cycling. And we've had tons and tons of iteration internally, and it's been going out as frequently as the PTU builds are. So I'm sorry to everyone who's been testing those builds and finding every patch has a completely different setup, but there's been so many options to try and sort of a limited amount of time to try the different combinations. But I think what we've got now is a pretty good mix of being able to look and lock and pin targets. So if you've got TrackIR or you're just using head look, you've got the ability to look at a target, lock it, pin it, or you can just use cycling. And that cycling does work for both everything on screen and around you.
TL;DRTakeoff pitch can come from landing-gear stickiness being overcome unevenly, especially on VTOL ships with off-center thrusters, but an extreme pitch is almost certainly a bug and not intended.
It could be a lot of things. When you take off, there is this sort of stickiness on the landing gear that keeps you stuck to the ground that you have to overcome with your vertical thrust. So I wouldn't say it's on every ship. Maybe it's on some in particular, especially VTOL ones where the VTOLs aren't centered. Because it's fairly well simulated, if you've got, say, four landing gear and you're stuck to the floor and all your VTOL engines are at the back, say, like the Cutlass, it's going to rip some of the landing gear off the floor before the others, and you'll end up with this sort of torque imbalance that you then have to correct. If it's extreme, it's almost certainly a bug. It's not intended that every ship should do a 45 degree pitch up or down when you take off. Without more specifics, I can't say more.
And just to be clear, when you talk about the landing gear being sticky, that's a game thing to make sure your ships don't fly off the landing gear. There's not a digital adhesive.
We've not got a glue stick going around sticking it. It's just to ensure some level of reliability when you land your ship and leave it. It's not going to slide down a mountain.
The opening and closing is definitely a bug. I think it's fixed now. I think that was fixed last night. Especially problematic for the larger hangars, or larger ships in larger hangars, where the doors open and then close immediately as soon as they're open. You didn't quite have enough time to get out. But the cancelling requests, definitely something we're looking at, as well as increasing the accessibility of that, rather than having to either go into your mobiGlas and call someone or go into the MFDs and call them, making it a more direct action.
TL;DRThey say it wasn't work-from-home issues; targeting and restricted zones took longer, build stability problems delayed feedback, and they'd rather take extra time to get it right than ship by date.
I don't think there's any work from home issues. I think after, let's say, easily the first month, everybody was kind of in the groove of what we needed to do. There were definitely certain aspects that took a little bit longer to get right, targeting and restricted zones, two of them. And then even then there were some other bugs that we had to just deal with. And a lot of times what happens is that basically we'll be working on a build and then all of a sudden we get that build ready for Evocati. We get it out there and then there's crashes or there's deadlocks or there's a lot of stuff that basically is keeping us from actually getting proper feedback. And so once we get those things stable and we get a more stable build, then that actually allows us [to evaluate] those features and the positives and negatives of those features. So that's the way I feel about it. So with targeting and restricted zones, we want to make sure targeting was right. It's a very, very important part of the game. And we want to make sure that we supported the team that was working on it and we gave them as much time as they needed to get it right. And I mean, John can attest to it. Every single morning, in our morning, CR is sending notes and saying, hey guys, how's this? Let's look at it, so on and so forth. This one has been very, very near and dear to CR's heart to get it right. We just want to make sure the team had enough time.
TL;DRTeams start their planned sprints when the quarter ends, and the impact of a late release depends case by case on which teams are pulled onto must-fix bugs versus feature work.
So basically when the quarter ends, we already have plans for every team and what they need to do, all their upcoming sprints and so on and so forth. So as soon as that quarter ends, those teams actually start working on it. Now, if a Live Must Fix bug comes in, or something that I feel really needs to get fixed or John feels really needs to get fixed or any one of the other directors, then we pull somebody off to fix it, and then they go back to their sprint work. So it will really depend on the team that is working on it. But for example, let's say we shipped 3.10 right at the beginning of July. And let's say targeting wasn't working the way that we wanted it to work. That team would still be working on targeting. We wouldn't just be putting it down saying, okay, it's good enough. We would continue to work on it and basically adjust other plans. In essence, it really depends on what team is being affected, but for the most part, a lot of our bugs are just somebody going in, recognizing, oh, that needs to be fixed, and they fix it, and then they go back to their feature work.
Yeah, and even then, for example, if it's a moderate bug or a trivial bug or something like that, we take it on the chin, we're like, okay, we're not going to fix it this patch. We'll move it to the next one, and basically we'll allow them to continue on their feature work, because we feel like that's more important versus a moderate bug or something like that.
Yes. And the other thing is that we have a label that we call gameplay experience. So anything that has a gameplay experience bug that is a trivial or a moderate or anything like that, I view those as extreme. So basically QA flags those to me and I go through and I basically am kind of the judge and jury on those. I'll sit down and I'll review it and I'll think about it and then basically either assign the label or not assign the label. And then what we've asked the teams is to try to work through as many of those bugs as they possibly can. And even when they're triaging bugs or working on bugs, they're still looking at those and viewing those as, yes, I need to fix those before we do another release.
Yes, but not in 3.10. We're definitely looking at all those quality of life things, like Todd mentioned with the gameplay experience label. These little bits that all add up to a less than ideal experience when you're playing the game, that compared to a feature aren't as much work but do add just as much experience to the game.
It was intentionally reduced from its 3.9 levels, and again, it's had another pass this week. It was a little too harshly tuned down compared to 3.9, so it's had a little bump back up again. It's still a very effective fighter if you look at all the metrics for it. The Vanguard owners are caught in this weird cycle of they hate their ship, but it's an amazing ship to use and fight with, but they hate it.
There's definitely some things we want to tweak, but where it is in 3.10 is probably where it's going to stay for 3.10; everything else would be in the future. A common thing we've seen from helicopter pilots is asking for a more collective way of controlling it. I'm not sure we'll go down that route, but certainly the behavior, I don't have my spaceship to hand, where people are expecting VTOL, if they pitch forward, to fly slightly forward is not quite that. It just sort of strafes and does a weird thing. That's something we'll be looking at.
TL;DR3.10 slows missile lock and auto-gimbal tracking above SCM speed to discourage high-speed fights; other ideas were tried but not enabled, with further changes possible later and flares working again.
Yep. So the two features of high-speed combat that we're releasing in 3.10 are the increase in lock-on time for missiles when you're above SCM, and that scales depending on how far above your SCM speed you are. So if you're one meter a second over it, you're probably not going to notice the slowdown in your lock time for missiles. If you're doing 2,000 meters a second, it's going to be minutes to lock. And all of these ideas and implementations were there to disincentivize players from fighting at high speeds, because at higher speeds the combat range just got bigger and bigger and bigger and you just ended up pixel hunting, and we really wanted to bring those fights back in. And we've got some mid and long term plans that we'll go over in the future about bringing that in more, which sort of superseded some of our plans for high speed combat, which is why it's perhaps not quite as big as people were expecting for 3.10. The other thing that it does is it changes the auto gimbal slew rate when you're above SCM, so the speed it takes for your auto gimbal cursor to track over the target in the cone is slowed down. Again, it scales: the faster you go, the harder that is. We had some other things that we tried, which was just a flat out weapon spread increase, but it felt very artificial and weird to play with. We tried reducing the shield face strength. And that was sort of cool. It worked, but we didn't really have the UI reinforcement to explain what was going on there. So we didn't enable that in the patch because it ultimately just became confusing. And a lot of it was tied into the state of missiles and countermeasures. When your shields became weaker at speed and you were trying to run away, for example, without a way to effectively countermeasure missiles, missiles just became a one-click win for the person who wasn't running away. And we wanted there to be a lot more counterplay there. So for 3.10, it's just those first two bits. For 3.11 or later, we might do some more, but we have some other ideas that we want to try first. High-speed combat is sort of the wrong term for it. It's more getting closer combat at lower speeds versus high-speed combat.
Close combat improvements or something like that might have been a better term. And then, of course, I know we're talking about 3.10 here, but part of that continuing work that will continue beyond 3.10 is revisiting missiles and how they work.
Yeah, flares should work again in 3.10 now. We're looking at chaff. Chaff is a curious one. It's quite hard to use anyway, but we're going to try and squeeze a temporary fix in there so at least those two work for 3.10.
TL;DRThe pip erratic behavior is real: pips depend on data quality and network conditions, Fixed Assist mitigates it, getting closer helps, and 3.10 removed acceleration that caused rubber banding.
You're not crazy about this one. Pips can only be as good as what's given to them and how the network is performing at that time. So they're not a 100% guarantee of success if you hit them, because there's things outside of everyone's control that can get in the way there. And that's part of the reason Fixed Assist was put in, to sort of try and mitigate some of that fuzziness for when people are doing stuff like this. The best way to mitigate that is to just get close, because there's just less chance of things going wrong in between. That's really it. Yogi would be a really good person to answer this more in depth, because he did a lot of changes for 3.10. I think we removed the acceleration off them for 3.10, which was causing a lot of that rubber banding effect that people were getting with the pip. So they are more accurate, but they're now at the mercy of: if you put rubbish in, you get rubbish out of the data.
TL;DRIt's a fine line: racers can be fast but must not become better combat ships, so they'd look at other advantages like handling, sustained G in turns or atmospheric performance instead of top speed.
It's a tricky one. It's a fine line, because certainly past history has shown that the faster things get, the better they are, because they're harder to hit. No matter how weak you make them, if you can get a bit of paper with four size 10 guns on it, you're going to win every fight because you'll hit first. So it is a fine line of letting racers be fast, but not allowing them to be so overgunned that they become better combat ships than the dedicated combat ships. So we have to look at other ways, like maybe they're not technically the fastest on paper in a straight line, but they have the best handling. Maybe they can sustain more G in turns, maybe they're better in atmosphere, all these little things we can add that when you put them all together make a nice handling agile ship that isn't the de facto best combat ship.
TL;DRTeams did some small rework for Server Meshing, but for iCache they wait and redo things afterward or live with the pain, building current systems so they should work when those features switch on.
No, no, no. In fact, for example, every single team had to redo certain aspects of their code for Server Meshing, just to make sure things worked. But those were pretty small tasks. And I think at least my teams blasted through them in, I would say, about a week, so it wasn't like a huge painstaking thing. But with iCache or the other aspects, let's say we know we're going to be redoing something. We'll wait until iCache is done, and then we'll redo it. In some cases, we'll live with the pain, where we look at a system and we know we want it redone. But if we're working on a system now, we know what iCache is going to be doing, we know what Server Meshing is going to be doing, and we're making sure of that when we're building these systems, and they should work when that switch is flipped.
The actual visual styling of them is pretty close to where we want them to be. There are a few things that we want to add, but it's not going to come for 3.10, because it requires some work from other teams, and that's adding the ability to add drop shadow or dynamic brightness to those HUD elements, just so they work across all visual backgrounds. Something else that went into 3.10 was the actual HUD. The HUD UI in ships dynamically adjusts based on what's on screen. If you're in the dark depths of space, it dims down so the eye adaption doesn't get blown out. And then if you're facing a bright white planet, it brightens up so you can see it. But unfortunately, that only applies to things in the world, whereas these reticles and markers are sort of on your lens or in your visor, and that goes through a slightly different rendering path. So it can't use that system out of the box, and we want that to be able to be used. So then everything HUD-wise will dynamically adapt in terms of brightness and visibility.
TL;DRProximity assist raycasts in six directions and lowers acceleration near obstacles by a design-set curve per ship, giving time to correct rather than preventing collisions.
Yep. So proximity assist basically just looks around the ship in six different directions. It just does a very quick, simple, cheap raycast. And if there's something that it hits in that range, it then works out how much it needs to lower the acceleration of the ship, not to avoid it, but to give you a chance to correct yourself before you hit it. And then how much it drops off is just based on a design-driven curve. So it's not the same drop-off for every ship. We could make it not drop off at all for one ship if we wanted, or be insanely high for another.
Yeah. Nothing's going to stop you as a player just holding down that button and crashing into things. If you want to do that, sure, do that. This is just for those situations where you haven't quite realized how close you are to a surface, and without any assist at all, you would just smash into it. This gives you those extra valuable half seconds to make a correction.
Some of the stuff that we've seen is basically setup issues. With us going through and setting up each bar differently, because each one is different, we have to go through and do an initial setup of those things. In some cases, some animations have been set up wrong, or maybe there was a code bug or other things that were happening on the server. Over the past week, I think I've approved, I want to say, about 20 different bug fixes just in bartenders. So it's something that the team's aware of, and they are focusing on making sure that it's as smooth as it possibly can be. I mean, we know that it's taken a while to get out there, but basically that vendor behavior was a bear.
TL;DRBartender work, covering usable routing, menus, patrons, liquids and animation, is meant to establish vendor behavior reusable for weapon vendors, possibly mission givers, and shared with Squadron 42.
There's basically usable channel routing, the way that the bartenders select what they're going to do and how they're going to do it. There's the menu system, that's basically where we bring up the inner thought and how that connects into the stores. There's obviously the patrons and how they react to it. Then there's liquids, and basically the pouring of liquids and making sure that that stuff looks right. Then there's the way that the bartenders actually go in and out of usables, and in the future it'll be motion matching that will help that. So there's a lot of intricacies that happen with basically the bartender as well as the bar patrons that have taken time to get right.
And the virtue of all that is that it's not just to make a bartender. It's to make our weapon vendors. Aspects of that can be applied to mission givers at some point.
It's just vendors in general. Basically, we have an S42 rep, so when we're developing these things, we're looking at what's needed in S42. So there's correlation between both projects on this thing, making sure it's done right.
Not yet. ... Actor Status 2.0, or the next version of actor status, where you're dealing with radiation or you're dealing with being able to be drunk or stims. And then from there, in the future, we'll have diseases and we'll have other aspects that the players will need to deal with. But at least for actor status 2.0, that's when you'll be able to get drunk.
So basically, when we do the initial calculations, it is based off the distance to the star and then atmosphere. For example, Aberdeen is really, really hot, and we knew that that one was going to be very similar to Venus. So then we have what we consider a min-max of basically the temperature at its hottest point and then at its coolest point. And then throughout the day, it just cycles through that.
TL;DRTemperature doesn't currently affect handling except through pressure, air resistance and gravity, but in future it will affect ship items, such as cold-start warm-up, overheating, and heat spreading inside a ship.
The temperature doesn't currently. Well, handling-wise, it's purely just based off sort of pressure, air resistance, gravity. If temperature adjusts any of those things, then it will, by virtue of adjusting those three parameters, change the handling. What it will do in the future, though, is impact the items on the ship. If you land your Carrack on microTech in a storm and you turn everything off and you just go on an expedition for a couple of hours, when you come back to your ship, it's going to be so cold that you can't just flick a switch and take off immediately. You're going to have to sit there and let it warm up to operating temperatures before you can do anything. The same is true for, say, Aberdeen, that's quite toasty. So you would expect your thrusters and your external items to start overheating a lot quicker than they would in space. And it will even go down to the extent of, again using the Carrack, you land the Carrack on Aberdeen, open that front ramp. The heat from outside is going to start going into that front cargo area. If you just start opening doors between the two on the ship, the heat's going to start spreading through, and your life support on board is going to try and maintain that, but just like an air conditioner in real life, if you just open the front door of your house, your air conditioner is going to start trying to cool the outside of the house down and not do it well.
We're still talking about it. If we do it, I think it'll probably be for everyone. But there's always considerations. As far as wiping, is there an exploit or something like that that we have? And right now we do have an exploit on PTU that we're fixing. But nothing that I can confirm at this moment, just because we're still on wave one. And once we get to wave two, wave three, wave four, we'll basically start really talking about this. Right now, we'll wait and see.
In 3.10, it'll be killing. The whole idea about these things was just a way for us to introduce some new fun types of Star Citizen style weapons, or weapons that we feel fit in our universe. So that was the first initial stab. And then from there, basically we've adjusted our damage types. So electric is one of the ones that will actually kill, but then we've got stun and we've got distortion, which will obviously affect your ship and will affect your components, but it won't do anything lethal to you, but stun will actually knock you out. So in the future, you could see these electric type weapons as maybe tasers or non-lethal weapons that you can actually use for bounty hunting or whatever else you want to do.
TL;DRBoth engine styles were built and the older round ones were kept because they looked cooler; the plan is for swappable thruster sets, with the M50 almost certainly first in a future patch.
So we built both sets. When we were doing the M50 rework, we thought it'd be cool to see what it looked like with the modern Origin style slatted engines. And ultimately we presented both options to Chris. I was like, this one fits with the style guide, looks cool. And he was like, yep, looks cool. But here's the older style ones. And he was like, yeah, sure, they don't meet the style guide, but they look cooler. And that's what's there to start with, so let's keep them there. But in the future, we are going to enable you to swap out thruster sets, and so the M50 will almost certainly be the first one, in a future patch, where you can go to an in-game shop and buy square slatted style rear thrusters and put them on your M50 and have slightly different handling and slightly different visuals, because we built both, it'd be a shame not to use them. I know some people really love the round engines, some people really love the slatted engines, so why not both?
TL;DRJohn Crewe is proudest of the turret improvements for multi-crew play, while Todd Papy highlights the new UI, delivery work, and finishing New Babbage.
For me, it's all the turret improvements. Huge, huge improvement over what was there in previous patches. And it really adds just a whole new level of multi-crew gameplay, because the turrets can now track things better. They can hit things better. You've got the pinning from the pilot so you can coordinate. It's such a big change.
I think there's the new UI going in. I work very closely with the UI team, so seeing that go in has been very beneficial for team morale, as well as, I think, players enjoying it. Then, basically, there's the new stuff that we're doing with delivery. And I'm talking about teams that I deal with. So I think those are two things that I'm very proud of for my teams. And then things that I deal with on a secondary basis would be us finishing off New Babbage, putting in the factory line, and being done with New Babbage now. It's basically just one more thing done to the same system, and now we go on to some of the big boys.