Kirk Tome

Sure, I'll sort of lead it off in terms of what the expectation is on the high level. And this is something we, company structure-wise, put into place about a year and a half, two years ago, where we had pillars, where there was a given director, whether it was John Crewe on the vehicles, whether it was Rich Tyrer on the actors, whether it was myself with both of them, that the way the pillars need to work is that there's content teams within there, there's a feature team within there, and then there's a tech team. And they're all reliant on each other. So the tech team, sorry, I should go the other way. The content team relies on the feature team for whatever the feature that they're developing is. The content team also relies on the experience team because, again, they're the ones that are thinking about the player experience with the thing. So they're coming up with the actual designs. The content team delivers that. To get there, you're going to need technology, and that's where the tech teams come into play. Now, because this was put into place, again, a year and a half, two years ago, we've been basically cleaning out, in terms of the vehicle tech team, the last of the features that were mainly driven and designed and developed by that tech team so that they can become fully realized support. And technical team, again, it's all about delivering on what the needs of that feature would be, what technology you need to get there, whether it was radar scanning and needing to be able to do 100 kilometer plus scanning or whatever that is, it's delivering on that. So that is what the mandate of the vehicle tech team is, and the current state is they are wrapping up their last really central player-facing feature to go, and then everything else will be tech related. Mark, did you have anything to add on top of that?

I was just going to elaborate that another thing that we do is we build tech that is mostly for other developers. And they'll use that technology to make features that are more player facing. So like when we made the Item 2.0 system, we built the underlying structure of how all those things will function on a ship, on a player. We communicated to different teams how that would all work. But the feature teams came along and actually used it to make like a power plant or they made an actual weapon. So you'll see a lot of our work, but it's mostly behind the scenes because it's core pieces that feature teams put together to make something.

I think to elaborate on that, those of you that have been with us early on, I think remember that we used to release hangar-only ships or ships with features that weren't functional. And we've been endeavoring to make sure that when you do finally get your hands on the ship that you purchased, that you can actually utilize all the systems on it. And so we work closely with the ship teams as far as the scheduling is concerned. And then we make sure that, hey, there's this new feature that the ship was specifically designed for. Let's make sure that the ship comes out with that feature as functional.

So I think if I can put it into practice as an example here, you guys work on the door lights and door switches, but it is a content team that determines where to put the door lights and the switches on a ship. So you guys can develop thruster tech, but it is the content team that determines where those thrusters go on a ship. It's more the general systems and support of everything underneath and not, hey, why does my ship do this? Or why does my ship look like this? Or why does my vehicle behave like this? Those are the questions for the content teams, the teams that work on the specific ships. You are the support system that gives them the tools that they can play with.

It's weird for me to make it super concise. It's something I say to the tech art groups all the time, but it is very accurate here. Vehicle tech team works on the pipeline, not in the pipeline, if that makes any sense. They come up with a way to do it. Calix will document it. Kirk will prove it out from the design standpoint. Mark will make sure the code works. They document it up, and they send it over to the other teams, and they go to town on it.

So if your question is about a specific ship, this isn't the team for that. That would be a content team. If your question is about all ships and all vehicles, then we're probably closer to the right area.

And doors, because Mark is also the door tech team.

It's tough to give hard updates. I can tell you where it's at, because physical damage is a big undertaking. It's not just about ships. This is about everything in the game. And generally, the top-level intent that Chris has had for this system is broad. And the reason I say that is every material in the game should be a real material, has tensile strength and all the things you would expect of a real material. So it's not a very gamified implementation where there's just some penetration value or whatnot. He wants to go through and have every one of those materials, whether it's a box, whether it's a character, whether it's a ship, whether it's a space station, all be respected. That's mass, everything that comes with it. You can imagine how many teams that affects. And then on top of that, because the way our surface types work with physics and where they're actually stored is very art-centric. So our physics type and what the impact of that given surface will do is defined actually by an artist when they do the physical proxy. So it's also stored in the material. So anything that we do within here is not only going to affect all the gameplay balance of the ships. Again, it's not just health anymore or not just parts, but it's actual density and thickness and those kind of things that will affect. But it's also going to affect the art setup itself, because all of that stuff comes into play, because obviously we don't want to have, well, maybe that's a bad example, but let's say aluminum on a ship. We don't want to have that aluminum act differently or read differently on a box, on a character, and do something different. So anyways, long story short, affects a lot of teams. I think everybody understands that. Where things are currently at is on the core gameplay pillar, Rich Tyrer and the physics guys have been doing a ton of work just going back and forth with narrative, because again, we have some real materials, like a titanium or whatever, but we also have things that are created from in-game lore that are lore materials, let's say. It's a real material that exists, just not in the real world, so we have to come up with all those values, and they have to coincide with the reality of a value. It's even just getting the details of all of that. Then beyond that, it's talking about what's the kinetic reaction of it, the radiant reaction. I've got a list here. Thermal, electrical, chemical, cold, heat, rarity. There's so many layers of it. So really right now, it's a big Excel sheet of here's all the surfaces that we're going to need. Here's all the reactions that those surfaces do. Where can we get that onto the content teams? And then once we do get that on the content teams, it's going to have to go to all the different experience teams. So vehicle experience team will have to tweak everything, because imagine what's going to happen with the ships. We have some balance in on the ships. We know that ship A will beat ship B in most cases because health is here, damage output is higher. Once it goes to a physically based setup, that changes the ballgame, because now all of a sudden the art of that ship informs what the armor is, how strong it is. And this to balance is just going to take some doing, I can imagine. In terms of if that's coming soon, I don't want to say anything in terms of timing, but it is an ongoing discussion and constant design that is being done and a lot of back and forth with Chris. And again, Rich Tyrer is really driving hard on it on the physics and the core gameplay side. So I expect more to be talked about in the future, but just do appreciate the complexity of the task, and it would be less complex if we didn't have any assets, but again, here we are a couple years running, so we've got a lot of assets already in place that need to be updated and converted to such a system.

On the implementation side as well, we've talked about the physically based damage over the years because we've done explorations and experimentations of what would it take to set this up to get the kinds of behaviors that we want in a closed system. And those have been informative, but like Sean says, we can't move forward until we find the version of that that addresses all those considerations at the same time. So a lot of that has been explorations to determine what it was we needed to be able to hit, what it was we needed to be able to accomplish, and then with that information starting to chart out the full scope of what this entails, which carries into all the stuff that Sean just said.

Another change might be that this also affects mass and also center of mass. Our flight model will have to get updated to accommodate the more realistic physics that will get informed by the art that's generated by the artists.

There's even some more fun with it. Our vehicles are one of the most destructible and interesting ways of blowing up an entity. You could break off wings, you could break off panels, you could break ships into different pieces, and all that is kind of customized into this XML packet. And if we want to be able to utilize the same breakable technology across entities across the board, we can't just use what vehicles are doing. And so there's been other discussions and even pipeline tools of changes where we could change the asset itself to define how and why things could break based off material properties. So it's no longer we have an asset of a ship with XML. You have the asset and it behaves correctly. So there's a lot of cool things coming along with this tech.

Yeah, just there's tons. Because I don't know, we made it sound pretty negative because it's work, right? And we're just going over, oh my God, it's all this work. But the stuff that it gives us is pretty incredible. Because now all of a sudden, it's not a gamified physical damage thing. It is a force damage. It's a kinetic damage. And they all have different reactions and all have different byproducts of them, whether it's an effect that is different or whatever. But it also just really embeds the materials and the art into the actual gameplay of the world, because we don't just color it because it looks cool. We make it aluminum because it needs to be aluminum in that part of the ship. And what I hope is that it informs the design even further as we make new stuff. It just would make sense.

Like the cascading damage effects that can be reinforced or negated by whatever particular circumstances are happening. Yeah, it makes it a much more reactive and specific behavior.

And procedural. Chris always talks about it, but he'd prefer, right now we have a very specific thing. If you damage a part at whatever it is, 75 to 100%, then you have a chance of detaching it. And then we have to apply a proper impulse. We do it very specifically. So it's like, oh, okay, we know that ship has gone to 90% of wing damage, so the wing has to punt off. Where Chris would like this to be much more, there's a technology called BMNG or something, way more physically based, where it's like there's a constraint. There's a constraint and after so much of an impact, let's say you hit it with a size nine railgun, it doesn't destroy the wing, but that's going to rip it off, because it just physically makes sense that that would happen. Anyways, stuff like that absolutely comes out of it.

Hopefully we can find a solution to prevent players being able to exit seats into other ships too at the same time. That'd be nice to get rid of that.

So that's almost fully on vehicle experience team for obvious reasons, the cockpit experience, vehicle experience. These guys on the VTT side are absolutely supporting it, though, in terms of the MFD setups, the UI setups, the UI updates. A big part of what's coming, not a lot to do with the MFDs, but a big part of what's coming is the UI updates for the given ships and things like canvas slicing, scanning and radar, and that's what these guys are working on very specifically. So a lot of the UI is being updated, and we're really hoping to roll that out soon with the connection of scanning as well as potentially missile operator modes and these other things in the nearest future. I want to avoid dates.

Calix prepared a lot of the physical button actions on that dashboard. You want to talk about that for a second?

Yeah, so one of the things that we started with was just figuring out the technical side of how do we get an arbitrary feature, an arbitrary interaction on a ship, any ship, regardless of how we've connected to it, to be able to connect that to the physical state of a piece of geometry and being able to point at that specifically and update that, being able to animate that procedurally without having to export specific animations for every single button, being able to do that in fewer draw calls by having it still be part of the same mesh. And then once we had a basic pipeline for how this thing can connect to that thing to tell the other thing to do something, if you can even do that, which it needs to be able to affirm before it allows you to do things, because if you don't actually have control, the thing shouldn't respond. And if you don't have power, it shouldn't tell you that it's responded. And if it doesn't actually do the thing, it shouldn't. There's a lot of things going on in this one channel. But once we have that, then we need to go back through and decide, okay, well, what are the buttons that we have? Because there's a lot of things that the ships can do. Some ships have cargo, some ships have torpedoes, some ships don't even have real landing gear. So how do we set all this stuff up in a way that we can address each of those very different concerns? And made a template and a design sheet for how you figure out what buttons a ship has, how you figure out where they should be placed so that they get grouped up in a sensible way. And there's still some getting to know your ship, to know exactly where things are. But when you step into a new ship, it shouldn't just be madness. There should be some logic to it of, oh, all of my systems ended up over here. And maybe on this other ship, they're over here. But that's because everything is flowing in this direction. So systems, and then you've got your parameters, and then you've got the specific call and response type events or the comms type things. Having a format for determining that and then making it so that all of that was packaged in a way that artists can use it. And artists don't want to hear about any of the things I just said. So that's its own task of making all that make sense in just a purely aesthetic way: what does a button need to look like? How do the labels need to be? What are the sizes that that needs to be? What kind of distances do you need? Yeah, it's been a lot. It's been passed over to the vehicle content team to begin working on. We did the Gladius as the first implementation. There are improvements to be made to the system. But the foundational work is in a pretty solid place, and we have a lot of the general information that we need to move forward with it.

Yeah, Chris really wanted to make the player immersion experience when you're within a ship cockpit to be realistic and intuitive. So it should be like you're getting into the driver's seat of your car. All the buttons should be intuitive. They should read out the proper statuses of all the ship systems. When you press a button, it should physically move. There should be a light indicator that actually shows you not only what the status of that system is, but does light up you, the environment, the dashboard itself, and then making that a system that our developers can use in an easy way and also to not tax the system. These need to be optimized systems because we have hundreds of buttons that are going to be within the cockpit, is the challenge we have.

Mark set up the light linking tech, which we use for those, which is really, really strong because it lets us use a texture to create the emissive light effect, which lets us be a lot more specific and have text that lights up or doesn't or changes. It's much better than my early attempts with just putting a light there or making it glow brightly. That was a big improvement.

With those things, here's another fun thing when you're building out tech for other people. First part of it is, as Calix and Kirk mentioned, how do we go about making this? How can we make something optimal? We have hundreds of states. We don't want to bog down the network. We don't want to bog down rendering. We don't want to add tons of setup issues. So once we figured out how we could do this and get all the states that we want to show replicated to buttons and we had a working example, we have that kind of as our tier zero technology where we hook up a ship like a Gladius and we say, proof of concept, it works, it's great. The next phase of that for our team is how do we expand this to the rest of the ships? And that's where you start building tooling or improved workflows and getting engagement from how the community is reacting to those type of changes. So we have done the first part, which is here's the tech. Let's add some more. Now, how do we make it easier for someone else to just go in and plop it in and add it in?

Well, to hark back to the physical damage question, that's really what breaching should be. It's a matter of the surface that's on that given door taking the damage that it needs to take. So there's no specific door breaching per se, because that's how it's set up right now, right? Right now, a door is in there, you can do some damage to it. Sometimes, I think in some cases they'll open slightly, they'll animate to open or they'll switch to a damage model. Yeah, they'll unlock, switch to a damage model. It's all very specific and bespoke. What we want to do is make sure that that's actually part of the overall physical damage and it just has to be. You can definitely argue, wouldn't you then armor the doors of your ship pretty heavily if that would be breached? But then again, it brings gameplay up if you want to punch holes elsewhere. That makes a lot of sense. But again, it really relies a little bit on that physical damage. But breaching as it is right now, I don't know that the design necessarily would change dramatically. It's just the way you get there would be different.

The problem with locks is that they're made to be opened.

I just want to mention that the one other system that we rely on is we need to finalize our room and atmosphere system, because part of the result of the breaching is that you're actually rending a hole in the side of the ship. We want atmosphere to vent out, and conversely, we want to be able to have airlocks that can seal off and then you want to re-pressurize the evacuated area. There's just some underlying systems that we need to do some work on first.

And to expand on this as well, fundamentally, the thing that makes all of this work is kind of the room system. This is something Chad McKinney worked on a long time ago where you have two volumes and they could hold atmosphere, and he uses the ideal gas pressure laws to indicate how and why certain gases transfer. So if you have two rooms and you add a connection, they'll transfer gas. So what a breach essentially is, is you connecting the inside room to the outside room and it just suddenly ventilates out. So if you know the connections, you could create a force. If you know when a door opens, you could establish a connection. When you know a turret is blown off, you could establish a connection to the outside. Right now our ships have immutable rooms, which basically don't allow the transfer to go through. We have worked on a life support system which allows us to turn that off, and when powered on, it would increase the oxygen and the gases in the room so that you could breathe. And if you were to turn it off, if you stayed in that room for a long time, it would all turn to carbon dioxide and you'd probably die. That's not fun unless you have systems in place that inform the player what's going on. A lot of times I see these things, you have worked on the system, what's the next step? That is the next step. How do we hook this up in a way that's player facing so you know what's going on? That's basically the next step. Then suffocation is fun.

And then we want this too. Nothing would be more fun than blowing up the top turret of a Cutlass, right? And then, sorry for the guy that happened to be in it at the time, but if it vents the atmosphere out from the hole that results from blowing it away, we want to have a door system that will shut that off so that you don't compromise the rest of the hull when you're in the Cutlass. But we need that atmosphere system to be functional in a way that we can implement this gameplay in there first.

Yeah, for the actual process of breaching the door, we've updated the doors to be able to derive their lock state from other items. I had a deadbolt item that I made as an example. But anything that would be specifically in charge of keeping this door shut mechanically, it would be able to get that information from there instead, which would allow us to make specific breach points within a door, that maybe this part needs to be the thing that takes damage. Or if the whole thing takes damage, does the entire thing come off? That affects what will happen when you lose atmosphere. And then also having it so that you have the ability to, like you were saying, counteract the loss of pressure, being able to inject the room with atmosphere again. We have this compressor, which has been a way of taking the airlock behaviors that we had and taking it from being this hyper-bespoke setup that we had, where this room is just an airlock because we've made a room that is an airlock and wherever you place it is an airlock, to here's how you make a room into an airlock: you give it a compressor, which takes the atmosphere that's in the room and puts it into its tank and takes what was in its tank and puts it into the room. So if there was atmosphere in the room and nothing in the tank, it swaps to be atmosphere in the tank and nothing in the room; you are now depressurized to go outside the ship. If outside the ship was a toxic environment, when the doors open, it will flood full of the toxic environment, and the breathable environment in the canister will switch with the non-breathable environment in the room, and now you're back to a breathable environment to safely enter your ship. So that is the go-between from the life support system that we made, which very, very slowly regenerates and filters the atmosphere in the entire ship, to being able to intentionally use the systems to give yourself an edge or find yourself at a disadvantage because someone else has filled your airlock with toxic gas. Why'd they do that?

That was a fun thing when I remember you were experimenting with it. It's like, wait, we can't just pump oxygen into the room. We have to take out the bad gas and then replace it with the good gas. And then we started debating, all right, if you have that canister that takes the good gas and then changes the atmosphere, what happens if someone swaps it on the ship for fun? Like, hey, Sean, can I come aboard your ship? Swap his air tanks with toxic gas. All right, I'll see you later. And then Sean goes flying away. He passes out. I steal his ship. Standard pirate run.

Sure, I'll start off. So as has been clear, scanning has been the greatest experience in the world. So what we're doing is we're trying to make it so that, A, it's easier to find entities in the vastness of space in the CIG universe. And once you do identify them and get up to them, you can scan them and get worthwhile information that you want from the entities. It's not, unfortunately, as simple as just putting in what information you need from it. Each entity type needs to be set up so that we receive information that's useful to the player when you do scan. It's two experiences but one system. So we have FPS scanning. So you're scanning when you're on foot. And it's going to be mainly focused on other AI or other living entities. Then we have ship scanning. So when you're in the pilot seat or the scanning seat of a ship, what information do you glean back from doing the scan? So in the past, I think we got the ship class, the pilot or the owner, and the health of the ship. We wanted to expand that to more useful things, like what's the weaponry of the ship? Armor of the ship? Does it have cargo? Is it going to be worth raiding and emptying out the cargo bay of that ship? And then we can layer on gameplay later on. We actually have smuggling gameplay, like the Star Runner could maybe, in the lower cargo area, that can be shielded from a scan. Again, to a previous point, why would you make the whole ship out of that? But it's part of the gameplay. We'll figure out some lore to make it so that you can obfuscate the scan results there. And then figuring out all the info and then expanding it to other entities. We want to be able to scan Port Olisar or other space stations or any ground-based stations. Doing ships within ships is a thing that's coming sometime soon, and we want to be able to get that info as well from the scan. But before that, we need to find the ships. Now we need to just find all entities. And so expanding pinging and getting better results from the blob that we had. So we did some work previously to allow you to find mineables. That took some time. But it's still, I think, an experience that we need to improve upon. But at least you were able to do pings, find mineables on planets or in the asteroid sections, and then be able to kind of pinpoint where those mineables were so you could take your mining ship over and then mine the rocks. We want to make that experience the same across all entity types. So if you're looking for a particular mission goal or another ship or another player, combining all those systems together to make it so that doing the pings and doing the scans is a worthwhile experience and intuitive. Some of the systems that we've been doing that with is we've been modifying the detection of entities. So right now we're using signatures. We do have EM, IR, CS as far as our signatures are currently implemented. We're going to be expanding it. We do have dB, decibels, that we don't fully utilize. We want to expand it, make sure that those signatures are working so that you can, say, hide behind a wall, or you can, as a ship, if you're a small ship that's generating really low signatures, you can sit next to an Idris that's generating incredibly high signatures and then hide within the space of that Idris so that from the perspective of someone else's radar, they only see the Idris. And all of a sudden, oh, there's like five escorts on there that I didn't get to see because they're being hidden by the Idris itself.

Helps give a reason to fly in formation, because when you're flying very closely together and your signatures can bleed a little bit, it gives you a bit of an advantage for hiding your numbers.

To go back to what Kirk was talking about, it really comes down to those signatures. That's what scanning is all about. Scanning is the electronic gameplay, electronic warfare gameplay that goes on. And it will result in better or worse situational awareness for the player. That's what it comes down to. And each of those signatures have differences, right? How they work together. In a gas cloud, the EM and IR is going to be hard to pick up. There's just a ton of noise. There's other things happening within that gas cloud that are going to make that hard to pick up. But again, if the cross section, CS, is so large, then it might make up for that. And that's where you're going to go. Now, some of the stuff that's been added on top of it has been info of the given ship. For example, how many people are in the ship? What are they? Who are they? How deep can that scan go? And all that kind of stuff is actually coming back. What's really nice about this feature overall is that we've been driving it from a pillar standpoint. And I mentioned it before that we have this core gameplay and then the vehicle pillar. This is all being attacked together. So FPS scanning and ship scanning are all generally using the same systems. They just really rely heavily on different signatures. So to go back to one of them, Kirk mentioned dB, decibels. Doesn't make a ton of sense that a ship in space is going to be making a whole bunch of noise, but it makes tons of sense that a character or even an item is going to make a lot of noise. So what's interesting is if you have a generator in a room that's emitting a ton of dB, you can actually stomp around that generator and nobody's going to pick you up in the dB sort of thing, because you kind of get that, I call it thief gameplay, where you're in the shadows or whatever you're being. [garbled passage] But there's no really absolute value within them. And that's what has been getting worked out, especially on ambient signatures, CS and whatnot. So again, all of those signatures, they all have different sort of rule sets that you can include with or do things to, to benefit or detract from being able to be scanned or not. Just one last example, maybe. For example, when we go active missiles, if you're going to this active sort of combat mode with missiles or whatnot, it's very Hunt for Red October kind of moments, like an active ping, right? As soon as you go active, you are super hot on that radar. So you're going to be able to be locked on. But you also know that that guy's turned on his missiles and everything. So he's about to shoot me, whether or not you're going to do something. So again, it is about the signatures informing the situational awareness for the player. That's the general intention.

Yeah, we're implementing the actual signature tech and detection. And then we'll take a pass afterward. Well, our particular team won't, but we'll have one of our teams do a balance pass so that all the ships are generating signatures that are within the ranges that they should be. And then same thing for players, same thing for anything that would be generating signature and interacting with other signatures around it to change the gameplay. And then in Sean's example, we put a sun somewhere in the galaxy and it's generating a ton of EM and IR, and directionally. So you can do the thing where if you position yourself between the detector and the entity that's generating all the signature, you can effectively hide right in front of the player in plain sight, because you are within the array of the giant signature that's emitting from behind you.

The other big fun thing is with all these changes, there's no point unless you have some good player feedback. So a major revision to all this is also adjusting our UI so that we could show this information in something that's more meaningful. Our scan UI, I think in the current release, kind of just has like a list of information. Now we're trying to organize it into more meaningful ways, like a general area saying, here's information on the ship or the player, the name, the wanted level. And then there's like an interior area that tells you, here's some of the cargo contents we found, some of the weapons that we found. Then there's like an exterior. And group the information in a way that the player could scroll around. And the other big change to this thing is making it more data and design driven. So design now has the ability to make a scanner that finds things for medical. A scanner that's made to find things that's more for like pirate cargo. Design can now make upgrade paths to specific tiers of scanning. That won't be in the initial tier. This framework just allows this gateway to open up for design. So there's a lot of fundamental changes on the core gameplay and what design can do with it thereafter.

Yeah, to Mark's point, players have been asking for the one system that I think works right now the best with our signature system, which is mining, to be able to filter out for particular mineables. If you're using one of the smaller ships, you don't want to find the big rocks. Conversely, you don't want to find the FPS rocks if you're in a big ship. If you're not in the ship, maybe you don't want to find rocks at all. So we're implementing that system. And then we'll have a way for the players to be able to filter out the signatures that they're particularly looking for by some dashboard control.

Again, that is up to the particular ship whether or not they want that or the format that they want it in. But the tech and the implementation pipeline for achieving that is there now. So I expect that probably we'll begin to use that and other similar kinds of features moving forward. I don't know anything about retroactively going back through the ships to update those unless they specifically have an update scheduled.

Calix, you want to talk about how you worked on getting the system states to be more controllable by the player, so that design and art can go and do things like we can change light states? We can do things like actually control multiple doors. We can have the door control panels actually react to the state of the door that it's controlling rather than it being a one-way communication path.

I think Kirk just did. Well, the issue is we've been able to do this for a long time, with very few exceptions of maybe you couldn't specifically get the UI panel to show up quite so easily. But the engine has been capable of doing this for a long time, but it's been incredibly difficult to actually set something up to achieve it. And so the thing that I started all this working on was trying to make it so that it was less of a chore to set up a door with its control panel, setting it up so that you can either put it in the object container with the ship and link it or you put it on the loadout and have it link automatically. And the reason that we weren't able to have this behavior is that the only way that you would get it is by having someone who knew absolutely everything about the door, how it worked, where it was getting the sensor information from, how the lights were set up in the light states of the room, and knew all that stuff at every step of the process, and then do it at every step of the process, which is not really how we make things. We have people who are dedicated to making our environments and dedicated to making the ships and dedicated to making the tech. And it's not really feasible to have these shamans to just walk through and bless everything. So it's much more important to be able to make it so that you can use these things without needing deep arcane understanding of the under-the-hood things that it's doing in order to set it up to behave that way. So the actual fix isn't so much making it that the doors can be locked or unlocked or even that the proximity sensor can be turned on or off or that the lights can be on. Those were already behaviors that those things had for the most part. There are some additional ones that we're adding, with the sensor being able to tell you that someone is there. We're expanding from here, but the real problem was making it so that you could place down a control panel, you could place down a door, and then it could have a proximity sensor or not, and it could have a light in the room or not. And then you could link those things and be done. And being able to do that is what lets our environment team and our designers on the ship side be able to actually use these to create the content that is useful and player facing. Because otherwise, it ends up being such a dark path to follow that you never get out.

By the way, there was also a bug fixed quite some time ago. The bug was that multiple control panels set up in different ways didn't properly handle the door states. So I know for a long time, the rear Connie door, if you open it from the inside, only the inside control panel would know about the state, the external enter, exit [garbled]. So, I hope we don't, but if we do have issues with that, please inform the Issue Council.

Yeah, the Cutlass and the Caterpillar, because the ships will support these things in different ways. The Cutlass and the Caterpillar both have control panels which have buttons that light up to reflect the state of the doors, whereas obviously the Star Runner has the screen, and we want to expand even from there. The other thing is that adding in the light controls for the rooms is much more limited at the moment than where we want it to be. And that's because the rooms that we have in our ships and the lighting states that we use with those is actually very deeply hard-coded into the ships, the emergency states and the power states. Those are fundamental aspects of ships at the moment. And so, except for the small slice that we're branching in the Star Runner, it's not really set up in a way that lets us manipulate those states outside of the scope of the ship from the player perspective, as an example. So there's work to be done there to make it so that that's feasible.

I do like the direction that we went, though, with the Star Runner. Touchpad-like devices that you actually interact with to change the door states, and they can have as many buttons as you want. Very, I don't know if this was mentioned, but very LCARS-ish UI to be able to manipulate the states of all the things you can with the control panel. And it's much more useful as far as giving player feedback as far as what the state of the room is and what they can and can't do. I'm pretty sure we're going to be using that particular design language moving forward.

Personally, I want screens all over ships. I love it. But not every ship should have that, I guess.

You can definitely use it for piracy. That is one of the uses that it's not really designed for, but it fits that role nicely. But for the lawful player, really the whole point of the QED is to stop players, either by pulling them out of quantum travel or by preventing them from entering quantum travel and quantuming away. So for the lawful player, it's really to stop any players that you may consider a criminal, or that the game has determined are criminals by their criminality stat, and prevent them from escaping, either out to another area or just away from you or away from the particular lawful zone that they happen to be occupying at the time. So you're kind of acting like security forces, or really just a way to hold people in place and make them pay for their crimes.

When I was asking around to a couple other designers working on other systems, I got answers such as: the team working on bounty hunting is excited about the possibilities of a crew of bounty hunters going around with a Mantis and being able to pull criminals out of quantum or keep them from escaping into quantum. And of course, when I talked to Dave Haddock, he mentioned that in the lore, RSI is a major military contractor. RSI is the maker of the Bengal carrier, for instance. So they definitely have their military contracts. And the Mantis is something that would definitely be used by the Advocacy, for instance, in their efforts to police UEE space.

It's the same concept behind the security forces that come and scan you and prevent you from quantum traveling away, and in fact require you to not have your quantum device on while they scan you, or else your criminality stat does rise.

And current marketing for the Mantis in our fiction is towards militias. We've had the UEE militia initiative before. This is just one more thing like that, to provide the ship to militias who are trying to defend outposts that are maybe on the outskirts of UEE space. But there's plenty of lawful uses for the Mantis.

So it's actually a quantum enforcement device. We can't currently target it, but we are exploring ways in which you can sub-target the QED in particular and keep hitting it till it's destroyed, and then it will disable the device. That is something we're looking into. It is not currently available in 3.7, but we're hoping to be able to make that a reality soon.

With all subsystem targeting.

Sure, right. And it's an external item. In the very near future we want to introduce a concept that's going to be difficult: being able to sub-target internal items, things like power plants and shield generators and the like. That's difficult because of the differences between how we physicalize items on the exteriors of ships and on the interiors. However, because this is an external item, that should be something that we can solve for the QED.

It also goes with the fact that since Item 2.0, we've had everything basically be componentized. So the health, the physics: as long as you strap them onto these items, like this QED device, it will function. It's just that we have to add in those extra bits, like if the health's low, it has to do this behavior or that behavior. So of course, every time we do the tier zero requirement, we want to get the base functionality in and then add in those extra bits. So we could add a health component and then allow the sub-targeting system to target it, and then you could shoot it. But it wouldn't be fun as a player until we add in those extra bits where we notify you that your device got hit, and the gameplay changes because of it. So it's more like we have the ability to do it, but once we combine them all, we want to approach the behaviors and add those behaviors onto it before we release it.

Yeah, we want to complete the gameplay loop for that. Because yesterday, actually, Matt and Trueri, who I'm sure a lot of people know about, and I were messing around with physicalizing the rings that make up the QED. It's actually very visually impressive, because you get knocked about as the rings encircle you, and you can enter the middle of the rings and feel very godlike in the midst of the QED firing. So it's pretty cool. But we need to make sure that all aspects of the gameplay work before we release it.

Oh, that's a great question. The short answer is: currently not. We do hope to investigate being able to predict where players travel from quantum point to quantum point in the future. Obviously, that's the most effective way to use the QED. So one of the things we're thinking about is introducing things like heat maps into the star map. The most traveled quantum travel lanes could have a glow that indicates the most used lanes, which becomes brighter as there's more traffic along them. So it's just like seeing them on some kind of electronic map. You see where people travel the most so that you can do what we talked about. One analogy for the QED was that you're fishing. You'd have these streams that represent the most used quantum travel paths, and you're setting up a net. So you want to know: where is the most effective place that I can set up these quantum enforcement or quantum snare volumes so that I'll have the best chance of actually entrapping people? The other thing that we want to do is make some improvements to the radar so that we can detect players at further distances than we currently can. That way we could not only increase the distance at which the QED or the quantum snare is most effective, but also let you know where they are when you do pull them in at those larger ranges. Because right now, with the way we're doing our client streaming, the device doesn't allow us to get much further than what we have streamed into the client. And so these are things that we'll need to experiment with to figure out what's going to be most effective, not only for the gameplay, but also for how to communicate that to the player.

You're referring to when things travel a certain distance away from you and those items are culled out as part of OCS and stuff like that.

You want to talk about the technical limitations we have right now, the distances?

Right now we have client-side streaming, and if a vehicle is not within a certain range, we stream it out. Now, if you're a player, you'll always be streamed in on the server. You'll always be there. But if you're not a player and you're just a random entity, you could get streamed out once we enable server-side streaming. And that brings some problems, because right now we're counting on all the things being there on the server when we interdict and when players are detecting things on the radar. But if they're not there because things are streaming out, we can no longer rely on the dedicated server, which means we won't be able to know where people are traveling towards unless they're a real person. This is where we want to move stuff out of the dedicated server and maybe more into the backend. Right now the quantum drive fully functions on the dedicated server, because players will always be around. So it's kind of cool. But if we ever have to do any kind of interdiction, or we want to see trace points of where things are, we have to know what they are to report to the clients. And that gets difficult if you want to then report some of that stuff to the backend. So there's been some talk about how we can rearrange some of this data. Maybe we could put some of that information about how we're jumping into the backend, so then we could be aware of all the players on the server. It's also going to get more and more challenging as we add more players to a server. Maybe we want to move some of that logic out of the server into these backend services, so they could go: this guy's quantuming, and we don't have to know where he's going to be until we want to pull him to see the path he's going on. Maybe he'll get interdicted, and then we put him in there and report it to the client, or something fun. So in the future, a lot more stuff is going to be in these services, and we've got to figure out how we're going to relay the information between the server, the backend and all the clients. So we could get that information where I could pull up a heat map or something to see where all the players have been traveling, rather than going through every quantum drive and asking, hey, are you traveling here? Are you traveling here? Right now that might be okay because we have only a few, but if you want a server with thousands of players, you can't do that. We need to rely on the servers and the services more.

Once we're finished with these underlying systems, how much fun would it be to bring up the star map and see all these paths, and maybe see dynamically where everyone is, especially the ones that are quantum traveling, and where the quantum snare volumes are, in real time? Then you could actually see all this information and decide where you want to park and activate the quantum enforcement.

Yes, that's correct. We had to update the backend services with the trajectory constantly, if you allow me to say this word, and do a little prediction in order to be able to detect when someone is actually being enforced by another player. So we have to track both the position of the player who is activating a quantum snare and the player who is quantum traveling, in order to detect when they get caught by the Mantis. This was basically the main challenge in this development cycle that we had to tackle.

It was a lot bigger too, because for the longest time since we've had quantum drive, the moment you activated the device was when we determined whether you were going to get interdicted or not. And I know some players used that to their advantage, because that's when we streamed in the mission, and they could go, oh, I could cut off my device and not get interdicted. So now, other than knowing we're going to fix that, some of the work Aldo did was... well, what did you do to fix that?

Oh yes, we basically had to send constant messages to the backend services, and we had to tweak the probability of being interdicted by an environmental mission, and we basically had to run this sort of prediction of the trajectory to have the backend services correctly locate you and the enforcement device.

Before, you had the jump from A to B, we detected that you get interdicted, cool. Now, since we have player devices, they could just turn it on, but we still wanted you to get interdicted during that travel. So some of the work that you had to do was: as you're traveling, we now send consistent messages with your prediction model to see how far out, or whether, you would get interdicted. And I know there were some fun complications that you ran into with the notification and the effects of the interdiction, because we have that warning that we want to give you that you're about to be interdicted. But if someone just pops up a quantum interference device right in front of your face, there's only so much time we can give you before you're smacking right into it.

And to get out of quantum travel in the exact predicted position where you should. Yeah, we had to do a little bit of math for that. Just a little bit.

Do you want to talk about how some of the difficulties came from how fast quantum travel actually occurs, and the fact that the quantum travel path isn't always a straight line?

Correct. Oh yes, the spline quantum traveling thing. When you travel on the surface, the predictive model needs to be a little bit more complicated than if you travel in deep space, because that's basically a straight trajectory, if you will. When you quantum travel on the surface, it's a curve, and so the predictive model needs to be tweaked and adapted, hopefully in an optimized way, I do hope so, to factor this in and have the trajectory correctly calculated by the backend services, in order to correctly find the intersection between the trajectory and the interdicting bubble. This was one of the problems we had to tackle, and we are actually still working on it.

There was actually another fun one too. This goes with Kirk saying that quantum drive isn't always traveling in a straight line. It depends on your perspective. If I'm traveling from point A to B, it will look like I'm going in a straight line. But the moment you hit one of those planets that orbit, from your point of view, you're going in a straight line, but from another person's point of view, you're actually orbiting around, because as you orbit, you're traveling toward the planet. And the backend services don't know anything about zones or this orbital rotation. So some of the work that Aldo had to do was not only to send the information in world space to the backend, but also to predict where the quantum jump would be during that rotation. I know that's ongoing work right now, and there are some complications with the sampling, because you're sending, I think it was every two seconds, roughly...

Roughly.

And then the backend does a smooth interpolation. But there was a problem with that, because our quantum drive does, was it fourth-order motion, where it does velocity, acceleration and jerk.

Yes, the rate at which acceleration changes when you jump. That caused complications.

So the time that the backend gave us corresponded to a completely different position than where we thought we were going to get interdicted. That's where the fun maths had to come in: this is where the backend thought we were, and we have to readjust to figure out where we would actually be.

Yes, you reproject the time in space, and that enables the code to calculate where that point is on the correct trajectory of the quantum travel. And that triggers the calculation of where you're going to get out of quantum travel correctly. So we hope we got it right.

We'll find out when we see how players use it. To sum up, one of the major changes we made is this: before, with the AI mission interdiction, we could basically calculate or predict where you were going to get stopped. Now we actually have to dynamically figure out whether you would get stopped, and, when you actually enter the position that we predicted, whether the quantum snare volume is still active at the time. So that was the major change.

And then some future stuff. I was mentioning before that we want to move some stuff into the backend services. Well, we're bringing in some new technology to write our services in a way that's more focused on how the game objects work. Right now, a lot of our backend services are written in C# or some other language, I forget which, but it's a whole different story. It doesn't know how the game world works. It just makes some approximations. These new service APIs are very hooked into the game, and they know about the same structures as the game does. They're more on the C++ level, which allows us gameplay programmers to write the code ourselves and not rely on another engineer whose sole focus is the backend stuff. And that would hopefully open up the doors to account for some of the issues with the zones, so we could account for them correctly in the backend rather than doing these little hookups and fixups on the game side. So again, it's just one of those tier zero things. This is the tech that we have, here's how we can solve it, and then when the newer tech comes online, we can improve it.

Right. And the improvements that Mark's talking about would maybe allow us to do longer-range radar or longer-range pings, or just get further distance and more fidelity for scanning, for example.

And less CPU consumption with this new technology once it's available, and it will also enable more features and more power. Space is big. And it moves. Everything moves.

Yes. You should be able to turn around and attack the person that interdicted you. And to be honest, if you are a sole Mantis doing an interdiction, it's kind of at your own peril, because we all know the Mantis is not the most heavily armed ship in our fleet.

I was watching poor Detox try to take somebody out in the Mantis the other night, and it was not a pleasant sight.

Yeah, so you'll want to have friends with you, unless you happen to pull out a much smaller ship or a much smaller AI. So it's best used with others who do the attacking for you. But yes, you should be able to retaliate, and if you're a large ship, retaliate pretty effectively once you get pulled out.

I saw the conversation with Dave Pollard, and we've talked about this before in other segments on the law system. Basically, the system tracks who shot first. It tracks aggressors. And there was some question about whether using the QED would count as an aggressive move against other people. In some earlier builds it didn't, so if you defended yourself, you looked like the aggressor. But that is definitely the direction that we're moving in. Hopefully it will work the way that we intend, and if it doesn't, it will be bugged up and it will be fixed.

If it's not working that way, that's not the intention. Bug it up and let us know.

But being hit with an interdiction wave or interdiction field, or whatever we're calling it, will count as the aggressive action.

Yeah, you're the bad guy in that case.

Sure. There's quantum dampening, where you create a small sphere around you that prevents the quantum drive from engaging, so people can't quantum travel away. Right now it's a 2,000-meter-radius volume, so you kind of have to sidle up to someone to make use of it. It definitely uses less power than the other mode, which is quantum snare. The quantum snare is the charge, big explosion, create a big volume. The big difference there is that it actually pulls players and AI out of quantum travel and then holds them, also preventing them from quantum traveling away while they're in that much larger sphere. At the current time, that's a 20,000-meter-radius sphere. And to mitigate overpowered use of it, there are larger green zones for each of those, the quantum snare and the quantum dampening features. The quantum dampening green zone extends a little bit past the normal green zones we have. The quantum snare one is much larger than our green zone. So you can't just go to Port Olisar and keep firing off these quantum snare events.

You could consider it a system that RSI put in place to prevent unlawful use of this device. So if you're in a region that should be protected, the device is aware of it and will prevent you from activating it.

Right. Plus it's just really annoying to be stopped right outside of [a station].

Well, that was one of the main things we were worried about up front: I could activate this device, so how do we prevent people from griefing? Because honestly, it sounds fun to just go to Port Olisar and turn it on, and people can't stop you. They can't shoot you, because you're in a green zone. So that was problem number one: make sure that they can't activate it in the green zone, and if they do go inside the green zone, we disable it. So if you do activate it outside, the other person can shoot you down. And once David Pollard's change goes in, you'll be able to shoot him and take him out without getting a criminal infraction yourself. So a lot of the stuff being added uses the existing systems to say: you can use it, but you're going to use it at your own risk. You can activate it outside, you'll get a criminal rating, and then some AI might take you down eventually, because you turn into a baddie. There are also restraints on the device itself. The Mantis is kind of one of the lower-tier interdiction ships, so it only has that small range that it can pull ships out of. And it also requires a lot of power from the ship. Just activating it will basically make flying feel drunk, and if you try to shoot, you'll end up using all your power. So if you just use it by yourself, you're going to have trouble. If you use it with some other players and form your own little group, that brings in some systemic stuff. And then the question is, how do you go and retaliate? Well, I love the community, and I'm pretty sure if they find a bunch of people... Maybe this could be one of those service beacon things that we add. Actually, that would be pretty cool. A bunch of players are trolling, and someone makes a service beacon saying, hey, take that guy out, they're griefing a bunch of people with the Mantis, and then a whole swarm of people come in. So we want to add some ways to make it systemic gameplay for the players, so they have ways to counter it using some of the systems. Now, again, this is tier zero. We did the green zone, the power and the criminal stuff. We'll see how players use it and abuse it, and we'll react accordingly.

Right, to expand on what Mark said, the primary way we're balancing it is by requiring a lot of power. Having the Mantis at its complete idle state and then charging up and activating the quantum snare gets you right to the edge of what your power plant is capable of. So if you do any afterburner maneuvers or fire your weapons, as limited as they are, at the same time, it will shut down the device. So players will quickly learn that they'll want to turn down their other systems in order to use the snare effectively. That's where it's up to the players to decide: do I want to reduce my shield? Do I want to turn off my primary weapons? Do I want to reduce the thrusters' capability? You make that decision before you set up your trap. Then you go ahead and spring the trap. And then, again, using your friends is probably the best method there.

And of course, like any other game system, we'll continue to monitor it. We watch streams, we read the Issue Council reports, we check Spectrum. We'll continue to monitor feedback, and if tweaks need to be made, either making it more restrictive or making it more available, those changes will be made as we deem necessary.

This is tier zero and we've just implemented it, so the counterplay will be something that we develop as we get more feedback and have time to iterate on this. But for now, again, the Mantis is not the greatest ship to take on another ship head to head. So there's that. Unfortunately, we don't have the ability to quantum travel outside of the normal lanes, so you can't choose to create your own path, but you can certainly choose to make a dogleg path to your destination to avoid possible QED volumes if you think there's going to be one on that path.

To go off of what Kirk was saying: vehicle features specifically has plans in the near future to upgrade ping to use more of those backend services to uncover more information further out. Right now, ping just finds stuff that's actually spawned. We want to adjust it to find interesting things that may not exist yet or could happen in an area. So we also want to ping much further and allow you to scan potentially much further distances. I'm not saying it will happen, but something we would probably explore is: you do a large ping, and you discover there's maybe an interdiction happening in that area. Maybe not give you the exact coordinates, but say that area has some kind of interdiction play, you should be wary.

Give you a clue as to where these things could be. And then there are other things we can explore. This is currently our only QED ship. Should we make more? We can certainly balance it so that maybe you need a capital-ship-sized QED device in order to pull other capital ships out. There might be some counterplay with that, like maybe you do have to have the same size ship to do that. Maybe the smaller ships can pass through these using some kind of quantum physics, tunneling. Or maybe we can team up multiple smaller QED ships at the same time to create a really powerful quantum enforcement bubble that can pull a capital ship out of quantum travel.

And we do warn players that they're about to be interdicted a few seconds beforehand. It would be cool if we had a mechanic where you could boost power to some system to potentially burst through it. There are a lot of options we've talked about exploring in the future.

And of course, we've also mentioned in the past that the size, quality and grade of components themselves will begin to play a factor. You may be able to outfit a ship that's more resistant to the effects of a quantum enforcement device. So as more and more of the component system comes online, there'll be a number of ways to work around this.

You guys know the app Waze? When you travel, there's a word-of-mouth thing where someone has been interdicted, and they can leave a mark and message everyone, so it's a known thing: oh, there's an interdictor down this way, so be careful to avoid it.

I think you're probably absolutely right about that, Chris. As more of the Stanton system and more of Star Citizen comes online and this becomes a bigger thing, you will see orgs that act as service organizations for this kind of thing, reporting that quantum enforcement has been reported in this sector, along this route. And there will be an entire new cottage industry created for players to provide services to other players.

In the future, we want to improve the UI so that we give you more information about that. Currently, though, we do have the rather large VFX ring that emanates from the Mantis as it's doing either the dampening or the quantum snare. So you will see this shark-like ship floating toward you with this ring of rather impressive VFX coming around you. So that is one method. Because of the current distances at which we entrap players with the quantum snare, it should also be on your radar. So you will see the Mantis that ensnared you, because it should be within radar distance. And because the quantum snare also increases your EM substantially, there's no way it'll be hidden once you get pulled out of quantum travel and are within the range of your radar.

We were talking about that the other day: when you pull them out of quantum, you want to be there to hit them. If they come out of quantum so far away that you have to travel to them, you can't catch up to them.

Right, that's the dichotomy. If we're preventing quantum travel, then we can't pull you out so far away that it requires quantum travel to get to them, because what fun is that?

Plus, you want to pull them out within enough range that you can actually get to them and attack them or steal from them or whatever. But at the same time, for game balance, we want them to come out close enough that they have a chance to attack you for pulling them out. So there are many gameplay reasons to make sure that they stay close together once they come out.

The most difficult technical hurdle is probably what we talked about earlier: the predictive model, and having it work with backend services whose model is very simplified. They don't know anything about zones at the moment, so they don't know that you could be in a certain zone that rotates because it's orbiting. So the game server has to do the math and the calculations, hopefully in an optimal way that consumes as little CPU as possible, and send this prediction of the trajectory to the backend services in a simplified but not too approximate way. So I do believe this was the biggest challenge we tackled in this implementation.

There's also the interdiction device itself. For this functionality to work with player interdiction, we had to have the backend be aware of all the interdiction devices that are active at a time. We didn't have the nice new API I was referring to earlier, where we could hook into that with the new services. So we still have the old, or I wouldn't call it old, but our current service that determines whether or not you're going to get interdicted. I think it was the probability volume service. And so we had to work with Tony to figure out how we could give the backend information about these interdiction spheres, along with those segmented interdiction points, to determine whether we actually have been interdicted. Aldo was mentioning those rotating zones: when the interdiction device is on, we have to relay to the backend that we have this bubble and it's at this location, but that location is in world space. So you have to worry about the frequency of these updates, because if you're orbiting and you're going this way and the dot's right here, it will rotate around, and maybe you don't get interdicted, but the backend says that you are. So then we have to take the information that we gave to the backend and go: okay, when we gave them the information, we were over here; when we got the information back, because there are delays sending and receiving, we're now here. Are we actually going to interdict, or is the interdiction point at a new location? So we use the backend service to give us a hint, and then on the game side we look at that and go: that's right, but we're actually going to be here; or, we're not going to get interdicted, but it looks like we are, so let's send another one to see if that hits the backend, because maybe it's on or off. So the problem is not just the device itself, but how to send where the interdiction is and where we're jumping to, and have everyone agree that we actually did do an interdiction.

I think the general issue we had to overcome was that we're dealing with quantum travel. Quantum travel is very fast, and with that speed come big distances. So being able to ensure that we're actually going to hit the mark and be accurate with the collision of the quantum snare volumes and these quantum travel paths, and ensuring that it will work every time, was the biggest hurdle we had to overcome.

Asynchronous communication.

Asynchronous communication.

And we have acceleration getting higher and higher as we move along. One second into your jump, you could be a few thousand kilometers along, which is a lot. But a second later, you could be a few million, just because of our acceleration ramp. So a little small error can add up to a lot of error.

Okay, this is a pretty deep question. So let's talk about the different systems to start with. So radar on ships are the items that allow you to detect entities that are within your radar bounds. And so they become active targets that are on your radar. And so everything is based off the signatures. There's EM, IR, and CS, which is not in great shape right now. I think it needs some work. EM and IR are our primary signatures that we use to detect entities that are within a certain distance from your ship. And then there's a new signature type, which is RS, which is resource. That's what you use to find mineable targets.

So what the radar generally does is that there is a certain radius from your ship at which you can detect certain levels of those signatures. Anything that is around your ship that generates signatures, like ships or people or things like power plants or anything that is tied into our signature system, generates those signatures to a certain level. So say there is a spaceship that is generating 1,000 EM and 500 IR, which would be a pretty tiny one. Because our signatures fall off at a rate of one unit per meter, that means that it generates enough EM to be detectable at 1,000 meters away from it, because the EM level was 1,000. Now, your radar, say it has a radius of 5,000, and it's set to, at that 5,000 level, detect any EM that is at a minimum of one. So 5,000 meters away from your ship, you have this big radius around the ship. If that other ship that was generating 1,000 EM is just under 6,000 meters away from you, because it's generating 1,000 and it falls off at a rate of one per one meter, at 1,000 meters away from it the signatures decay down to one. And since your radar can detect at a minimum of one 5,000 away, at about 5,999 meters you'll be able to detect it, because those two circles overlap. When you get outside that distance is when they fall off the radar. Or if the signatures drop at a point where you can't detect them. And so we need to do some tweaking on the radar to make sure that our distances and our sensitivity levels are more in line with the gameplay we want, which we haven't taken a pass at yet. Once we do that, you'll see some more fine-tuned distances. We should get better also at displaying what those values are to the player, because they're completely invisible right now. So we need to do some UI work on that. That's how radar works. And so when everything's active on radar, that's when you see it on your HUD and as AR markers, and that's when you see it on your radars.

So ping. Ping is a ping item on all ships. They're not too different right now. Again, we need to do a pass on making different flavors of them. But what ping does is it acts as a multiplier to the radar. So if the radar distance is 5,000 and the ping is a strength level of two times, then it can ping out to 10,000 meters away. And it has the exact same minimum detection values for EM, IR, CS, and RS. What that does is, if you do a ping, the same way that we do the radar detection for the minimum signature values, the item or entity is detected by the ping radius but not by the radar radius. So it's farther than you can see in your active radar, but it's within the distance of the ping, so you get these signatures on it. Then we collect all those entities that you get from outside your radar but within the ping bounds, and then we generate blobs with them. So the blobs are collections of entities that give you a vague info as far as what direction they're in. Right now, we do have at least a readout on the blob to tell you the distance of the blob, because it's really hard to tell what the scales of those blobs are. But those blobs are pretty massive and they're pretty far away from you. But they give you a general indication of signatures that you're detecting at a distance that's outside of your radar. We want to do some work on, again, the UI for that, to actually get some more info about exactly what the strength levels of each of those signatures are. That way in the future, when we do a ping, if you're specifically looking for mineable resources, you'll look for those blobs that have a lot of mineable RS signature and you're like, hey, I'm going to go for those guys over there. So that's how the ping works.

And then finally scanning. So scanning is different in that when you go to the scan mode and then you move your cursor over an entity that can be scanned, so far those are spaceships and other vehicles and mineable resources, then holding your scan cursor over the item will give you a readout about what type of entity it is. So for ships, we have the owner, the pilot, faction, the fleet, we have its hit points, cargo that's on it, and that's it for ships. For mineable resources, we'll tell you the levels of the mineable resource that's available for that rock that you're looking at. And we're just about to expand that right now to other celestial entities, which right now are going to be associated with that point. So planets and space stations and the like will give you some info about what you're scanning when you, again, are pointing your ship at that item.

So the question is, what are we going to get as far as the flexibility for the radar, the ping, and the scanning items? So once we kind of solidify these behaviors, we can play around with the sensitivity of the radar. Not only how far it can seek out and put active entities onto your HUD and the radar. And again, we have those four signatures to play with. So we can vary how sensitive they are and also what distances they can search for. Ping the same way. So the ping, again, because it acts as a multiplier of the radar, how much better at influencing your radar they are, how sensitive they are to getting those signatures and sharing those blobs for you. Maybe some of the pings aren't so good at distilling exactly how much signature is in a blob, but maybe others are. So we'll be able to play with those values and give you some different behavior for that. As far as scanning, we haven't really done a lot of stuff on the scanning yet. So that's to be determined. But I imagine some things we can do is simply determine what types of entities you can scan. So far, because we don't have so many, we can't really play with that. But once you start adding the ability to scan a whole bunch of different types of entities in the universe, maybe some are really good at penetrating ship hulls. Maybe some are great at telling you about the population of some kind of colony on the planet. Maybe some, for you pirates out there, are really going to tell you how much cargo and exactly what type of cargo is on a ship and give you that info. It could be some defensive ones, like some scanners can tell you, hey, exactly what type of armament does this guy have that's coming to attack me, and down to how much DPS do they have, just how powerful are they? So there are those things that we can play with. Once we get that gameplay in there, it's as simple as making sure that we just generate each item that can modify those parameters and then give players access to those items.

So the short answer is the scanners are not tied to the hull, and it'll be a component that you can swap out and upgrade.

Correct. Just like anything we make, as long as we tie it to an item, all we do is we're really just reading parameters from that item. And then as long as the gameplay is disparate enough for those parameters, we just adjust them all and we're set.