Shot 1 is an auto-tracking camera program(WIP). Still lacking major functionality, but I'm getting closer to a useable product. Automatically sets the target to the closest non-player craft but also allows the user to select a target from a list of all crafts within the current planet's SOI(for now) at any time. Using a simple motor/rotator setup to "gymbal" the camera on 2 axes coupled to sliders, it automatically tracks moving targets(ie, a rocket launch/landing) along with adjusting the zoom to keep the target in frame(when possible). Currently this is a demonstration model to prove the concept before developing a complete auto tracking camera system for multiple use cases.
Shot 2 is my first real attempt at implementing a simple PID to make a rocket hover at a predetermined altitude. Results have been lackluster with many hours spent in frustration agonizing over bugs and various implementations of the processes involved. While the PID itself works flawlessly, the current implementation of the overall code makes it nearly useless. Overcorrection and "bouncing" between extremes is inevitable, and even when it seems to balance out close to the target Integral creep causes wild variations in output after a while. Needs more testing and a complete rebuild from the ground up
It's just a slightly more complex ranking system. It's been redone and added onto because of the shear number of users and how quickly some users got to the original highest rank.
Each color is split into 4 sub-ranks denoted by 1-3 bars or stars depending on your points. This makes it easier to tell how close someone is to ranking up to another color without doing math. It also just looks cooler like that lol
But the launch towers are built into the launchpad facilities used for them. The tower itself doesn't move. You must be talking about the massive transport vehicle that moved those LVs to the pad and functionally served as the bottom of the pad as well
A launch tower is stationary, while a gantry moves out of the way. Systems like the Saturn V and Space Shuttle used launch towers(although the quick disconnect systems are technically just small gantries). Soyuz on the other hand uses a wraparound gantry tower that opens from the top like a flower immediately after ignition. A lot of smaller rockets use gantries too. I'm not sure exactly why one system is chosen over the other for different applications, but I'm sure it boils down to economics and the reliability of the rocket in question.
Interesting idea. Not sure if it's really practical, but seeing as this game's still just a sandbox, I guess it doesn't really matter lol. It also depends on the scale and complexity of what you want to accomplish. If it works in KSP, it should work here too, right? I'm interested to know if it does. Best of luck with your project
@Hashys lol yeah, it's about as ridiculous as it sounds. I'm basically a low level supervisor for a major carnival company on the west coast. I spend about 6 months of the year traveling with the carnival working almost nonstop, then the rest of the year I can do whatever. My average weekly hours were closer to 70(12 hours a day 6 days a week is 72 hours) but I had a couple weeks above 80(the most so far is 85 hours in one week). We also work for 20-30ish hours straight on teardown nights. We run the carnival all day, close for the day, then immediately spend 16 hours tearing everything down throughout the night so we can leave the next morning to the next spot. It's brutal work, but the pay is good and having 6 months off is even better. I made about $30,000 in 6 months which is more than I make in an entire year doing my other job(security). I've also been learning a lot about mechanical stuff, engineering, hydraulics systems, computers, electrical, etc etc
Math. It's the only reliably repeatable method. It's also kinda hard so 🤷. Look up stuff about satellite rendezvous and launch guidance. It also helps to have a good understanding of orbital elements. The biggest challenge for you is gonna be accounting for the planets rotation. Launching into an equatorial (0° inclination) orbit doesn't make as much difference, but the higher the target inclination, the more the planets rotation effects your actual orbit. Using vizzy, you can calculate the future position of the target and account for the plabet's rotation to determine the ideal launch window
@sacr3dbac0n0 also, I made a series of programs that can determine drag force in realtime using the equations for drag that look similar to what's below. The specific coefficient of drag for any craft can be found by letting it freefall through the atmosphere while running the calculations(this is the first of my programs. It works for any craft shape/size and in any atmosphere). Then you use the "average" drag coefficient to run the drag calculations in realtime(the second program). Using this method, I've gotten surprisingly accurate results, in fact nearly identical to the games own calculations. I haven't uploaded those yet as they're not quite finished to my liking, but I'll try to make them available soon. The equations for lift are very similar and could probably be calculated using a similar method, but I haven't tried it yet
Like someone stated before, you have to upload your image to a hosting site like Discord, Reddit, imgur, or something else you have access to that allows for public sharing. Then you have to copy the link and insert it into the proper formatting as shown below. If you use a site that doesn't work, try another one. And yeah, you can just edit the existing post until it works instead of making a new one every time. It gets kinda annoying
It's been a while, but not that I know of. If my foray into drag taught me anything there's an easier way to do that using what the game offers. Take the acceleration vector and subtract everything that isn't lift from it(gravity, drag, thrust, etc). You probably have to do some projecting of vectors, but if done right, the ONLY type of acceleration left will be from lift, and you can then convert that back into force units or whatever from there
@TritonAerospace that makes more sense now. I figured it was something for a moveable part. To isolate a single component of a vector, you either multiply the vector by the unit vector(in this case (vector*(0,0,1))) or you find the (vector()(z axis)) block in the math tab and input the vector there. Also, I forgot to mention, Unity uses a weird coordinate system that makes some stuff backwards, so you might have to play with it. In standard coordinates, x and y go from the center of the planet to the equator and z goes to the poles, but unity has x and z on the equator and y going through the poles. This isn't a big deal, but it makes it more complicated when doing vector math because you have to remember everything is backwards or it won't work right(especially with cross products :/ the cross product of two vectors will always be at 90° to the original two, but in unity it's the opposite direction from standard)
And no problem, it took me months of messing around with vectors to finally understand how they work. I even had to go through a number of physics textbooks at the library just to get a good understanding of them(and I still have problems lol)
Also, it's been a while(about a year in fact) since I've done much with vectors and stuff in the game. I also can't remember the easy way to find pitch yaw and roll using an arbitrary vector, and it's not easy to find the specific post it was in
So I'm still kinda lost on exactly what you're trying to do with this. Maybe you could explain what the purpose of the code is and how it's supposed to work.
There's also a few things that I gotta point out to help you. To start, the [nav(position)] block returns a value in vector format, so there's no need to put that in a (vec()()()) block. Second, the [nav(position)] block gives you the line from the center of the parent body to the "center" of the craft(or part). This line will ALWAYS point straight up from the ground unless you do some vector math with it.
I think I kinda see what you might be trying to do and I might have a better way. Subtract the [part()(position)] vector from the [Nav(position)]{or another parts position} vector(or the other way around if that's backwards). This will give you a new vector that goes from the part to the "center" of the craft(or another part) and you can then measure the angle between this vector and a few others(nav position and cross products) to get pitch, yaw, roll(if done properly, for a specific part of a craft, seperately from the crafts actual pitch,yaw,roll)
Jk, but I'm not sure exactly how. I believe you have to manually add it to the game files, so be careful if you do. I've never bothered trying any of that though, so idk
Hmmm. Something about that doesn't seem right. (0,0,1) is a unit vector with a magnitude of 1 in the z axis, which you can use to constrain a vector in a specific direction or turn a non-vector value into a vector in the specified direction. In PCI (0,0,1) will always point in the same direction relative to space and is therefore a constant value[(1,0,0) and (0,1,0) being the x and y unit vectors respectively]. In local, the x, y, and z axes are fixed to the craft and change values as the craft moves. The x axis is the crafts roll axis, y is pitch, and z is yaw.
The actual PCI coordinates of whatever part you're messing with should look more like: (3.937153849,1.765893355,0.00027370) and at least two of those numbers will slowly but constantly change even if the craft is grounded because the planet is rotating underneath
Look up "Earth Centric Inertial coordite system" to get a pretty good rundown of exactly how PCI(Planet Centered Inertial) works. If you've already gotten that far, it's just a matter of finding the right block in vizzy. Gimme a bit and I'll check it out
That's where the efficiency comes from though. You conserve on mass and internal energy requirements by accelerating very slowly through use of charged particles
@Zenithspeed I really wish the devs could add some kind of Lagrange point mechanics. I know it's not easy to do n-body physics, so that's probably not an option. Maybe even just an invisible "planet" that stays in the same position relative to the parent and just change the soi over once close enough, idk
@plane918273645 also, you could just project the vector onto North and East, then add those vectors to get a vector that's tangential to the ground and still pointing the right direction
@plane918273645 I meant to add that it needs to be flattened, but I'm too busy with work and stuff to even notice stuff like that lol. Really I was just trying to give ideas. Besides, it's not that inaccurate. I have a ballistic missile launch code that uses the same idea for heading guidance
@TritonAerospace variables. Use the [set variable() to ()] block to set previous position to current position. Then wait 1 second. Now the current position from 1 second ago is the previous position. Rinse, cycle, repeat. The timestep can be any amount you want, not just 1 second, but it illustrates the point easily. Something like .1 seconds is more accurate for any practical uses.
Not sure exactly what you mean there. In vizzy there's a block that gives target info like it's position and velocity vectors, and use that to find the direction the target is moving(current target position - previous target position will give you a vector along the path of the target's flight. Then use [(nav north) angle (target path vector)] to find the angle
Could be. Could be your settings, or the launch location. Maybe you've downloaded a custom system? Idk there's a lot of potential reasons for it to be weird like that
@PointBreak I'm not sure, but the link comes from the Chinese version of NASA, so it might be an international server thing, or it could be my phone, or even just Google's settings, idk. Thanks so much for that though, I really appreciate it! 😎
@SamTheFox in a nutshell, yes. There's a bunch of other stuff(mostly theoretical physics and relativity among other things) that goes into it, but everything in the game is going to be based off these equations and general ideas(even if a different specific equation is used). Really though, everything in the book is pretty much all the info you need to send rockets to anywhere in our solar system and even beyond(even if it takes forever)
That's actually a really good idea! I never really liked the basic wings that only look like a flat panel no matter what, and having to hide the "real" wings inside of "fake" wings made from fuel tanks and rotators is tedious and time consuming at best. I actually wonder why Jundroo never made wings shapeable in the first place(at least beyond what we currently have), but oh well
Yes, and no... The "primary" chip will always be the main one, and is absolutely required to fly/drive a craft. However, you can broadcast to any other chips to start secondary programs(or another craft's program). Basically, yes you can have multiple chips with multiple programs running at once (or one overall program with smaller subprograms on different chips), but you will always have the same primary chip in control of things
Honestly though, I'm not sure what you mean by that lol. As far as the actual speed that light particles/waves move goes, it's all the same regardless of the color/spectrum. As far as frequency goes, violet would be fastest with a very high frequency and red the slowest(if only counting "visible" light). As far as what color "looks" the fastest, it's probably red, orange, or yellow because those are warning colors in nature and your brain is specifically wired to pick those colors out and notice them first
@Matteovir yeah, the devs mentioned that the last couple updates probably broke a lot of mods since the actual base code of the game changed so much so quickly, especially since the damage models and part properties have been redone(I think physics was updated too, but not exactly sure how). Some mods probably still work, and others have already been fixed by their creators, but not all of them are actively maintained or easy to update, so it might be a while before they work again
You have to wait for it like the rest of us. It's the next major update, but there's doubtless a few more smaller updates/patches before that happens. Just give it time
@Zenithspeed lol true, but that's the only way to actually play around with mods. And I'm an avid mobile user, so I wish it wasn't the way it is, but we can't really change it. Also, it was mostly just a joke, but I also had no choice but to buy a PC and the game again just to mess around with mods, so 🤷
Step 1: go to Amazon or Best Buy
Step 2: buy a PC
Step 3: download Steam
Step 4: buy SimpleRockets 2 on Steam
Step 5: download mods
Step 6: throw away your phone/tablet
Step 7: have fun!
@Sushiboi honestly I'm not sure. I'm trying to not overcomplicate things, but I don't know if I can with that. The method of determining the angle difference between planes works regardless of the orientation of the vectors used. As far as the RAAN and inclination go, I think you'd have to measure the difference of each individually then use some sort of function to determine when and where to burn to match orbits. Assuming you're trying to rendezvous or parking into a specific orbital location, then it would take multiple small maneuvers to adjust inclination, RAAN, and SMA individually as opposed to all at once. You'd want to line up the line of nodes for both orbits first(1-2 maneuvers), then adjust inclination(1-3 maneuvers), and finally adjust SMA(1-3 maneuvers). The book I linked should have a pretty good overview of the particular maneuvers involved, especially plane changes
Okay, so assuming you can find the Semi-Major Axis of both current and target orbits, you can find the angle between the normal vectors. In other words use ((norm(SMA)) angle (norm(SMA))) to find the angle between the two planes regardless of orbit orientation
@Sushiboi I don't currently have a simple answer to that. The book I shared has the equations and stuff in chapter 6.9 page 290, but it's pretty well involved
@TronicOrbital technically, broadcasting just starts a new thread. You can broadcast to another portion of the same program, another program on another chip, or a completely seperate craft. The receiving end will only activate if the broadcasting end matches the name, but the data that gets broadcast can be anything and won't effect the broadcasting. It's useful if you need to send data to a particular part or start a new instruction set with data from the previous instruction set, and helps to make more modular codes
@Ylias f
+1 2.0 years ago@Ylias d
+1 2.0 years ago@GaryamaxInc lol, yeah Innova Aerospace is a good one. Different from the norm and I like the connotation of "Innova(tion)"
2.0 years ago@Ylias b
+1 2.0 years agoShot 1 is an auto-tracking camera program(WIP). Still lacking major functionality, but I'm getting closer to a useable product. Automatically sets the target to the closest non-player craft but also allows the user to select a target from a list of all crafts within the current planet's SOI(for now) at any time. Using a simple motor/rotator setup to "gymbal" the camera on 2 axes coupled to sliders, it automatically tracks moving targets(ie, a rocket launch/landing) along with adjusting the zoom to keep the target in frame(when possible). Currently this is a demonstration model to prove the concept before developing a complete auto tracking camera system for multiple use cases.
Shot 2 is my first real attempt at implementing a simple PID to make a rocket hover at a predetermined altitude. Results have been lackluster with many hours spent in frustration agonizing over bugs and various implementations of the processes involved. While the PID itself works flawlessly, the current implementation of the overall code makes it nearly useless. Overcorrection and "bouncing" between extremes is inevitable, and even when it seems to balance out close to the target Integral creep causes wild variations in output after a while. Needs more testing and a complete rebuild from the ground up
2.0 years agoSpaghettiCode
2.0 years agoIt's just a slightly more complex ranking system. It's been redone and added onto because of the shear number of users and how quickly some users got to the original highest rank.
Each color is split into 4 sub-ranks denoted by 1-3 bars or stars depending on your points. This makes it easier to tell how close someone is to ranking up to another color without doing math. It also just looks cooler like that lol
+1 2.1 years ago@Toinkove confused look
But the launch towers are built into the launchpad facilities used for them. The tower itself doesn't move. You must be talking about the massive transport vehicle that moved those LVs to the pad and functionally served as the bottom of the pad as well
+1 2.1 years agoA launch tower is stationary, while a gantry moves out of the way. Systems like the Saturn V and Space Shuttle used launch towers(although the quick disconnect systems are technically just small gantries). Soyuz on the other hand uses a wraparound gantry tower that opens from the top like a flower immediately after ignition. A lot of smaller rockets use gantries too. I'm not sure exactly why one system is chosen over the other for different applications, but I'm sure it boils down to economics and the reliability of the rocket in question.
+1 2.1 years agoInteresting idea. Not sure if it's really practical, but seeing as this game's still just a sandbox, I guess it doesn't really matter lol. It also depends on the scale and complexity of what you want to accomplish. If it works in KSP, it should work here too, right? I'm interested to know if it does. Best of luck with your project
+2 2.1 years ago@Hashys lol yeah, it's about as ridiculous as it sounds. I'm basically a low level supervisor for a major carnival company on the west coast. I spend about 6 months of the year traveling with the carnival working almost nonstop, then the rest of the year I can do whatever. My average weekly hours were closer to 70(12 hours a day 6 days a week is 72 hours) but I had a couple weeks above 80(the most so far is 85 hours in one week). We also work for 20-30ish hours straight on teardown nights. We run the carnival all day, close for the day, then immediately spend 16 hours tearing everything down throughout the night so we can leave the next morning to the next spot. It's brutal work, but the pay is good and having 6 months off is even better. I made about $30,000 in 6 months which is more than I make in an entire year doing my other job(security). I've also been learning a lot about mechanical stuff, engineering, hydraulics systems, computers, electrical, etc etc
+1 2.1 years agoMath. It's the only reliably repeatable method. It's also kinda hard so 🤷. Look up stuff about satellite rendezvous and launch guidance. It also helps to have a good understanding of orbital elements. The biggest challenge for you is gonna be accounting for the planets rotation. Launching into an equatorial (0° inclination) orbit doesn't make as much difference, but the higher the target inclination, the more the planets rotation effects your actual orbit. Using vizzy, you can calculate the future position of the target and account for the plabet's rotation to determine the ideal launch window
2.1 years agoD = Cd * A * .5 * r * V^2
Cd = D / (A * .5 * r * V^2)
2.1 years ago@sacr3dbac0n0 also, I made a series of programs that can determine drag force in realtime using the equations for drag that look similar to what's below. The specific coefficient of drag for any craft can be found by letting it freefall through the atmosphere while running the calculations(this is the first of my programs. It works for any craft shape/size and in any atmosphere). Then you use the "average" drag coefficient to run the drag calculations in realtime(the second program). Using this method, I've gotten surprisingly accurate results, in fact nearly identical to the games own calculations. I haven't uploaded those yet as they're not quite finished to my liking, but I'll try to make them available soon. The equations for lift are very similar and could probably be calculated using a similar method, but I haven't tried it yet
2.1 years agoLike someone stated before, you have to upload your image to a hosting site like Discord, Reddit, imgur, or something else you have access to that allows for public sharing. Then you have to copy the link and insert it into the proper formatting as shown below. If you use a site that doesn't work, try another one. And yeah, you can just edit the existing post until it works instead of making a new one every time. It gets kinda annoying
2.1 years ago@SamTheFox as a side note, that's nearly the same as the drag equation lol
2.1 years agoIt's been a while, but not that I know of. If my foray into drag taught me anything there's an easier way to do that using what the game offers. Take the acceleration vector and subtract everything that isn't lift from it(gravity, drag, thrust, etc). You probably have to do some projecting of vectors, but if done right, the ONLY type of acceleration left will be from lift, and you can then convert that back into force units or whatever from there
2.1 years ago@TritonAerospace that makes more sense now. I figured it was something for a moveable part. To isolate a single component of a vector, you either multiply the vector by the unit vector(in this case (vector*(0,0,1))) or you find the (vector()(z axis)) block in the math tab and input the vector there. Also, I forgot to mention, Unity uses a weird coordinate system that makes some stuff backwards, so you might have to play with it. In standard coordinates, x and y go from the center of the planet to the equator and z goes to the poles, but unity has x and z on the equator and y going through the poles. This isn't a big deal, but it makes it more complicated when doing vector math because you have to remember everything is backwards or it won't work right(especially with cross products :/ the cross product of two vectors will always be at 90° to the original two, but in unity it's the opposite direction from standard)
And no problem, it took me months of messing around with vectors to finally understand how they work. I even had to go through a number of physics textbooks at the library just to get a good understanding of them(and I still have problems lol)
+1 2.1 years agoAlso, it's been a while(about a year in fact) since I've done much with vectors and stuff in the game. I also can't remember the easy way to find pitch yaw and roll using an arbitrary vector, and it's not easy to find the specific post it was in
2.1 years ago@TritonAerospace lol it's all good.
So I'm still kinda lost on exactly what you're trying to do with this. Maybe you could explain what the purpose of the code is and how it's supposed to work.
There's also a few things that I gotta point out to help you. To start, the [nav(position)] block returns a value in vector format, so there's no need to put that in a (vec()()()) block. Second, the [nav(position)] block gives you the line from the center of the parent body to the "center" of the craft(or part). This line will ALWAYS point straight up from the ground unless you do some vector math with it.
I think I kinda see what you might be trying to do and I might have a better way. Subtract the [part()(position)] vector from the [Nav(position)]{or another parts position} vector(or the other way around if that's backwards). This will give you a new vector that goes from the part to the "center" of the craft(or another part) and you can then measure the angle between this vector and a few others(nav position and cross products) to get pitch, yaw, roll(if done properly, for a specific part of a craft, seperately from the crafts actual pitch,yaw,roll)
2.1 years agoYou don't.
;)
Jk, but I'm not sure exactly how. I believe you have to manually add it to the game files, so be careful if you do. I've never bothered trying any of that though, so idk
+2 2.1 years ago🖼️ATATATA
2.1 years ago🖼️B
2.1 years agoHmmm. Something about that doesn't seem right. (0,0,1) is a unit vector with a magnitude of 1 in the z axis, which you can use to constrain a vector in a specific direction or turn a non-vector value into a vector in the specified direction. In PCI (0,0,1) will always point in the same direction relative to space and is therefore a constant value[(1,0,0) and (0,1,0) being the x and y unit vectors respectively]. In local, the x, y, and z axes are fixed to the craft and change values as the craft moves. The x axis is the crafts roll axis, y is pitch, and z is yaw.
The actual PCI coordinates of whatever part you're messing with should look more like: (3.937153849,1.765893355,0.00027370) and at least two of those numbers will slowly but constantly change even if the craft is grounded because the planet is rotating underneath
2.1 years agoLook up "Earth Centric Inertial coordite system" to get a pretty good rundown of exactly how PCI(Planet Centered Inertial) works. If you've already gotten that far, it's just a matter of finding the right block in vizzy. Gimme a bit and I'll check it out
2.1 years agoThat's where the efficiency comes from though. You conserve on mass and internal energy requirements by accelerating very slowly through use of charged particles
2.5 years ago@Zenithspeed I really wish the devs could add some kind of Lagrange point mechanics. I know it's not easy to do n-body physics, so that's probably not an option. Maybe even just an invisible "planet" that stays in the same position relative to the parent and just change the soi over once close enough, idk
+1 2.5 years ago@FIREFLYSPACE lol I get that part. What I mean is do you say it "LEED" or "LEDD"?
+1 2.5 years agoI'm just confused by whether it's lead like the metal or lead like "to lead" or "leader"?!?!?!?
2.5 years ago@plane918273645 also, you could just project the vector onto North and East, then add those vectors to get a vector that's tangential to the ground and still pointing the right direction
2.5 years ago@plane918273645 I meant to add that it needs to be flattened, but I'm too busy with work and stuff to even notice stuff like that lol. Really I was just trying to give ideas. Besides, it's not that inaccurate. I have a ballistic missile launch code that uses the same idea for heading guidance
2.5 years ago@TritonAerospace variables. Use the [set variable() to ()] block to set previous position to current position. Then wait 1 second. Now the current position from 1 second ago is the previous position. Rinse, cycle, repeat. The timestep can be any amount you want, not just 1 second, but it illustrates the point easily. Something like .1 seconds is more accurate for any practical uses.
+1 2.5 years agoNot sure exactly what you mean there. In vizzy there's a block that gives target info like it's position and velocity vectors, and use that to find the direction the target is moving(current target position - previous target position will give you a vector along the path of the target's flight. Then use [(nav north) angle (target path vector)] to find the angle
2.5 years agoCould be. Could be your settings, or the launch location. Maybe you've downloaded a custom system? Idk there's a lot of potential reasons for it to be weird like that
2.5 years ago@PointBreak I'm not sure, but the link comes from the Chinese version of NASA, so it might be an international server thing, or it could be my phone, or even just Google's settings, idk. Thanks so much for that though, I really appreciate it! 😎
+1 2.5 years ago@SamTheFox in a nutshell, yes. There's a bunch of other stuff(mostly theoretical physics and relativity among other things) that goes into it, but everything in the game is going to be based off these equations and general ideas(even if a different specific equation is used). Really though, everything in the book is pretty much all the info you need to send rockets to anywhere in our solar system and even beyond(even if it takes forever)
2.5 years agoThat's actually a really good idea! I never really liked the basic wings that only look like a flat panel no matter what, and having to hide the "real" wings inside of "fake" wings made from fuel tanks and rotators is tedious and time consuming at best. I actually wonder why Jundroo never made wings shapeable in the first place(at least beyond what we currently have), but oh well
+1 2.5 years agoYou can do that too. Just use the [switch to craft()] block. The original craft will continue it's vizzy too as long as it's within physics diatance
2.5 years agoYes, and no... The "primary" chip will always be the main one, and is absolutely required to fly/drive a craft. However, you can broadcast to any other chips to start secondary programs(or another craft's program). Basically, yes you can have multiple chips with multiple programs running at once (or one overall program with smaller subprograms on different chips), but you will always have the same primary chip in control of things
2.5 years agoHonestly though, I'm not sure what you mean by that lol. As far as the actual speed that light particles/waves move goes, it's all the same regardless of the color/spectrum. As far as frequency goes, violet would be fastest with a very high frequency and red the slowest(if only counting "visible" light). As far as what color "looks" the fastest, it's probably red, orange, or yellow because those are warning colors in nature and your brain is specifically wired to pick those colors out and notice them first
+2 2.5 years ago@t4zcomz yes!
2.5 years ago@Matteovir yeah, the devs mentioned that the last couple updates probably broke a lot of mods since the actual base code of the game changed so much so quickly, especially since the damage models and part properties have been redone(I think physics was updated too, but not exactly sure how). Some mods probably still work, and others have already been fixed by their creators, but not all of them are actively maintained or easy to update, so it might be a while before they work again
2.5 years agoYou have to wait for it like the rest of us. It's the next major update, but there's doubtless a few more smaller updates/patches before that happens. Just give it time
2.5 years agoDoin a little formation flying, eh? Nice pic! 👍
2.5 years ago@Zenithspeed lol true, but that's the only way to actually play around with mods. And I'm an avid mobile user, so I wish it wasn't the way it is, but we can't really change it. Also, it was mostly just a joke, but I also had no choice but to buy a PC and the game again just to mess around with mods, so 🤷
2.5 years agoStep 1: go to Amazon or Best Buy
2.5 years agoStep 2: buy a PC
Step 3: download Steam
Step 4: buy SimpleRockets 2 on Steam
Step 5: download mods
Step 6: throw away your phone/tablet
Step 7: have fun!
@Sushiboi honestly I'm not sure. I'm trying to not overcomplicate things, but I don't know if I can with that. The method of determining the angle difference between planes works regardless of the orientation of the vectors used. As far as the RAAN and inclination go, I think you'd have to measure the difference of each individually then use some sort of function to determine when and where to burn to match orbits. Assuming you're trying to rendezvous or parking into a specific orbital location, then it would take multiple small maneuvers to adjust inclination, RAAN, and SMA individually as opposed to all at once. You'd want to line up the line of nodes for both orbits first(1-2 maneuvers), then adjust inclination(1-3 maneuvers), and finally adjust SMA(1-3 maneuvers). The book I linked should have a pretty good overview of the particular maneuvers involved, especially plane changes
2.5 years agoOkay, so assuming you can find the Semi-Major Axis of both current and target orbits, you can find the angle between the normal vectors. In other words use ((norm(SMA)) angle (norm(SMA))) to find the angle between the two planes regardless of orbit orientation
2.5 years ago@Sushiboi I don't currently have a simple answer to that. The book I shared has the equations and stuff in chapter 6.9 page 290, but it's pretty well involved
2.5 years ago@TronicOrbital technically, broadcasting just starts a new thread. You can broadcast to another portion of the same program, another program on another chip, or a completely seperate craft. The receiving end will only activate if the broadcasting end matches the name, but the data that gets broadcast can be anything and won't effect the broadcasting. It's useful if you need to send data to a particular part or start a new instruction set with data from the previous instruction set, and helps to make more modular codes
2.6 years ago