Increase the technology and contract requirements for the crewed lunar missions #2626
Conversation
Update TV broadcast to only need two crew at most, remove minaltitude requirement, wasn't working and already achieved via space high situation mask.
…ed needs to be done in zzzKerbalism.
…multiple tiers of capsule.
…t of 2nd gen capsule tier definition. Fix broken tag deletion in stations science
|
The minimum data rate requirements require this Kerbalism PR: Kerbalism/Kerbalism#931 |
…t it to a data rate somehow.
1.5 dBi omnis at 30 dBm longer work, but there is no way to require an S-band dish as everything is limited to a 330 Kbps max speed. All S-bands can achieve that at the moon by just boosting transmission speed. At least there's some penalty to it that way, but it's not great.
…ble on TL4 comms. It would work on TL3 comms via Evpatoria but at TL4 you're limited to 165kbps, which is 20.625 kB/s.
Modify data rates to match 500 kHz analog bandwith.
…'t edit a value that doesn't exist yet. Note for future me: figure out a better place to put the band definition file?
… an S-band antenna
…h at least two crew. Landing still only requires one. I believe the way I wrote the contracts the requirements to launch a new vessel with two crew can be bypassed if you launch a new two-crew vessel and then launch a one-crew moon mission. However, I don't know how to fix that currently.
The nested contract requirements should still complete fine even though the two-crew requirement will temporarily disable if one crew is on the surface, so we don't have to lock the parameter.
…oon is mandatory. This should eliminate the value of any LEO two crew mission + 1crew lunar mission cheese.
njits23
changed the title
|
Alright, I think that's all I wanted to accomplish with this PR. I'll leave it as a draft until the Kerbalism PR that's needed is merged and a version of kerbalism with it is released. I would still appreciate feedback on the changes made. |
|
One point I would appreciate feedback on is whether to also add the 2-crew to the moon requirement for the flyby, orbit, and first landing contracts. It'd make them a little harder but would also prevent weird stuff like D2 Block 1 mission module landers. |
…other than the flyby. Direct makes you land with both. Add missing flag requirement to targeted landing. Also various text fixes.
|
The Kerbalism version required to make the live TV experiments work as intended has released. https://github.com/Kerbalism/Kerbalism/releases/tag/3.23 |
Fix incorrect patch timing causing configure module to not get assigned. Fix text being too long causing it to overflow the text field.
…ing the Analog Video S-band tech level
|
I don't love adding a whole new antenna band just for a contract |
|
Well, what other solution(s) would you propose to make hitting the IRL bandwidth requirements of Apollo feasible? Widening the regular S-band channel is of course possible but seemed even more heavy-handed to me. I also think the existence of the band could lead to potential future applications for other programs, where other high-bandwidth experiments could be defined. Though then the band should probably be renamed to Wide S-band. I did look at doing it via the Skopos bands, but those don't go to regular DSN ground stations and don't allow the transmission of science. Enforcing the bandwidth requirement via Skopos wasn't feasible either, as far as I could tell, because it wasn't designed to work for a ground-vessel link only. Adding the Skopos bands to the DSN stations seems undesireable, so I don't think that'd work either. |
This is somewhat problematic for sure. I've seen people try to configure the Skopos bands on their antennas for regular comms. |
|
Well, that part won't be a problem here. Analog Video S-band band just acts like regular S-band with a much bigger bandwidth but less bandwidth at range due to not having an encoder. Maybe the name needs to be Unencoded Wide S-band instead, to better reflect what it actually is. |
|
Ok did some testing, saturating a wideband S-band channel to a DSN station using the Apollo HGA at the moon with TL5 antennas and ground stations requires 0.05 Watts, while with default S-band it requires 0.01 Watts. Turns out the DSN stations are pretty chunky, you don't need much of an antenna at all to talk to them. In light of this information, this is not worth adding a new antenna band at all. The data rate requirement is functionally just an S-band check, any directional antenna will trivially saturate the band if the DSN stations are listening, so just use normal S-band. It's mildly ahistorical but after Skopos, I really don't want to add more bands, especially as a "gotcha" for completing a lunar landing contract. Just force the player to saturate S-band (call it 150 kbps for encoder margin) to make sure they brought some kind of high-gain S-band. |
Correct, but the main thing here is that you only tested with a dish antenna. Reducing the bandwidth requirements suddenly makes omnidirectional S-bands also viable, which I find undesirable. Here is what you need to hit 500 Kbps with a 3 dBi omni on the wideband: Mass-wise and cost-wise a 500 Kbps 19.2 dBi 24 dBm dish and a 165 Kbps 3.0 dBi 33 dBm omni are basically the same, though, so I suppose it doesn't really matter. And yeah, a 165 Kbps dish and a 500 Kbps dish aren't much different either. I still don't see the problem with an extra band, but I'll change it. |
|
I suspect the problem with a new band definition is entirely UI/UX, not anything else. What this calls for is creation of a filtering system to enable/disable band defs in the PAW selection. Not hard to do [especially with a simple configuration UI controlling toggles], just doesn't exist yet. This should include a programmatic way for Skopos or the contract system to edit those toggles. Adding the contract enables the band. TBD what automatically disables it. (No contract and no vessels using?) There is a difference between exposing channel-level design to the players ["players" create their own band definition] and developer-managed definitions with an acceptable UI/UX for keeping the channel options list accessible to a basic user. |
|
Yeah, pretty much. The Skopos bands are tolerable because they don't overlap with existing bands, this would create a redundant S-band that's better in some ways and worse in others. On top of this, it means you can't use "normal" S-band even though IRL it was the same transmitters operating in narrow-band or wide-band mode. The average player seems to struggle with the band selector in general and does not read contract flavor text, adding a special band that's needed to complete the contract will only generate bug reports. The solution is to add better channel handling to RA. Due to the aforementioned player knowledge issues, a proper channel selector, while cool, would not be utilized properly by the average player. My idea would be to automatically handle channel selection much how modulation is automatically selected: start at the narrowest channel width, and double bandwidth when the channel is saturated until the maximum bandwidth is reached, hopefully preserving existing behavior at low recieved power while allowing much higher data rates at high received power for EOS, contracts, and even Skopos. However, that is way outside scope for this PR, and I seriously doubt I have the skill to implement it anyway. So at the end of the day it is what it is. The custom channel width encourages the player to bring a high-gain, but even so a few kg and a dozen watts on a manned lander isn't really a dealbreaker unless you already have no margins. I'd rather err on the side of caution than add more UI clutter and another "gotcha" for the lunar landing contract. |
Currently, the crewed lunar exploration program has no limitations on what sort of capsules are acceptable for use in the cislunar environment. This leads to strange situations where a Vostok lunar landing is an entirely workable concept.
This PR adds a new experiment, Lunar Landing Television Broadcast, which unlocks once the lunar landing tech node is unlocked and adds it to lunar orbiter, mature and later capsules, and lunar landing capsules. This experiment is required to be completed to complete the first crewed moon landing of either type.
The preexisting experiment for TV broadcast on the way to the moon is now required to complete the crewed lunar orbit contract.
To achieve this assignment of experiments, the way crew science was assigned to capsules had to be reworked as well. I've also added the 2nd gen experiments to mature capsules to enhance player choice.
Hopefully we can figure out some way to require near-live transmission of the TV broadcasts by requiring a sufficient bandwidth during it. Perhaps via what Skopos implements. I don't know how to achieve that, though. For now it just requires all the data to be transmitted before recovery.