I think the most important thing would be that the craft be distinctive. So based on a new/original idea is definitely a one option. But on top of that, and whether it's an original or a replica of an uncommon rocket, it needs to have an attention to detail that is shown in the screenshots that will catch peoples eye.
Also, when making replicas or realistic crafts I think some users frown on excessive use of tinker panel, but it looks like your crafts all of realistic masses and thrust levels.
I'm not sure you can download celestial bodies individually on mobile, since Planet Studio isn't currently available on mobile. However you should be able to download a planetary system by clicking the blue download button and then clicking download for mobile. This should automatically open the app and download the system.
So, I've played around with your rover a bit, and I've come to the conclusion that the built in autopilot logic may just not work well for wheel based vehicles. The thing is the plane auto pilot is designed to bank (roll) in the direction of the desired heading, and then use pitch to change current heading to approach the target, and then return to level once the craft arrives at it's target. As it is you are basically ignoring the pitch component, which I think makes things prone to oscillation. It might be possible to use Vizzy to combine roll and pitch into a single input to the wheels such that the autopilot does the job, I'm not sure. You can improve the situation by cranking down the Proportional and Derivative autopilot settings to very low levels.
Full flow staged methalox w/ max chamber pressure is pretty much as good as it gets for launch vehicles. One thing you could try to eke out a little more delta-v would be to decrease your nozzle throat sizes. A smaller nozzle throat will be more efficient but generate less thrust. Fortunately with a starting TWR of 2.4x you have thrust to spare.
@ANik2007 there's no excuse for pirating software. It is theft, it hurts software developers who work hard on these things, and it is against the law in many if not most jurisdictions. Situations like yours are the reason Jundroo has an educational use program. What you need to do is talk to a teacher or librarian about working with you to use SimpleRockets 2 as a tool to teach you about physics, math, computer programming, and/or history.
Are this sitting on the surface? If so you will need some mechanism to perfect the alignment. Docking ports must be precisely aligned down to the millimeter and fraction of a degree. In space this can be achieved because craft can drift freely, but on the surface of a planet friction and gravity get it the way.
It's hard to tell what is going on. Probably an issue with part connections or the interaction of the physics components (pistons, shocks, rotators). It's going to be hard to debug without a link to the craft.
Good question. I'm glad you posted it and it looks like you got a good answer. Your post would be a little better with a more descriptive title like "how to transfer data between Android devices." Also if CASXA's comment answered your question you should pin it.
This seems like a pretty helpful post. Would you consider changing the title to be title cased "How to Download a Modded Craft on Mobile" instead of all caps?
So several of the issues I pointed out originally were still relevant, but the solution is obviously quite different then what I described before. To restate the problem: the goal is to activate stages when specific parts (bombs) are in a particular position relative to the craft as they rotate around a central drum. There are several ways to skin this cat: you could check the orientation of the drum itself, you can check the angle between a vector to the bombs and some reference angle, or you can explicitly check the position of the bombs. I elected to check the position because it was the closest to the original and didn't require any complex vector math. The implementation I used was to take the PCI position of the rotating drum (part 162) and subtract it from the PCI position of the bomb to be dropped, which gives us a PCI vector from the COM of the drum to the bomb; then convert that into the craft's local frame of reference (we don't want to use the PCI frame of reference because it would give us different vectors as the craft orientation changed relative to the planet, and we don't want to use the frame of reference of the shaft or anything rotating because that would result in a constant vector, i.e. the bombs are not moving with respect to the drum they're attached to); once we have the craft relative vector from the drum to the bomb we subtract it from the desired position, and if the length of the resulting vector is less than 3mm we activate the stage. I won't write this up in text since you can see it in the screen shot on the craft.
@DoublehshAerospace I think that is a reasonable opinion. Since those milestones will be relatively infrequent, I think that if people follow your suggestion it won't create too much noise in the forum.
Oh haha I Completely misinterpreted what you were trying to do. That makes way more sense. I'll take another look now that I understand what you were actually trying to do.
I believe they are accurate, but be aware that when you resize fuel tanks it is indicating radius not diameter. So if you are using specifications that indicate diameter and forget to divide by 2 you will end up with a very fat rocket.
This is done by editing the xml for the craft and setting the respective attributes to a value that is greater than the maximum allowed in the UI. My understanding is that there are apps for Android you can use to edit the craft xml files, but I'm not an android user so I don't know the details. You might find this guide I found on Reddit useful.
If you include a screenshot in your post it will be easier to see what might be going wrong. You can also try asking in the #vizzy channel on the SimpleRockets Chat Discord
In order to share a sandbox you need to be in the flight view (i.e. launch a new craft, or resume an existing flight). Then on the flight menu panel click the share button (box with an up arrow).
Also here is the missile I was talking about. It plots the ballistic re-entry of a target ignoring drag, and does a ham handed job of projecting and guiding the trajectory of the missile that is fired at it.
I'm on a Mac and have been able to set the texture of parts without difficulty. In quality settings if craft textures and normal maps are both disabled then you won't see any textures.
time % 60 will give you the current second from 0 to 59 (1 to 59 doesn't make sense since there are 60 seconds in a minute, not 59). If you display this in a look with a short wait (0.1 seconds or less) you should have a display that is accurate to within a tenth of a second so long as you have ample CPU power. In theory the game engine may not run vizzy for longer periods of time if the CPU is bogged down by physics, graphics, or other processes.
There are lots of things in the Vizzy program that will need to change such as the names of the planetary bodies to target, the apoapsis to reach the target (which is hard coded), the phase angle for the transfer orbit burn (which is dependent on the initial and target apoapsis), also the either the flight program or the craft will need to be adjusted because the program makes assumptions about when stages will be expended while reaching orbit which are not valid for Kerbin because it is smaller than Droo. The flight program is a little hard to get to because it is on a part besides the primary command chip, but you can use the part list (click the magnifying glass on the left hand side of the designer), the flight program is on a part called Vizzy Here. Go through the flight program, try to understand what it is doing on step ate a time and where you see planetary body names and related constants replace them with the Kerbol equivalents.
Note: this script should adaptable to Kerbin/Mun, but getting to Minmus will take some extra logic because of inclination.
Seriously though "better" is kinda subjective but I think Methalox with a full flow staged engine is pretty good for launch and Hydrogen with a nuclear thermal engine is good for orbital maneuvers. Part of the fun is learning what Isp is and exhaust velocity and engine cycles and TWR, not to mention experimentation and trying different designs for yourself. So you tell me, what are the best fuels?!
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.
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.
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.
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.
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.
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).
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.
A couple of ideas for deploying cargo: a lot of little wheels with motors creating a conveyor belt (this would be sweet but it would probably melt mobile devices), a high speed piston activated to give the payload a shove, a lever on a hinge used much like the piston, a vizzy script on the payload itself that causes RCS to fire.
Wow, nice plane! How about automated deployment of a payload with a parachute. I think even with the limits on vizzy programs running on non controlled craft that should be possible.
After our discussion in Discord, I think what you are looking for is the following:
For a given target:
How many seconds until the next closest approach between the current craft and that target
A PCI vector for the position of the target relative to it's parent at the time of closest approach
A PCI vector for the position of the current craft relative to it's parent at the time of closest approach
The last one gets a little complicated because it begs the question: from what origin should this vector be. Should it be the crafts current sphere of influence parent? Its parent at the time of the closest approach? Or the target itself? I'm tempted to go with the latter because that is the most useful piece of information (how close will you get to your target). And the others can probable be derived from that.
If this is indeed what you are looking for then I agree that this would be a useful addition to Vizzy. It is theoretically possible now, but it is not easy.
Also "best" is dependent on a number of variables, chiefly the mass of your payload and your target altitude. A fuel type/power cycle combo that might be the most efficient for one payload/altitude wouldn't get another payload off the ground.
I think the most important thing would be that the craft be distinctive. So based on a new/original idea is definitely a one option. But on top of that, and whether it's an original or a replica of an uncommon rocket, it needs to have an attention to detail that is shown in the screenshots that will catch peoples eye.
Also, when making replicas or realistic crafts I think some users frown on excessive use of tinker panel, but it looks like your crafts all of realistic masses and thrust levels.
+1 3.8 years agoI'm not sure you can download celestial bodies individually on mobile, since Planet Studio isn't currently available on mobile. However you should be able to download a planetary system by clicking the blue download button and then clicking download for mobile. This should automatically open the app and download the system.
+1 3.8 years ago@Nhonho It doesn't hurt to leave this here for others having a similar issue to find and learn from (you're not the first to make this mistake).
+1 3.8 years agoSo, I've played around with your rover a bit, and I've come to the conclusion that the built in autopilot logic may just not work well for wheel based vehicles. The thing is the plane auto pilot is designed to bank (roll) in the direction of the desired heading, and then use pitch to change current heading to approach the target, and then return to level once the craft arrives at it's target. As it is you are basically ignoring the pitch component, which I think makes things prone to oscillation. It might be possible to use Vizzy to combine roll and pitch into a single input to the wheels such that the autopilot does the job, I'm not sure. You can improve the situation by cranking down the Proportional and Derivative autopilot settings to very low levels.
+1 3.8 years agoFor getting log data out of SR2 and into a text file you can use the SR2LoggerPlus mod, assuming you're on a PC.
+1 3.8 years agoFull flow staged methalox w/ max chamber pressure is pretty much as good as it gets for launch vehicles. One thing you could try to eke out a little more delta-v would be to decrease your nozzle throat sizes. A smaller nozzle throat will be more efficient but generate less thrust. Fortunately with a starting TWR of 2.4x you have thrust to spare.
+1 3.8 years ago@ANik2007 there's no excuse for pirating software. It is theft, it hurts software developers who work hard on these things, and it is against the law in many if not most jurisdictions. Situations like yours are the reason Jundroo has an educational use program. What you need to do is talk to a teacher or librarian about working with you to use SimpleRockets 2 as a tool to teach you about physics, math, computer programming, and/or history.
+1 3.8 years agoAre this sitting on the surface? If so you will need some mechanism to perfect the alignment. Docking ports must be precisely aligned down to the millimeter and fraction of a degree. In space this can be achieved because craft can drift freely, but on the surface of a planet friction and gravity get it the way.
+1 3.8 years agoThis sounds like something a hybrid from Battlestar Galactica would say 🤣
+1 3.8 years agoIt's hard to tell what is going on. Probably an issue with part connections or the interaction of the physics components (pistons, shocks, rotators). It's going to be hard to debug without a link to the craft.
+1 3.8 years agoThe URL for planetary systems should look like:
+1 3.8 years agohttps://www.simplerockets.com/PlanetarySystems/View/{system_code}/{system_title}.Good question. I'm glad you posted it and it looks like you got a good answer. Your post would be a little better with a more descriptive title like "how to transfer data between Android devices." Also if CASXA's comment answered your question you should pin it.
+1 3.8 years agoIf you are going to use an
+1 3.8 years agoifinstead of await untilthen it will need to be inside of a loop.This seems like a pretty helpful post. Would you consider changing the title to be title cased "How to Download a Modded Craft on Mobile" instead of all caps?
+1 3.8 years agoSo several of the issues I pointed out originally were still relevant, but the solution is obviously quite different then what I described before. To restate the problem: the goal is to activate stages when specific parts (bombs) are in a particular position relative to the craft as they rotate around a central drum. There are several ways to skin this cat: you could check the orientation of the drum itself, you can check the angle between a vector to the bombs and some reference angle, or you can explicitly check the position of the bombs. I elected to check the position because it was the closest to the original and didn't require any complex vector math. The implementation I used was to take the PCI position of the rotating drum (part 162) and subtract it from the PCI position of the bomb to be dropped, which gives us a PCI vector from the COM of the drum to the bomb; then convert that into the craft's local frame of reference (we don't want to use the PCI frame of reference because it would give us different vectors as the craft orientation changed relative to the planet, and we don't want to use the frame of reference of the shaft or anything rotating because that would result in a constant vector, i.e. the bombs are not moving with respect to the drum they're attached to); once we have the craft relative vector from the drum to the bomb we subtract it from the desired position, and if the length of the resulting vector is less than 3mm we activate the stage. I won't write this up in text since you can see it in the screen shot on the craft.
+1 3.8 years agoHere you go. I can explain the code shortly.
+1 3.8 years ago@DoublehshAerospace I think that is a reasonable opinion. Since those milestones will be relatively infrequent, I think that if people follow your suggestion it won't create too much noise in the forum.
+1 3.8 years agoOh haha I Completely misinterpreted what you were trying to do. That makes way more sense. I'll take another look now that I understand what you were actually trying to do.
+1 3.8 years agoInstructions are pinned to the top of the forum. I would say you can't miss 'em, but....
+1 3.8 years agoI believe they are accurate, but be aware that when you resize fuel tanks it is indicating radius not diameter. So if you are using specifications that indicate diameter and forget to divide by 2 you will end up with a very fat rocket.
+1 3.8 years agoThis is done by editing the xml for the craft and setting the respective attributes to a value that is greater than the maximum allowed in the UI. My understanding is that there are apps for Android you can use to edit the craft xml files, but I'm not an android user so I don't know the details. You might find this guide I found on Reddit useful.
+1 3.8 years agoIf you include a screenshot in your post it will be easier to see what might be going wrong. You can also try asking in the #vizzy channel on the SimpleRockets Chat Discord
+1 3.9 years agoIn order to share a sandbox you need to be in the flight view (i.e. launch a new craft, or resume an existing flight). Then on the flight menu panel click the share button (box with an up arrow).
+1 3.9 years agoAlso here is the missile I was talking about. It plots the ballistic re-entry of a target ignoring drag, and does a ham handed job of projecting and guiding the trajectory of the missile that is fired at it.
+1 3.9 years agoLooks pretty good. Releasing it soon?
+1 3.9 years agoI'm on a Mac and have been able to set the texture of parts without difficulty. In quality settings if craft textures and normal maps are both disabled then you won't see any textures.
+1 3.9 years agoWhat do you mean by "harden" and "failure"? Assuming you mean it blows up on the launchpad, you could try adding landing legs or a launch tower.
+1 3.9 years agoGoogle Docs Link
Discord Link
I would suggest you rename this to "Community Campaign Mode" to avoid confusion in the future.
+1 3.9 years ago
+1 3.9 years agotime % 60will give you the current second from 0 to 59 (1 to 59 doesn't make sense since there are 60 seconds in a minute, not 59). If you display this in a look with a short wait (0.1 seconds or less) you should have a display that is accurate to within a tenth of a second so long as you have ample CPU power. In theory the game engine may not run vizzy for longer periods of time if the CPU is bogged down by physics, graphics, or other processes.There are lots of things in the Vizzy program that will need to change such as the names of the planetary bodies to target, the apoapsis to reach the target (which is hard coded), the phase angle for the transfer orbit burn (which is dependent on the initial and target apoapsis), also the either the flight program or the craft will need to be adjusted because the program makes assumptions about when stages will be expended while reaching orbit which are not valid for Kerbin because it is smaller than Droo. The flight program is a little hard to get to because it is on a part besides the primary command chip, but you can use the part list (click the magnifying glass on the left hand side of the designer), the flight program is on a part called Vizzy Here. Go through the flight program, try to understand what it is doing on step ate a time and where you see planetary body names and related constants replace them with the Kerbol equivalents.
Note: this script should adaptable to Kerbin/Mun, but getting to Minmus will take some extra logic because of inclination.
+1 3.9 years ago🎄🎁
+1 3.9 years agoSeriously though "better" is kinda subjective but I think Methalox with a full flow staged engine is pretty good for launch and Hydrogen with a nuclear thermal engine is good for orbital maneuvers. Part of the fun is learning what Isp is and exhaust velocity and engine cycles and TWR, not to mention experimentation and trying different designs for yourself. So you tell me, what are the best fuels?!
+1 3.9 years agoFYI: https://simplerockets2.fandom.com/
+1 3.9 years agoAlso, the all caps titles are unnecessary, just saying.
+1 3.9 years agoI'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.0 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.Enjoy
+1 4.0 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.0 years agoMake 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 4.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 4.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 4.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 4.0 years agoA 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 4.0 years agoThis 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 4.0 years agoAcceleration due to gravity changes slightly with altitude, but on Droo at sea level
+1 4.0 years agogis9.798Very 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 4.0 years agoA couple of ideas for deploying cargo: a lot of little wheels with motors creating a conveyor belt (this would be sweet but it would probably melt mobile devices), a high speed piston activated to give the payload a shove, a lever on a hinge used much like the piston, a vizzy script on the payload itself that causes RCS to fire.
+1 4.0 years agoWow, nice plane! How about automated deployment of a payload with a parachute. I think even with the limits on vizzy programs running on non controlled craft that should be possible.
+1 4.0 years agoCheck out this tutorial.
+1 4.1 years agoAfter our discussion in Discord, I think what you are looking for is the following:
For a given target:
The last one gets a little complicated because it begs the question: from what origin should this vector be. Should it be the crafts current sphere of influence parent? Its parent at the time of the closest approach? Or the target itself? I'm tempted to go with the latter because that is the most useful piece of information (how close will you get to your target). And the others can probable be derived from that.
If this is indeed what you are looking for then I agree that this would be a useful addition to Vizzy. It is theoretically possible now, but it is not easy.
+1 4.1 years agoI suggest you do some research online. It is a lot more fun than just having someone tell you what engine you should use:
https://en.wikipedia.org/wiki/Rocket_engine
https://en.wikipedia.org/wiki/Liquid-propellant_rocket#Engine_cycles
https://en.wikipedia.org/wiki/Rocket_engine_nozzle
https://en.wikipedia.org/wiki/Aerospike_engine
Also "best" is dependent on a number of variables, chiefly the mass of your payload and your target altitude. A fuel type/power cycle combo that might be the most efficient for one payload/altitude wouldn't get another payload off the ground.
+1 4.1 years ago