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.
I think the answer to this is yes. There are hints at career/campaign mode in the game (like tracking the cost of rockets), and right in the description on Steam you've got: "We're bringing it to Early Access while we work on a Planet Builder, Campaign Mode, and other key features." Speaking of which, I don't know about the verbiage on other app stores, but I wouldn't say SimpleRockets 2 has been released for 2 years, it was in beta for some of that time, and even now it is "Early Access." The version number is still 0.9xxx, when that rolls over to 1.0 the game should be considered "released." Sorry if I sound defensive, I just think this game is amazing and super fun as it exists today. In my mind the "goals" are: learn about the physics of rockets, aerodynamic flight, and orbital mechanics/maneuvers; recreate historic, current, and future vehicles and missions from real world spaceflight; create complex and ingenious automation for craft maneuvers and functionality; build amazing, intricate, and beautiful vehicles (space worthy or planet bound) that are either strikingly true to their real life inspirations, or stunningly creative and fanciful.
That said, will campaign mode be a welcome addition, absolutely.
Well, I'm sorry to say I failed to thoroughly research this before asking, and it turns out there is an wikipedia article describing how a sphere of influence is defined. I did however discover through investigation that SR2 tacks on an extra 5% when checking for exit of an SOI. So the equation for the radius of an SOI is:
r_soi = sma * (mass / mass_parent) ^ 0.4
And the equation for the SOI when checking for the exit of an SOI is:
The going theory, thanks to @pedro16797, is that SOI is based on the distance at which the acceleration due to gravity from the parent body becomes greater than the acceleration due to gravity from the body whose SOI we are trying to determine. I'm assuming at this point that we're talking about the point where the two accelerations are in opposite directions (i.e. the point in between the two bodies). I'll try to verify this experimentally and report back.
I presume you are talking about "Burn Nodes." These are similar to "Maneuver Nodes" in Kerbal Space Program. Unfortunately the built in tutorials only cover the basics. However, you can check out this player produced tutorial, or this brief description from the blog, for more information.
I'm having trouble understanding your question. The gyroscope exerts rotational force based on the control inputs pitch, yaw, and roll. I'm not sure it is possible to use an InputController with a gyroscope but if it is you would need to edit the XML, and I imagine you could map whatever inputs you wanted to the pitch, roll, and yaw input ids.
Kudos to the dev team for making that magically work. It was just a stab in the dark but I was thrilled to see it work (and I verified the behavior for different numeric values).
Using 1 or 1.0 as the "Input" property makes the input value a fixed number instead of reading the current value of a slider, attribute, or variable. If you used 0.5 the piston would be half extended any time it was activated.
You can achieve this by setting the Input property of your piston to the numeric value 1.0, the Activation Group property to your desired AG, and enabling the "Zero On Deactivate" property. All under the Piston Input section of the part properties.
If you don't see some of these properties you need to do the following: In the part settings for your piston, enable "Show Hidden Properties" in the Tinker Panel, you will then see a number of new options under the Piston Input section.
Once a part of your craft becomes disconnected, either via an interstage, a docking port, or an explosion, it is considered a separate craft. It is not currently possible for a vizzy program on one craft to get position information about specific parts on another unless the player specifically targets that part. A vizzy program can set the target, but only be planet or craft name.
Additionally, guided air to air missiles are going to be difficult if not impossible owing to all the limitations of vizzy programs on crafts the player doesn't currently control. These limitations are especially problematic inside the atmosphere, where this really go badly once the craft in question is over 1km from the player controlled craft.
Well don't I feel stupid 🤯. It does have some glitches I'll report in game (undo adding a new expression to an existing expression slot is weird, leaves the expression in the slot and a copy not in the slot; redo sometimes causes an un-delete-able value floating next to the expression to which something was added). Also if somebody makes a suggestion to add buttons to the same location as they are in the editor I will up vote that as well.
You should create a new suggestion, share a link here and I will happily upvote. I have occasionally mess up a program by dropping an expression in the wrong slot and it would be nice to be able to undo that.
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.
I think you answered your own question. SSTOs and space planes are hard because engine effectiveness varies with altitude and you end up toting a lot of excess weight with you into orbit. I've made an SSTO space plane that used a mix of jets and aerospike engines. It get's to low Droo orbit, but it doesn't have enough delta V left to get to the moon. I'm pretty sure this would be extremely difficult without excessive use of the tinker panel. That said, I think it would be possible to design a pure rocket based SSTO with the ~6500 m/s of delta-v needed to get to Luna. Getting home again is another story.
You can use vizzy to detect when you enter the sphere of influence of a specific planet although you have to use on enter [planet] SOI event rather than just a wait until [condition] instruction. You can also determine your distance to the planet using a combination of the planet [name] [Solar Position] and nav [Position] craft information expressions (It's a little complicated because you have to take your current planet's solar position, add your craft position, and then subtract that from the target planet's solar position). So I am also still unclear on what you are looking for.
One quick hint for you though: Aerospikes have the least delta between their atmospheric performance and their vacuum performance. However they are also have worse TWR and max thrust compare to other nozzle types. So you have to decide if the stable performance characteristics are worth the power limitations. That said if I were designing an SSTO, and I weren't concerned about realism, I'd probably go with an Aerospike since we don't have to deal with some of the real world problems in SR2.
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.
This is definitely possible. To turn your rotator on and off without using an activation group you can use the set part [id] [Activated] to [1 or 0] craft instruction. To control your rotator's position you can set a variable in Vizzy, and then link your rotators input to be that variable. To do this you select the rotator, go to the "Rotator Input" section of the Part Properties panel, select the text in the "Input" field and type "TheNameOfYourCommandPod.FlightProgram.VaraibleName". The Variable in question should store a numeric value between 1 and -1. This was announced here and I believe it is now in the latest stable release.
I don't think you can change your account name. However you can set your avatar via gravatar.com. You will also find a link for this by expanding the menu by clicking your user name, select "View Profile," then use the blue "Account Settings" button and select "Manage Account."
Also, consider joining this discord where you can easily share screen shots and video, and you will sometimes get a quicker response in the #help channel than you might get here on the forum (although both are good resources).
You're going to need to provided a little more information. Can you upload and share your craft? Or at a minimum post a screenshot of the staging editor with all the stages expanded?
I'm assuming you are aware that you need to throttle up separately from/in addition to activating the stage including your engines.
See this post. Be aware that this is still really just a preview of how a planet will work and all editing is done via XML files. This functionality is still in a very nascent/experimental state. Documentation is non-existent as far as I'm aware and what folks have achieved for projects like ESS and RSS is a testament to the authors' industriousness and drive to figure things out by experimentation.
Keep an I out for announcements from the devs here and in future release notes, because a more full featured planet editor is on the roadmap.
I'm not sure what the Id is for gimbal (which is what the tilt of an engine used for steering is generally called). I got "Throttle" by guessing and testing.
Hmm, tagging the devs might be a little presumptuous.
You can add an InputController element to an engine. The critical thing is that the inputId attribute be "Throttle". The input attribute can be whatever input you like, or a variable reference. Here is a simple example using Slider 2:
As far as I'm aware this isn't possible right now. You can only target crafts or planets with Vizzy, and this is done by name (and it would appear that if there are multiple craft with the same name in flight only the oldest one is targetable with Vizzy). This area is ripe for suggestions, such as the ability to list all craft in flight, have a way to refer to each craft in flight by some unique id, have a way to get information about another craft in flight without actually targeting it, and as you are trying to do, target a specific part by craft id + part number or part name.
There is no one command that will abort any running program. The correct way to abort will depend on how your program is structured. You will need to break out of any running loops or wait until instructions, including those in event receivers, and stop execution from continuing after those instructions exit. One thing to note is that the break instruction can be used both to exit a while loop, and to exit a thread (a series of instructions connected to either a start block or a receive block). This can prevent you from having to have many nested if blocks if you have threads that have multiple successive loops. Without seeing your actual program it's hard to say how much of this you will have to worry about.
There are also multiple ways to provide input to your program, but as @PointBreak points out, activation groups are a good one.
Also, FYI, I investigated the possibility of simply deactivating the command pod that contains the running program, but unfortunately Flight Programs continue to run on command pods that are deactivated! I think it would be a good suggestion for a Flight Program to terminate when a command pod is deactivated, and when it is reactivated the Flight Program should "reboot" as if the craft just launched.
Nice work on the video series, I'm sure these will be helpful to the community. I suggest you consider giving voice over commentary a try. I know from my own experience making a video that this is really challenging, so I completely understand why there is an advantage to producing videos without them. A good voice over requires developing a script, adjusting timing, rehearsing, and doing extra takes. However the benefits are that your videos will be more engaging and accessible.
No matter what you decide regarding voice over, this is still great content. Thank you for producing it.
I haven't made a lot of planes by my SSTO does sometimes yaw a little bit, but that's what vertical control surfaces are for (i.e. rudders). I'm not sure what causes this, I don't think SR2 simulates wind, so could be something to do with torque of spinning engines (if you're using jets) and gyros. Or I suppose it could theoretically be some sort of Coriolis effect due to the rotation of the planet. And I'm obviously assuming your plane is perfectly symmetrical.
I think the developers want to avoid the risk of people uploading inappropriate content. If there is a specific part of the application you want to be able to take screen shots of that you cannot then you should make a suggestion, or upvote an existing one. For example if you want to take screenshots of Vizzy, I have posted this suggestion.
@Kishore0115 you should be able to edit your original post and anywhere there is an underscore _ replace it with backslash underscore \_. Also if you want to make a hyperlink place your link text inside square brackets, and the url inside parenthesis, example [visible text](http://url/). You should not need to escape (I.e. Put backslash in front of) underscores in a url for a link using the square bracket/parent syntax
@AndrewGarrison can you help me out? The only way I can make the vector math work is if the Position vectors are actually reversed (vectors from the craft toward the center of the planet instead of the other way around). For example North ⨯ norm(position) should be equal to East should it not? But in reality it is -1 * East. I'm using version 0.9.300.5 FWIW. It is entirely possible that I'm doing something stupid, in which case I apologize for bothering you (checks to see if he's been using the correct hand when applying the right hand rule).
instead of using the cross product of the North and East vectors, just normalize your position vector, that will always point "up" with respect to the planet.
It looks like you have an understanding of PCI coordinates so I won't belabor that. Instead I'll walk through the steps you're taking here one by one.
First, the East Vector returned by the Nav [East] craft information expression, will be a unit vector oscillating from (1, 0, 0) to (0, 0, 1) to (-1, 0, 0) to (0, 0, -1) as the planet rotates, or as you move around the planet heading east.
Next we have the North Vector from Nav [North]. At the equator this vector is very simple: (0, 1, 0) as you move away from the equator it gets more complicated because it will remain tangential to the surface of the planet, so lets just stick with the scenario where we are at the equator (which is where the Launch Pad is and that is where I presume your craft is).
Next you're taking the cross product of these two vectors, which you clearly are aware returns a vector perpendicular to both the input vectors. However, there are two such vectors, one pointing up relative to the plane represented by the input vectors, and one pointing down. Which one you get will depend on the order you put the vectors in. According to the right and rule (with your pointer finger in the direction of the first vector, palm facing the direction of the second vector, your thumb should point in the direction of the cross product), it seems to me that your expectation should be correct. So now I'm going to look at the actual math.
Give this arbitrary East vector I get when I launch: (0.115, 0, -0.993), if I calculate the cross product with North (0, 1, 0) after simplification thanks the the zeros: (vec [0 - aᶻ], [0], [aˣ]), I get (0.993, 0, 0.115). If I graph these three vectors using https://academo.org/demos/3d-vector-plotter/ they do indeed match the right hand rule, however when I compare this vector to my normalized position vector it is opposite: `(-0.993, 0, -0.155). So I am quite confused by this.
For the moment one quick fix is to reverse the order of North and East in the cross product expression. Another quick fix is instead of using the cross product of the North and East vectors, just normalize your position vector, that will always point up with respect to the planet. I'm still doing a little more investigation to figure out why this is happening, I'll let you know if I figure it out.
I'm not aware of a specific guide to various transfers, however, conceptually it's fairly simple. To do a fuel efficient transfer (ignoring gravity assists which are much more complicated), you are basically going to be doing a Hohmann transfer to get you from one planet to another. TLDR; A Hohmann transfer means doing a burn to go from an initial (generally circular) orbit to an elliptical orbit having one apsis touching the initial orbit and the other apsis touching the target orbit, and then do another burn at the opposite apsis to change from that elliptical orbit to the target circular orbit. Interplanetary Hohmann transfers are a little bit more complicated than a Hohmann transfer because 1) you have to time your burn to arrive at the target orbit at the right time to have a rendezvous, and 2) you have to deal with exiting your current sphere of influence (which basically means making your initial burn at the appropriate point in your current orbit). There is a really good video about this by Scott Manley. He is using Kerbal Space Program but many of the concepts are transferable. If you want to see it done in SR2, here is a slightly less awesome tutorial (<-- not Scott Manley, but still many kudos to folks making these SR2 tutorial videos 👍).
I just use Google with the site:simplerockets.com/Forums keyword. Seems to work reasonably well. Google updates their index more frequently and seems to have better precision. For example I was able to find this exact post by searching for site:simplerockets.com/Forums "search inside".
I have encountered this only in cases where I manually edited the XML file for a saved Flight Program and then tried to load it. I have usually been able to recover such programs with more XML editing, but in some cases I've never been able to get the original Flight Program to load again.
So as far as the cause in your case I'm not sure. If you are able to share the xml file for a flight program you are having trouble loading I would be willing to see if I can recover it for you.
@ManBearPig0 honestly it's been a while, but I think I just did a search for "PCI Coordinates" and the ECI wikipedia page was the first result. After reading that I verified how the PCI system works in the game experimentally, I've written a bunch of Vizzy programs that make heavy use of PCI coordinates so I'm confident that this is how it works.
As for non-visual ways of programming. As of right now: no there is no practical way. Technically flight programs are stored as XML files (or parts of Craft XML) in your com.jundroo.SimpleRockets2/UserData folder (exact location depends on OS), however hand editing this XML is not really practical, and while it can be used to share code, it is generally easier to save the code to a craft and share the craft on this site.
I am interested in creating a mod that allows flight programs to be modified as a normal text based programing language with the ability to both compile to Vizzy XML. I haven't decided on the structure of the language. I'm tempted to do either a simplified common lisp, possible with type annotations (à la Typed Racket) or something based on Linden Scripting Language.
Some of the requirements I've been thinking of:
Define/import modules
Module definitions are shared across all craft.
Modules are versioned on save so that changes don't break existing Flight Programs.
Modules contain custom expressions, custom instructions, and event handlers.
Variables defined within modules should be module scoped not global.
Event handlers are still global, so choose broadcast strings wisely.
Expressions, instructions and variables should only be accessible from other files if exported. (Think ES6 modules).
In game text editor, with multiple tabs for editing modules.
Import/export helper for loading Flight Program and its dependencies from a folder to make external editing easy.
Syntax for defining event handlers should be simple and declarative.
I would be interested to know what the community's thoughts are on language features. Personally I love lisps, but I think the community might be more comfortable with something that looked like javascript or python (hence LSL). I also love type checking, but it does add more syntax that people would have to learn. I would definitely like the language to be a close derivative of something so I can easily point to existing documentation. I also want it to be easy to parse and compile (another reason to go with some type of lisp).
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.
+1 5.0 years agoAlso I hope you upload this craft at some point. It could be a great way to deploy your favorite off-road vehicle to remote parts of Droo.
5.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 5.0 years agoI think the answer to this is yes. There are hints at career/campaign mode in the game (like tracking the cost of rockets), and right in the description on Steam you've got: "We're bringing it to Early Access while we work on a Planet Builder, Campaign Mode, and other key features." Speaking of which, I don't know about the verbiage on other app stores, but I wouldn't say SimpleRockets 2 has been released for 2 years, it was in beta for some of that time, and even now it is "Early Access." The version number is still 0.9xxx, when that rolls over to 1.0 the game should be considered "released." Sorry if I sound defensive, I just think this game is amazing and super fun as it exists today. In my mind the "goals" are: learn about the physics of rockets, aerodynamic flight, and orbital mechanics/maneuvers; recreate historic, current, and future vehicles and missions from real world spaceflight; create complex and ingenious automation for craft maneuvers and functionality; build amazing, intricate, and beautiful vehicles (space worthy or planet bound) that are either strikingly true to their real life inspirations, or stunningly creative and fanciful.
That said, will campaign mode be a welcome addition, absolutely.
+12 5.0 years agoWell, I'm sorry to say I failed to thoroughly research this before asking, and it turns out there is an wikipedia article describing how a sphere of influence is defined. I did however discover through investigation that SR2 tacks on an extra 5% when checking for exit of an SOI. So the equation for the radius of an SOI is:
r_soi = sma * (mass / mass_parent) ^ 0.4
And the equation for the SOI when checking for the exit of an SOI is:
5.0 years agor_exit_soi = 1.05 * r_soi
The going theory, thanks to @pedro16797, is that SOI is based on the distance at which the acceleration due to gravity from the parent body becomes greater than the acceleration due to gravity from the body whose SOI we are trying to determine. I'm assuming at this point that we're talking about the point where the two accelerations are in opposite directions (i.e. the point in between the two bodies). I'll try to verify this experimentally and report back.
5.0 years agoI presume you are talking about "Burn Nodes." These are similar to "Maneuver Nodes" in Kerbal Space Program. Unfortunately the built in tutorials only cover the basics. However, you can check out this player produced tutorial, or this brief description from the blog, for more information.
5.0 years agoI'm having trouble understanding your question. The gyroscope exerts rotational force based on the control inputs
5.0 years agopitch,yaw, androll. I'm not sure it is possible to use anInputControllerwith a gyroscope but if it is you would need to edit the XML, and I imagine you could map whatever inputs you wanted to thepitch,roll, andyawinput ids.Kudos to the dev team for making that magically work. It was just a stab in the dark but I was thrilled to see it work (and I verified the behavior for different numeric values).
+2 5.0 years agoUsing
+3 5.0 years ago1or1.0as the "Input" property makes the input value a fixed number instead of reading the current value of a slider, attribute, or variable. If you used0.5the piston would be half extended any time it was activated.You can achieve this by setting the
Inputproperty of your piston to the numeric value1.0, theActivation Groupproperty to your desired AG, and enabling the "Zero On Deactivate" property. All under the Piston Input section of the part properties.If you don't see some of these properties you need to do the following: In the part settings for your piston, enable "Show Hidden Properties" in the Tinker Panel, you will then see a number of new options under the Piston Input section.
+4 5.0 years agoOnce a part of your craft becomes disconnected, either via an interstage, a docking port, or an explosion, it is considered a separate craft. It is not currently possible for a vizzy program on one craft to get position information about specific parts on another unless the player specifically targets that part. A vizzy program can set the target, but only be planet or craft name.
Additionally, guided air to air missiles are going to be difficult if not impossible owing to all the limitations of vizzy programs on crafts the player doesn't currently control. These limitations are especially problematic inside the atmosphere, where this really go badly once the craft in question is over 1km from the player controlled craft.
5.0 years agoWell don't I feel stupid 🤯. It does have some glitches I'll report in game (undo adding a new expression to an existing expression slot is weird, leaves the expression in the slot and a copy not in the slot; redo sometimes causes an un-delete-able value floating next to the expression to which something was added). Also if somebody makes a suggestion to add buttons to the same location as they are in the editor I will up vote that as well.
5.0 years agoYou should create a new suggestion, share a link here and I will happily upvote. I have occasionally mess up a program by dropping an expression in the wrong slot and it would be nice to be able to undo that.
5.0 years agoCheck out this tutorial.
+1 5.0 years agoI'm glad you found a solution that works for you. Multiple command chips/pods is pretty clever.
5.0 years agoI'm glad you found a solution that works for you. Multiple command chips/pods is pretty clever.
5.0 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 5.0 years agoI think you answered your own question. SSTOs and space planes are hard because engine effectiveness varies with altitude and you end up toting a lot of excess weight with you into orbit. I've made an SSTO space plane that used a mix of jets and aerospike engines. It get's to low Droo orbit, but it doesn't have enough delta V left to get to the moon. I'm pretty sure this would be extremely difficult without excessive use of the tinker panel. That said, I think it would be possible to design a pure rocket based SSTO with the ~6500 m/s of delta-v needed to get to Luna. Getting home again is another story.
5.0 years agoYou can use vizzy to detect when you enter the sphere of influence of a specific planet although you have to use
+2 5.0 years agoon enter [planet] SOIevent rather than just await until [condition]instruction. You can also determine your distance to the planet using a combination of theplanet [name] [Solar Position]andnav [Position]craft information expressions (It's a little complicated because you have to take your current planet's solar position, add your craft position, and then subtract that from the target planet's solar position). So I am also still unclear on what you are looking for.One quick hint for you though: Aerospikes have the least delta between their atmospheric performance and their vacuum performance. However they are also have worse TWR and max thrust compare to other nozzle types. So you have to decide if the stable performance characteristics are worth the power limitations. That said if I were designing an SSTO, and I weren't concerned about realism, I'd probably go with an Aerospike since we don't have to deal with some of the real world problems in SR2.
5.0 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 5.0 years agoThis is definitely possible. To turn your rotator on and off without using an activation group you can use the
+2 5.0 years agoset part [id] [Activated] to [1 or 0]craft instruction. To control your rotator's position you can set a variable in Vizzy, and then link your rotators input to be that variable. To do this you select the rotator, go to the "Rotator Input" section of the Part Properties panel, select the text in the "Input" field and type "TheNameOfYourCommandPod.FlightProgram.VaraibleName". The Variable in question should store a numeric value between 1 and -1. This was announced here and I believe it is now in the latest stable release.I don't think you can change your account name. However you can set your avatar via gravatar.com. You will also find a link for this by expanding the menu by clicking your user name, select "View Profile," then use the blue "Account Settings" button and select "Manage Account."
+1 5.0 years agoAlso, consider joining this discord where you can easily share screen shots and video, and you will sometimes get a quicker response in the #help channel than you might get here on the forum (although both are good resources).
+1 5.1 years agoYou're going to need to provided a little more information. Can you upload and share your craft? Or at a minimum post a screenshot of the staging editor with all the stages expanded?
5.1 years agoI'm assuming you are aware that you need to throttle up separately from/in addition to activating the stage including your engines.
See this post. Be aware that this is still really just a preview of how a planet will work and all editing is done via XML files. This functionality is still in a very nascent/experimental state. Documentation is non-existent as far as I'm aware and what folks have achieved for projects like ESS and RSS is a testament to the authors' industriousness and drive to figure things out by experimentation.
Keep an I out for announcements from the devs here and in future release notes, because a more full featured planet editor is on the roadmap.
+2 5.1 years agoWhy not join SimpleRockets Chat?
+2 5.1 years agoI'm not sure what the Id is for gimbal (which is what the tilt of an engine used for steering is generally called). I got "Throttle" by guessing and testing.
5.1 years agoHmm, tagging the devs might be a little presumptuous.
You can add an
5.1 years agoInputControllerelement to an engine. The critical thing is that theinputIdattribute be "Throttle". Theinputattribute can be whatever input you like, or a variable reference. Here is a simple example using Slider 2:As far as I'm aware this isn't possible right now. You can only target crafts or planets with Vizzy, and this is done by name (and it would appear that if there are multiple craft with the same name in flight only the oldest one is targetable with Vizzy). This area is ripe for suggestions, such as the ability to list all craft in flight, have a way to refer to each craft in flight by some unique id, have a way to get information about another craft in flight without actually targeting it, and as you are trying to do, target a specific part by craft id + part number or part name.
+4 5.1 years agoHere is a tutorial video on this topic.
5.1 years agoInstead of "pasting" (which is normally done with
5.1 years agoCommand+Von a mac) actually hitCtrl+Vwhich is the keypress SR2 is looking for.There is no one command that will abort any running program. The correct way to abort will depend on how your program is structured. You will need to break out of any running loops or
wait untilinstructions, including those in event receivers, and stop execution from continuing after those instructions exit. One thing to note is that thebreakinstruction can be used both to exit a while loop, and to exit a thread (a series of instructions connected to either astartblock or areceiveblock). This can prevent you from having to have many nestedifblocks if you have threads that have multiple successive loops. Without seeing your actual program it's hard to say how much of this you will have to worry about.There are also multiple ways to provide input to your program, but as @PointBreak points out, activation groups are a good one.
Also, FYI, I investigated the possibility of simply deactivating the command pod that contains the running program, but unfortunately Flight Programs continue to run on command pods that are deactivated! I think it would be a good suggestion for a Flight Program to terminate when a command pod is deactivated, and when it is reactivated the Flight Program should "reboot" as if the craft just launched.
Update: suggestion added: https://www.simplerockets.com/Feedback/View/yiIo3i/Flight-programs-should-terminate-when-the-command-pod-or-command-chip-they-are-ru
5.1 years agoNice work on the video series, I'm sure these will be helpful to the community. I suggest you consider giving voice over commentary a try. I know from my own experience making a video that this is really challenging, so I completely understand why there is an advantage to producing videos without them. A good voice over requires developing a script, adjusting timing, rehearsing, and doing extra takes. However the benefits are that your videos will be more engaging and accessible.
No matter what you decide regarding voice over, this is still great content. Thank you for producing it.
5.1 years agoI haven't made a lot of planes by my SSTO does sometimes yaw a little bit, but that's what vertical control surfaces are for (i.e. rudders). I'm not sure what causes this, I don't think SR2 simulates wind, so could be something to do with torque of spinning engines (if you're using jets) and gyros. Or I suppose it could theoretically be some sort of Coriolis effect due to the rotation of the planet. And I'm obviously assuming your plane is perfectly symmetrical.
5.1 years agoPost this in the "Suggestions" section, share a link here, I will so totally give it an upvote.
5.1 years ago@AndrewGarrison well that explains it then. Thanks.
5.1 years agoI think the developers want to avoid the risk of people uploading inappropriate content. If there is a specific part of the application you want to be able to take screen shots of that you cannot then you should make a suggestion, or upvote an existing one. For example if you want to take screenshots of Vizzy, I have posted this suggestion.
🙈🙊
5.1 years ago@Kishore0115 you should be able to edit your original post and anywhere there is an underscore _ replace it with backslash underscore \_. Also if you want to make a hyperlink place your link text inside square brackets, and the url inside parenthesis, example [visible text](http://url/). You should not need to escape (I.e. Put backslash in front of) underscores in a url for a link using the square bracket/parent syntax
5.1 years agoI think that link is broken because it contains underscores which the formatter is turning into italics. Try this link instead: https://www.youtube.com/channel/UCp1VIWnTIAu_OwuyBb_5K3g
5.1 years ago@AndrewGarrison can you help me out? The only way I can make the vector math work is if the Position vectors are actually reversed (vectors from the craft toward the center of the planet instead of the other way around). For example
5.1 years agoNorth ⨯ norm(position)should be equal to East should it not? But in reality it is-1 * East. I'm using version 0.9.300.5 FWIW. It is entirely possible that I'm doing something stupid, in which case I apologize for bothering you (checks to see if he's been using the correct hand when applying the right hand rule).TLDR:
It looks like you have an understanding of PCI coordinates so I won't belabor that. Instead I'll walk through the steps you're taking here one by one.
First, the East Vector returned by the
Nav [East]craft information expression, will be a unit vector oscillating from(1, 0, 0)to(0, 0, 1)to(-1, 0, 0)to(0, 0, -1)as the planet rotates, or as you move around the planet heading east.Next we have the North Vector from
Nav [North]. At the equator this vector is very simple:(0, 1, 0)as you move away from the equator it gets more complicated because it will remain tangential to the surface of the planet, so lets just stick with the scenario where we are at the equator (which is where the Launch Pad is and that is where I presume your craft is).Next you're taking the cross product of these two vectors, which you clearly are aware returns a vector perpendicular to both the input vectors. However, there are two such vectors, one pointing up relative to the plane represented by the input vectors, and one pointing down. Which one you get will depend on the order you put the vectors in. According to the right and rule (with your pointer finger in the direction of the first vector, palm facing the direction of the second vector, your thumb should point in the direction of the cross product), it seems to me that your expectation should be correct. So now I'm going to look at the actual math.
[a] cross [b] = vec [aʸ * bᶻ - aᶻ * bʸ], [aᶻ * bˣ - aˣ * bᶻ], [aˣ * bʸ - aʸ * bˣ]Give this arbitrary East vector I get when I launch:
(0.115, 0, -0.993), if I calculate the cross product with North(0, 1, 0)after simplification thanks the the zeros: (vec [0 - aᶻ], [0], [aˣ]), I get(0.993, 0, 0.115). If I graph these three vectors using https://academo.org/demos/3d-vector-plotter/ they do indeed match the right hand rule, however when I compare this vector to my normalized position vector it is opposite: `(-0.993, 0, -0.155). So I am quite confused by this.For the moment one quick fix is to reverse the order of North and East in the cross product expression. Another quick fix is instead of using the cross product of the North and East vectors, just normalize your position vector, that will always point up with respect to the planet. I'm still doing a little more investigation to figure out why this is happening, I'll let you know if I figure it out.
+2 5.1 years agoAlso, it's not a guide per se, but one of the brilliant minds here created this excellent diagram of delta-v requirements for different transfers.
+1 5.1 years agoI'm not aware of a specific guide to various transfers, however, conceptually it's fairly simple. To do a fuel efficient transfer (ignoring gravity assists which are much more complicated), you are basically going to be doing a Hohmann transfer to get you from one planet to another. TLDR; A Hohmann transfer means doing a burn to go from an initial (generally circular) orbit to an elliptical orbit having one apsis touching the initial orbit and the other apsis touching the target orbit, and then do another burn at the opposite apsis to change from that elliptical orbit to the target circular orbit. Interplanetary Hohmann transfers are a little bit more complicated than a Hohmann transfer because 1) you have to time your burn to arrive at the target orbit at the right time to have a rendezvous, and 2) you have to deal with exiting your current sphere of influence (which basically means making your initial burn at the appropriate point in your current orbit). There is a really good video about this by Scott Manley. He is using Kerbal Space Program but many of the concepts are transferable. If you want to see it done in SR2, here is a slightly less awesome tutorial (<-- not Scott Manley, but still many kudos to folks making these SR2 tutorial videos 👍).
There's also lot more to be found about Hohmann transfers and interplanetary maneuvers on the web, for example: https://ai-solutions.com/freeflyeruniversityguide/interplanetaryhohmann_transfe.htm#calculatinganinterplanetaryhohmanntransfer
+1 5.1 years agoI just use Google with the
+1 5.1 years agosite:simplerockets.com/Forumskeyword. Seems to work reasonably well. Google updates their index more frequently and seems to have better precision. For example I was able to find this exact post by searching for site:simplerockets.com/Forums "search inside".I have encountered this only in cases where I manually edited the XML file for a saved Flight Program and then tried to load it. I have usually been able to recover such programs with more XML editing, but in some cases I've never been able to get the original Flight Program to load again.
So as far as the cause in your case I'm not sure. If you are able to share the xml file for a flight program you are having trouble loading I would be willing to see if I can recover it for you.
Edit: never mind, I see you found your problem.
+1 5.1 years ago@ManBearPig0 honestly it's been a while, but I think I just did a search for "PCI Coordinates" and the ECI wikipedia page was the first result. After reading that I verified how the PCI system works in the game experimentally, I've written a bunch of Vizzy programs that make heavy use of PCI coordinates so I'm confident that this is how it works.
+1 5.1 years agoAs for non-visual ways of programming. As of right now: no there is no practical way. Technically flight programs are stored as XML files (or parts of Craft XML) in your
com.jundroo.SimpleRockets2/UserDatafolder (exact location depends on OS), however hand editing this XML is not really practical, and while it can be used to share code, it is generally easier to save the code to a craft and share the craft on this site.I am interested in creating a mod that allows flight programs to be modified as a normal text based programing language with the ability to both compile to Vizzy XML. I haven't decided on the structure of the language. I'm tempted to do either a simplified common lisp, possible with type annotations (à la Typed Racket) or something based on Linden Scripting Language.
Some of the requirements I've been thinking of:
I would be interested to know what the community's thoughts are on language features. Personally I love lisps, but I think the community might be more comfortable with something that looked like javascript or python (hence LSL). I also love type checking, but it does add more syntax that people would have to learn. I would definitely like the language to be a close derivative of something so I can easily point to existing documentation. I also want it to be easy to parse and compile (another reason to go with some type of lisp).
5.1 years agoRegarding searching the forums, yes, they are unfortunately difficult to search on the site. However Google does a pretty good job: https://www.google.com/search?q=site%3Asimplerockets.com%2FForums+vizzy&oq=site%3Asimplerockets.com%2FForums+vizzy
+2 5.1 years ago