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.
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.
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.
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.
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.
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.
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:
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).
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).
Hmm, I'm not sure how you would get the rotation flipped, or why that would keep you from attaching a side interstage to a fuel tank. However, if you want to reset the rotation to zero you can use the Rotate Parts Tool.
Also, if you get into a bad state in the tutorial, you can just have it jump to where it want's you to be by clicking the revert button.
If you have a list of craft names you can loop through the list, set them as target, and check the distance to target in order to get a list of nearby craft. You could add new craft to that list whenever the player manually sets the target to something new. There is no way to automatically detect new craft that you don't know the name of.
I'm not sure why you would need to muck with the XML unless you are trying to modify a running program in an active craft, which I suppose would be doable if you prefer stopping the game and modifying XML as a way to add new craft to your list.
What altitude and pitch angle are you developing stability problems at? Are you using a rocket orientation craft or a plane orientation craft?
At lower altitudes, stability problems can be addressed with proper aerodynamics. If you tilt your wings slightly upward then the craft will naturally tend toward level roll. However, as you increase altitude and pitch angle aerodynamics stop working for this purpose. In my SSTO experiments I've had limited roll stability issues later in the flight (altitudes over 20km and pitch angle over 45 degrees), but they were slight enough to safely ignore (I was still able to rely on the autopilot to achieve the desired pitch and heading).
Also, are you using auto pilot to lock heading and pitch (either to explicit orientation or prograde)? If so, and if you are using rocket orientation, then you have some inherent stability or control issues with your craft design. The autopilot is designed to null out any roll rate. It could be that adjusting gyro power, or weight distribution, or autopilot settings solves your problem without resorting to Vizzy.
In a significantly more trivial case I've been able to use Vizzy to set the Roll input based the current and desired orientation (I used the current pitch axis versus a desired pitch axis to determine the amount of change in role required), and the current angular velocity around the roll axis. However there are challenges if you are trying to do this and use autopilot. Here is an example craft with such a flight program.
Rotators don't have a minimum and a maximum, just a maximum. The maximum is set using the "Range" property in the part properties panel. They start at zero, and can go to there maximum range in the positive direction, or their maximum range in the negative direction. If you want to use a rotator to take something from a minimum angle of 20 degrees from vertical to a maximum angle of 40 degrees from vertical then you would need to set the rotator's range to 10 degrees and then set its rotation to 30 degrees from vertical. That way when the rotator's input is -1.0 it will be at 20 degrees from vertical and when the rotator's input is 1.0 it will be at 40 degrees from vertical.
If by code you're looking for this setting in Xml it is the range attribute of the JointRotator element which is a child of Part element for rotators and hinge rotators.
If by code you mean you want to change this from Vizzy, I don't think you can set the range for a rotator from Vizzy, you can only set the input value.
The join expression preserves spaces, so if the first slot contains "Throttle is set to " including a trailing space you should get your desired result. Perhaps there is something about the Android version that is preventing you from adding trailing whitespace.
I highly recommend you check out the format expression. It uses a .Net format string to interpolate a number of expressions into a string and gives you fine grain control of how each expression is displayed, for example you can adjust how many decimal places are displayed or whether thousands separators are used. You can even use it to change a fraction to a percentage. For example format (Throttle is set to {0:p}.) (input (Throttle)) would return the string you're looking for.
I shudder to think why you need this, however it is quite trivial to do, so here you go. The tinker panel only lets you take part scale up to 500% which doesn't quite do the trick. I found that a scale of 1100% works (assuming you want the gimbal struts to be the thing that measures at a diameter of 11.6 meters. If you wanted the bell or some other part of the engine to fit within that diameter you'd have to adjust it. The XML change is very easy:
<Config partScale="11,11,11" />
This element is a child of the <Part> element. partScale is a vector with the scale factor in each direction (to convert to % multiply by 100).
If you aren't familiar with XML and how to edit it, it is very easy to learn and there are lots of resources on the web. Given the day and age we live in it will be worth your time to learn.
It takes a little while to get to the point because it covers a little bit of rocket building, but this does a great job of explaining the practical considerations of rendezvous and docking.
It is not currently possible to create burn nodes with Vizzy. However, it is definitely possible to calculate parameters for a burn and execute it with Vizzy, it just takes some doing. For example the flight program in this rocket includes logic to plane a burn to take a rocket from an elliptical orbit to a circular orbit by making a prograde burn at apoapsis. It should be possible to generalize the concepts in that flight program to make a variety of transfer burns from apoapsis or periapsis. If the fight program in that rocket is confusing I'm working on a video to demystify it. You can also find the appropriate timing for your burn using the math here.
For a simpler flight program that only calculates orientation for a burn around apoapsis, and not delta-v for a burn see this craft.
Do yo mean email notification settings for this site? If so click your username in the top right, then "view profile", then "account settings" (blue button , top right), then "manage account." From there it looks like you can change your email, your forum notification settings, and your marketing email settings.
I'm trying to sort out what you are trying to accomplish. If you want a vector that represents your ships orientation relative to the surface you can take a normalized vector pointing north (say (0, 1, 0) where x is E/W, y is N/S and z is Up/Down), rotate around the Up vector (0, 0, 1) by your craft's heading (we'll call this your orientation vector), then create a pitch axis by rotating the East vector (1, 0, 0) around the Up vector by your heading, then rotate your orientation vector around your pitch axis by your pitch. If you have a craft sitting on the surface this vector should be constant so long as your craft isn't changing it's orientation relative to the surface. As your craft changes heading and pitch this vector should track it.
In order to rotate a vector around another vector by a number of degrees you'll need to do some math, but if you look at my submission to your Vizzy contest you'll find custom expressions to perform this operation.
Note: betas are meant to allow experienced users to tested new and experimental functionality. That means it should not surprise you if there are bugs, glitches, or some lack of polish. If you encounter bugs while playing you should report them using the in-game bug reporting capabilities, after checking the website to see if it has already been reported. If you have suggestions you should make them in the Feedback section of the site: https://www.simplerockets.com/Feedback. Here is more information about beta testing.
@Insanity ah good point, see comments on this post for more about launching and using PlanetStudio. And of course in some future release we should be getting Planet Builder a more full featured UI for editing solar systems.
As far as #2 saved flight programs are just XML files in your UserData\FlightPrograms folder. So you can copy the XML and share them via forum posts if you like.
On a Mac this folder can be found at: ~/Library/Application Support/com.jundroo.SimpleRockets2/UserData/FlightPrograms
On a PC I believe this folder can be found at: C:\Users\YourUsernameHere\AppData\LocalLow\Jundroo\SimpleRockets 2\UserData\FlightPrograms
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.Screenshots:
Planet Studio
Share Planet Dialog
4.6 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.
4.6 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:
4.6 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.
4.6 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.
4.6 years agoI'm having trouble understanding your question. The gyroscope exerts rotational force based on the control inputs
4.6 years agopitch
,yaw
, androll
. I'm not sure it is possible to use anInputController
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 thepitch
,roll
, andyaw
input ids.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.
4.6 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.
4.6 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.
4.6 years agoI'm glad you found a solution that works for you. Multiple command chips/pods is pretty clever.
4.6 years agoI'm glad you found a solution that works for you. Multiple command chips/pods is pretty clever.
4.6 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.
4.6 years agoOne 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.
4.6 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?
4.6 years agoI'm assuming you are aware that you need to throttle up separately from/in addition to activating the stage including your engines.
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.
4.6 years agoHmm, tagging the devs might be a little presumptuous.
You can add an
4.6 years agoInputController
element to an engine. The critical thing is that theinputId
attribute be "Throttle". Theinput
attribute can be whatever input you like, or a variable reference. Here is a simple example using Slider 2:Here is a tutorial video on this topic.
4.6 years agoInstead of "pasting" (which is normally done with
4.6 years agoCommand+V
on a mac) actually hitCtrl+V
which 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 until
instructions, including those in event receivers, and stop execution from continuing after those instructions exit. One thing to note is that thebreak
instruction can be used both to exit a while loop, and to exit a thread (a series of instructions connected to either astart
block or areceive
block). This can prevent you from having to have many nestedif
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.
Update: suggestion added: https://www.simplerockets.com/Feedback/View/yiIo3i/Flight-programs-should-terminate-when-the-command-pod-or-command-chip-they-are-ru
4.7 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.
4.7 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.
4.7 years agoPost this in the "Suggestions" section, share a link here, I will so totally give it an upvote.
4.7 years ago@AndrewGarrison well that explains it then. Thanks.
4.7 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.
🙈🙊
4.7 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
4.7 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
4.7 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
4.7 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).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:
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).
4.7 years agoHmm, I'm not sure how you would get the rotation flipped, or why that would keep you from attaching a side interstage to a fuel tank. However, if you want to reset the rotation to zero you can use the Rotate Parts Tool.
Also, if you get into a bad state in the tutorial, you can just have it jump to where it want's you to be by clicking the revert button.
4.7 years agoIf you have a list of craft names you can loop through the list, set them as target, and check the distance to target in order to get a list of nearby craft. You could add new craft to that list whenever the player manually sets the target to something new. There is no way to automatically detect new craft that you don't know the name of.
I'm not sure why you would need to muck with the XML unless you are trying to modify a running program in an active craft, which I suppose would be doable if you prefer stopping the game and modifying XML as a way to add new craft to your list.
4.7 years agoAs with many such questions, it would be a lot easier to diagnose problems and make suggestions if people would share their craft.
4.7 years agoWhat altitude and pitch angle are you developing stability problems at? Are you using a rocket orientation craft or a plane orientation craft?
At lower altitudes, stability problems can be addressed with proper aerodynamics. If you tilt your wings slightly upward then the craft will naturally tend toward level roll. However, as you increase altitude and pitch angle aerodynamics stop working for this purpose. In my SSTO experiments I've had limited roll stability issues later in the flight (altitudes over 20km and pitch angle over 45 degrees), but they were slight enough to safely ignore (I was still able to rely on the autopilot to achieve the desired pitch and heading).
Also, are you using auto pilot to lock heading and pitch (either to explicit orientation or prograde)? If so, and if you are using rocket orientation, then you have some inherent stability or control issues with your craft design. The autopilot is designed to null out any roll rate. It could be that adjusting gyro power, or weight distribution, or autopilot settings solves your problem without resorting to Vizzy.
In a significantly more trivial case I've been able to use Vizzy to set the Roll input based the current and desired orientation (I used the current pitch axis versus a desired pitch axis to determine the amount of change in role required), and the current angular velocity around the roll axis. However there are challenges if you are trying to do this and use autopilot. Here is an example craft with such a flight program.
4.7 years agoRotators don't have a minimum and a maximum, just a maximum. The maximum is set using the "Range" property in the part properties panel. They start at zero, and can go to there maximum range in the positive direction, or their maximum range in the negative direction. If you want to use a rotator to take something from a minimum angle of 20 degrees from vertical to a maximum angle of 40 degrees from vertical then you would need to set the rotator's range to 10 degrees and then set its rotation to 30 degrees from vertical. That way when the rotator's input is -1.0 it will be at 20 degrees from vertical and when the rotator's input is 1.0 it will be at 40 degrees from vertical.
If by code you're looking for this setting in Xml it is the
range
attribute of theJointRotator
element which is a child ofPart
element for rotators and hinge rotators.If by code you mean you want to change this from Vizzy, I don't think you can set the range for a rotator from Vizzy, you can only set the input value.
4.7 years agoThe
join
expression preserves spaces, so if the first slot contains "Throttle is set to " including a trailing space you should get your desired result. Perhaps there is something about the Android version that is preventing you from adding trailing whitespace.I highly recommend you check out the
4.7 years agoformat
expression. It uses a .Net format string to interpolate a number of expressions into a string and gives you fine grain control of how each expression is displayed, for example you can adjust how many decimal places are displayed or whether thousands separators are used. You can even use it to change a fraction to a percentage. For exampleformat (Throttle is set to {0:p}.) (input (Throttle))
would return the string you're looking for.I shudder to think why you need this, however it is quite trivial to do, so here you go. The tinker panel only lets you take part scale up to 500% which doesn't quite do the trick. I found that a scale of 1100% works (assuming you want the gimbal struts to be the thing that measures at a diameter of 11.6 meters. If you wanted the bell or some other part of the engine to fit within that diameter you'd have to adjust it. The XML change is very easy:
This element is a child of the <Part> element.
partScale
is a vector with the scale factor in each direction (to convert to % multiply by 100).If you aren't familiar with XML and how to edit it, it is very easy to learn and there are lots of resources on the web. Given the day and age we live in it will be worth your time to learn.
4.7 years agoYou should try watching this video.
It takes a little while to get to the point because it covers a little bit of rocket building, but this does a great job of explaining the practical considerations of rendezvous and docking.
4.7 years agoIf you set Luna as your target you can get its position in vizzy.
4.7 years agoIt is not currently possible to create burn nodes with Vizzy. However, it is definitely possible to calculate parameters for a burn and execute it with Vizzy, it just takes some doing. For example the flight program in this rocket includes logic to plane a burn to take a rocket from an elliptical orbit to a circular orbit by making a prograde burn at apoapsis. It should be possible to generalize the concepts in that flight program to make a variety of transfer burns from apoapsis or periapsis. If the fight program in that rocket is confusing I'm working on a video to demystify it. You can also find the appropriate timing for your burn using the math here.
For a simpler flight program that only calculates orientation for a burn around apoapsis, and not delta-v for a burn see this craft.
4.7 years ago@crowxe I've moved my comment to a separate post with some additions.
4.7 years agoDo yo mean email notification settings for this site? If so click your username in the top right, then "view profile", then "account settings" (blue button , top right), then "manage account." From there it looks like you can change your email, your forum notification settings, and your marketing email settings.
4.7 years agoI'm trying to sort out what you are trying to accomplish. If you want a vector that represents your ships orientation relative to the surface you can take a normalized vector pointing north (say (0, 1, 0) where x is E/W, y is N/S and z is Up/Down), rotate around the Up vector (0, 0, 1) by your craft's heading (we'll call this your orientation vector), then create a pitch axis by rotating the East vector (1, 0, 0) around the Up vector by your heading, then rotate your orientation vector around your pitch axis by your pitch. If you have a craft sitting on the surface this vector should be constant so long as your craft isn't changing it's orientation relative to the surface. As your craft changes heading and pitch this vector should track it.
In order to rotate a vector around another vector by a number of degrees you'll need to do some math, but if you look at my submission to your Vizzy contest you'll find custom expressions to perform this operation.
!rotate expression
!
How come my embedded screenshots never work :-(
![](http://www.paulwheeler.us/images/Vizzy%20Rotate%20Expression.png)
Disclaimer: Somebody smarter than me regarding vector math may have a simpler solution.
4.8 years agoCitation (for the math I'm using): Rodrigues rotation formula
Assuming it's the same as in Mac:
!Screenshot
Note: betas are meant to allow experienced users to tested new and experimental functionality. That means it should not surprise you if there are bugs, glitches, or some lack of polish. If you encounter bugs while playing you should report them using the in-game bug reporting capabilities, after checking the website to see if it has already been reported. If you have suggestions you should make them in the Feedback section of the site: https://www.simplerockets.com/Feedback. Here is more information about beta testing.
4.8 years ago@Insanity ah good point, see comments on this post for more about launching and using PlanetStudio. And of course in some future release we should be getting Planet Builder a more full featured UI for editing solar systems.
4.8 years agoAlso useful: T-F-G-H move the light source up-left-down-right respectively.
4.8 years agoFor anybody curious about what the heck I'm talking about below, here is an example of getting a rocket oriented correctly for a prograde burn around apoapsis: Calculate Orbital Parameters and Orient to Prograde at Apoapsis
4.8 years ago@Insanity should work now. Simplerockets.com is very wonky some times.
4.8 years agoI apologize for the poor code block formatting. This forum has a glitch in its markdown processing where it double escapes special characters.
4.8 years agoFor what it's worth posts and comments are basically just Markdown:
Comments don't seem to have full support because paragraphs get squished together (although this is just a CSS think, the resulting HTML is correct).
For example there is no space between this text and the previous line.
4.8 years agoAs far as #2 saved flight programs are just XML files in your UserData\FlightPrograms folder. So you can copy the XML and share them via forum posts if you like.
On a Mac this folder can be found at: ~/Library/Application Support/com.jundroo.SimpleRockets2/UserData/FlightPrograms
4.8 years agoOn a PC I believe this folder can be found at: C:\Users\YourUsernameHere\AppData\LocalLow\Jundroo\SimpleRockets 2\UserData\FlightPrograms
You should read this blog post: https://www.simplerockets.com/Blog/View/41007/Say-Hello-World-to-Vizzy it has a helpful video tutorial.
4.8 years ago