Star Citizen Live: Vehicle Tech Team

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.

So last year we had a prototype of this running. And I can tell you, we had it working; it was a prototype. So what we did is in VMA, you picked, I think it was the Starfarer, and then we put a rover in the back. And you used VMA, and you picked the Starfarer, you picked the rover, and you hit the button. Then you had to run all the way over to ASOP and hit spawn. And when we did that, we ran across a bunch of technological challenges that we had to solve. And in fact, the stuff that we solved for those went into the landing system for ship-on-ship docking. So you are seeing the work that we did little by little as we, I guess I want to say, harden it and make it stronger, making sure it works. Getting a ship spawning in a ship, we could do it on the dev side. It's more of how we let the player do it. Going through VMA and then running to ASOP is not very user friendly, because it's two separate systems that you have to do in order to toggle it. There are some other technical challenges, which I'll get to after. We've had discussions with different teams about what we could do to potentially change the ASOP spawning, because it would be really nice if I could go up to that ASOP terminal, say, I want this Constellation, I want the rover here, hit spawn. It puts everything in one package. But before we could do that, we have to change other systems before we could get to that point. So the player front-facing side has to get addressed. And the other technical challenges we have to figure out is what happens if Sean parks his rover in my ship. I own the ship, so if it despawns, he can't get his ship back. Do we want to allow that? Have I stolen his ship? Should I get a CrimeStat for that? And I got despawned. There's those little type of technical hurdles that we have to figure out before we allow this. There's also cargo. In the back of the Starfarer, I think there's a cargo area where you could put some cargo spots. If we also want to put your ship there, we can't allow you to put the ship there if there's cargo there, because you could add cargo to stuff and then you want to add a ship or an object there. That won't work. So we now need to get the cargo system to understand that there's going to be a ship in there. Now, the good news is there is going to be a major revision to the cargo system. And we're going to utilize that API once it comes online to prevent these sort of things from happening. I think it even may be incorporated inside of it. So there have been some prototypes. We've hit some technical hurdles. Some we solved, some are still in our backlog, and some are going to get addressed in the near future.

And some are getting used now, like ship-on-ship docking. So to remind that, that's all physical inventory. It's another sort of scanning thing where both of the pillars are working together on this one. Physical inventory is a requirement for that to work correctly, which is another, it was a question that was on the forums anyways, about the cargo grid, what the future of the cargo grid is, and it's that there is no future for the cargo grid. There is the reality of being able to put down the actual objects that are within your ship, now in your ship in the cargo area, but it doesn't have to be tied to this cargo grid. And that is exactly what Mark is mentioning. You have this in there, but you also have a whole bunch of boxes placed around.

Long story short, I know repair needs a huge overhaul. It's an old system and there's been talks about how to revamp it. I miss those little drones.

It's a little bit of overlap with salvage, and I know it doesn't seem directly related, but when you consider what repair really is, it's like the opposite of salvage. So if we have a salvage gun, we will also have a welding and repair gun. And I think we've talked about it before, the multi-tool stuff. So you could imagine that there's little bots that are welding your thing. I'm just not sure how Star Citizen that is, that's all. But if people miss it, I think something's coming back online. But I'm sure it'll be escalated to Chris once we're getting done on the salvage.

It'd be cool to shoot those little drones as someone's getting repaired. You see someone getting repaired, pop out the little drones.

Well, the problem I have is what it opens up is, as soon as you've got little repair bots, what other bots wouldn't you do? Why wouldn't you have shield bots and anti-missile bots?