-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
X-15 altitude limits #1909
base: master
Are you sure you want to change the base?
X-15 altitude limits #1909
Conversation
125km to begin with, roughly matching history. 1Gm (because the partmodule has no off switchs) in the mercury node to throw people a bone without twisting the tree out of shape
What if the upgrade were conditioned on human-rated EDL instead? I kinda don't want to block orbit-rated X-15 behind the very same node that you need for capsules... |
current total capsule-node cost: 125 My plan B was to put it in the matsci node, total cost 55+edl=70, basically same as HEDL. Either way yields an orbital x15 that doesn't need life support or flight control nodes, which is even more bizarre than x15 not needing those nodes in the first place. The "good" plan is to add a even-more-prototype-spaceplanes node with orbital x15, and move the spaceplane wings there (or maybe a new tier of wings, but ew); but that's going a bit far in the direction of "we approve of orbital x15" |
IMO the problem here is that there's a huge difference between a 180km suborbital, and an orbital flight. I would not want to prevent doing suborbital flights with the X-15. |
There's also a pretty big difference between the historical 108km and 180km in terms of reentry challenges; it's not clear to me that preventing the latter is much of a loss. But if we want to go in that direction, maybe we can play with the scrubber instead of altitude limits? Give it a 20-minute scrubber or such, possibly with later upgrade if we really really want to give it orbit access. Wouldn't make a whole lot of sense realism-wise, but I don't see a path that doesn't involve some level of arbitrariness. Amusingly, the current 'good enough for orbit, not as good as Mercury' scrubber was my doing.
quoth the PR:
Even if it did work, there's always the 'add a big braking stage' strategy (~4km/s lets a bare cockpit survive, I think). In any case, it's the "why does mercury need so much r&d and x15 needs so little for the same end result" problem I'd like to see solved. |
Why not just create a new part?? Create an Orbital Rated X-15 part that unlocks later. |
The core of the question is how to non orbital rate the X-15, no? |
New part or partupgrade doesn't really make much difference; either way, the main point of contention is where to put the new unlock. Just what the difference should be between the two seems comparatively unimportant. Temp rating seems obvious but doesn't really work; altitude or scrubber limits would both feel arbitrary but would both work fine |
For now I've added the non-reentry-rated tags. We'll see if that's enough, since the other options are more involved. |
does not appear to be enough https://discord.com/channels/319857228905447436/845456949331623985/1192424856701124618 |
125km to begin with, roughly matching history.
1Gm (because the partmodule has no off switch) in the mercury node, to more or less represent the extra r&d assumed to be necessary to "orbit-rate" a x-15.
Would be nicer if the partmodule did support getting turned off; as is, the in-game info will still say "unpressurized cockpit, crew will die above 1Gm" which is pretty silly.
extra notes: