PCI stands for Planet Centered Inertial, and it is the similar/equivalent for Earth Centered Inertial except that it is based on the planet whose sphere of influence your craft is currently in rather than Earth specifically. The key concept of a Planet Centered Inertial coordinate system is that while it remains centered on the planet as the planet moves through space, it does not change orientation with respect to "fixed" points in space (i.e. distant stars). So as the planet rotates and moves in its orbit the unit vector (1, 0, 0) will always be pointed off in the same direction with respect to the rest of the universe. Because there is no axial tilt, and the Y axis represents up and down relative to the "celestial plane", (0, 1, 0) always points towards the north pole. You can observe the behavior of PCI coordinates by watching the position change as a craft moves in orbit. If the orbit as 0 degrees of inclination X and Z will continually change, but Y will remain basically constant. Using latitude and longitude can be easier to think about when moving relative to the surface of the planet, however, working with lat/long as a coordinate system is challenging mathematically because it is not a cartesian system (i.e. mapped to a flat plane), it is a spherical system, so the vector math doesn't work the same (see spherical coordinate system).
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.
@Oscarcarserud interesting idea. I think it is possible to communicate between multiple command pods/chips using the broadcast [message] with data [value] to craft instruction. However that only works when they are both in the same craft (where multiple things connected with docking ports count as one "craft").
So, unfortunately this doesn't help when we're talking about the limitations of non-controlled craft. If a craft isn't player controlled it has absolutely no way to sense other craft.
Did you know SimpleRockets2 is available free for education? Have you considered talking to a teacher or librarian about creating a program to teach people trigonometry or physics or computer programming using SimpleRockets 2?
@KraZIvan oops, sorry I failed at completely reading your post. I hope my Vizzy script is useful let me know if you have any questions. However it does seem like given the rocket auto pilot's default behavior it should be able to maintain stable roll. There must be something about your craft inducing the roll in the first place.
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.
I have updated the post with some new information about Flight Programs running on non-player-controlled craft within the atmosphere. Unfortunately the results are quite disheartening. Basically after the craft is more than 1km away from the player almost nothing works, your rocket becomes a ballistic lump of metal with no angular velocity and no flight controls.
I have reason to believe that things may be better in orbit, but I still need to do more testing.
I'm not sure if by "without using the sliders" you mean not involving them at all, or just not having to manually set them in the UI. If the former, follow AnotherFireFox's suggestion. However, if it is just the latter then the xml modification is unnecessary and you can just use the set [Slider 1] to [number] craft instruction.
@AnotherFireFox I have not reproduced this bug, I have been able to leave a vizzy program running that sets slider and roll inputs on a craft I'm not controlling. Is this a new bug? Link? Repro steps?
There is a lot to unpack here, but firstly, most vectors (velocity, position, etc) are in PCI coordinates (Planet Centered Inertial) which basically means that one plane of the coordinate system is lined up with the equator of the Planet whose sphere of influence you are in, and the third direction is up and down toward the poles. In SR2 PCI the "up/down" axis is Y, and X/Z represent the "celestial plane". so moving away from the planet will affect X or Z or both depending on where you are in your orbit around the planet. The X and Z axis remain fixed relative to distance stars, which means that a given point on the planet will change as the planet spins and a vector toward the sun will change as the planet moves in its orbit.
I touch briefly on many concepts regarding dealing with vectors, finding prograde (and therefore retrograde by extension) vectors, and converting from a vector to Heading/Pitch, in the video I recently shared and some of the Flight Program laden craft I have shared. However I don't have time or space to go into all of it here.
That said, the key concepts are sprinkled here and there and I think a focused tutorial on vectors in SR2 is in order. Now I have my next video project, I'll let you know when I post it.
What do you mean, "to numbers?" You have a vector, do you want its length? Its x, y, and z components? Do you mean you want to plot an intercept course in heading & pitch based on your position, your target's position, and your target's velocity?
If you want length or x/y/z components there is an expression that takes a vector and has a drop down that defaults to length, that's the one you want.
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.
FWIW I think my trig is correct, but there must be a practical consideration I'm missing, because experimentally the error is quite a bit lower. When I launched at a heading of 43 degrees I wound up with an inclination of 46.5, only 0.5 degrees off from what you would get if there were no adjustment due to rotation.
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.
What kind of distance are you talking about? If you're talking about being in a different orbit than the target or out of phase by more than a few kilometers than you should focus on learning and mastering orbital maneuvers.
Once you are within a few kilometers the technique I've been using is to use RCS in translate mode to move toward the target while compensating for any altitude change that might induce and then match velocities once you are very close to the target (within 100 meters) focus on exactly matching velocity (keep in mind that however much you change your velocity by to close the gap you have to undo that to avoid overshooting). Patience is a virtue, if you come in to fast you will have trouble overshooting your target. It's important to have a good RCS setup on your craft so that you can translate without inducing spin, and so that it is powerful enough to make it responsive without being excessively twitchy. Managing your ships orientation while translating can be quite tricky. There are numerous approaches, but I like to lock toward the target to translate towards it and then lock to current heading when matching velocity. Remember to get your roll leveled so that translation inputs go in the direction you expect. One other tip when matching velocity is focus on one axis at a time. Zoom out so that your nav rings extend far enough to encompass your target and then orient the camera so that you're seeing one of the planes from the side, translate perpendicular to that plane such that the target is on the same plane as you and holding steady.
I take it you're talking about launching into an inclined orbit as opposed to making a plane change maneuver in orbit since Droo's rotation would be irrelevant in the latter case.
Droo's rotation imparts ~150 meters per second of horizontal velocity when launching from the launchpad. Orbital velocity for 100km Droo orbit is 3400 m/s. Therefore if you point at 43 degrees and launch up to 100km circular orbit that 150 m/s will be responsible for some of your forward motion and a small change in your trajectory. Theoretically you can use trig to figure out how much. If you launch at 43 degrees the component of velocity due to rotation that is going to change your trajectory is going to be 150 * sin(47) and given that the angle of deflection going to be arctan(150 * sin(47) / 3400 which is 1.85 degrees. So you could just adjust your trajectory -1.85 degrees, however the amount of deflection at this new trajectory will be slightly different. I feel like it should be possible to define this equations in terms of a target and some error, and then solve for error, but it's late and I'm not coming up with it in my head.
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.
Ok, I've been working on coming up with a list of things that do and don't work (in Vizzy programs running on crafts not currently controlled by the player). Not yet complete but here you go:
Works
Setting Activation Groups
Reading the status of activation groups
Setting Inputs (Throttle/Slider)
Reading Inputs
Reading changes in orientation (measured by converting fixed PCI to local)
Does Not Work
Locking Heading (Current, Prograde, Target, etc)
Having a Target (and by extension getting Target information like position vector)
Setting Heading/Pitch in Degrees (because you can't Lock Heading)
Reading Current AGL (reports AGL at the last time the craft was in player control)
Obviously there are more things to test, I will update later if I come up with more. UPDATE: for additional information see this post.
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.
Most rockets designed for Droo and the default solar system won't perform very will in Realistic Solar System because of the increased size and mass of the home planet, plus the increased distances between the planets and moons. You'll want to look at Realistic Engine Overhaul when making rockets that will perform well in RSS.
That said you don't "need" to make these adaptations if you're not using the modded solar system yourself.
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.
That said, I think more proximity sensor capabilities is a great idea and you should definitely post this in the suggestions section of the site. It would be awesome if there were a Vizzy command to get a list of all the other craft within a certain range, and it would be awesome if non-controlled craft could continue to have and track targets. I look forward to unleashing artificial life satellite swarms and watching my GPU melt!
TLDR: not currently possible, if you are controlling an astronaut or another craft, and you want to cause something to happen on a craft you are not controlling, your best option is to select a part on the other craft and activate it.
Vizzy programs do continue to execute on crafts not currently controlled by the player, at least when the craft that is controlled by the player is in a certain range, although some things stop working such as locked headings IIRC (i.e. autopilot). There isn't a general purpose proximity sensor, however you can sense the position of both the current target for a craft, and a part in that craft (by id). Unfortunately one of the things that stops working when you are no longer in control of a craft is its ability to have & track a target. So while you can target astronauts and other craft from a craft with a proximity sensing Vizzy script, as soon as you take control of the astronaut or other craft the Vizzy script on the first craft forgets about the targeting. Also even though astronauts count as parts, as soon as they go EVA the craft loses the ability to get their position. So if you are approaching a craft with an EVA astronaut and you want a rotator on your craft to do something your easiest option is to just select that part and activate it. It might be possible to do complicated things by activating a trigger part (like a light), and then detecting that activation in a Vizzy script on the craft and manipulating other parts in complex ways, however I haven't tested this so I don't know exhaustively what does and doesn't work on the non-controlled craft.
I'm guessing these are stored in the game's installation directory, as Unity asset files. Unity is the game development platform Simple Rockets is built in. I don't think these textures are meant to be modified and if you did modify them it's not something you would be able to share with anybody. I suggest you wait for the Planet Builder feature and see what it has in store. The ESS folks managed to get some pretty impressive results just tweaking the stock textures.
@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.
This is a great question, and I wonder if the creators of Enhanced Solar System (@JastroOne1 and @pedro16797 I think) might be willing to to share some of their knowledge with the community (or if they can point to something they're using for documentation). Although I know they're probably super busy working the next version of ESS.
ESS 2.0 is not really a Mod per se. It is a custom SolarSystem.xml file which lists planetary bodies, there orbital and physical properties, and a set of procedural generators and transforms used to produce their terrain (elevation, color, and texture). However, what exactly all of these procedural generators and transforms do is a mystery to me. As far as I can tell there is no way to make deliberate adjustments to the elevation or biome map for a planet (i.e. the exact shape and placement of land masses or geographic features). However, with almost 4.3 billion random seeds to pick from, you could just keep trying until you get terrain that looks the way you want (given the right set of modifiers layered on of course).
From a SolarSystem.xml file SimpleRockets2 will automatically generate texture bitmaps and normal maps (which is a way of measuring the angle of a surface in order to give a surface the appearance of depth/texture when it is lit from the side). You can theoretically modify these bitmaps, however this only affects how your planet looks in map view!
SolarSystem.xml is located in your app data folder (~/Library/Application Support/com.jundroo.SimpleRockets2 on mac), in the UserData/SolarSystems/[YourSolarSystemName] folder.
Solar system textures are located in GameData/SolarSystems/[YourSolarSystemName] folder.
You can make a copy of the current solar system for a sandbox with the CloneSolarSystem [NewSolarSystemName] command in the dev console.
In theory you could go either way. If you know exactly how much payload mass you have and precisely what orbit you want to put it in, you can build a rocket to perfectly match that specification and neither has more fuel capacity than it needs nor bigger engines than it needs. However this takes extra work for each payload (especially relevant in the real world where you cannot just tweak fuel tank sizes and engine parameters). Therefore it makes a lot more sense to build one rocket that can support a range of payload masses and orbits and simply calculate the fuel requirements for your particular payload/orbit profile.
When designing a rocket I usually design for maximum mass to LDO (Low Droo Orbit, aka parking orbit). Once have your rocket designed you should be able to calculate maximum payload masses for various orbits. If you want to launch a payload lighter than your maximum you can just adjust your fuel load accordingly.
It might help if you were a little more specific. I am not an expert on SSTO space planes, but I understand they are notoriously challenging because you have to carry 100% of your propellant storage and engines with you into orbit. Additionally, jet engines, assuming you're using a mix of air breathing engines and rocket, don't get you to anywhere near the velocities or altitudes you need.
But unless you can be more specific than just not having enough thrust I'm not sure anybody is going to be able to help you. What kind of engines are you using? What are their specific impulses (at sea level and in vacuum)? What kind of fuels? What is the mass of your craft? What is the mass of your fuel (jet fuel and rocket fuel separately if you're using both)?
Better yet, upload your craft and share a link then people could actually take a look, see what you are trying to do, and give you some pointers.
Also you could try searching the craft other people have uploaded: https://www.simplerockets.com/Crafts/Search?q=ssto although be aware that many of the craft you'll find on the site have had there XML modified in ways that violates the realism of the game (i.e. they have engines that generate unrealistic amounts of thrust for the fuel they consume).
You should consider uploading an example rocket with this flight program to make it easier for folks to try out. You can make it unlisted if you only want people to discover it via this post.
You should make this a Suggestion instead of a Forum post (the link to this section of the site is under the STUFF menu).
That said, 👍to this idea. I've been working on basically doing planned maneuvers from scratch in Vizzy, and it is complicated: 1) figure out orbital parameters based on position and velocity vectors, 2) determine delta V requirements based on the difference between the current parameters and the desired parameters, 3) figure out burn time based on craft mass and and Isp, 4) figure out burn vector based on what would be the prograde or retrograde direction at the position of the burn node, 5) convert that PCI vector into Heading and Pitch... and finally we're ready to automate our burn.
It would be so much easier if we could just 1) create a burn node at a given True Anomaly, 2) set that burn's direction as a PCI vector (it would be nice to be able to get a Prograde/Retrograde PCI vector for any given True Anomaly as well), and 3) set the burn node's delta V.
I think stringing together multiple burn nodes with Vizzy like you can in the UI would be quite a bit more complicated, so I'm not sure how that would work.
I started writing a response to this two weeks ago, and it turned in to a research project and an essay. It is still a work in progress, but I'm developing a syllabus for teaching beginners (especially middle school and high school kids) how to get a rocket into orbit that I hope does a better job of giving people a firm grasp on the core concepts than just following the tutorials and using trial and error: https://docs.google.com/document/d/1EAcnHexoaeTKNtFMxZpYhgeurQAqb9AhhQjzTuiLea8/edit
OK, here you go: This rocket has a Vizzy program to get it to 150km orbit. And this rocket has a Vizzy program to launch it at the right time to rendezvous with a target that is in a circular 150km orbit with near zero inclination.
To be clear this is about the most simplistic approach to automating this, you can definitely do more advanced math to make a guidance program that works for different orbits, inclinations, payload masses, etc.
Option 1. Port PEGAS to Vizzy 😱
https://www.youtube.com/watch?v=NEQD7AQoLXk
https://github.com/Noiredd/PEGAS
Option 2. Given an existing Vizzy program that gets your space craft to the desired circular orbit (everything is much simpler if we're talking about circular orbits), based on the 1) time it takes your craft to get to orbit, and 2) the degrees of rotation in the celestial plane that your rocket travels on it's way to orbit, you should be able to automate a launch to rendezvous within a few kilometers. It will be a little tricky because there doesn't seem to be a way to get the orbital parameters of another craft, however I think it can be done using the direction to target vector. I've been meaning to do this myself so I can stop manually timing my rendezvous launches, so I'll see if I can provide you an example.
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
PCI stands for Planet Centered Inertial, and it is the similar/equivalent for Earth Centered Inertial except that it is based on the planet whose sphere of influence your craft is currently in rather than Earth specifically. The key concept of a Planet Centered Inertial coordinate system is that while it remains centered on the planet as the planet moves through space, it does not change orientation with respect to "fixed" points in space (i.e. distant stars). So as the planet rotates and moves in its orbit the unit vector
+5 5.1 years ago(1, 0, 0)will always be pointed off in the same direction with respect to the rest of the universe. Because there is no axial tilt, and the Y axis represents up and down relative to the "celestial plane",(0, 1, 0)always points towards the north pole. You can observe the behavior of PCI coordinates by watching the position change as a craft moves in orbit. If the orbit as 0 degrees of inclination X and Z will continually change, but Y will remain basically constant. Using latitude and longitude can be easier to think about when moving relative to the surface of the planet, however, working with lat/long as a coordinate system is challenging mathematically because it is not a cartesian system (i.e. mapped to a flat plane), it is a spherical system, so the vector math doesn't work the same (see spherical coordinate system).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.
5.1 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.
5.1 years ago@Oscarcarserud interesting idea. I think it is possible to communicate between multiple command pods/chips using the
broadcast [message] with data [value] to craftinstruction. However that only works when they are both in the same craft (where multiple things connected with docking ports count as one "craft").So, unfortunately this doesn't help when we're talking about the limitations of non-controlled craft. If a craft isn't player controlled it has absolutely no way to sense other craft.
+2 5.1 years ago@DeboStreams I figured it was more constructive than suggesting they go mow some lawns.
+2 5.1 years agoDid you know SimpleRockets2 is available free for education? Have you considered talking to a teacher or librarian about creating a program to teach people trigonometry or physics or computer programming using SimpleRockets 2?
+4 5.1 years ago@KraZIvan oops, sorry I failed at completely reading your post. I hope my Vizzy script is useful let me know if you have any questions. However it does seem like given the rocket auto pilot's default behavior it should be able to maintain stable roll. There must be something about your craft inducing the roll in the first place.
+1 5.1 years agoAs with many such questions, it would be a lot easier to diagnose problems and make suggestions if people would share their craft.
5.1 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.
5.1 years agoI have updated the post with some new information about Flight Programs running on non-player-controlled craft within the atmosphere. Unfortunately the results are quite disheartening. Basically after the craft is more than 1km away from the player almost nothing works, your rocket becomes a ballistic lump of metal with no angular velocity and no flight controls.
I have reason to believe that things may be better in orbit, but I still need to do more testing.
+1 5.1 years agoI'm not sure if by "without using the sliders" you mean not involving them at all, or just not having to manually set them in the UI. If the former, follow AnotherFireFox's suggestion. However, if it is just the latter then the xml modification is unnecessary and you can just use the
+1 5.1 years agoset [Slider 1] to [number]craft instruction.I have also been wondering about this lately. Trying to keep a craft rotating seens to be harder than it ought to be.
+2 5.2 years agoSee this post: Vizzy-on-Non-Controlled-Craft-What-Works-and-What-Doesnt.
@AnotherFireFox I have not reproduced this bug, I have been able to leave a vizzy program running that sets slider and roll inputs on a craft I'm not controlling. Is this a new bug? Link? Repro steps?
+1 5.2 years agoThere is a lot to unpack here, but firstly, most vectors (velocity, position, etc) are in PCI coordinates (Planet Centered Inertial) which basically means that one plane of the coordinate system is lined up with the equator of the Planet whose sphere of influence you are in, and the third direction is up and down toward the poles. In SR2 PCI the "up/down" axis is Y, and X/Z represent the "celestial plane". so moving away from the planet will affect X or Z or both depending on where you are in your orbit around the planet. The X and Z axis remain fixed relative to distance stars, which means that a given point on the planet will change as the planet spins and a vector toward the sun will change as the planet moves in its orbit.
I touch briefly on many concepts regarding dealing with vectors, finding prograde (and therefore retrograde by extension) vectors, and converting from a vector to Heading/Pitch, in the video I recently shared and some of the Flight Program laden craft I have shared. However I don't have time or space to go into all of it here.
That said, the key concepts are sprinkled here and there and I think a focused tutorial on vectors in SR2 is in order. Now I have my next video project, I'll let you know when I post it.
+2 5.2 years agoWhat do you mean, "to numbers?" You have a vector, do you want its length? Its x, y, and z components? Do you mean you want to plot an intercept course in heading & pitch based on your position, your target's position, and your target's velocity?
If you want length or x/y/z components there is an expression that takes a vector and has a drop down that defaults to length, that's the one you want.
+1 5.2 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
rangeattribute of theJointRotatorelement which is a child ofPartelement 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.
5.2 years agoThe
joinexpression 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
5.2 years agoformatexpression. 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.FWIW I think my trig is correct, but there must be a practical consideration I'm missing, because experimentally the error is quite a bit lower. When I launched at a heading of 43 degrees I wound up with an inclination of 46.5, only 0.5 degrees off from what you would get if there were no adjustment due to rotation.
+1 5.2 years agoI 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.
partScaleis 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.
5.2 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.
5.2 years agoWhat kind of distance are you talking about? If you're talking about being in a different orbit than the target or out of phase by more than a few kilometers than you should focus on learning and mastering orbital maneuvers.
Once you are within a few kilometers the technique I've been using is to use RCS in translate mode to move toward the target while compensating for any altitude change that might induce and then match velocities once you are very close to the target (within 100 meters) focus on exactly matching velocity (keep in mind that however much you change your velocity by to close the gap you have to undo that to avoid overshooting). Patience is a virtue, if you come in to fast you will have trouble overshooting your target. It's important to have a good RCS setup on your craft so that you can translate without inducing spin, and so that it is powerful enough to make it responsive without being excessively twitchy. Managing your ships orientation while translating can be quite tricky. There are numerous approaches, but I like to lock toward the target to translate towards it and then lock to current heading when matching velocity. Remember to get your roll leveled so that translation inputs go in the direction you expect. One other tip when matching velocity is focus on one axis at a time. Zoom out so that your nav rings extend far enough to encompass your target and then orient the camera so that you're seeing one of the planes from the side, translate perpendicular to that plane such that the target is on the same plane as you and holding steady.
+1 5.2 years agoI take it you're talking about launching into an inclined orbit as opposed to making a plane change maneuver in orbit since Droo's rotation would be irrelevant in the latter case.
Droo's rotation imparts ~150 meters per second of horizontal velocity when launching from the launchpad. Orbital velocity for 100km Droo orbit is 3400 m/s. Therefore if you point at 43 degrees and launch up to 100km circular orbit that 150 m/s will be responsible for some of your forward motion and a small change in your trajectory. Theoretically you can use trig to figure out how much. If you launch at 43 degrees the component of velocity due to rotation that is going to change your trajectory is going to be
+1 5.2 years ago150 * sin(47)and given that the angle of deflection going to bearctan(150 * sin(47) / 3400which is 1.85 degrees. So you could just adjust your trajectory -1.85 degrees, however the amount of deflection at this new trajectory will be slightly different. I feel like it should be possible to define this equations in terms of a target and some error, and then solve for error, but it's late and I'm not coming up with it in my head.If you set Luna as your target you can get its position in vizzy.
5.2 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.
5.2 years ago@crowxe I've moved my comment to a separate post with some additions.
5.2 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.
5.2 years agoOk, I've been working on coming up with a list of things that do and don't work (in Vizzy programs running on crafts not currently controlled by the player). Not yet complete but here you go:
Works
Does Not Work
Obviously there are more things to test, I will update later if I come up with more. UPDATE: for additional information see this post.
+4 5.2 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 :-(
Disclaimer: Somebody smarter than me regarding vector math may have a simpler solution.
5.2 years agoCitation (for the math I'm using): Rodrigues rotation formula
Most rockets designed for Droo and the default solar system won't perform very will in Realistic Solar System because of the increased size and mass of the home planet, plus the increased distances between the planets and moons. You'll want to look at Realistic Engine Overhaul when making rockets that will perform well in RSS.
That said you don't "need" to make these adaptations if you're not using the modded solar system yourself.
+1 5.2 years agoAssuming 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.
5.2 years agoThat said, I think more proximity sensor capabilities is a great idea and you should definitely post this in the suggestions section of the site. It would be awesome if there were a Vizzy command to get a list of all the other craft within a certain range, and it would be awesome if non-controlled craft could continue to have and track targets. I look forward to unleashing artificial life satellite swarms and watching my GPU melt!
+1 5.2 years agoTLDR: not currently possible, if you are controlling an astronaut or another craft, and you want to cause something to happen on a craft you are not controlling, your best option is to select a part on the other craft and activate it.
Vizzy programs do continue to execute on crafts not currently controlled by the player, at least when the craft that is controlled by the player is in a certain range, although some things stop working such as locked headings IIRC (i.e. autopilot). There isn't a general purpose proximity sensor, however you can sense the position of both the current target for a craft, and a part in that craft (by id). Unfortunately one of the things that stops working when you are no longer in control of a craft is its ability to have & track a target. So while you can target astronauts and other craft from a craft with a proximity sensing Vizzy script, as soon as you take control of the astronaut or other craft the Vizzy script on the first craft forgets about the targeting. Also even though astronauts count as parts, as soon as they go EVA the craft loses the ability to get their position. So if you are approaching a craft with an EVA astronaut and you want a rotator on your craft to do something your easiest option is to just select that part and activate it. It might be possible to do complicated things by activating a trigger part (like a light), and then detecting that activation in a Vizzy script on the craft and manipulating other parts in complex ways, however I haven't tested this so I don't know exhaustively what does and doesn't work on the non-controlled craft.
+1 5.2 years agoI'm guessing these are stored in the game's installation directory, as Unity asset files. Unity is the game development platform Simple Rockets is built in. I don't think these textures are meant to be modified and if you did modify them it's not something you would be able to share with anybody. I suggest you wait for the Planet Builder feature and see what it has in store. The ESS folks managed to get some pretty impressive results just tweaking the stock textures.
+1 5.2 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.
5.2 years agoAlso useful: T-F-G-H move the light source up-left-down-right respectively.
5.2 years agoThis is a great question, and I wonder if the creators of Enhanced Solar System (@JastroOne1 and @pedro16797 I think) might be willing to to share some of their knowledge with the community (or if they can point to something they're using for documentation). Although I know they're probably super busy working the next version of ESS.
ESS 2.0 is not really a Mod per se. It is a custom
SolarSystem.xmlfile which lists planetary bodies, there orbital and physical properties, and a set of procedural generators and transforms used to produce their terrain (elevation, color, and texture). However, what exactly all of these procedural generators and transforms do is a mystery to me. As far as I can tell there is no way to make deliberate adjustments to the elevation or biome map for a planet (i.e. the exact shape and placement of land masses or geographic features). However, with almost 4.3 billion random seeds to pick from, you could just keep trying until you get terrain that looks the way you want (given the right set of modifiers layered on of course).From a SolarSystem.xml file SimpleRockets2 will automatically generate texture bitmaps and normal maps (which is a way of measuring the angle of a surface in order to give a surface the appearance of depth/texture when it is lit from the side). You can theoretically modify these bitmaps, however this only affects how your planet looks in map view!
- SolarSystem.xml is located in your app data folder (
- Solar system textures are located in
- You can make a copy of the current solar system for a sandbox with the
+6 5.2 years ago~/Library/Application Support/com.jundroo.SimpleRockets2on mac), in theUserData/SolarSystems/[YourSolarSystemName]folder.GameData/SolarSystems/[YourSolarSystemName]folder.CloneSolarSystem [NewSolarSystemName]command in the dev console.In theory you could go either way. If you know exactly how much payload mass you have and precisely what orbit you want to put it in, you can build a rocket to perfectly match that specification and neither has more fuel capacity than it needs nor bigger engines than it needs. However this takes extra work for each payload (especially relevant in the real world where you cannot just tweak fuel tank sizes and engine parameters). Therefore it makes a lot more sense to build one rocket that can support a range of payload masses and orbits and simply calculate the fuel requirements for your particular payload/orbit profile.
+1 5.2 years agoWhen designing a rocket I usually design for maximum mass to LDO (Low Droo Orbit, aka parking orbit). Once have your rocket designed you should be able to calculate maximum payload masses for various orbits. If you want to launch a payload lighter than your maximum you can just adjust your fuel load accordingly.
You got me curious so I decided to see what it would take to build a functional SSTO spaceplane. Here is my attempt: https://www.simplerockets.com/c/YoLQky/Semi-functional-SSTO-Spaceplane
The autopilot is pretty dysfunctional, and this craft is not re-entry ready (it just burns up).
+1 5.2 years agoIt might help if you were a little more specific. I am not an expert on SSTO space planes, but I understand they are notoriously challenging because you have to carry 100% of your propellant storage and engines with you into orbit. Additionally, jet engines, assuming you're using a mix of air breathing engines and rocket, don't get you to anywhere near the velocities or altitudes you need.
+1 5.2 years agoBut unless you can be more specific than just not having enough thrust I'm not sure anybody is going to be able to help you. What kind of engines are you using? What are their specific impulses (at sea level and in vacuum)? What kind of fuels? What is the mass of your craft? What is the mass of your fuel (jet fuel and rocket fuel separately if you're using both)?
Better yet, upload your craft and share a link then people could actually take a look, see what you are trying to do, and give you some pointers.
Also you could try searching the craft other people have uploaded: https://www.simplerockets.com/Crafts/Search?q=ssto although be aware that many of the craft you'll find on the site have had there XML modified in ways that violates the realism of the game (i.e. they have engines that generate unrealistic amounts of thrust for the fuel they consume).
For 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
5.2 years agoYou should consider uploading an example rocket with this flight program to make it easier for folks to try out. You can make it unlisted if you only want people to discover it via this post.
+1 5.2 years agoYou should make this a Suggestion instead of a Forum post (the link to this section of the site is under the STUFF menu).
That said, 👍to this idea. I've been working on basically doing planned maneuvers from scratch in Vizzy, and it is complicated: 1) figure out orbital parameters based on position and velocity vectors, 2) determine delta V requirements based on the difference between the current parameters and the desired parameters, 3) figure out burn time based on craft mass and and Isp, 4) figure out burn vector based on what would be the prograde or retrograde direction at the position of the burn node, 5) convert that PCI vector into Heading and Pitch... and finally we're ready to automate our burn.
It would be so much easier if we could just 1) create a burn node at a given True Anomaly, 2) set that burn's direction as a PCI vector (it would be nice to be able to get a Prograde/Retrograde PCI vector for any given True Anomaly as well), and 3) set the burn node's delta V.
I think stringing together multiple burn nodes with Vizzy like you can in the UI would be quite a bit more complicated, so I'm not sure how that would work.
+2 5.2 years agoI started writing a response to this two weeks ago, and it turned in to a research project and an essay. It is still a work in progress, but I'm developing a syllabus for teaching beginners (especially middle school and high school kids) how to get a rocket into orbit that I hope does a better job of giving people a firm grasp on the core concepts than just following the tutorials and using trial and error: https://docs.google.com/document/d/1EAcnHexoaeTKNtFMxZpYhgeurQAqb9AhhQjzTuiLea8/edit
+1 5.2 years ago@Insanity should work now. Simplerockets.com is very wonky some times.
5.2 years agoI apologize for the poor code block formatting. This forum has a glitch in its markdown processing where it double escapes special characters.
5.2 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.
5.2 years agoOK, here you go: This rocket has a Vizzy program to get it to 150km orbit. And this rocket has a Vizzy program to launch it at the right time to rendezvous with a target that is in a circular 150km orbit with near zero inclination.
To be clear this is about the most simplistic approach to automating this, you can definitely do more advanced math to make a guidance program that works for different orbits, inclinations, payload masses, etc.
+1 5.2 years agoOption 1. Port PEGAS to Vizzy 😱
https://www.youtube.com/watch?v=NEQD7AQoLXk
https://github.com/Noiredd/PEGAS
Option 2. Given an existing Vizzy program that gets your space craft to the desired circular orbit (everything is much simpler if we're talking about circular orbits), based on the 1) time it takes your craft to get to orbit, and 2) the degrees of rotation in the celestial plane that your rocket travels on it's way to orbit, you should be able to automate a launch to rendezvous within a few kilometers. It will be a little tricky because there doesn't seem to be a way to get the orbital parameters of another craft, however I think it can be done using the direction to target vector. I've been meaning to do this myself so I can stop manually timing my rendezvous launches, so I'll see if I can provide you an example.
+1 5.2 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
5.2 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.
5.2 years ago