Conversation
Introduces a "cameras" ship system type that holds the viewscreen FOV setting. Ships without a cameras system render a black viewscreen. The system appears as "Main Camera" in the config UI with a FOV input (10-120 degrees, default 45).
alexanderson1993
left a comment
alexanderson1993
left a comment
There was a problem hiding this comment.
A few thoughts:
- I love the NoSignal component. Great thinking.
- Good implementation of a new ship system.
- I think naming it "MainCameraPlugin" is an odd choice. Why are we modeling the camera and not the entire view screen?
- There will be aspects of the view screen that are not related to the camera that will be adjusted by the crew which will need to be modeled — which widgets appear, contacts that are highlighted on the view screen, whether certain contextual overlays appear, whether the viewscreen is showing the view from a probe with a camera. And then there's also the zoom and direction of the camera.
- There might be more than one view screen, each pointing in a different direction. Imagine TVs set up along the sides of the bridge showing what's going on to the port and starboard. So "Main Camera" is a misnomer in that case.
Hmm... This gets to be a tricky modeling problem. Because ships are intended to be bridge-agnostic (when I say "bridge", I'm meaning the physical set which gameplay happens in). It shouldn't matter which ship you use on what set — they're two different concepts that become related when a flight is started.
And the viewscreens are definitely associated with the bridge, not necessarily the ship. A "ship" doesn't know how many viewscreens it bridge is going to have. The Phoenix at the CMSC has two viewscreens. The Voyager at Renaissance Academy has one viewscreen (plus a number of ancillary screens that might be lumped in there). An NPC ship has zero viewscreens.
But ship systems are a ship concept, and it would be great to have the viewscreen be a ship system so it can be damaged, have ambiance and sound effects attached to it, etc.
This feels kind of foundational — not a straightforward one-off feature, but one which has huge impact on the overall gameplay — which is why I'm putting the brakes on this PR until we give the community a chance to discuss it.
Before we move forward, we need at least two Github discussions: one for viewscreens, based on what's discussed here and what we talked about on Discord about cinematography and poses; and one for bridges. You don't have to write either — I'll get around to writing both in the next few days, but feel free to beat me to it if you want.
See the following prior discussions as well:
#41
#320
We'll give it the requisite 48 hours for folks to weigh in, and then we can move forward with the implementation.
Things that need to be figured out as part of those discussions:
- How are bridges modeled? (We can look to Thorium Classic "Sets" for some inspiration, since it's the same concept. Though it will definitely be expanded and improved upon.)
- How are viewscreens modeled and associated with bridges? What things (if any) need to be configured on the plugin level, what are configured when the viewscreen is assigned to a bridge (see next item), and what things are only changed as part of a flight?
- How do we connect viewscreens in bridges to viewscreen systems on ships? (Perhaps the viewscreen ship system(s) are modeled as ship system plugins, but are not assigned to ship plugins, but to bridge plugins. Then the viewscreens are created when the ship is spawned with a bridge configuration, and not configured as part of the ship)
| .autoPublish([], () => null) | ||
| .request(({ ctx, input }) => { | ||
| if (!ctx.flight?.ecs) return null; | ||
| for (const [, entity] of ctx.flight.ecs.entities) { |
There was a problem hiding this comment.
This can be better. We cache entities by component using ctx.ecs.componentCache.get(componentName)
| for (const [, entity] of ctx.flight.ecs.entities) { | |
| for (const entity of ctx.ecs.componentCache.get('isMainCamera') || []) { |
| /> | ||
| ))} | ||
| </div> | ||
| <span className="block text-white text-3xl tracking-[0.3em] font-bold text-center mt-4 uppercase"> |
There was a problem hiding this comment.
Let's not use the uppercase class here, and instead put a descriptive class like viewscreen-no-signal-header so themes can selectively uppercase it if they want.
| <span className="block text-white text-3xl tracking-[0.3em] font-bold text-center mt-4 uppercase"> | |
| <span className="block text-white text-3xl tracking-[0.3em] font-bold text-center mt-4"> |
There was a problem hiding this comment.
yes... I did think about this... and thought who in their right mind would want to customize the "No Signal" screen in a theme so absently snuck in my own design sense. I'll try not to do it again.
| <span className="block text-white text-3xl tracking-[0.3em] font-bold text-center mt-4 uppercase"> | ||
| No Signal Found | ||
| </span> | ||
| <p className="text-white/60 text-sm tracking-widest text-center mt-2 uppercase"> |
There was a problem hiding this comment.
In case you couldn't tell, I really don't like uppercase.
| <p className="text-white/60 text-sm tracking-widest text-center mt-2 uppercase"> | |
| <p className="text-white/60 text-sm tracking-widest text-center mt-2"> |
There was a problem hiding this comment.
Yeah, I can change this. I was emulating real NO SIGNAL screens and had falsely assumed it would be wanted that way.
| import type { ShipSystemFlags } from "./shipSystemTypes"; | ||
|
|
||
| export default class MainCameraPlugin extends BaseShipSystemPlugin { | ||
| static flags: ShipSystemFlags[] = []; |
There was a problem hiding this comment.
I think we might want to include damage on here. The view screen being damaged will happen in missions I'm sure, and we should give the crew the ability to repair it themselves.
Not sure about power — is it worth an extra bar of power for such a minor system? I don't know.
|
Sorry, I didn't get a chance tonight to fully delve in, but I wanted to respond to your higher level topics. No worries about the comment or waiting period, I'm not in a rush. I prototyped this on the way to trying out the posing system and thought I'd clean it up and put it into a PR. As I had thought through it, the viewscreen is a display. There might be multiple viewscreens, or just one, or none. I didn't think the viewscreen itself would ever break or become damaged (I didn't think an entire crew station could go unresponsive/broken but I'm now remembering this could totally happen at CMSC). Viewscreens will show things (configurable, but at the moment, I haven't gone through the work to make it flexible/robust because we only have the main camera to show but I think this is what you are asking for?). Regarding the ship and the bridges being agnostic... my first thought was "if the ship and bridge are agnostic, how do we map the crew station to ship station". I found this is done just with the "Station Count" number and there are predefined mappings of screens to stations (Navigation and Pilot -> Pilot | Engineer -> Engineer etc.). This is kind of a bummer if for some reason I wanted to give the engineer both the pilot and engineer jobs. I also noted that there is currently only one viewscreen. I'm wondering if we should add a bridge configuration section to the plugin editor. In order to break stations/viewscreens, we probably need to make the bridge configurations part of the ship (so that the stations/viewscreens can be systems and/or link to systems that can break). If we make the stations/viewscreens agnostic of the ship, I don't know how we could could dynamically link breakable systems unless we guarantee they are present and a singleton in every single ship. The Main Camera (of which there is only one) is a strict forward facing camera with fixed lens focal length (set by the FOV angle). Crew do not have control over the main camera. I had intended for it to be simple. At the moment, if the main camera is missing, the viewscreen has nothing to display and I had intended that the main camera could become damaged and show a similar "No Signal" screen indicating the main camera was broken. Not yet implemented are "Secondary Cameras" that can rotate, zoom, etc. I would expect crew might have control over one or more secondary cameras. Maybe crew can view secondary cameras from their workstation and push secondary camera views to the main view screen. The flight director might also have control over secondary cameras or there is even a hidden secondary camera so as not to interfere with the crew's secondary camera. I was also mentally playing with the idea that the main camera wouldn't ALWAYS be on... maybe the viewscreen could use an LCARS style animation. The animation would be very theme dependent though... at the very least something so that the main camera could be turned off (or not present) and the viewscreen would do something more interesting than "No Signal". I could see a situation where a mission is carried out without using a main camera (not being able to directly see outside the ship and relying on sensors only adds a different flavor). Pretty sure there was a terrifying CMSC mission where all the sensors were dead and the viewscreen was static for half the mission. |
|
Read #41… Why are there still 5 alert tiers? |
Great question. What's the alternative? They'll become more relevant as we implement NPC crew members, since the crew will respond to the different alert levels. Though we'll probably adjust as we get around to implementing and see how it works in practice. |
You're conflating "station complements" with "bridge configurations" — they are related, but are still two different things. For a given bridge simulator set, the station complement is different based on the number of players (and maybe eventually the system load out of the player ship), while the bridge configuration will be the same regardless. It's possible to run any of the CMSC simulators with fewer than the max crew number. And the station complements are largely going to be the same across different bridges anyway. The reason there is no station complement configuration is because it's not something I want to be configurable to start off. Some unimplemented aspects of it might get a little messy, like dynamically changing the card distribution across the stations when a ship has or lacks certain ship systems, like the stealth field. (Though I might be overthinking this aspect). In any case, it's a configuration I want to add eventually, but it's not necessary quite yet. That said, I still think that bridges and station complements need to be modeled separately.
I think we could get away with them being separate and then dynamically linking when the flight is started/ship is spawned. I want to make it so a single bridge can be used for multiple ships. This isn't unheard of. The Phoenix bridge was famously both a Defiant and Intrepid class ship between 2005 and 2010. The Odyssey bridge was used as both a Seeker class ship and a Romulan imperial ship. Same bridge, multiple different ships.
This part is doable. We already model flight clients (eg individual client computers) as ECS entities. We can damage flight clients by adding the For damaging stations (eg. the same card load out assigned to multiple flight clients), we would need to model stations as ECS entities, link flight clients to the appropriate station entity, and then add the In both cases, we provide the This work isn't crucial for 1.0.
I recognize there are times for special one-off exceptional entities, but I don't think this is one. What's the difference between a main camera and secondary cameras vs. every camera being able to rotate and zoom but having a default orientation that it can be returned to? It seems to like they're basically the same, so I'd prefer to not model the same thing twice. I think a much simpler implementation would have a single camera per viewscreen that can look any which way but has defaults that it can easily snap back to when necessary (defined as part of the bridge configuration, since viewscreens are part of the bridge).
I don't know how this would ever be valuable to the crew. That was done by necessity at the CMSC because the Flight Director needed filler to show while they cued up footage on a VCR or DVD player. That isn't a problem with Thorium Nova because we can always show the forward view out the front. (Also, the video you linked is for one of the ancillary stations surrounding the bridge, never the viewscreen, which almost always shows a view out the front of the ship.) And that's my preference — even if something is superimposed on top of the viewscreen, including a different rotated/zoomed camera view, the periphery will always show the default forward view (or an angled view in the case of port/starboard viewscreens). Maybe that's why I want to model viewscreens instead of individual cameras — I don't want the crew to even have to think about different cameras that their ship has. Like, if they only have two cameras but four viewscreens, they have to share the cameras between the viewscreens? That's lame. Let's just let any viewscreen have any camera view it wants.
You're likely thinking of "Shadows." It is terrifying. |
|
Bridge discussion here: |
|
Viewscreen discussion here: #745 |
|
Ah yes… shadows. Good times. The main camera is special because it is the camera that is always used for the purposes of posing the ship on arrival to a waypoint. It is guaranteed to exist (which I think I failed to do in this PR) and for there to only be one so the posing algorithm can do its job to place the waypoint. Without a guaranteed main camera, we need to assign a viewscreen/camera to be the one used for poses (which I assume would be normally thought of as the “main viewscreen”). If there’s no main camera, then posing will need to use some other formula for waypoint placement or pretend a fake main camera exists anyways. If the FOV or rotation of the camera being used for poses changes mid-flight for some reason, the pose is of course not per intent when the ship arrives. A particular difficulty in the posing utility is that it doesn’t know what the FOV of the “main camera” is and because poses are ship and bridge agnostic, there is no way to guarantee a pose ends up as intended universally. The person making the pose has to assume some FOV and the final pose won’t be right if the FOV doesn’t match. You could of course make two poses (one for “At Right 45deg FOV” and the other for “Centered 90%, 20deg FOV Telephoto”). The pose utility doesn’t currently have any accommodations for actually changing the FOV of the camera. |
|
This is a tricky problem, and one that probably should be given a proper treatment in a Github discussion. Would you mind writing up a "Poses" discussion where we can continue this conversation in the context of the other discussions? To briefly address your thoughts here
There will be a convention that the main viewscreen has a
Nor should it, in my opinion. It might be necessary for poses to provide a best effort at getting the object in the right position relative to the camera, not 100% perfect every time. Poses should probably be concerned with the position of the object relative to the ship, not necessarily relative to the camera's view frustum. I don't understand how big of a difference that is — if you wouldn't mind addressing that in the Github discussion, that would be most helpful. The point being, we can't expect to hit our mark 100% of the time in a weird, highly configurable, highly dynamic system like this. I prefer to make the tradeoff on configurability and flexibility of viewscreens than on perfect poses, but if you think it's possible to get better tradeoffs, I'd love to hear it. Not mentioned in the viewscreen discussion is that I expect cameras to automatically reset to default settings when the ship jumps to warp, so we can anticipate some baseline "normal camera" when poses become relevant. This is kind of implied when I said that zooming only happens if an object is being actively focused on the viewscreen — that can't happen when warping, hence the camera resets. I think we can do the same when the camera is rotated to one of the cardinal directions too — just reset it to forward. |
|
done: #746 |
2 participants
Description of Changes
Related Issue
How do you know the changes work correctly?
Manual Testing
Screenshots (if appropriate):