@ThesaturnaerospaceRedo No problem. I did notice education was a light thread, but unfortunately, there is no other possible way I believe it could be classified. It's strictly for teaching and it can be used in custom created crafts as well (complicated script but a little flexible with a good bit of things that don't rely on the craft itself, just what the situation is and what to do about it to not go BOOM! because it's so easy to do 🙈.) It's also intended only for Simple Rockets 2. I didn't think Vizzy could do it at first, and when I figured out oh yes Vizzy can, I've been hardcore making it to where I tend to be sleepy posting sometimes 🤦🏼♂️ I should probably stop that 😂
@ThesaturnaerospaceRedo also, now the project is completed (v1.0 I think is safe to say now, just bug hunting for what I missed or couldn't imagine accounting for), there are two people I would like to edit into the post, because they gave inspiration and subtle hints of idea that steered the project along. If the post is ok I'll do that as well 👍
@ThesaturnaerospaceRedo No. I've created a project that kind of grew into an entity of its own. I'm about to upload the full version of the craft with a full blown script to teach players basic rocket control. I just finished out the script to be a full flight and not just halfway to only get up there. If this post is classified wrong or should be done differently, please let me know. I just know some players have a hard time with rocket sims, and I want to have a way for them to learn and fully enjoy the game for what it can be 😊.
The rare bug was actually helpful! New suggestion and how I can make it happen now, read on:
Now I can make it do it on command. This time it was actually helpful so it brings me to another suggestion. First how it happens: When you drop the code block, it hangs slightly before triggering the trash to close and reopen the left side menu. If during that time you click on the plain background/grid, it freezes the part you drop and you can drag your code around. Clicking again to what you dropped and dragging unfreezes it and lets you drop it normally.
We should make that an option to be INTENTIONAL. Like as you have something held, right click but let go of left click and cause the code to hold in place on the screen, instead of like now where that just drops a copy of whatever you have the mouse over like normal, for example. I was able to copy something from way up top and instead of drag drop, pan, drag drop pan, about 6 or so times, I was able to just keep rolling until I got back to where I needed the copy and dropped it right in.
And yes I could easily break the script to pieces and put them into separate parts, but.....
That breaks Vanilla rules as it requires the tinker panel, so kinda stuck with working with what's there 😂 🤷♂️
At 9 screens long (zooming out as much as it allows). Now I'm on to another little bug.
If I grab a section, like a small if block, move it to the side and let go of the mouse, the rest of the screen pans (the grid and untouched code) yet the code block I should not be holding is frozen in place. I click back to grab the piece I let go that started this issue, the rest of the code (grid) then goes back to normal and I have the code block again, and then clicking again releases it. Not a big deal but trippy to see 😂
It's done it twice now, first time was after it past about 7 screen lengths, second time just now so rarely.
I'm zoomed in to where I see only a handful of code pieces at the time I'm trying to modify when this happens. Being zoomed in tight seems to help with other issues as well but it still has a noticable lag in this case too.
Got the variable thing didn't see the button 🤦🏼♂️ but another idea I have but not too sure how exactly to put it together but it would involve using planet information with solar position and your own craft position relative to the planet, but I don't see any way to target the base specifically that way. One other thought is if the base had a specific part ID you can use maybe plug that into the craft (0) position and replace the (0) with the ID of the base or of a base part? But if that would work then you could also replace that (0) with a nav (target) piece and that may be all you need? That's about all I've got idea wise for now, definitely like to see this solved 😂
One idea and, it's very possible you've tried it, "craft information>nav(target position)" - "craft information>nav(craft pitch axis)" then convert PCI vector to local with "craft information>(part(0)(PCI to local)" of that (part 0 replace with part id of the part id of the command pod) and have an x y & z of it? It would all be one block of Vizzy, take target position and craft pitch in 0-0 block, get a part of "partName" and change that to command pod or whatever the command pod is called, then get the part 0 PCI to local (0,0,0) bit. Drop the math block into the (0,0,0) and the part ID of bit drop on the part 0, and then put that into the rest of the calculation you have to use that information. I'm interested in this if it works for you because I have a need for a similar use solution I'm planning for a future project... Trying to figure out this custom variables thing myself
@FriendlyFin I've noticed that game and have always been hesitant to hit the buy and download button. I'm a fan of realistic, and that just seems a little "out there" ( no pun intended 🤣) it's on the radar but not the nearby radar for now lol
@FriendlyFin sorry just getting started with the forum. I've thought of actually making some guides for new players on how to get into orbit and manage a few things, but I have most of my experience in KSP so I need to get some space time with SR2 in so I can speak in SR2 terms and not Kerbal terms 🙈🤣 translation of math is all lol
I think you may be more looking for the geostationary orbit information. It's some nice math, but I found the KSP wiki has a good article about it. It's labled as "Geosynchronous Orbit (Math)" but explains more how to find the geostationary, which is similar but I think more what you're looking for. That article does a much better job explaining than I can.
Sorry if I can do this a different way, first time in the forum and things aren't coming all at once. Some final thoughts on the radial out and in, is when it comes to trajectory adjustment on landings. If you overshoot, but have a good speed you don't want to change, radial in acan shorten the trajectory, and radial out will lengthen if you undershoot. It's a little more advanced in maneuvering, but it will not require wasted delta v by drastically affecting your speed, an is also much faster at rotations to the marks, which is better for keeping the power to the ground direction with last minute adjustment. Normal and anti normal also become involved at this point, because they will do the same for left and right adjustment without affecting your speed much as well. If you do your entry angle burn right, chances are pretty good you have the right speed and are about 20km off target, so these menuvers in this situation help make major adjustment without using high amounts of delta v, or changing your speed requiring more delta v and more adjustment because you slowed down for overshooting and now your under🙈.
If you are halfway between the periapsis and apoapsis, a full radial in will raise your periapsis and lower your apoapsis, retrograde direction burn will maintain the periapsis but lower the apoapsis in this situation. The opposite is true with radial out in this situation. You can radial out and raise the apoapsis but lower the periapsis, retrograde direction burning will maintain the periapsis.
If your between apoapsis and periapsis, everything I just said is flipped. Radial in will lower the periapsis and raise the apoapsis, prograde direction burn will maintain the apoapsis, and radial out will raise your periapsis and lower the apoapsis. Prograde burn direction maintains the apoapsis.
The best way to explain it is like a ceterfuge or cetrifical force. The closer you are to the center, the faster you go. Each gravitational field is round, and therefore nothing but a sling shot. To slow down/ go lower, get further from the center, to speed up/ get higher, get closer. I hope it's not too confusing, and I hope I didn't mixit all up 🙈, but that's the most I've understood about radial out and in pertaining to landing, escape angles, getting to orbit, not crashing because somehow your periapsis passes through a moon mountain, and so on. Sometimes a small adjustment just won't cut it, that's where radial out and in shines.
One use I've recently found for radial out/in maneuvering is in very low or at sub orbital levels. It tends to help the best halfway between apoapsis and periapsis, but you can greatly affect your upcoming node while maintaining your previous node and make major adjustment. Only downside is it takes about 20% more delta v over doing burns at a node.
Example, you launch slow, get into sub orbit low and don't quite have the speed to raise a complete orbit before you pass your apoapsis. Common without enough twr starting off the pad. You already have a high enough apoapsis or maybe it's as low, but don't want it at 200k meters before you make it to an orbit, so to correct the situation and maintain say a 90km node(apoapsis or periapsis) you pitch 45 degrees to radial out or if it's really bad full radial out. Then by pitching between full radial out and less than full (all prograde direction burning) you can essentially maintain the past point or raise it more if close to it, and drastically change the periapsis to make an orbit and not dip in and out of the atmosphere wasting delta v just getting up there, or having a massive apoapsis you now have to retro burn to bring back down.
By using the radial in, in a retrograde direction, it will bring the coming apoapsis down, but not affect the periapsis, like if you were to be aerobraking, and have a little more left to bleed off, plenty of delta v, and no more atmosphere until you come around again, you can use this type of radial in retrograde burn to keep your periapsis but lower your apoapsis down more. These menuvers have the greatest effects at halfway between between Ap and Pe, but will work the same closer to these nodes, but with lesser effect to the furthest node the further from between the two you are.
Little difficult to explain on paper, but a quick try while watching your ap and pe as you do the burns and it will make sense.
@ThesaturnaerospaceRedo No problem. I did notice education was a light thread, but unfortunately, there is no other possible way I believe it could be classified. It's strictly for teaching and it can be used in custom created crafts as well (complicated script but a little flexible with a good bit of things that don't rely on the craft itself, just what the situation is and what to do about it to not go BOOM! because it's so easy to do 🙈.) It's also intended only for Simple Rockets 2. I didn't think Vizzy could do it at first, and when I figured out oh yes Vizzy can, I've been hardcore making it to where I tend to be sleepy posting sometimes 🤦🏼♂️ I should probably stop that 😂
3.1 years ago@ThesaturnaerospaceRedo also, now the project is completed (v1.0 I think is safe to say now, just bug hunting for what I missed or couldn't imagine accounting for), there are two people I would like to edit into the post, because they gave inspiration and subtle hints of idea that steered the project along. If the post is ok I'll do that as well 👍
3.1 years ago@ThesaturnaerospaceRedo No. I've created a project that kind of grew into an entity of its own. I'm about to upload the full version of the craft with a full blown script to teach players basic rocket control. I just finished out the script to be a full flight and not just halfway to only get up there. If this post is classified wrong or should be done differently, please let me know. I just know some players have a hard time with rocket sims, and I want to have a way for them to learn and fully enjoy the game for what it can be 😊.
3.1 years ago9.1 screens, and no flights since the last update 🙈 never been so worried about a launch 😂 The project is coming to full fruition 😊
3.1 years agoThe rare bug was actually helpful! New suggestion and how I can make it happen now, read on:
Now I can make it do it on command. This time it was actually helpful so it brings me to another suggestion. First how it happens: When you drop the code block, it hangs slightly before triggering the trash to close and reopen the left side menu. If during that time you click on the plain background/grid, it freezes the part you drop and you can drag your code around. Clicking again to what you dropped and dragging unfreezes it and lets you drop it normally.
We should make that an option to be INTENTIONAL. Like as you have something held, right click but let go of left click and cause the code to hold in place on the screen, instead of like now where that just drops a copy of whatever you have the mouse over like normal, for example. I was able to copy something from way up top and instead of drag drop, pan, drag drop pan, about 6 or so times, I was able to just keep rolling until I got back to where I needed the copy and dropped it right in.
3.1 years agoAnd yes I could easily break the script to pieces and put them into separate parts, but.....
3.1 years agoThat breaks Vanilla rules as it requires the tinker panel, so kinda stuck with working with what's there 😂 🤷♂️
At 9 screens long (zooming out as much as it allows). Now I'm on to another little bug.
If I grab a section, like a small if block, move it to the side and let go of the mouse, the rest of the screen pans (the grid and untouched code) yet the code block I should not be holding is frozen in place. I click back to grab the piece I let go that started this issue, the rest of the code (grid) then goes back to normal and I have the code block again, and then clicking again releases it. Not a big deal but trippy to see 😂
It's done it twice now, first time was after it past about 7 screen lengths, second time just now so rarely.
I'm zoomed in to where I see only a handful of code pieces at the time I'm trying to modify when this happens. Being zoomed in tight seems to help with other issues as well but it still has a noticable lag in this case too.
3.1 years agoGot the variable thing didn't see the button 🤦🏼♂️ but another idea I have but not too sure how exactly to put it together but it would involve using planet information with solar position and your own craft position relative to the planet, but I don't see any way to target the base specifically that way. One other thought is if the base had a specific part ID you can use maybe plug that into the craft (0) position and replace the (0) with the ID of the base or of a base part? But if that would work then you could also replace that (0) with a nav (target) piece and that may be all you need? That's about all I've got idea wise for now, definitely like to see this solved 😂
3.1 years agoLike forward facing radar?
One idea and, it's very possible you've tried it, "craft information>nav(target position)" - "craft information>nav(craft pitch axis)" then convert PCI vector to local with "craft information>(part(0)(PCI to local)" of that (part 0 replace with part id of the part id of the command pod) and have an x y & z of it? It would all be one block of Vizzy, take target position and craft pitch in 0-0 block, get a part of "partName" and change that to command pod or whatever the command pod is called, then get the part 0 PCI to local (0,0,0) bit. Drop the math block into the (0,0,0) and the part ID of bit drop on the part 0, and then put that into the rest of the calculation you have to use that information. I'm interested in this if it works for you because I have a need for a similar use solution I'm planning for a future project... Trying to figure out this custom variables thing myself
3.1 years ago@FriendlyFin
Hey, just wanted to let you know I've come up with something very interesting and it was inspired in part from this discussion 😉
If you want to check it out and give it a go it's here: .
3.1 years ago@FriendlyFin I've noticed that game and have always been hesitant to hit the buy and download button. I'm a fan of realistic, and that just seems a little "out there" ( no pun intended 🤣) it's on the radar but not the nearby radar for now lol
3.1 years ago@FriendlyFin sorry just getting started with the forum. I've thought of actually making some guides for new players on how to get into orbit and manage a few things, but I have most of my experience in KSP so I need to get some space time with SR2 in so I can speak in SR2 terms and not Kerbal terms 🙈🤣 translation of math is all lol
3.1 years agoI think you may be more looking for the geostationary orbit information. It's some nice math, but I found the KSP wiki has a good article about it. It's labled as "Geosynchronous Orbit (Math)" but explains more how to find the geostationary, which is similar but I think more what you're looking for. That article does a much better job explaining than I can.
3.1 years agoSorry if I can do this a different way, first time in the forum and things aren't coming all at once. Some final thoughts on the radial out and in, is when it comes to trajectory adjustment on landings. If you overshoot, but have a good speed you don't want to change, radial in acan shorten the trajectory, and radial out will lengthen if you undershoot. It's a little more advanced in maneuvering, but it will not require wasted delta v by drastically affecting your speed, an is also much faster at rotations to the marks, which is better for keeping the power to the ground direction with last minute adjustment. Normal and anti normal also become involved at this point, because they will do the same for left and right adjustment without affecting your speed much as well. If you do your entry angle burn right, chances are pretty good you have the right speed and are about 20km off target, so these menuvers in this situation help make major adjustment without using high amounts of delta v, or changing your speed requiring more delta v and more adjustment because you slowed down for overshooting and now your under🙈.
3.1 years agoSome expansion on the radial out and radial in.
If you are halfway between the periapsis and apoapsis, a full radial in will raise your periapsis and lower your apoapsis, retrograde direction burn will maintain the periapsis but lower the apoapsis in this situation. The opposite is true with radial out in this situation. You can radial out and raise the apoapsis but lower the periapsis, retrograde direction burning will maintain the periapsis.
If your between apoapsis and periapsis, everything I just said is flipped. Radial in will lower the periapsis and raise the apoapsis, prograde direction burn will maintain the apoapsis, and radial out will raise your periapsis and lower the apoapsis. Prograde burn direction maintains the apoapsis.
The best way to explain it is like a ceterfuge or cetrifical force. The closer you are to the center, the faster you go. Each gravitational field is round, and therefore nothing but a sling shot. To slow down/ go lower, get further from the center, to speed up/ get higher, get closer. I hope it's not too confusing, and I hope I didn't mixit all up 🙈, but that's the most I've understood about radial out and in pertaining to landing, escape angles, getting to orbit, not crashing because somehow your periapsis passes through a moon mountain, and so on. Sometimes a small adjustment just won't cut it, that's where radial out and in shines.
3.1 years agoOne use I've recently found for radial out/in maneuvering is in very low or at sub orbital levels. It tends to help the best halfway between apoapsis and periapsis, but you can greatly affect your upcoming node while maintaining your previous node and make major adjustment. Only downside is it takes about 20% more delta v over doing burns at a node.
Example, you launch slow, get into sub orbit low and don't quite have the speed to raise a complete orbit before you pass your apoapsis. Common without enough twr starting off the pad. You already have a high enough apoapsis or maybe it's as low, but don't want it at 200k meters before you make it to an orbit, so to correct the situation and maintain say a 90km node(apoapsis or periapsis) you pitch 45 degrees to radial out or if it's really bad full radial out. Then by pitching between full radial out and less than full (all prograde direction burning) you can essentially maintain the past point or raise it more if close to it, and drastically change the periapsis to make an orbit and not dip in and out of the atmosphere wasting delta v just getting up there, or having a massive apoapsis you now have to retro burn to bring back down.
By using the radial in, in a retrograde direction, it will bring the coming apoapsis down, but not affect the periapsis, like if you were to be aerobraking, and have a little more left to bleed off, plenty of delta v, and no more atmosphere until you come around again, you can use this type of radial in retrograde burn to keep your periapsis but lower your apoapsis down more. These menuvers have the greatest effects at halfway between between Ap and Pe, but will work the same closer to these nodes, but with lesser effect to the furthest node the further from between the two you are.
Little difficult to explain on paper, but a quick try while watching your ap and pe as you do the burns and it will make sense.
3.1 years ago