@LiamW - well, I hope SR2 is more reasonable and doesn't require taking thermometer readings in deep space for science points. Even KSP admits that's quite pointless, yet, you have to do the little science dance everywhere you go.
I'm hoping that the rewards for doing things in SR2 career are related to the things you did. For example, firing a new engine on a test stand makes it less likely that engine with catastrophically explode when you use it on a launch.
@Kell - if I'm not mistaken, Ctrl-rightclick copies the part and all the children parts that are attached. If the primary part is the root of a tree, you can Ctrl-rightclick a branch and it copies the branch and all the twigs and leaves attached to it.
I'm hoping the SR2 mod interface, when it eventually arrives, has some more advanced package management.
I remember every time KSP changed versions, a bunch of my mods would be subtly broken. But each would have to be updated manually.
I never developed mods for KSP, but I would hope that SR2 devs would give modders access to testing hooks and prerelease versions so that the mods can be kept up-to-date with SR2 releases and keep working.
Don't feel bad. This is what Buzz Aldrin wrote his PhD thesis about.
It's a bit to much for me to describe in a comment post. I think there are probably several YouTube videos about rendezvous in KSP, such as Scott Manley.
Maybe I could do one specific to SR2, but the only difference is the interface. The astrodynamics are the same.
I'm guessing that before astronauts are added, there will be more options for capsules, cockpits, habitats, etc. Hopefully all of them will be scalable like most SR2 parts.
I wouldn't stress about previously built craft that are the wrong scale or custom crew modules. That's par for the course on early access, sometimes you have to rebuild when new releases break your design.
It's probably going to be unsatisfying, because there's not currently support for controlling multiple vehicles simultaneously. So you won't be able to land the boosters while also getting the payload to orbit.
@AtlantikWall45 is right. Since fictional Droo is much smaller and less massive than Earth, you only need about 4500 m/s DV to get to orbit. But with RSS you need about 9000 m/s. So you need a much bigger to rocket for RSS, and they will be labeled as RSS in the gallery.
If the craft docks successfully, the orientation changes suddenly to the other craft's, and the autopilot immediately tries to flip the combined vehicle around. (This also happened in older versions.)
When I made the video, "w" and "s" were flipped -- that is, "s" translated toward the other craft. But when I load the sandbox, the orientation is correct -- that is, "w" translates toward the other craft.
Furthermore, Lagrange points are unstable equilibrium points. So you would need station keeping automation to be active when the craft is not in focus.
@Kell - personally I would like the benefit of better plausibility of fictional solar systems. US² can help a designer find planet compositions, atmosphere compositions, temperatures, and orbit parameters that are self-consistent. First, I think there's an educational benefit to exploring more realistic planets building. Second, as a player I think there's a benefit to planning a mission for a planet by making guesses about the destination based on real phenomena.
I think the US² output is already in an open json format, so there may not be any changes needed on the US² side. And writing an importer for SR2 might be straightforward.
Inflatable structures for habitats, wings, buoyancy, etc. would also be a very cool addition to the game. However, I can guess that the physics modeling is nontrivial.
I want to use SR2 with middle school kids. Our local districts have a bunch of Chromebooks. I think they can run Android apps, but I don't know how licensing works. It would not be practical for each student to buy the game in the Play Store.
I like your concept a freezing a design, but I'd like to suggest that the penalty for changing a design should be risk.
In the current version of SR2, all the parts are 100% reliable. But in the real world, risk is the reason spaceflight is expensive. I would like future versions of SR2 to add the possibility of parts failing.
I want the SR2 campaign player to make tough choices between making small tweaks to a proven design versus taking a leap with new technologies that promise higher performance.
The player can reduce risk by operating the part in ground tests, dedicated flight tests, or as a ride-along test after the primary mission is done.
Risk goes up when the part is used in new operating conditions, or when a parameter of the part is changed.
So, if you are a clever player and freeze your launch vehicle design, then each time you fly the reliability of all of its parts goes up. The more trusted your vehicle gets, the more contract offers come up. However, if you don't continue to expand your envelope, you will get surpassed by others.
spaceflight companies that weren't state-owned or heavily funded, ... But now, there is finally a company that is playing real world career mode; SpaceX.
SpaceX gets a lot of revenue and guaranteed loans from the US government (NASA and DOD.) For example.
@mjdfx150529 - I'm really glad to see someone thinking in this direction, and putting out a concept to provoke a conversation. I see the general theme of this concept is small-medium-large in discrete steps. I think that will be familiar and comfortable for KSP veterans, but I think SR2 has a very procedural / continuum theme that could really make for a novel campaign-mode experience.
I have some half-baked ideas that I'd like to throw in. None of these are particularly special to me, so feel free to push back on any of them.
1. Trade-offs between continuing a legacy system versus a clean-sheet design or new tech.
2. Point designs can get great performance, but they are brittle.
3. Parts have a chance of failing randomly. More operating time at a condition reduces the risk. Changing a parameter on part increases risk. Operating at a new condition increases risk.
4. Aborting a launch and recovering whole pieces is worth more than an unmitigated disaster. A failure on a test stand on Droo reduces risk more than a failure in deep space because the forensic data is better.
5. Part experience can combine. Test full-scale on the surface. Test sub-scale in orbit. Then fly full-scale in orbit and benefit from both risk reductions.
6. Size is mostly limited by infrastructure (facilities, tooling, transport), not so much by technology.
7. The technology milestones should improve efficiency, reduce risk, reduce cost, or add completely new capabilities. That could mean starting with a performance penalty that is half the ideal performance and gradually reducing that penalty to something like 10% of the ideal. The return on investment should taper off asymptotically.
8. Astronauts are sort of orthogonal to technology. Each individual character builds up experience quickly, but they cannot be duplicated.
9. Astronaut character performance should improve with experience in similar situations (not just purchased with XP points).
In general, I'd like the player's experience to loosely follow the history of spaceflight. Instead of a tech tree, I think it should work like a surface gradient. The player chooses one path up the tech mountain from what is an almost infinite variety. There are relative ridges, valleys, and cliffs, and it's hard to see the ideal path.
@LiamW - well, I hope SR2 is more reasonable and doesn't require taking thermometer readings in deep space for science points. Even KSP admits that's quite pointless, yet, you have to do the little science dance everywhere you go.
I'm hoping that the rewards for doing things in SR2 career are related to the things you did. For example, firing a new engine on a test stand makes it less likely that engine with catastrophically explode when you use it on a launch.
5.6 years agoHoly sigfigs Batman!
That's intense level of precision on the numbers you listed.
I think the Droo map is composed of six squares that form a cube that is projected on to a sphere.
!cube sphere
The map files are stored in the program folders. However, I think there are various layers that are assembled procedurally in the game.
+1 5.6 years ago@Mavizasyon - great! I have worked with DLR colleagues on a couple different projects and I very much like their contributions.
5.6 years ago@Mavizasyon - I am an aerospace engineer. But I only go to Europe about twice a year.
5.6 years ago@Mavizasyon - I was just playing on the word "eurospace".
5.6 years ago@pedro16797 - I'll give a try in a few days time. Your technique should help me land heavy spaceplanes.
5.6 years agoHas anyone used this for shock absorbers on landing gear?
If so, does it allow for beefier gear by using dual shocks?
5.6 years agoNot interested in amerispace engineers? 🤔
+1 5.6 years agoAnother case when git for crafts would be good.
5.6 years ago@Kell - if I'm not mistaken, Ctrl-rightclick copies the part and all the children parts that are attached. If the primary part is the root of a tree, you can Ctrl-rightclick a branch and it copies the branch and all the twigs and leaves attached to it.
+1 5.6 years agoYou can also drag the parts to the upper left corner icon (only appears when dragging) and to will add the part(s) as a subassembly you can add later.
+1 5.6 years ago@WNP78 - that's one way to do it. But there are equivalent alternative ways. I'm not going to pick the solution.
5.6 years ago@SupremeDorian - yes. Sorry I don't use the same handle on everything.
5.6 years agoRussia makes a couple hundred-million dollars more for another year of astronaut fares.
5.6 years agoI'm hoping the SR2 mod interface, when it eventually arrives, has some more advanced package management.
I remember every time KSP changed versions, a bunch of my mods would be subtly broken. But each would have to be updated manually.
I never developed mods for KSP, but I would hope that SR2 devs would give modders access to testing hooks and prerelease versions so that the mods can be kept up-to-date with SR2 releases and keep working.
+6 5.6 years agoSpace Shuttle used hydrazine APUs during ascent and entry/descent/landing.
Maybe to keep things simple, in SR2 there could be an APU part that uses "monopropellant" the same as RCS.
+2 5.6 years agoBooks.
+1 5.6 years agoDon't feel bad. This is what Buzz Aldrin wrote his PhD thesis about.
It's a bit to much for me to describe in a comment post. I think there are probably several YouTube videos about rendezvous in KSP, such as Scott Manley.
Maybe I could do one specific to SR2, but the only difference is the interface. The astrodynamics are the same.
+3 5.6 years ago@AnotherFireFox maybe since docking is improved, it's time to try again?
5.6 years agoI think it's an interesting idea.
5.6 years agoSeems like something that should be in the FAQ.
+2 5.6 years agoI'm guessing that before astronauts are added, there will be more options for capsules, cockpits, habitats, etc. Hopefully all of them will be scalable like most SR2 parts.
I wouldn't stress about previously built craft that are the wrong scale or custom crew modules. That's par for the course on early access, sometimes you have to rebuild when new releases break your design.
+2 5.6 years ago@RAF100 - yes I know, but fast switching isn't simultaneity.
5.6 years agoIt's probably going to be unsatisfying, because there's not currently support for controlling multiple vehicles simultaneously. So you won't be able to land the boosters while also getting the payload to orbit.
+1 5.6 years agoProbably best to specify which version when you're posting an hour after an update rolls out.
5.6 years ago@Kell - anyone building important rockets probably shouldn't be on beta channel...
+1 5.6 years agoThe usual key to map is ` (backtick).
5.6 years ago@AtlantikWall45 is right. Since fictional Droo is much smaller and less massive than Earth, you only need about 4500 m/s DV to get to orbit. But with RSS you need about 9000 m/s. So you need a much bigger to rocket for RSS, and they will be labeled as RSS in the gallery.
+3 5.6 years ago@pedro16797 bug report
5.6 years agoI'm having problems while docking.
I made a bug report but when I download that sandbox, everything seems to work fine.
I suspect the problem is related to un-docking and then re-docking (like Apollo pulling the LEM out).
Some problems I noted working on this experiment:
- The RCS goes haywire when I get in close.
- The docking rings get stuck slightly off-axis. Docking peaks at 86%, but oscillates down to 40%.
- If the craft docks successfully, the orientation changes suddenly to the other craft's, and the autopilot immediately tries to flip the combined vehicle around. (This also happened in older versions.)
- When I made the video, "w" and "s" were flipped -- that is, "s" translated toward the other craft. But when I load the sandbox, the orientation is correct -- that is, "w" translates toward the other craft.
+1 5.7 years agoFurthermore, Lagrange points are unstable equilibrium points. So you would need station keeping automation to be active when the craft is not in focus.
+1 5.7 years agoAnother potential use of inflatable structures. (Habs, airbags, wings, etc.)
+1 5.7 years ago@Kell - personally I would like the benefit of better plausibility of fictional solar systems. US² can help a designer find planet compositions, atmosphere compositions, temperatures, and orbit parameters that are self-consistent. First, I think there's an educational benefit to exploring more realistic planets building. Second, as a player I think there's a benefit to planning a mission for a planet by making guesses about the destination based on real phenomena.
+1 5.7 years agoI think the US² output is already in an open json format, so there may not be any changes needed on the US² side. And writing an importer for SR2 might be straightforward.
Tow ropes that pull gliders are another example. Aerodynamic drag makes them "sail" so they curve up rather than down.
5.7 years agoI'm pretty sure tethers have been suggested several times before, but I'm having trouble finding one of those threads.
5.7 years agoInflatable structures for habitats, wings, buoyancy, etc. would also be a very cool addition to the game. However, I can guess that the physics modeling is nontrivial.
+2 5.7 years agoAnother Discord server?
5.7 years agoUseful!
+3 5.7 years agoSome other devs already beat you to the virtual wind idea:
Sound Card: We don't think you need one. You can really just place a fan in front of you to simulate the wind-sounds.
5.7 years agoHow about shocks that refract light?
+2 5.7 years agoWell, I'm glad that's settled just before Apex goes extinct.
5.7 years ago@aircoolbro21 - I would want to make sure the licensing is square with Jundroo before doing anything like that.
5.7 years agoI want to use SR2 with middle school kids. Our local districts have a bunch of Chromebooks. I think they can run Android apps, but I don't know how licensing works. It would not be practical for each student to buy the game in the Play Store.
+1 5.7 years agoAndroid for me.
+1 5.7 years agoI also think there should be more coherency across missions. More like a campaign than a bunch of random, unrelated missions.
5.7 years agoI like your concept a freezing a design, but I'd like to suggest that the penalty for changing a design should be risk.
In the current version of SR2, all the parts are 100% reliable. But in the real world, risk is the reason spaceflight is expensive. I would like future versions of SR2 to add the possibility of parts failing.
I want the SR2 campaign player to make tough choices between making small tweaks to a proven design versus taking a leap with new technologies that promise higher performance.
The player can reduce risk by operating the part in ground tests, dedicated flight tests, or as a ride-along test after the primary mission is done.
Risk goes up when the part is used in new operating conditions, or when a parameter of the part is changed.
So, if you are a clever player and freeze your launch vehicle design, then each time you fly the reliability of all of its parts goes up. The more trusted your vehicle gets, the more contract offers come up. However, if you don't continue to expand your envelope, you will get surpassed by others.
+5 5.7 years agoSpaceX gets a lot of revenue and guaranteed loans from the US government (NASA and DOD.) For example.
+2 5.7 years agoDeja Vu. It means they changed something in the Matrix. 😉
!matrix
+2 5.7 years ago@mjdfx150529 - I'm really glad to see someone thinking in this direction, and putting out a concept to provoke a conversation. I see the general theme of this concept is small-medium-large in discrete steps. I think that will be familiar and comfortable for KSP veterans, but I think SR2 has a very procedural / continuum theme that could really make for a novel campaign-mode experience.
+1 5.7 years agoI have some half-baked ideas that I'd like to throw in. None of these are particularly special to me, so feel free to push back on any of them.
1. Trade-offs between continuing a legacy system versus a clean-sheet design or new tech.
2. Point designs can get great performance, but they are brittle.
3. Parts have a chance of failing randomly. More operating time at a condition reduces the risk. Changing a parameter on part increases risk. Operating at a new condition increases risk.
4. Aborting a launch and recovering whole pieces is worth more than an unmitigated disaster. A failure on a test stand on Droo reduces risk more than a failure in deep space because the forensic data is better.
5. Part experience can combine. Test full-scale on the surface. Test sub-scale in orbit. Then fly full-scale in orbit and benefit from both risk reductions.
6. Size is mostly limited by infrastructure (facilities, tooling, transport), not so much by technology.
7. The technology milestones should improve efficiency, reduce risk, reduce cost, or add completely new capabilities. That could mean starting with a performance penalty that is half the ideal performance and gradually reducing that penalty to something like 10% of the ideal. The return on investment should taper off asymptotically.
8. Astronauts are sort of orthogonal to technology. Each individual character builds up experience quickly, but they cannot be duplicated.
9. Astronaut character performance should improve with experience in similar situations (not just purchased with XP points).
In general, I'd like the player's experience to loosely follow the history of spaceflight. Instead of a tech tree, I think it should work like a surface gradient. The player chooses one path up the tech mountain from what is an almost infinite variety. There are relative ridges, valleys, and cliffs, and it's hard to see the ideal path.
I'm still sad that tables aren't part of native Markdown. Also, I wish
+1 5.7 years ago$ \TeX $displayed math.