Developers answer subscriber questions on persistence (SSOCS), the Redeemer's manufacturer, cargo elevators on the Caterpillar, scanning and exploration design, salvage and physical inventory. They also cover docking tech, hair and scars, and the Subscriber Program revamp.
Possibly, since there's no reason why they couldn't do it - they'll review this feedback.
They don't know that there's any tech stopping it. They have the required animations, as well as the Interaction State Machine (what handles the interaction mode), it's that they're missing the ability to trigger the state machine to go into those states required for the elevators to work. The reason they're not yet functioning in-game is likely because it's something in their backlog that they haven't gotten to yet. They will get to it eventually, they just need to sync a programmer and a designer to do it. Incidentally, it might get looked at next quarter by the Active Feature Team who will be looking at the Player Interaction System in Q3 of this year.
There are no plans, at least within the next few months, to do anything with roads. It's a matter of priority, and it's been decided that broader environmental elements are a higher priority than more specific elements like roads, because this allows them to focus on the content they need to continue to create, rather than focusing on just what they've got so far. (I understand this to mean that their priority is getting all of the planetary bodies in Stanton ASAP, as well as continuing work in that area so that they can ensure their pipeline is getting faster and faster, which is necessary if they're going to get other solar systems done in a reasonable amount of time - focusing on things like roads would be a distraction from this).
TL;DRScanning doesn't directly answer exploration, but its backend is being changed to hold arbitrary information, which could let scanned items feed missions and exploration discoveries and hopefully player-written data.
There's no direct answer, but they can give insight on the design of the scanning system which will relate to Exploration. They've had a big discussion with John Crewe (the Vehicle Director) who has to be talked to regarding any Vehicle Team work. JC went through the entire radar and scanning infrastructure, looked at all of the designs, and created a radar/scan bible of how they want it to work. In that, they discovered how they want to finalise scanning information, how they give Players that info, and how that info is stored. Previously to this there was Surface Scan (shows Ship Health, Names) and Detailed Scan (Passengers' Name & Health). This worked great for ships and mine-ables, but not for other things like signs and cups. So the Scan backend is currently being changed to hold technically arbitrary info, which will allow for the storage of any info on mine-able rocks, info to help Players get the optimal level to mine, info on all of the contents inside a rock, info on passengers, their faction, their health, info on cargo, and what type of cargo, such as illicit or stolen cargo. They're broadening how they can store the info, and what info can be stored, into a data model that they could technically store and put on anything. With that data model, they could put it on an arbitrary item, and design could attach arbitrary info to that item, which could lead into "random data mission access" stuff, such as a mission that requires you to go to a specific location, or acquire someone's stolen cargo - essentially anything could be stored in that arbitrary info box. They could hook up the Mission System to install and be able to read this stuff, so that then the Mission Devs could act on this info that's now available, to create a mission that might say, "steal this cargo, and then sneak into this area to avoid scans by authorities." So the entire Scanning System data structure has changed to allow this bigger and broader gameplay that they want. Regarding Exploration, if you come across a data item/device, that device could be scanned, info could be recovered from it and displayed to the Player, and that info could be relevant to a mission, or perhaps it's a note that another Player kept on them which details the location of where they've stored valuable resources and what the security combination is to access them. This will open up doors for design to make interesting missions, and will hopefully also enable the Devs to provide tools for Players to put info into scan data themselves to make interesting mechanics and gameplay. (I understand this to mean: imagine if a Player could own a tablet, such as the one featured in the Squadron 42 Vertical Slice that Trejo had before she was captured, and on that tablet the Player could store some info which could be valuable to other Players one way or another).
There's no official plan, but if they do it, it'll be after Squadron 42 is released. There are further questions related to this that would need to be answered, such as: What ranks would people be? (because that's something that's fleshed out for Squadron atm) What would the UEE be in Star Citizen exactly? (A Peacekeeping force? A Guild? A Faction? A Group?) It's something they'll talk about [internally] once Squadron's been released.
TL;DRPersistence is moving toward server-side object container streaming and server persistence, which is needed to improve performance and requires big code changes; server meshing is much further away.
here are several types of persistence, and they're currently aiming to help Server-Side Object Container Streaming (SSOCS) with their development of persistence. We currently have Client-Side Object Container Streaming (CSOCS), where if a cup moves away from a ship, the cup streams out for the client which helps to improve the client's FPS, but is still on the Server. The next evolution of this tech is SSOCS, where if no-one's near the cup, the Server doesn't need to know about it (so the cup is streamed-out for the Server just as it was for the client, boosting the server's performance). The problem with SSOCS is that, if it's a ship that was damaged that's going to be streamed-out, it needs to be brought back to the Server with the same damage it had before, which is where the next evolution of persistence is (where things like damage states persist regardless of whether the entity is streamed-in or out). There are a lot of teams working on it, to get both the engine and persistence working, and to do that they will have to change how and when persistence is stored. With the current persistence model, if a Player owns a cup then the cup has persistent info because it's bound to the Player, but an AI is not bound to a Player but to the Server. This is where global persistence comes in, where the cup is saving its persistent state (damage, health, who's inside it) to the Server's version of persistence info. This will allow for things to be streamed-out on each dedicated server, to unroll an entity and then bring it back. Further out, we'll see stuff like Server Meshing where maybe the cup is owned by a different Server, so then the persistence info of the cup has to be stored to the global universe, rather than to a particular Server - this is much further away, so right now we're just looking at SSOCS and Server Persistence. Just like with CSOCS, this will change a tremendous amount of game code, and most engineers are focusing on this development. As the tech becomes available, game coders (like Mark Abent) will have to change the system to expect that the cup is no longer (potentially) on the Server, so they need to figure out what needs to be saved in the general persistence so that it "comes back" as it was before it was streamed-out. The Ping System is a good example of what gets heavily affected by this. Right now with Ping, you can ping out and find things outside of the radar, but if the cup could be seen by a Player and it's streamed-out by both the Client and the Server, and the Player pings out and is expected to know that there's something there, the Player won't get that info (because it's streamed-out and there's nothing to communicate that it would be there). So now the coders have to change the Ping code to run a "service" - code that can read the persistent data - so that the Ping could as the service if there's anything within the area that's being pinged, and then the service checks to persistent entities that are streamed-out and what info is attached to them, so that it can be relayed back to the Player, who could then fly to that point of interest and find that a ship, which was there but was streamed-out, has now been streamed back in. Sean Tracy adds: SSOCS will have a dramatic effect on performance. Last quarter they hit a serious limit for content they can load on a Server, to the point where it's really hard for even the Devs to run their Servers locally, just because of the amount of RAM they need. So there's no more content they can shove in; they need SSOCS. And work on SSOCS doesn't stop work on Features, instead tasks are periodically fed to Devs, although SSOCS does take precedent over any Feature by far, because of how badly it's holding them back. A lot of the problems with performance, both Client and Server, is just too much stuff being held in memory, which SSOCS will help with. Also, the Persistence Team has laid out a calendar of when they want to get certain things in, which isn't a direct "on this day this" but more just a "we're here on the schedule" and "when we get to this point we'll have to talk to these people to do these things", and then when that's done they move forward on the schedule. Having done CSOCS already, it's helped them to know exactly what's going to happen with SSOCS so that they could plan pretty rigidly, to the point where SSOCS is more like game construction than game development.
They could have it in now if they made the ball, really it'd just be about keeping it persistent. It's noted that this isn't a commitment to adding a volley/basketball to the game.
TL;DRThere is no firm answer on inventory, which is currently split between teams; next quarter they will look at a unified physical inventory covering everything from medpens to ship cargo.
Sean Tracy doesn't have all the answers; Inventory is disparate atm, split between teams doing different things. In the next quarter they'll be looking at the Physical Inventory (the entirety of the system) covering everything from a Medpen all the way up to cargo in a ship, and being able to put things in those boxes. There's no rigid answer right now, but he can say that they've got to holistically tie all of the different designs together. A good example is the strange way that they determine cargo size on the ships, when they should acknowledge that whilst your ship might have a cargo pad which has a certain amount of room, there's nothing stopping the Player from just dropping boxes anywhere in the ship. So really cargo sizes should be regarding what you can secure inside the ship, but then there's also unsecure volume inside the ship for cargo. The main drive for now is on the Player Inventory, so things could be taken off the Player and put into the world and exist as it should, which would also "give" lootables. ST also refers to the preview of the Harvestable Entities Tech that was shown in ISC this week, where a Player could find fruit growing in the wild and pick some, but then the Player currently has nowhere to put that harvested entity, and reiterates that they'll be figuring it out next quarter. Regarding HET, Jared Huckaby clarifies that it could be applied to surface-side FPS mining and all sorts of things, which is held up by the lack of Player Inventories because you need somewhere to put things you've gathered.
As it happens, Jared knows the answer, which is no, they haven't chosen a new manufacturer, or at least not yet. It hasn't been decided that it needs to change manufacturer but it's being considered. The issue is that the Redeemer was conceived before the Aegis style-guide had been completed. So the question to be asked, when the time comes, is: which is more important? Keeping the look of the ship and therefore changing the manufacturer? Or keeping the manufacturer and changing the look of the ship? When the time comes, we'll likely hear about it on ISC, SCL, or their equivalent.
TL;DRArmour can't show damage like ships because of resource and texture-channel limits, but themed suits and actor status should let players generally read another player's role and condition; scanning would be needed for specifics.
There are some technical artistic limitations. Ships currently have a second layer, extra UV sets, to show the damage it has taken if any (so the top layer gets eroded when damaged, revealing a texture underneath that gives it the "damaged" look"). Players (armour) don't have that right now, because it would cost additional resources that are unaffordable. So the first thing they're looking into instead is to be able to see the status or type of a character from a glance. As part of this they've been talking about different types of suits and clothing that Players would wear, and to potentially theme them to different jobs. This would result in changing the stats of armour to fit different types, rather than having a situation where everyone where's similar or different armour, with similar stats. To elaborate, armour adds different things to a Player's stats, such as damage resistances (and perhaps other things like weight to slow the Player down by a certain degree depending on the armour). But this works quite similar to how the ships work, with the power triangle idea (so moving a stat in one direction reduces a stat in another, such as increasing armour might also increase weight). Ultimately, it depends on the suit in question and how it's been set-up regarding these stats. What's nice about the system is that they mix and match stuff, so Players can set-up their own custom profile to a degree, such as having an Explorer Undersuit with a Heavy Armour Core, which will be a different set-up than someone who goes full Heavy Armoured Marine. Armours and Suits might therefore be rethemed to fit types, so an Explorer type will be themed towards Exploration, which will be reflected in gameplay (so perhaps better climate control for the suit, or better protection from hazardous environments) - which is important so that Players can actually feel a difference in the gameplay, but also changing the looks should help Players "read" the different Armour/Suits easier. Whilst this won't help gauge another Player's health/damage state, it will help gauge what that Player is doing, or what activities that Player is geared up for (so if you met someone and they said they were a miner, but they were geared up for combat, you might be suspicious). This is more about being able to determine another Player's overall capabilities based upon what they're wearing. On a related note, they're doing a tonne of work around Actor States right now. The Actor Status system isn't just health, but all kinds of things like hunger, thirst, knockdown resistances etc. So a Player should be able to tell to a degree what another Player's status is from looking at them, but only generally speaking, and anything more specific would require Scanning. There is dirt and wear that will affect it, but really that just shows that the items equipped have been used. They'd like to have ship-like damage on the characters, but it's a problem with the UV2 channel which needs to be used for other things on characters, so it's just about a data-set not existing for it.
TL;DRSalvage faces hurdles including physical inventory, character-based salvaging and keeping items inside debris after a ship is destroyed; what salvage will look like is unclear, possibly starting as mining ships.
The big hurdles are the Physical Inventory that they talked about, and also Player Interaction regarding character-based salvaging (like salvaging components by removing them from their slots). One hurdle that the Art Vehicle Team has is that there are debris entities created when a ship is destroyed, and right now when that happens they take the item, move it over, and then it's magically moved - it doesn't have any pipe connections or persistent info, so it'll just spawn, vanish, and that's it. They need a more robust system to keep them there, to extract items, and then maybe also the resources on those debris pieces. Otherwise, if you blow up a ship and look inside it looks like an empty husk, and maybe a seat is floating. Ships spawn with Object Containers inside of the ship, and they want those to remain when a ship turns into a debris piece, but there are some tech limits on why they don't. So if you were to put a Big Benny's inside a Cutlass and it then explodes, you'd want them, or any other items that were inside, to still be there. As such, they have to solve how they're going to keep those, and transfer those Object Containers and what's inside them to the debris pieces, so that whatever mechanic is used, Players could extract those things outside of the debris piece or turn chunks into some sort of commodity. Mark Abent has seen prototypes of the mining laser being used to extract salvage, but that's just a "what if we did this" situation and not final. Really, it's unclear what Salvage will look like and what hurdles there will definitely be. Even if Salvage ends up being "mining ships" at the least that will be the first iteration for Players to try out, before the Devs get something more complicated out.
The first roll-out of the Female Character is a work-in-progress, and therefore issues like this are just something they haven't gotten to yet. The specific issue with the Female Character being unable to see over a box/crate that they're carrying could be an animation, design, or metric issue, and they'll have to investigate to determine which and fix it. But this issue relates to other things, such as how cover works, where the Female Character is shorter than the metric for cover is designed for, which requires a fix so that cover works regardless of the sex of the Player's character.
This is more of a question for "US2" (assuming this means Turbulent), but Jared's going to chase it up and see if he can find an answer, which he would then pass on to Tyler Witkin who can post it on Spectrum at a later time. For reference, the Friends List seems to be capped at 250 right now, which might just be an arbitrary limit.
It's a theoretical question, and it's hard to say but the probable answer is "as many as we can get". It's likely something that will be tested with the Evocati when the time comes, beginning with testing SSOCS with the current Player cap, and then expanding to see what happens. That said, they do have more sophisticated ways of testing this other than the Evocati, and they have "headless" client testing as well as Player testing (where headless clients are just clients that don't do anything). Either way, they'll be doing profiling around the Player cap, although SSOCS itself isn't likely to have a dramatic effect on it, unlike Server Meshing which will because they can shunt Players from Server to Server as needed.
This is an ongoing conversation, and the topic of a lot of active discussions internally. They can't give an answer or really even speculate, because what they decide upon could go one way or another, and if they were to discuss one way (which could get Players excited) and then decide upon the other, half the people would be disappointed. If it's a small degree of change then they're comfortable talking about it, but when it's significant it's best not to. So no answer just yet, but they're close to being able to say something.
TL;DRThey want ships landed at outposts to be storable and retrievable, but not magically spawnable if never flown there, since that would remove danger; ship-valet missions are being considered.
If a Player lands a ship at an outpost, they want that ship to be able to be stored, and for it to then be retrievable, but not for Players to just be able to magically spawn a ship that wasn't ever flown there. Part of the question with this is making sure the Landing Pads are big enough for ships to spawn. The reason why they don't want Players to be able to magically spawn whatever ship they want, is because that removes an element of danger. On a related note, Sean Tracy adds that they've even been thinking of things like, putting up missions as ship valets, such as, "I'm at this outpost and need my Caterpillar from ArcCorp" which a Player can then put up a Service Beacon for, asking, "Can someone do this for me?" ST comments on how he loves features/designs that give Players agency to create gameplay, like giving Players 10 Racing Rods so a race could be established, or the Service Beacons for the Players to be creative with.
TL;DRNew hair tech is going well; assets can be made and run well, but production is too slow, so they are building tools to speed it up, which is why little new hair has appeared.
It's going well, and they're in the phase of trying to finalise the pipeline of how they create the assets. They know they can make the assets, that they can run well and look good in-game, but the speed that it takes to make them is much longer than they want, so they're developing tools to speed it up. Typically hair as an asset type is really difficult to make in any type of production and can be very tedious, so they want to speed it up so that they can make as many types as they can. This is why we haven't seen new hair stuff yet, and why there isn't much diversity. ST comments that the process they currently have is much faster than usual anyway, so they already have big improvements, but because of the sheer amount of content they've got to make, it's got to be as fast as possible. And they don't want to keep using the old tech, which is why they haven't just done more stuff using that.
Planets have a Magnetic North, so it's possible. They comment that they think Coulson (David) talked about it before, and that they want to put it on the Ship HUD right now, but it's unclear about the character. Jared acknowledges that there are often questions not just regarding directions or compasses, but also a coordinate system, or at least to be able to modularly say "I'm at this coordinate on this planet". ST replies that they could output coordinates, that they do it all the time (particularly QA has to do it a lot) but that they're long and therefore not good to read (the implication being that if they were to add such a thing, they'd have to make sure it's convenient for the Player).
TL;DRMore female hairstyles will come after the tools to speed up the hair pipeline are done, since they are deliberately holding off to avoid updating existing styles; no date is given.
These will come after the tools have been developed to speed up the pipeline. Once that's done, they've got a catalogue of hairstyles they want to make, and even in regards to the hairstyles that could be used now they have more that they could put in the game. Instead, they've decided to stall for a little bit so that they'd have time to not have to update currently existing hairstyles. There are lots of bugs that come with hair, such as sticking through helmets, and they want to limit all that considering they're going to replace it anyway with the new hair tech. So they'll have more hairstyles, better hairstyles, generally more hair things, and beards too. ST adds that they are still making some hairs, it's just that they're for Squadron right now, and the Hero Characters in that, which is why we don't see them, and they don't really want to just take on of those hairstyles and drop them into the game as-is (because really they should be unique to those characters).
Most of character creator stuff is DNA-based regarding the faces, which they're continuing to work on. They have tech for face decals right now, which could handle tattoos or face paint, but it doesn't do scars well because scars require depth (and therefore a normal map) to look realistic, otherwise they just look painted on. To create scars using a normal map would be complicated to do because they have a lot of normal maps on characters faces as it is. They also don't have a good way to place it somewhere, and then further it would have to be persisted, so it would need a port for it to be attached to the character. What ST would prefer to do, is for scars to not be available initially but be something that appears over the course of the characters life, should something happen to create that scar.
TL;DRDocking depends on new attachment tech that must get through QA, plus persistence for docked ships and gameplay decisions like atmosphere handling; it's coming but no timing is given.
One thing stopping it that MA can think of is "CR's magical stream". Mark goes on to say that CR (Chris Roberts) is an amazing programmer who has a nice little stream (of code I presume?) where he's changing a lot of the underlying ways of how they attach things, and he has the support of a lot of the Lead Programmers and Engine Tech. So in this stream, he's changing how the Devs attach things to-and-from different things, and one of the problems with the current tech is that, if they want to attach a ship to another ship, a whole slew of problems arise because the ship has an interior physics grid with a bunch of Object Containers, and if you attach it to another one of those, the code doesn't handle it very well and it has problems. So in that stream, he has provided a way to fix those issues, so that a ship could be attached to another ship and it would work as you would expect. If that tech gets past QA and they fix some of the bugs that have resulted from it, it would open up the doors to give them the ability to attach a ship to a ship, so you could dock a ship directly on another ship. For example, on the Constellation there's a fake Merlin atm because they don't have this docking ability yet, but if they get this tech in and working then they could do this properly. The other part of the problem is persistence, where if they do Dock two ships then they have to have some sort of game code understand that they have some sort of ship docked to another, so that when they're streamed-out and streamed back in, the states and connections are established. Then there's the other aspect of gameplay: what does it mean to dock a ship to another ship? Does the interior atmo need to be vented, or do they need to decompress? So it's coming, and once all the pieces are together then more might be said about Docking.
TL;DRThey want bigger Subscriber Program changes with more in-game value, but it's too early to share specifics, so a later discussion is planned once a direction is settled.
They want to do revamps to the Program, not just to Flair, but larger changes and more in-game benefits that represent a greater value. Subscriptions make shows like ISC and SCL etc. possible, but they want a Subscription to provide much more for the Subscriber. Jared goes on to say that they're in the sixth year of the Subscriber Program, and that they're ready to push it forward to see if they can make Subs' SC experience better as well. Kinda like the Quantum Travel discussions currently happening internally, if the specifics are discussed right now when they're still figuring out which direction to take, some people might be disappointed if they go in a direction that wasn't the one that was talked about publicly. So not ready to do that just yet, but a discussion will happen in a forum like SCL when they're ready. They're keenly aware of "Pay-to-Win" and stuff like that, which they're going to try and steer clear of. Jared mentions again how he's recently been made an Associate Creative Producer for the Sub Program, which is why we're seeing some changes, and it's a big part of his responsibility going forward. He finishes by saying they're in talks with Tony Z, Todd Papy, with the Design Team, and the Mission Team, to find ways to incorporate the Sub Program within the PU more, and therefore make it much more attractive for people to Subscribe.