This really isn't how the game is intended to be used. There are four hollow components: cargo bays, fairings, inlets, and engine shrouds (I don't know how people use engine shrouds by I've heard it's a thing). In the designer I doubt it would be feasible to make a part this side, however, if you edit the XML you might be able to. I tested making a giant square inlet by modifying the Fuselage element of an Inlet part like so:
This makes a 1km cube shaped inlet. However in the designer you can't see the part at all, and I could only launch it in orbit it in water (otherwise the part does not spawn.
Sorry about the < that is because there is an issue with the markdown processor on this website that prevents it from displaying less than signs in code blocks, I fixed it using a unicode alternative. If you see < it should be ＜.
If you are trying to reach a targeted craft then instead of using the distance to a lat/long/AGL converted to a PCI position, you can just use the distance from your position to your target: nav |Target Position|. The dist operator is one of the options for the operator that takes two vectors (I believe the default option show in the toolbox is dot which takes the dot product).
You probably want to engage the brakes once your distance to the target is below a certain threshold. Assuming you have your destination as lat/long/AGL coordinates, this would look something like this:
> wait until [ [ [nav |Position|] |dist| [convert [$your_destination_coords] to position] ] ＜ 10 ]
> set |Brake| to [1]
A note on loops (even though I realize it is not relevant for you @Shmexysmpilot). I would use stronger wording than @CodeCaptain did below: every loop (that isn't doing iterative math*) should have at least a wait for [0] seconds. The reason is this: let's say you have a loop for a gravity turn that computes a formula for pitch based on altitude and sets craft pitch. Without a wait for [0] seconds such a loop will run multiple iterations during a single frame, and within the same frame altitude will not change and therefore the value for pitch will not change, and you will have simply recomputed the exact same value for pitch several times for no reason.
* The only reason to run multiple iterations within the same frame is if you are not calculating something directly from some game state value, but instead doing some iterative math (a.k.a. numeric methods) to solve equations with no closed form solution, such as finding Eccentric or True Anomaly from the Mean Anomaly, or dealing with some complicated differential equations.
@DoublehshAerospace yup that's why I wanted to open this up for discussion. I think there're many players that are just following others' example, and there is also a silent majority who wish there were a little better signal to noise ratio in the forums. And who knows, maybe there are some players that really like seeing other people post about point milestones, and make posts with inscrutable titles, but I know I don't. The best way to lead is by example.
There are a couple of special cases of trajectory:
In the atmosphere
Under power
Not under power
Not in the atmosphere
Not under power
Under power
In the atmosphere under power is the most complicated. In order to solve this you have to account for all of the changing variables: velocity is changing, therefore atmospheric drag is changing (even if we assume your angle of attack is constant so that your drag coefficient stays constant); mass is changing, therefore acceleration due to thrust is changing; gravity is changing, assuming your altitude is changing, although this change will be relatively small in the range of altitudes in the atmosphere; the direction of thrust is probably changing. I recently made an attempt to solve for displacement over time of a missile fired more or less horizontally, ignoring many factors, and I found out the math is really hard and I had to watch 12 hours of youtube videos about differential equations in order to figure it out. In the end I dropped most of the math and used a simple formula that approximated the flight path (but it would not be generalizable to any other missiles).
The simplest case-- not in the atmosphere, not under power-- is much easier. It is basically orbital mechanics plug and chug. Given your current position and velocity (a.k.a. cartesian state vectors), assuming only one planetary body is going to affect your path, you should be able to plot you trajectory and find your position and velocity at any given time. Here is a list of resources:
SimpleRockets 2 already has a Thrust Vectoring System between rocket engine gimbals and autopilot.
If you just want to have more extreme vectoring you can use XML to increase gimbal range
If you want to vector using inputs other than pitch/yaw I believe you can use input controllers to change what is mapped to the pitch and yaw input ids.
If you want to vector ungimbaled engine (jet or solid or ion), then you have to build it out of a clever combination of hinges, rotators, and pistons.
If for some reason the autopilot doesn't meet your requirements for adjusting the vectoring to maintain a heading/pitch, then you'll have to implement your own PID controller in Vizzy.
For semi-private conversations I think you could upload an unlisted craft and then tag a user in the comments. This would be far from a secure communication channel, but I think it would be hard to stumble on without the link.
It is true that the game is still in development and as such is a little rough around the edges. However I think it is well worth it because learning the physics of rocketry and spaceflight is really fascinating and challenging. Plus the amount of things you can create between the designer and Vizzy programs as incredible.
You no longer need to download a file to install planetary systems. From the ESS 3.1 Page when you click the Download link it should display a dialog with a URL. Copy that URL, open SimpleRockets 2 and from the menu screen hit Ctrl+V. That should download and install the system, after which you should be able to create a new game using the system.
Caveats: images don't work in comments and may be restricted to some minimum reputation score. There isn't any way to specify color, I don't think there is any support for raw <span style="color: red">HTML</span>.
This is indeed sad news, and I am disappointed in Take Two. TBD what this means for Simple Rockets 2 vs. KSP 2, but while I think/hope there is space in the market for both, it certainly doesn't seem like a bad thing for Simple Rockets 2.
Another workaround is to check for a sudden changes in mass or in part count. With part count you can do this with a wait until by setting a variable to the current part count and then wait until the current part count is less than the original. With mass I think you would need to use a while loop (because you want to ignore gradual changes caused by burning fuel). In either case these methods can be fooled by things like undocking or explosive disassembly. Additionally these techniques will not work for stages that don't separate the craft in some way (i.e. a parachute stage).
Kudos to the dev team for making that magically work. It was just a stab in the dark but I was thrilled to see it work (and I verified the behavior for different numeric values).
You can use vizzy to detect when you enter the sphere of influence of a specific planet although you have to use on enter [planet] SOI event rather than just a wait until [condition] instruction. You can also determine your distance to the planet using a combination of the planet [name] [Solar Position] and nav [Position] craft information expressions (It's a little complicated because you have to take your current planet's solar position, add your craft position, and then subtract that from the target planet's solar position). So I am also still unclear on what you are looking for.
This is definitely possible. To turn your rotator on and off without using an activation group you can use the set part [id] [Activated] to [1 or 0] craft instruction. To control your rotator's position you can set a variable in Vizzy, and then link your rotators input to be that variable. To do this you select the rotator, go to the "Rotator Input" section of the Part Properties panel, select the text in the "Input" field and type "TheNameOfYourCommandPod.FlightProgram.VaraibleName". The Variable in question should store a numeric value between 1 and -1. This was announced here and I believe it is now in the latest stable release.
See this post. Be aware that this is still really just a preview of how a planet will work and all editing is done via XML files. This functionality is still in a very nascent/experimental state. Documentation is non-existent as far as I'm aware and what folks have achieved for projects like ESS and RSS is a testament to the authors' industriousness and drive to figure things out by experimentation.
Keep an I out for announcements from the devs here and in future release notes, because a more full featured planet editor is on the roadmap.
instead of using the cross product of the North and East vectors, just normalize your position vector, that will always point "up" with respect to the planet.
It looks like you have an understanding of PCI coordinates so I won't belabor that. Instead I'll walk through the steps you're taking here one by one.
First, the East Vector returned by the Nav [East] craft information expression, will be a unit vector oscillating from (1, 0, 0) to (0, 0, 1) to (-1, 0, 0) to (0, 0, -1) as the planet rotates, or as you move around the planet heading east.
Next we have the North Vector from Nav [North]. At the equator this vector is very simple: (0, 1, 0) as you move away from the equator it gets more complicated because it will remain tangential to the surface of the planet, so lets just stick with the scenario where we are at the equator (which is where the Launch Pad is and that is where I presume your craft is).
Next you're taking the cross product of these two vectors, which you clearly are aware returns a vector perpendicular to both the input vectors. However, there are two such vectors, one pointing up relative to the plane represented by the input vectors, and one pointing down. Which one you get will depend on the order you put the vectors in. According to the right and rule (with your pointer finger in the direction of the first vector, palm facing the direction of the second vector, your thumb should point in the direction of the cross product), it seems to me that your expectation should be correct. So now I'm going to look at the actual math.
Give this arbitrary East vector I get when I launch: (0.115, 0, -0.993), if I calculate the cross product with North (0, 1, 0) after simplification thanks the the zeros: (vec [0 - aᶻ], [0], [aˣ]), I get (0.993, 0, 0.115). If I graph these three vectors using https://academo.org/demos/3d-vector-plotter/ they do indeed match the right hand rule, however when I compare this vector to my normalized position vector it is opposite: `(-0.993, 0, -0.155). So I am quite confused by this.
For the moment one quick fix is to reverse the order of North and East in the cross product expression. Another quick fix is instead of using the cross product of the North and East vectors, just normalize your position vector, that will always point up with respect to the planet. I'm still doing a little more investigation to figure out why this is happening, I'll let you know if I figure it out.
@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.
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.
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.
In order to prevent the new craft feed from being cluttered with posts that aren't actually useful that just celebrate points milestones, we remove them under the off-topic rule. However you are free to upload this kind of craft as an unlisted post and then link to it in a forum post.
I am just clarifying because it seems like Chtite might be implying that this forumn post was "unallowed" (but they may have also just meant the craft).
Craft search on this website depends on Google. So what shows up, and how it is ranked depends on Google's search algorithms. You'll definitely want to allow some time for Google's index to be updated and include your craft.
So your flight program was eventually separating the SRBs, but I'm guessing you want it to happen as soon as the SRBs are depleted. The issue is that the fuel |Stage| Vizzy expression returns the fuel percentage for the all tanks attached to all the engines that are part of the current stage (which in this case includes your liquid fueled main engines). I was able to make it work by using a while loop and checking for a rapid drop in engine thrust (which happens when the SRBs cut out): here's the craft.
I'm no expert builder by any stretch, but when I made my SU-27 Flanker I included links to unlisted crafts for each step in the build so people could see how it was made (note this predates the now available cockpit part). Here are a few basic pieces of advice:
Get comfortable with the part shape tool
Sometimes it's useful to build things larger than life and then use the resize tool to shrink them because the SR2 designer is a little dysfunctional for really small parts.
If you're on PC the Designer Tools Mod is really useful (but make sure you save frequently, it crashes sometimes).
For circular panelling, doing the math to determine the size and angle of each part, and then making liberal use of the mirroring tool (mirror a part, then break symmetry, then mirror again with different settings) can really speed things up.
@TestRunner Angle of attack sort of works for this because it gives the angle between the orientation fo the craft and the velocity vector, thus it will be 90 when the craft is in the orientation that JSO18 is trying to achieve. However you can really use this information to lock your heading effectively.
Gravatar is a site that hosts avatar images that can be referenced by other websites based on email address (so anybody who knows your email can fetch your avatar). It is now owned by the company that owns Wordpress.com. You can read more about it on wikipedia. It is not affiliated with Jundroo.
Make things that are original/unique/distinctive. There's a lot of SpaceX Starships on the site, so it's difficult to stand out making yet another one.
Make it look good, people really appreciate attention to detail. If your craft looks like you were really meticulous and put a lot of energy, and you take really good screenshots that show that work off, people tend to respond.
When you put a lot of work in to a craft, such as your Ares I (nice launch escape system), make a forum post about it with a descriptive title, including images, and links to your video content. Don't over do this and spam the forum with quick uninteresting builds, but it's a good way to get more people to see the crafts you put a lot of work into.
When making authentic/realistic replicas do your best to avoid XML modifications and tinker panel usage that makes your dry mass wonky. If it's sci-fi I don't care what you do with tinker panel so long as it looks cool, but if it's a realistic replica rocket, or a "get payload X to orbit" type utility rocket, I feel link tinker panel tends to indicate shortcuts were taken. (note: this is just my humble opinion, other players may not care).
Lastly, just don't sweat it. Remember, your self worth is something internal to your mind. The plaudits of others is something you can't truly control. If you depend on others approval, you surrender your power over yourself to others unnecessarily. Make stuff because you like doing it, if others don't appreciate it that is up to them and should not detract from your experience.
⠀
P.S. here's a hack I've discovered (before I became a moderator and my score became even more irrelevant to me): if you make a mod for the game that people find useful it can generate a lot of points in a short time. Plus you'll learn to code and how to use Unity in the process of doing so, which could be super useful long term. That said, coding and making mods isn't for everybody.
The feed icon (several concentric quarter circles, this is the standard icon for RSS feeds) allows you to subscribe or unsubscribe to comments on the post (blue = subscribed, black = unsubscribed). But the subscription in this case has nothing to do with RSS, it is via website notifications, which you may also receive via email depending on your settings.
Assuming that when you said "how to add crafts to my stock system" you actually meant Planets/Moons. In planet studio you select the celestial body around which your new planet/moon will orbit, then in the "Map View" panel click the button that looks like a target reticle (strange icon choice, but the tool tip says "Add new planet"). This will prompt you to select a previously saved planetary body and place it in orbit around the currently selected body. You can then set the new celestial body's orbital parameters.
If you actually did mean "craft." Then I don't really understand the question. Open a craft, click the blue play button, select Launch Craft. If you want to start from a different location, use the Flight Menu and click Relaunch. This will let you select a previously saved location. There's no way to select an arbitrary location to launch a craft*. So if you want to get there you've gotta fly there.
* Technically you can do this in planet studio as well, although initial launch locations must be on the surface of the planet, not in orbit.
@QarabinaKa @Insanity I'm not sure my improved docking port mod will be necessary here. Unless you have other reasons to want to make a connection between parts of the same craft (i.e. a robotic arm), I think simply articulating the existing docking port should work.
@QarabinaKa Attach one of your docking points via a hinge rotator, bind that rotator's input to a vizzy variable, and and then in vizzy after docking occurs calculate the angle required to achieve the desired alignment and set the variable accordingly.
This really isn't how the game is intended to be used. There are four hollow components: cargo bays, fairings, inlets, and engine shrouds (I don't know how people use engine shrouds by I've heard it's a thing). In the designer I doubt it would be feasible to make a part this side, however, if you edit the XML you might be able to. I tested making a giant square inlet by modifying the
Fuselageelement of anInletpart like so:This makes a 1km cube shaped inlet. However in the designer you can't see the part at all, and I could only launch it in orbit it in water (otherwise the part does not spawn.
+2 4.3 years agoSorry about the < that is because there is an issue with the markdown processor on this website that prevents it from displaying less than signs in code blocks, I fixed it using a unicode alternative. If you see
<it should be＜.If you are trying to reach a targeted craft then instead of using the distance to a lat/long/AGL converted to a PCI position, you can just use the distance from your position to your target:
+2 4.3 years agonav |Target Position|. Thedistoperator is one of the options for the operator that takes two vectors (I believe the default option show in the toolbox isdotwhich takes the dot product).You probably want to engage the brakes once your distance to the target is below a certain threshold. Assuming you have your destination as lat/long/AGL coordinates, this would look something like this:
+2 4.3 years agoA note on loops (even though I realize it is not relevant for you @Shmexysmpilot). I would use stronger wording than @CodeCaptain did below: every loop (that isn't doing iterative math*) should have at least a
wait for [0] seconds. The reason is this: let's say you have a loop for a gravity turn that computes a formula for pitch based on altitude and sets craft pitch. Without await for [0] secondssuch a loop will run multiple iterations during a single frame, and within the same frame altitude will not change and therefore the value for pitch will not change, and you will have simply recomputed the exact same value for pitch several times for no reason.* The only reason to run multiple iterations within the same frame is if you are not calculating something directly from some game state value, but instead doing some iterative math (a.k.a. numeric methods) to solve equations with no closed form solution, such as finding Eccentric or True Anomaly from the Mean Anomaly, or dealing with some complicated differential equations.
+2 4.3 years ago@DoublehshAerospace yup that's why I wanted to open this up for discussion. I think there're many players that are just following others' example, and there is also a silent majority who wish there were a little better signal to noise ratio in the forums. And who knows, maybe there are some players that really like seeing other people post about point milestones, and make posts with inscrutable titles, but I know I don't. The best way to lead is by example.
+2 4.4 years agoThere are a couple of special cases of trajectory:
In the atmosphere under power is the most complicated. In order to solve this you have to account for all of the changing variables: velocity is changing, therefore atmospheric drag is changing (even if we assume your angle of attack is constant so that your drag coefficient stays constant); mass is changing, therefore acceleration due to thrust is changing; gravity is changing, assuming your altitude is changing, although this change will be relatively small in the range of altitudes in the atmosphere; the direction of thrust is probably changing. I recently made an attempt to solve for displacement over time of a missile fired more or less horizontally, ignoring many factors, and I found out the math is really hard and I had to watch 12 hours of youtube videos about differential equations in order to figure it out. In the end I dropped most of the math and used a simple formula that approximated the flight path (but it would not be generalizable to any other missiles).
The simplest case-- not in the atmosphere, not under power-- is much easier. It is basically orbital mechanics plug and chug. Given your current position and velocity (a.k.a. cartesian state vectors), assuming only one planetary body is going to affect your path, you should be able to plot you trajectory and find your position and velocity at any given time. Here is a list of resources:
- Orbital Parameter Basics
- Converting Cartesian State Vectors to Orbital Parameters
- StackExchange Post With Pseudo Code
- Converting Orbital Elements to Cartesian State Vectors
- Table of Relations for Orbital Elements
+2 4.4 years ago-1 Question Too Broad 🤣
- SimpleRockets 2 already has a Thrust Vectoring System between rocket engine gimbals and autopilot.
- If you just want to have more extreme vectoring you can use XML to increase gimbal range
- If you want to vector using inputs other than pitch/yaw I believe you can use input controllers to change what is mapped to the pitch and yaw input ids.
- If you want to vector ungimbaled engine (jet or solid or ion), then you have to build it out of a clever combination of hinges, rotators, and pistons.
- If for some reason the autopilot doesn't meet your requirements for adjusting the vectoring to maintain a heading/pitch, then you'll have to implement your own PID controller in Vizzy.
+2 4.4 years agoFor semi-private conversations I think you could upload an unlisted craft and then tag a user in the comments. This would be far from a secure communication channel, but I think it would be hard to stumble on without the link.
+2 4.4 years agoFor what it's worth this is like saying to someone: "don't think about a pink elephant." Now you're thinking about a pink elephant. See my point?
But I agree thay we don't need drama. Hopefully we're all hear to have fun, learn new things, and help each other.
+2 4.4 years agoIt is true that the game is still in development and as such is a little rough around the edges. However I think it is well worth it because learning the physics of rocketry and spaceflight is really fascinating and challenging. Plus the amount of things you can create between the designer and Vizzy programs as incredible.
+2 4.4 years ago@Rizkyman made a pretty impressive one: https://www.simplerockets.com/Videos/View/69114
+2 4.4 years agoYou no longer need to download a file to install planetary systems. From the ESS 3.1 Page when you click the Download link it should display a dialog with a URL. Copy that URL, open SimpleRockets 2 and from the menu screen hit Ctrl+V. That should download and install the system, after which you should be able to create a new game using the system.
+2 4.5 years agoSR2 Post Formatting Guide
Caveats: images don't work in comments and may be restricted to some minimum reputation score. There isn't any way to specify color, I don't think there is any support for raw <span style="color: red">HTML</span>.
+2 4.5 years agoThis is indeed sad news, and I am disappointed in Take Two. TBD what this means for Simple Rockets 2 vs. KSP 2, but while I think/hope there is space in the market for both, it certainly doesn't seem like a bad thing for Simple Rockets 2.
Thank you @ TOMJeb117
+2 4.5 years agoAnother workaround is to check for a sudden changes in mass or in part count. With part count you can do this with a wait until by setting a variable to the current part count and then wait until the current part count is less than the original. With mass I think you would need to use a while loop (because you want to ignore gradual changes caused by burning fuel). In either case these methods can be fooled by things like undocking or explosive disassembly. Additionally these techniques will not work for stages that don't separate the craft in some way (i.e. a parachute stage).
+2 4.5 years agoKudos to the dev team for making that magically work. It was just a stab in the dark but I was thrilled to see it work (and I verified the behavior for different numeric values).
+2 4.6 years agoYou can use vizzy to detect when you enter the sphere of influence of a specific planet although you have to use
+2 4.6 years agoon enter [planet] SOIevent rather than just await until [condition]instruction. You can also determine your distance to the planet using a combination of theplanet [name] [Solar Position]andnav [Position]craft information expressions (It's a little complicated because you have to take your current planet's solar position, add your craft position, and then subtract that from the target planet's solar position). So I am also still unclear on what you are looking for.This is definitely possible. To turn your rotator on and off without using an activation group you can use the
+2 4.6 years agoset part [id] [Activated] to [1 or 0]craft instruction. To control your rotator's position you can set a variable in Vizzy, and then link your rotators input to be that variable. To do this you select the rotator, go to the "Rotator Input" section of the Part Properties panel, select the text in the "Input" field and type "TheNameOfYourCommandPod.FlightProgram.VaraibleName". The Variable in question should store a numeric value between 1 and -1. This was announced here and I believe it is now in the latest stable release.See this post. Be aware that this is still really just a preview of how a planet will work and all editing is done via XML files. This functionality is still in a very nascent/experimental state. Documentation is non-existent as far as I'm aware and what folks have achieved for projects like ESS and RSS is a testament to the authors' industriousness and drive to figure things out by experimentation.
Keep an I out for announcements from the devs here and in future release notes, because a more full featured planet editor is on the roadmap.
+2 4.6 years agoWhy not join SimpleRockets Chat?
+2 4.6 years agoTLDR:
It looks like you have an understanding of PCI coordinates so I won't belabor that. Instead I'll walk through the steps you're taking here one by one.
First, the East Vector returned by the
Nav [East]craft information expression, will be a unit vector oscillating from(1, 0, 0)to(0, 0, 1)to(-1, 0, 0)to(0, 0, -1)as the planet rotates, or as you move around the planet heading east.Next we have the North Vector from
Nav [North]. At the equator this vector is very simple:(0, 1, 0)as you move away from the equator it gets more complicated because it will remain tangential to the surface of the planet, so lets just stick with the scenario where we are at the equator (which is where the Launch Pad is and that is where I presume your craft is).Next you're taking the cross product of these two vectors, which you clearly are aware returns a vector perpendicular to both the input vectors. However, there are two such vectors, one pointing up relative to the plane represented by the input vectors, and one pointing down. Which one you get will depend on the order you put the vectors in. According to the right and rule (with your pointer finger in the direction of the first vector, palm facing the direction of the second vector, your thumb should point in the direction of the cross product), it seems to me that your expectation should be correct. So now I'm going to look at the actual math.
[a] cross [b] = vec [aʸ * bᶻ - aᶻ * bʸ], [aᶻ * bˣ - aˣ * bᶻ], [aˣ * bʸ - aʸ * bˣ]Give this arbitrary East vector I get when I launch:
(0.115, 0, -0.993), if I calculate the cross product with North(0, 1, 0)after simplification thanks the the zeros: (vec [0 - aᶻ], [0], [aˣ]), I get(0.993, 0, 0.115). If I graph these three vectors using https://academo.org/demos/3d-vector-plotter/ they do indeed match the right hand rule, however when I compare this vector to my normalized position vector it is opposite: `(-0.993, 0, -0.155). So I am quite confused by this.For the moment one quick fix is to reverse the order of North and East in the cross product expression. Another quick fix is instead of using the cross product of the North and East vectors, just normalize your position vector, that will always point up with respect to the planet. I'm still doing a little more investigation to figure out why this is happening, I'll let you know if I figure it out.
+2 4.7 years agoRegarding searching the forums, yes, they are unfortunately difficult to search on the site. However Google does a pretty good job: https://www.google.com/search?q=site%3Asimplerockets.com%2FForums+vizzy&oq=site%3Asimplerockets.com%2FForums+vizzy
+2 4.7 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 4.7 years ago@DeboStreams I figured it was more constructive than suggesting they go mow some lawns.
+2 4.7 years agoI have also been wondering about this lately. Trying to keep a craft rotating seens to be harder than it ought to be.
+2 4.7 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 4.7 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 4.8 years agoI fixed your image embed. But I'm removing this post because it was just a test and shouldn't remain in the forum.
+1 2.8 years agoThe cockpit part has 4 connection points:
Some connection points, such as panel, will only accept incoming connections.
+1 3.2 years agoIn order to prevent the new craft feed from being cluttered with posts that aren't actually useful that just celebrate points milestones, we remove them under the off-topic rule. However you are free to upload this kind of craft as an unlisted post and then link to it in a forum post.
I am just clarifying because it seems like Chtite might be implying that this forumn post was "unallowed" (but they may have also just meant the craft).
+1 3.6 years agoCraft search on this website depends on Google. So what shows up, and how it is ranked depends on Google's search algorithms. You'll definitely want to allow some time for Google's index to be updated and include your craft.
+1 3.7 years agoSo your flight program was eventually separating the SRBs, but I'm guessing you want it to happen as soon as the SRBs are depleted. The issue is that the
+1 3.7 years agofuel |Stage|Vizzy expression returns the fuel percentage for the all tanks attached to all the engines that are part of the current stage (which in this case includes your liquid fueled main engines). I was able to make it work by using a while loop and checking for a rapid drop in engine thrust (which happens when the SRBs cut out): here's the craft.@KeanuReeves I just edited your post to show you a working example.
+1 3.8 years agoSee the Post Formatting Guide and keep in mind you need to use a valid, publicly accessible, http/https URL that goes directly to your image.
+1 3.8 years agoAlternately if you are making a propeller based plane you will experience torque from the spin of the propeller.
+1 3.8 years agoUsually this means that something is misaligned on one side vs the other. Heavy use of the mirror settings and tool can alleviate this.
+1 3.8 years agoI'm no expert builder by any stretch, but when I made my SU-27 Flanker I included links to unlisted crafts for each step in the build so people could see how it was made (note this predates the now available cockpit part). Here are a few basic pieces of advice:
- Get comfortable with the part shape tool
- Sometimes it's useful to build things larger than life and then use the resize tool to shrink them because the SR2 designer is a little dysfunctional for really small parts.
- If you're on PC the Designer Tools Mod is really useful (but make sure you save frequently, it crashes sometimes).
- For circular panelling, doing the math to determine the size and angle of each part, and then making liberal use of the mirroring tool (mirror a part, then break symmetry, then mirror again with different settings) can really speed things up.
+1 3.9 years ago@TestRunner Angle of attack sort of works for this because it gives the angle between the orientation fo the craft and the velocity vector, thus it will be 90 when the craft is in the orientation that JSO18 is trying to achieve. However you can really use this information to lock your heading effectively.
+1 3.9 years ago@HSH then it should be really easy, just click the download on mobile link.
+1 4.1 years ago- Copy the URL
- Open the home screen of SR2
- Press Ctrl+V (at this point SR2 will download the solar system files)
- Create a new game (a.k.a. new sandbox)
- Click on "Juno System" under the "Planetary Systems" section of the new game dialog
- Make sure "Community" is enabled in the options menu of the "Planetary Systems" dialog (top right, button with three dots).
- Select ESS
+1 4.1 years agoGravatar is a site that hosts avatar images that can be referenced by other websites based on email address (so anybody who knows your email can fetch your avatar). It is now owned by the company that owns Wordpress.com. You can read more about it on wikipedia. It is not affiliated with Jundroo.
+1 4.1 years ago@MagellanAerospace Here's a few thoughts:
⠀
⠀
P.S. here's a hack I've discovered (before I became a moderator and my score became even more irrelevant to me): if you make a mod for the game that people find useful it can generate a lot of points in a short time. Plus you'll learn to code and how to use Unity in the process of doing so, which could be super useful long term. That said, coding and making mods isn't for everybody.
+1 4.1 years agoThe build id is part of the URL for the craft, which you can find in the location bar of your browser. For example, the build id for this craft: https://www.simplerockets.com/c/g7k0Ls/100km-fastmen-gg-1-working-Space-debris-sonar is
g7k0Ls.The feed icon (several concentric quarter circles, this is the standard icon for RSS feeds) allows you to subscribe or unsubscribe to comments on the post (blue = subscribed, black = unsubscribed). But the subscription in this case has nothing to do with RSS, it is via website notifications, which you may also receive via email depending on your settings.
+1 4.2 years agoMake you URL a link like this:
[link text](https://your-url-here/)Here's a link to your subreddit
+1 4.2 years ago🍰
+1 4.2 years agoI believe the part ids changed and so needed to be updated. I fixed this by using part names to get ids.
+1 4.2 years agoAssuming that when you said "how to add crafts to my stock system" you actually meant Planets/Moons. In planet studio you select the celestial body around which your new planet/moon will orbit, then in the "Map View" panel click the button that looks like a target reticle (strange icon choice, but the tool tip says "Add new planet"). This will prompt you to select a previously saved planetary body and place it in orbit around the currently selected body. You can then set the new celestial body's orbital parameters.
If you actually did mean "craft." Then I don't really understand the question. Open a craft, click the blue play button, select Launch Craft. If you want to start from a different location, use the Flight Menu and click Relaunch. This will let you select a previously saved location. There's no way to select an arbitrary location to launch a craft*. So if you want to get there you've gotta fly there.
* Technically you can do this in planet studio as well, although initial launch locations must be on the surface of the planet, not in orbit.
+1 4.2 years ago@QarabinaKa @Insanity I'm not sure my improved docking port mod will be necessary here. Unless you have other reasons to want to make a connection between parts of the same craft (i.e. a robotic arm), I think simply articulating the existing docking port should work.
+1 4.3 years ago@QarabinaKa Attach one of your docking points via a hinge rotator, bind that rotator's input to a vizzy variable, and and then in vizzy after docking occurs calculate the angle required to achieve the desired alignment and set the variable accordingly.
+1 4.3 years ago🎁
+1 4.3 years ago