Can you share a craft or some screenshots of your vizzy program? Also try asking in the SimpleRockets Chat Discord in the #vizzy channel, it's easier to share screenshots there.
Presumably you mean Cylero. Assuming you've got the basics down (building rockets, launching, and performing orbital maneuvers) there are a couple of good tutorial videos out there for performing basic interplanetary transfers. This one is specific to SimpleRockets 2 and going from Droo to Cylero. It's a little muddled but it demonstrates the concept. Then there's this video from none other than Scott Manly that does a great job explaining the fundamentals, so I highly recommend it even though it's a tutorial for Kerbal Space Program.
As far as where to start, here is the short version of the steps involved:
Build a rocket with at least 10.5 km/s Delta V (more if you want to land on Cylero, way more if you want to come home again).
Get into a circular "parking orbit" around Droo (~100km altitude is good).
Wait until a line from Cylero to Juno (the sun) to Droo makes a ~45 degree angle, and Droo is behind Cylero in its orbit (see Hohmann Transfer).
Create a burn node ~10 degrees into the dark side of Droo, and increase the prograde Delta-V until it is enough to escape Droo and gets you on an elliptical orbit that reaches Cylero's orbit (If you can get an encounter, meaning the closest approach indicator turns green, thats great, if not you can correct later). Execute that burn.
Wait until you are out of Droo's sphere of influence.
Find your ascending node, create a burn node at that point and adjust your inclination until you will be at the same elevation as Cylero when your orbit's cross.
If you don't yet have a rendezvous, tweak the burn using all three axises until you do (this is an art, or a lot of math, I cannot dictate simple steps).
Ideally, your rendezvous gives you a parabolic orbit with a low periapsis.
Wait until you are in Cylero's SOI.
Create a burn node at your periapsis, and add Delta-V retrograde until you get an orbit you're happy with. Execute that burn.
If you watch the videos and still need help given that, you'll need to be a little more specific about which steps you need help with.
You no longer need to download a file to install planetary systems. From the ESS 3.1 Page when you click the Download link it should display a dialog with a URL. Copy that URL, open SimpleRockets 2 and from the menu screen hit Ctrl+V. That should download and install the system, after which you should be able to create a new game using the system.
Caveats: images don't work in comments and may be restricted to some minimum reputation score. There isn't any way to specify color, I don't think there is any support for raw <span style="color: red">HTML</span>.
There is a set activation group instruction int the "Craft Instructions" section of the toolbox. This instruction takes the number of the activation group and a boolean value (true or false). You can check the current state of an activation group with the activation group expression in the "Craft Information" section.
To switch back to the latest stable version, if you're using Steam, go to the game page in your library, click the gear icon on the far right of the page, select the "properties" menu option, go to the "betas" tab, change the "select the betas you would like to opt into" dropdown to "NONE."
It does sound like there are some breaking changes for mods in this beta. Some mods (mine included), use unsupported internal features of the game engine which Jundroo cannot guarantee backward compatibility for. As a mod maintainer it is difficult to support the experimental branches because we have to switch back and forth between beta and stable (especially in this case because the mod API actually got updated, so it's a new version of Unity as well). I think you can expect to see mods get fixed around the time that the new version (9.40x.x) becomes stable/officially released.
I'm only speculating, but perhaps the fact that your recent Rotating Lunar Station is flagged as built with a beta prevents it from being on the home page. That is a very cool craft by the way.
This is indeed sad news, and I am disappointed in Take Two. TBD what this means for Simple Rockets 2 vs. KSP 2, but while I think/hope there is space in the market for both, it certainly doesn't seem like a bad thing for Simple Rockets 2.
Another workaround is to check for a sudden changes in mass or in part count. With part count you can do this with a wait until by setting a variable to the current part count and then wait until the current part count is less than the original. With mass I think you would need to use a while loop (because you want to ignore gradual changes caused by burning fuel). In either case these methods can be fooled by things like undocking or explosive disassembly. Additionally these techniques will not work for stages that don't separate the craft in some way (i.e. a parachute stage).
TLDR; simplerockets.com interprets pairs of _underscores_ as italics which will break plain text URLs that have underscores. To add a link to your post use something like this: [Corrected link](https://www.reddit.com/r/simplerockets/comments/gt61so/simple_rockets_2_new_marker_location_concept/?utm_source=share&utm_medium=web2x)
PCI stands for Planet Centered Inertial, which is a coordinate system that is centered at the center of mass of the planet whose sphere of influence you are in, and is otherwise fixed with respect to distant celestial bodies (i.e. the stars). It is basically the same as Earth Centered Inertial except for arbitrary planets including Droo.
The green line represents the target satellite's position vector. The red line represents the launch vehicle's position vector. In order to find out the green and orange angles you have to know some things about your vehicles flight path: how long it takes, and how far it travels laterally. Once you know those things you can figure out what that red angle should be when you launch. If you do this you should wind up in orbit close to your target. The most reliable way to do all of this is to automate everything with Vizzy. Having an automated launch helps you have a consistent flight path, and doing this vector math and launch timing manually is a pain. However, if you don't want to use Vizzy as at least an aid for timing your launch you can always resort to doing the math on paper and slapping a protractor on your screen to time the launch.
Assuming your target is in an orbit with zero inclination and you are launching from near the equator it is pretty simple. Estimate (or experimentally determine) the time it takes your rocket to get to your desired circular orbit, and the number of degrees of rotation in PCI terms that you travel during the launch. Wait until the angle between your craft's position vector and your target's position vector is equal to the number of degrees you travel during launch minus your target's angular velocity (degrees per second of rotation around the planet, aka 360 / orbit period) multiplied by the time it takes your launch vehicle to reach orbit. This angle will probably be negative, meaning that the target will need to be "behind" your launch vehicle at launch time, and you will have to account for that when waiting for the correct angle since the angle operator always returns a positive number, however depending on the launch vehicle this could theoretically be positive.
There are several examples out there of automating this procedure:
I'm a little fuzzy on what you are trying to do. However, if you just want to get the position of another craft relative to the current craft you can either use the nav [Target Position] if you are tracking the current target, or craft [id] [Position] if you are tracking an arbitrary craft. You can then take the difference between that vector and your nav [Position] vector. You can think of vectors as arrows, PCI position vectors are arrows pointing from the center of the current planet to the crafts. When you subtract position vector A from position vector B you get a vector (or arrow) that when it starts a craft A, points to craft B.
The resultant PCI vector we will be with respect to a reference frame that remains fixed in relation to distance stars. If you want the vector oriented with respect to the current craft's orientation you can use the part [0] [PCI to Local] [vector relative to your craft] instruction. This "local" vector will be relative to a coordinate system where the Z axis is up and down the length of your craft (i.e. (0, 0, 1) points "up" from the nose of your craft), the Y axis is the yaw axis, and the X axis is the pitch axis. This would be useful if you are interested in where the tracked object is relative to the direction or craft is pointing.
One way to do this would be to list all the crafts orbiting your current planet, and find the one that is closest. This isn't 100% guaranteed to work since there could theoretically be another craft hovering nearby that would actually be closer than the one that just separated. Another approach would be to enumerate all crafts around all planetary bodies (including the sun) in order to predict the next craft id that will be assigned. Here is an example of the first method. You could add extra checks like making sure the craft's name starts with the name of the current craft.
Modifying planets is currently done via XML. There is not yet a tutorial for how to go about this or any documentation of the XML tags and attributes so customizing planets is pure experimentation. The best way to start is to use PanetStudio to open an existing stock planet, save the planet with a new name, edit the XML file for your new planet, and then reload your new planet in PlanetStudio. The planet's XML files can be found in UserData/CelestialDatabase/CelestialBodies. Please refrain from re-uploading close copies of other peoples work, and do not circumvent the attribution system.
I believe the reason there is no documentation for this is because the developers are hard at work giving us an easy to use mobile friendly UI to customize planets. So if you are not up for experimenting and reverse engineering the XML, which I understand has taken others hundreds of ours to accomplish, I recommend you wait until the official release.
I forgot to mention, I uploaded a version of your craft with the Vizzy working. You will still need to add activation for stage 2, final pitch adjustment, and engine cutoff.
This code is built into the game, it is in the Assets.Scripts.Craft.Parts.Modifiers.Fuselage.FuselageScript class in the GetMaxFuelCapacity method. There is no way to alter or circumvent this code without a mod. Using a mod, such as Realistic Engine Overhaul you could introduce new fuel types with different storage overhead. Alternately you could create a mod with a custom fuel tank part that used different math.
It is possible to edit a craft's XML so that its fuel tanks are filled beyond capacity, or to increase the capacity (using the fuel and capacity attributes on the FuelTank element), but be aware that the minute you touch this part in the designer it will have its capacity reset to the default.
Make sure you are using the latest version of the game. If it is an older sandbox it is possible it is a backwards compatibility issue. You could open the dev console and before loading and see if any errors are reported (open the dev console by hitting the tilde/back tick key, check your control settings, and the click outside the dev console and hit ctrl+v to download the sandbox. If your on the latest version and this is a recent sandbox you should report this as a bug.
I just watched this video from Everyday Astronaut about how Starship won't have any launch abort capability, and it covers some interesting facts about launch abort capabilities of other launch vehicles. I'm not sure if others have made SR2 abort modules like those used in the Gemini/Apollo missions, or those on the Dragon Crew Capsule, but I think this would be pretty cool to implement. Obviously right now reliability concerns, not to mention the lives of your Droonauts, aren't really a thing in SR2. But some day (soonish?) we'll have career mode, and then maybe it will be a thing. Or I could add a mod for it 😉.
Personally I like that the SimpleRockets 2 trailer shows significantly more of the in game experience. The SR2 trailer could use a refresh now that we have astronauts, and it would be cool to see some more planetary flybys.
As I have pointed out here it would be nice to be able to get Keplerian Orbital Elements for an arbitrary node (planet or craft) instead of just the current craft.
I believe you can edit the xml to increase the maximum capacity without changing anything else. You will still have the same dead weight, and the additional fuel will still cost you. But combining this and a the mass scale in the tinker panel you should be able to make a more true to real life fuel tank in terms of capacity as a percentage of actual volume and dry weight vs full weight. However I've heard anecdotes about usage of mass scale mucking up the physics engine.
I don't suppose you are on a Mac with Time Machine enabled? I you were you could look at previous versions of your com.jundroo.SimpleRockets2/UserData/CraftDesigns/__editor__.xml file to see if you can recover a version of your unsaved craft from before it was overwritten by the downloaded craft.
I feel your pain, I think it would be a good idea for SR2 to warn you 1) before exiting the editor without actually saving your craft, 2) warn you when downloading a craft that you are about to lose unsaved changes if the __editor__.xml file has changed since the last save. Feel free to link a suggestion and I will upvote.
Because Cylero is further from the sun than Droo you need to start your transfer while Droo is "behind" Cylero in its orbit. Because the transfer orbit from Droo orbit to Cylero orbit has a shorter period than Cylero, you will "catch up" to Cylero.
Insanity is correct, the angle between Droo, the sun, and Cylero will need to be between 45 and 50 degrees. But FYI, this isn't magic, it is different depending on the two planets, and is proportional to the period of the transfer orbit and the angular velocity of the target body (here's the math).
When you make your burn to escape Droo you want to do it a few degrees after passing into the dark side of Droo. This is because when you make your orbit hyperbolic you want to exit Droo's orbit in the same direction it is traveling so that your excess velocity translates directly into raising the apoapsis of your transfer orbit around the sun.
The the greater the portion of the necessary Delta-V you put in while close to Droo the more efficient your transfer will be. If you wait until you have escaped Droo's SOI and then make another large burn to get your apoapsis up to Cylero's orbit you will waste >100 m/s.
Once you have left Droo's SOI you can tweak your arrival point and time by making a corrective burn, this burn will need to use a lateral component (the blue arrows) to shift your arrival time sooner or later, while correcting with a prograde/retrograde to keep your apoapsis lined up with Cylero's orbit.
Droo and Cylero both have 0 inclination so you shouldn't have to worry about that, but you should make sure your parking orbit around Droo before you start your transfer also has 0 inclination.
There are a few examples out there of crafts that calculate some of this for you, although I don't know of any that take eccentricity into account.
You can make links like this with the following text: [link plain text](https://www.reddit.com/r/Kos/comments/azfc05/impact_location_without_trajectories_mod/)
This missile tracks the reentry trajectory of a ballistic projectile with high accuracy using the ellipse/circle intercept method. However this has the huge caveat that it does not account for atmospheric drag. It works in my case because I am tracking something that is outside of physics range (1000 meters).
Ah, I see, so you're basically introducing some additional constraints on what craft can be taken control of. That sounds more doable. As long as the player abides by the rules you could have the flight programs orchestrate switching of control like so:
Player targets a particular craft.
Player toggles an AG or activates a "button" part
If the target is reachable via communications link player control is transferred, if not an "unreachable" error is displayed.
One limitation I can think of if you're not making a mod is verifying that a particular craft has a communication device that makes it part of your network. With a mod you could do things like check for reachability via a system of relays as opposed, and flip control back to the previous station (or the root station) when the player craft goes out of range of the network.
This is a neat idea and would be an interesting basis for a set of challenges.
My question is: what is the effect you want to achieve when the craft qualify as "communicating"? I think it is feasible using vizzy alone to come up with a list of crafts that meet your criteria, but then the question becomes what to do with that? There is a mod in development to do some sort of communication network, discussion in the Complex Rockets discord, perhaps @pedro16797 can invite you.
I don't think what you are describing is possible without a mod, but since you've upvoted my inter-craft communication mod perhaps you are planning to use that or something similar? When you say "the craft is within range" and "the player can control the ship" what do you mean exactly? While we do now have the ability to transfer control to other craft, there is no way to remotely control a craft. Regarding range, it is also important to note that the 10km limit for other crafts running vizzy is currently a pretty hard limit. I have looked for ways to create a mod that hacks this but the distance checks and craft-unloading code is pretty locked down, so even using private internal members I don't think it is possible to tweak this with a mod.
You can adjust the autopilot settings on you command pod/chip to account for sluggishness in the autopilot (I think this is usually done by increasing either the proportional and/or the integral components). However if your craft is difficult to control manually because it is sluggish to respond to inputs it may not be possible to compensate with autopilot settings. You may need to make changes to your control services, engine gimbals, or other aspects of your craft design.
Just so you know planetstudio is an experimental prototype, not a finished feature, and the planet xml is undocumented, so doing this is not for the faint of heart.
The default key to open the dev console is ~ if this doesn't work check your controls in settings (I've heard that it may be unconfigured by default in newer versions)
I'm not sure what one would do with OBJ files. Planets in SimpleRockets 2 are defined as XML, once loaded into PlanetStudio (which you open via the PlanetStudio console command), you can upload them with the usual menu button.
Very informative! I have used a little recursion but only for processing lists in expressions (in which case it is essential). Definitely good to know about the stack limit. I wish that were a little higher! 98 stack frames isn't very many. Thanks for investigating this and sharing.
FYI: https://simplerockets2.fandom.com/
+1 4.9 years agoCan you share a craft or some screenshots of your vizzy program? Also try asking in the SimpleRockets Chat Discord in the #vizzy channel, it's easier to share screenshots there.
4.9 years agoAlso, the all caps titles are unnecessary, just saying.
+1 4.9 years ago@Rizkyman made a pretty impressive one: https://www.simplerockets.com/Videos/View/69114
+2 4.9 years agoPresumably you mean Cylero. Assuming you've got the basics down (building rockets, launching, and performing orbital maneuvers) there are a couple of good tutorial videos out there for performing basic interplanetary transfers. This one is specific to SimpleRockets 2 and going from Droo to Cylero. It's a little muddled but it demonstrates the concept. Then there's this video from none other than Scott Manly that does a great job explaining the fundamentals, so I highly recommend it even though it's a tutorial for Kerbal Space Program.
As far as where to start, here is the short version of the steps involved:
If you watch the videos and still need help given that, you'll need to be a little more specific about which steps you need help with.
+5 4.9 years agoYou no longer need to download a file to install planetary systems. From the ESS 3.1 Page when you click the Download link it should display a dialog with a URL. Copy that URL, open SimpleRockets 2 and from the menu screen hit Ctrl+V. That should download and install the system, after which you should be able to create a new game using the system.
+2 4.9 years ago@AndrewGarrison can I get an update on this bug regarding buttons not being clickable after changing screens? It's very annoying and I thought it would get fixed before this shipped.
4.9 years agoSR2 Post Formatting Guide
Caveats: images don't work in comments and may be restricted to some minimum reputation score. There isn't any way to specify color, I don't think there is any support for raw <span style="color: red">HTML</span>.
+2 4.9 years agoThere is a
4.9 years agoset activation groupinstruction int the "Craft Instructions" section of the toolbox. This instruction takes the number of the activation group and a boolean value (trueorfalse). You can check the current state of an activation group with theactivation groupexpression in the "Craft Information" section.To switch back to the latest stable version, if you're using Steam, go to the game page in your library, click the gear icon on the far right of the page, select the "properties" menu option, go to the "betas" tab, change the "select the betas you would like to opt into" dropdown to "NONE."
It does sound like there are some breaking changes for mods in this beta. Some mods (mine included), use unsupported internal features of the game engine which Jundroo cannot guarantee backward compatibility for. As a mod maintainer it is difficult to support the experimental branches because we have to switch back and forth between beta and stable (especially in this case because the mod API actually got updated, so it's a new version of Unity as well). I think you can expect to see mods get fixed around the time that the new version (9.40x.x) becomes stable/officially released.
4.9 years agoI'm only speculating, but perhaps the fact that your recent Rotating Lunar Station is flagged as built with a beta prevents it from being on the home page. That is a very cool craft by the way.
4.9 years agoThis is indeed sad news, and I am disappointed in Take Two. TBD what this means for Simple Rockets 2 vs. KSP 2, but while I think/hope there is space in the market for both, it certainly doesn't seem like a bad thing for Simple Rockets 2.
Thank you @ TOMJeb117
+2 4.9 years agoAnother workaround is to check for a sudden changes in mass or in part count. With part count you can do this with a wait until by setting a variable to the current part count and then wait until the current part count is less than the original. With mass I think you would need to use a while loop (because you want to ignore gradual changes caused by burning fuel). In either case these methods can be fooled by things like undocking or explosive disassembly. Additionally these techniques will not work for stages that don't separate the craft in some way (i.e. a parachute stage).
+2 4.9 years agoI think you can probably achieve this without a mod by tweaking the XML for the engine part. Here is a guide to the XML elements.
4.9 years agoCorrected link
See the formatting guide
TLDR; simplerockets.com interprets pairs of _underscores_ as italics which will break plain text URLs that have underscores. To add a link to your post use something like this:
4.9 years ago[Corrected link](https://www.reddit.com/r/simplerockets/comments/gt61so/simple_rockets_2_new_marker_location_concept/?utm_source=share&utm_medium=web2x)PCI stands for Planet Centered Inertial, which is a coordinate system that is centered at the center of mass of the planet whose sphere of influence you are in, and is otherwise fixed with respect to distant celestial bodies (i.e. the stars). It is basically the same as Earth Centered Inertial except for arbitrary planets including Droo.
Here is a diagram that should help explain
The green line represents the target satellite's position vector. The red line represents the launch vehicle's position vector. In order to find out the green and orange angles you have to know some things about your vehicles flight path: how long it takes, and how far it travels laterally. Once you know those things you can figure out what that red angle should be when you launch. If you do this you should wind up in orbit close to your target. The most reliable way to do all of this is to automate everything with Vizzy. Having an automated launch helps you have a consistent flight path, and doing this vector math and launch timing manually is a pain. However, if you don't want to use Vizzy as at least an aid for timing your launch you can always resort to doing the math on paper and slapping a protractor on your screen to time the launch.
4.9 years agoAssuming your target is in an orbit with zero inclination and you are launching from near the equator it is pretty simple. Estimate (or experimentally determine) the time it takes your rocket to get to your desired circular orbit, and the number of degrees of rotation in PCI terms that you travel during the launch. Wait until the angle between your craft's position vector and your target's position vector is equal to the number of degrees you travel during launch minus your target's angular velocity (degrees per second of rotation around the planet, aka 360 / orbit period) multiplied by the time it takes your launch vehicle to reach orbit. This angle will probably be negative, meaning that the target will need to be "behind" your launch vehicle at launch time, and you will have to account for that when waiting for the correct angle since the
angleoperator always returns a positive number, however depending on the launch vehicle this could theoretically be positive.There are several examples out there of automating this procedure:
If you are trying to rendezvous with an inclined or elliptical orbit, or you are launching from higher latitudes, then things are more complicated.
4.9 years agolet me google that for you...
4.9 years agoAlso https://www.simplerockets.com/Forums/View/37070/How-can-I-set-up-a-Satellite-in-geostationary-orbit
This horse is dead and beaten:
https://www.simplerockets.com/Forums/View/34630/So-No-Mods-for-Android
+3 4.9 years agohttps://www.simplerockets.com/Forums/View/38335/Will-IOS-be-able-to-apply-mods
https://www.simplerockets.com/Forums/View/65447/Why-no-Overload-mod-for-android-I-just-want-an-explanation
I'm a little fuzzy on what you are trying to do. However, if you just want to get the position of another craft relative to the current craft you can either use the
nav [Target Position]if you are tracking the current target, orcraft [id] [Position]if you are tracking an arbitrary craft. You can then take the difference between that vector and yournav [Position]vector. You can think of vectors as arrows, PCI position vectors are arrows pointing from the center of the current planet to the crafts. When you subtract position vector A from position vector B you get a vector (or arrow) that when it starts a craft A, points to craft B.The resultant PCI vector we will be with respect to a reference frame that remains fixed in relation to distance stars. If you want the vector oriented with respect to the current craft's orientation you can use the
+1 4.9 years agopart [0] [PCI to Local] [vector relative to your craft]instruction. This "local" vector will be relative to a coordinate system where the Z axis is up and down the length of your craft (i.e.(0, 0, 1)points "up" from the nose of your craft), the Y axis is the yaw axis, and the X axis is the pitch axis. This would be useful if you are interested in where the tracked object is relative to the direction or craft is pointing.@SelectAKey if that's true they could have just asked 😅
4.9 years agoThis could use some more explanation. What's the objective? Droo orbit? What altitude? Limits on eccentricity?
How does the "least launches" thing work? Are you asking people to report how many tests launches they have to do to get their program working?
4.9 years agoOne way to do this would be to list all the crafts orbiting your current planet, and find the one that is closest. This isn't 100% guaranteed to work since there could theoretically be another craft hovering nearby that would actually be closer than the one that just separated. Another approach would be to enumerate all crafts around all planetary bodies (including the sun) in order to predict the next craft id that will be assigned. Here is an example of the first method. You could add extra checks like making sure the craft's name starts with the name of the current craft.
4.9 years agoEnjoy
+1 4.9 years agoModifying planets is currently done via XML. There is not yet a tutorial for how to go about this or any documentation of the XML tags and attributes so customizing planets is pure experimentation. The best way to start is to use PanetStudio to open an existing stock planet, save the planet with a new name, edit the XML file for your new planet, and then reload your new planet in PlanetStudio. The planet's XML files can be found in
UserData/CelestialDatabase/CelestialBodies. Please refrain from re-uploading close copies of other peoples work, and do not circumvent the attribution system.I believe the reason there is no documentation for this is because the developers are hard at work giving us an easy to use mobile friendly UI to customize planets. So if you are not up for experimenting and reverse engineering the XML, which I understand has taken others hundreds of ours to accomplish, I recommend you wait until the official release.
+1 4.9 years agoI forgot to mention, I uploaded a version of your craft with the Vizzy working. You will still need to add activation for stage 2, final pitch adjustment, and engine cutoff.
5.0 years agoThis code is built into the game, it is in the
Assets.Scripts.Craft.Parts.Modifiers.Fuselage.FuselageScriptclass in theGetMaxFuelCapacitymethod. There is no way to alter or circumvent this code without a mod. Using a mod, such as Realistic Engine Overhaul you could introduce new fuel types with different storage overhead. Alternately you could create a mod with a custom fuel tank part that used different math.It is possible to edit a craft's XML so that its fuel tanks are filled beyond capacity, or to increase the capacity (using the
5.0 years agofuelandcapacityattributes on theFuelTankelement), but be aware that the minute you touch this part in the designer it will have its capacity reset to the default.Here is a quick review of your vizzy
Issues
- Use of
- No
- Use of
5.0 years ago=instead of>=Lock Headinginstructionset [Pitch]instead ofset craft [Pitch]Make sure you are using the latest version of the game. If it is an older sandbox it is possible it is a backwards compatibility issue. You could open the dev console and before loading and see if any errors are reported (open the dev console by hitting the tilde/back tick key, check your control settings, and the click outside the dev console and hit ctrl+v to download the sandbox. If your on the latest version and this is a recent sandbox you should report this as a bug.
+1 5.0 years agoI just watched this video from Everyday Astronaut about how Starship won't have any launch abort capability, and it covers some interesting facts about launch abort capabilities of other launch vehicles. I'm not sure if others have made SR2 abort modules like those used in the Gemini/Apollo missions, or those on the Dragon Crew Capsule, but I think this would be pretty cool to implement. Obviously right now reliability concerns, not to mention the lives of your Droonauts, aren't really a thing in SR2. But some day (soonish?) we'll have career mode, and then maybe it will be a thing. Or I could add a mod for it 😉.
+1 5.0 years agoHere's another way to get this information: Vizzy++ Mod
5.0 years agoMissing Option: KSP 2.
Personally I like that the SimpleRockets 2 trailer shows significantly more of the in game experience. The SR2 trailer could use a refresh now that we have astronauts, and it would be cool to see some more planetary flybys.
+1 5.0 years agoAs I have pointed out here it would be nice to be able to get Keplerian Orbital Elements for an arbitrary node (planet or craft) instead of just the current craft.
5.0 years agoI believe you can edit the xml to increase the maximum capacity without changing anything else. You will still have the same dead weight, and the additional fuel will still cost you. But combining this and a the mass scale in the tinker panel you should be able to make a more true to real life fuel tank in terms of capacity as a percentage of actual volume and dry weight vs full weight. However I've heard anecdotes about usage of mass scale mucking up the physics engine.
+1 5.0 years agoI don't suppose you are on a Mac with Time Machine enabled? I you were you could look at previous versions of your
com.jundroo.SimpleRockets2/UserData/CraftDesigns/__editor__.xmlfile to see if you can recover a version of your unsaved craft from before it was overwritten by the downloaded craft.I feel your pain, I think it would be a good idea for SR2 to warn you 1) before exiting the editor without actually saving your craft, 2) warn you when downloading a craft that you are about to lose unsaved changes if the
5.0 years ago__editor__.xmlfile has changed since the last save. Feel free to link a suggestion and I will upvote.A few more details:
There are a few examples out there of crafts that calculate some of this for you, although I don't know of any that take eccentricity into account.
+1 5.0 years agoCorrected link to the referenced reddit post.
You can make links like this with the following text:
5.0 years ago[link plain text](https://www.reddit.com/r/Kos/comments/azfc05/impact_location_without_trajectories_mod/)This missile tracks the reentry trajectory of a ballistic projectile with high accuracy using the ellipse/circle intercept method. However this has the huge caveat that it does not account for atmospheric drag. It works in my case because I am tracking something that is outside of physics range (1000 meters).
+1 5.0 years agoAh, I see, so you're basically introducing some additional constraints on what craft can be taken control of. That sounds more doable. As long as the player abides by the rules you could have the flight programs orchestrate switching of control like so:
One limitation I can think of if you're not making a mod is verifying that a particular craft has a communication device that makes it part of your network. With a mod you could do things like check for reachability via a system of relays as opposed, and flip control back to the previous station (or the root station) when the player craft goes out of range of the network.
This is a neat idea and would be an interesting basis for a set of challenges.
5.0 years agoMy question is: what is the effect you want to achieve when the craft qualify as "communicating"? I think it is feasible using vizzy alone to come up with a list of crafts that meet your criteria, but then the question becomes what to do with that? There is a mod in development to do some sort of communication network, discussion in the Complex Rockets discord, perhaps @pedro16797 can invite you.
5.0 years agoI don't think what you are describing is possible without a mod, but since you've upvoted my inter-craft communication mod perhaps you are planning to use that or something similar? When you say "the craft is within range" and "the player can control the ship" what do you mean exactly? While we do now have the ability to transfer control to other craft, there is no way to remotely control a craft. Regarding range, it is also important to note that the 10km limit for other crafts running vizzy is currently a pretty hard limit. I have looked for ways to create a mod that hacks this but the distance checks and craft-unloading code is pretty locked down, so even using private internal members I don't think it is possible to tweak this with a mod.
5.0 years agoAt the moment I believe the only game type is "sandbox." Someday there will also be "career."
5.0 years agoAcceleration due to gravity changes slightly with altitude, but on Droo at sea level
+1 5.0 years agogis9.798You can adjust the autopilot settings on you command pod/chip to account for sluggishness in the autopilot (I think this is usually done by increasing either the proportional and/or the integral components). However if your craft is difficult to control manually because it is sluggish to respond to inputs it may not be possible to compensate with autopilot settings. You may need to make changes to your control services, engine gimbals, or other aspects of your craft design.
5.0 years agodisclaimer: experimental pre-release feature, good luck.
5.0 years agoOpen the dev console by pressing the
~(tilde) key, then typePlanetStudioand hit enter.If the
5.0 years ago~key doesn't open the console check your control settings (it's the last one under "Other Controls").Just so you know planetstudio is an experimental prototype, not a finished feature, and the planet xml is undocumented, so doing this is not for the faint of heart.
5.0 years agoThe default key to open the dev console is ~ if this doesn't work check your controls in settings (I've heard that it may be unconfigured by default in newer versions)
5.0 years agoI'm not sure what one would do with OBJ files. Planets in SimpleRockets 2 are defined as XML, once loaded into PlanetStudio (which you open via the
PlanetStudioconsole command), you can upload them with the usual menu button.Screenshots:
Planet Studio
Share Planet Dialog
5.0 years agoVery informative! I have used a little recursion but only for processing lists in expressions (in which case it is essential). Definitely good to know about the stack limit. I wish that were a little higher! 98 stack frames isn't very many. Thanks for investigating this and sharing.
+1 5.0 years ago