Docking is indeed pretty difficult in SR2. I think the main improvements we can hope for in future updates are 1) improved magnetic attraction physics that makes it more likely docking will be successful, and 2) adjustable tolerance settings for the Docking Port part. As it is though, with proper technique and well a designed craft you should be able to dock with a high rate of success. Here are a few tips:
Make sure your craft is maneuverable (RCS properly oriented around the center of mass).
Make sure RCS and Gyro power is appropriate for your mass (too much and it will be too twitchy, to little and it will be sluggish).
Slow is Pro! Don't move two quickly as you approach the target craft, if you bump into it and send it spinning this will not go well.
Utilize Quick Save so you get try again if things go sideways.
Use Chase View so that RCS translation controls behave predictably.
Utilize heading lock (including lock to target) and target relative velocity indicator (note, it may be advisable to avoid locked heading at the last moment so that the attractor can align your craft).
Lastly, if you are using PC, I will shameless like plug my Docking HUD Mod.
I haven't seen anything like the expressions described in "Funky Trees" documentation, in SR2 craft XML, but I am no expert. I think you can achieve some similar things using the native XML elements and attributes based on what is described in the SR2 XML Guide.
So several of the issues I pointed out originally were still relevant, but the solution is obviously quite different then what I described before. To restate the problem: the goal is to activate stages when specific parts (bombs) are in a particular position relative to the craft as they rotate around a central drum. There are several ways to skin this cat: you could check the orientation of the drum itself, you can check the angle between a vector to the bombs and some reference angle, or you can explicitly check the position of the bombs. I elected to check the position because it was the closest to the original and didn't require any complex vector math. The implementation I used was to take the PCI position of the rotating drum (part 162) and subtract it from the PCI position of the bomb to be dropped, which gives us a PCI vector from the COM of the drum to the bomb; then convert that into the craft's local frame of reference (we don't want to use the PCI frame of reference because it would give us different vectors as the craft orientation changed relative to the planet, and we don't want to use the frame of reference of the shaft or anything rotating because that would result in a constant vector, i.e. the bombs are not moving with respect to the drum they're attached to); once we have the craft relative vector from the drum to the bomb we subtract it from the desired position, and if the length of the resulting vector is less than 3mm we activate the stage. I won't write this up in text since you can see it in the screen shot on the craft.
@DoublehshAerospace I think that is a reasonable opinion. Since those milestones will be relatively infrequent, I think that if people follow your suggestion it won't create too much noise in the forum.
@Massdi The url you are using content://com.android.chrome... is not valid (except maybe on your device). You need to upload this image to some public hosting service. The url should start with http:// or https:// and the host needs to be publicly accessible.
Oh haha I Completely misinterpreted what you were trying to do. That makes way more sense. I'll take another look now that I understand what you were actually trying to do.
I believe they are accurate, but be aware that when you resize fuel tanks it is indicating radius not diameter. So if you are using specifications that indicate diameter and forget to divide by 2 you will end up with a very fat rocket.
@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.
The primary issue is that the expression part [number] |PCI to Local| [pci_vector] doesn't do what you think it does. First, the vector must be in PCI coordinates and relative to the part, and this instruction will change its orientation into the local coordinate system of the part. What this means is using a fixed vector like (0, -0.83, -0.92) doesn't make much sense assuming you want to hit a target on the ground. What you will probably want to do is start with a lat/lon/agl position, and convert that to PCI. Additionally you will need to take the difference between the part position and the target position. Second, that expression returns a vector, and you can't wait until a vector. You need to use that vector in some kind of comparison to make it a boolean value (i.e. true or false). To do this you will want to define some range limit, and then compare that with the the length of the resulting vector. Lastly you need to account for altitude, since I'm assuming you want to drop ordinance when you are above the target position (as opposed to dropping down to near ground level and dropping ordinance from point blank range). Given all that your instructions might look something like this:
> wait until [ [ [ part [322] |PCI to Local| [ [convert [ vec [-0.83], [-0.92], [ altitude |AGL| ] ] to position] - [ part [322] |Position| ] ] ] length ] < 500 ]
> activate stage
And you can actually drop the PCI to Local entirely because it only affects orientation, and you're just checking length, so: [ [ [ [convert [ vec [-0.83], [-0.92], [ altitude |AGL| ] ] to position] - [ part [322] |Position| ] ] ] length ] < 500 is what you want.
I will leave adding adjustments to compensate for lateral velocity as an exercise to the reader, because if you release your weapons directly above the target while traveling at 200 kph you are probably going to miss the target. If you're lazy you can probably just assume a certain altitude and airspeed and tweak the range accordingly.
This is done by editing the xml for the craft and setting the respective attributes to a value that is greater than the maximum allowed in the UI. My understanding is that there are apps for Android you can use to edit the craft xml files, but I'm not an android user so I don't know the details. You might find this guide I found on Reddit useful.
You shouldn't have to use custom expressions for this, although they may be useful. If any of the notation I'm using below is confusing here is a guide. It will definitely be useful to have a solid grasp on vizzy fundamentals in order to complete such a flight program (although sometimes the best way to learn is by doing).
If you include a screenshot in your post it will be easier to see what might be going wrong. You can also try asking in the #vizzy channel on the SimpleRockets Chat Discord
If what you are focused on is a transfer to the moon you are implementing a basic Hohmann transfer rendezvous. Luna's orbit is very slightly eccentric, so there may be a little error, but you can probably either ignore that, or make a small correction in your delta-v to account for it and still get a rendezvous. Executing a Hohmann transfer involves basically three things: determine the angle of departure, determine the amount of delta-v, determine the craft orientation for the burn. The last one can probably be skipped and you can just burn prograde. Determining the angle of departure requires you to determine the period of your transfer orbit (periapsis = your current orbit, apoapsis = average distance of Luna's orbit). Once you know your transfer orbit period, you know the number of degrees you need between your position and Luna's position: 180 - [ [360 / $lunas_period] * [$transfer_period / 2] ]. To describe this in simple terms, you are going to make half of an elliptical orbit from your current altitude out to Luna's orbit, during that time Luna is going to rotate through a fraction of its orbit, you want to depart while Luna positioned before your arrival point such such that it reaches your arrival point around the same time you do. Determining the amount of delta-v is necessary so that you know how much time the burn will take so that you can start the burn slightly before the actual target angle. You can find the amount of delta V by comparing your current circular orbit velocity which should be constant to the periapse velocity of your desired transfer orbit. For a circular orbit velocity is |sqrt| [ $mu / $semi_major_axis ] and for your elliptical transfer orbit the periapsis velocity is |sqrt| [ [$mu / $transfer_sma] * [ [1 + $e] / [1 - $e] ] ] where $e is your transfer orbit's eccentricity. Give your delta-v requirement you can calculate your burn time, either rough approximation $delta_v / [ [ performance |Max Engine Thrust| ] / [ performance |Mass| ] ] or using a more accurate method. Then you can adjust your burn start angle to the following $departure_angle + [ [ 360 / [ orbit |Period| ] ] * [ $burn_time / 2 ] ]. That should put you on a transfer orbit for a rendezvous with Luna. You will want to time your burn cut off based on your orbit Apoapsis (you want to burn until your apoapsis is the same as Luna's average orbit distance). Getting an ideal rendezvous with a specific periapsis is
In order to share a sandbox you need to be in the flight view (i.e. launch a new craft, or resume an existing flight). Then on the flight menu panel click the share button (box with an up arrow).
Also here is the missile I was talking about. It plots the ballistic re-entry of a target ignoring drag, and does a ham handed job of projecting and guiding the trajectory of the missile that is fired at it.
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:
You need to be in translate mode to "go straight" with RCS, which you get to by pressing T or using the button icon with the four way arrow on the right hand side of the screen.
It's also important that you have your RCS thrusters correctly positioned around your center of mass (COM), and with sufficient monoprop tanks.
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.
I'm on a Mac and have been able to set the texture of parts without difficulty. In quality settings if craft textures and normal maps are both disabled then you won't see any textures.
Different parts should have different reliability scores. Reliability might be based on shape (like in the case of wings), the mass of things attached to them (like hinges), or their parameters (like engines with different fuel types/pressures/etc). A part should have a probability of failure curve that increases over time used/activated (for things like wings this would only count time in atmosphere, for engines it would only count time where the engines were firing). Parts could have penalties for cycling (i.e. slamming the throttle up and down over and over again should wear an engine out more quickly). At any point an active part could randomly fail (low probability early on, more probably as time and penalties increase). Parts should have different possible failure modes: becomes non responsive (i.e. an activatable part stops functioning), structural failure (one ore more of its part connections disconnects), or explosion (limited to fuel tanks and engines). Assuming there is some legitimate reusability component of career mode, crafts being reused should carry forward their time/use penalty unless money is spent to "refurbish" the craft thereby resetting the reliability scores. Assuming there is some sort of tech tree component to career mode, players should be able to spend R&D dollars to increase the base reliability of different parts.
This would encourage players to build redundant systems, have launch abort/escape systems, minimize stress/heat damage to parts, and avoid excessive throttle adjustment.
There are a number of auto launch scripts out there, including one that I've made, so while I wasn't planning on including this it would be trivial to combine these given a suitable launch vehicle.
I'm actively working on this. I've come up with a solution that mostly works for circular orbits and I'm currently working on adapting it to work for elliptical orbits (but no support for inclined orbits) as well as refining the departure angle equations.
You have two options: 1) use a cargo bay, which will have a significant impact on the design of your capsule, or 2) make a hollow capsule using struts or panels, and then make a door by attaching one or more struts or panels to a hinge rotator. Constructing this kind of component requires some pretty meticulous work in the designer.
List values need to be stored in list variables, which are created using the blue "create list variable" button at the bottom of the Lists toolbox. If you are just typing in a name as text when setting or accessing your list that won't work. While the requirement of creating variables that can be drag and dropped in place is an extra step, it adds the convenience of being able to quickly rename the variable everywhere it is used. It is possible there are other issues with how you are using lists, but it's hard to tell. It is always best to include a screenshot of your Vizzy. However I can assure you that lists do generally work.
So long as you are close enough to the surface you can determine the elevation of points on the surface by getting the getting the lat/long/AGL of a given point, dropping the AGL component to zero, and converting back to PCI. The difference between the magnitude of that vector and the mean sea level is the elevation of the surface at that point (not sure if this works for terrain below sea level). Here is a fighter jet that calculated the slope of the terrain directly below it.
time % 60 will give you the current second from 0 to 59 (1 to 59 doesn't make sense since there are 60 seconds in a minute, not 59). If you display this in a look with a short wait (0.1 seconds or less) you should have a display that is accurate to within a tenth of a second so long as you have ample CPU power. In theory the game engine may not run vizzy for longer periods of time if the CPU is bogged down by physics, graphics, or other processes.
This Falcon 9 has such a vizzy script. It defaults to 100km, but I believe it has enough Delta-V to make 150km without trouble, and tweaking the program should be trivial.
There are lots of things in the Vizzy program that will need to change such as the names of the planetary bodies to target, the apoapsis to reach the target (which is hard coded), the phase angle for the transfer orbit burn (which is dependent on the initial and target apoapsis), also the either the flight program or the craft will need to be adjusted because the program makes assumptions about when stages will be expended while reaching orbit which are not valid for Kerbin because it is smaller than Droo. The flight program is a little hard to get to because it is on a part besides the primary command chip, but you can use the part list (click the magnifying glass on the left hand side of the designer), the flight program is on a part called Vizzy Here. Go through the flight program, try to understand what it is doing on step ate a time and where you see planetary body names and related constants replace them with the Kerbol equivalents.
Note: this script should adaptable to Kerbin/Mun, but getting to Minmus will take some extra logic because of inclination.
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.
I have not experienced any issue with hinge rotators in 0.9.2xx - 0.9.4xx. Make sure the part is Active and your input is configured correctly. If the problem persists you should certainly file a bug report and/or share your craft, I would be happy to take a look to see if it's an XML issue..
Seriously though "better" is kinda subjective but I think Methalox with a full flow staged engine is pretty good for launch and Hydrogen with a nuclear thermal engine is good for orbital maneuvers. Part of the fun is learning what Isp is and exhaust velocity and engine cycles and TWR, not to mention experimentation and trying different designs for yourself. So you tell me, what are the best fuels?!
Everybody should upvote this feedback suggestion. It was submitted by a developer, so I think it will probably be addressed.
+4 4.4 years agoDocking is indeed pretty difficult in SR2. I think the main improvements we can hope for in future updates are 1) improved magnetic attraction physics that makes it more likely docking will be successful, and 2) adjustable tolerance settings for the Docking Port part. As it is though, with proper technique and well a designed craft you should be able to dock with a high rate of success. Here are a few tips:
Lastly, if you are using PC, I will shameless like plug my Docking HUD Mod.
+8 4.4 years agoI haven't seen anything like the expressions described in "Funky Trees" documentation, in SR2 craft XML, but I am no expert. I think you can achieve some similar things using the native XML elements and attributes based on what is described in the SR2 XML Guide.
4.4 years agoSo several of the issues I pointed out originally were still relevant, but the solution is obviously quite different then what I described before. To restate the problem: the goal is to activate stages when specific parts (bombs) are in a particular position relative to the craft as they rotate around a central drum. There are several ways to skin this cat: you could check the orientation of the drum itself, you can check the angle between a vector to the bombs and some reference angle, or you can explicitly check the position of the bombs. I elected to check the position because it was the closest to the original and didn't require any complex vector math. The implementation I used was to take the PCI position of the rotating drum (part 162) and subtract it from the PCI position of the bomb to be dropped, which gives us a PCI vector from the COM of the drum to the bomb; then convert that into the craft's local frame of reference (we don't want to use the PCI frame of reference because it would give us different vectors as the craft orientation changed relative to the planet, and we don't want to use the frame of reference of the shaft or anything rotating because that would result in a constant vector, i.e. the bombs are not moving with respect to the drum they're attached to); once we have the craft relative vector from the drum to the bomb we subtract it from the desired position, and if the length of the resulting vector is less than 3mm we activate the stage. I won't write this up in text since you can see it in the screen shot on the craft.
+1 4.4 years agoHere you go. I can explain the code shortly.
+1 4.4 years ago@DoublehshAerospace I think that is a reasonable opinion. Since those milestones will be relatively infrequent, I think that if people follow your suggestion it won't create too much noise in the forum.
+1 4.4 years ago@Massdi The url you are using
4.4 years agocontent://com.android.chrome...is not valid (except maybe on your device). You need to upload this image to some public hosting service. The url should start withhttp://orhttps://and the host needs to be publicly accessible.Oh haha I Completely misinterpreted what you were trying to do. That makes way more sense. I'll take another look now that I understand what you were actually trying to do.
+1 4.4 years agoInstructions are pinned to the top of the forum. I would say you can't miss 'em, but....
+1 4.4 years agoI believe they are accurate, but be aware that when you resize fuel tanks it is indicating radius not diameter. So if you are using specifications that indicate diameter and forget to divide by 2 you will end up with a very fat rocket.
+1 4.4 years agoI'm excited to see some good SR2 machinima. I used to love Red vs. Blue back in the day.
4.4 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 agoHere's my tweaked version that basically seems to work (only drops the first pair of bombs).
4.4 years agoThe primary issue is that the expression
part [number] |PCI to Local| [pci_vector]doesn't do what you think it does. First, the vector must be in PCI coordinates and relative to the part, and this instruction will change its orientation into the local coordinate system of the part. What this means is using a fixed vector like(0, -0.83, -0.92)doesn't make much sense assuming you want to hit a target on the ground. What you will probably want to do is start with a lat/lon/agl position, and convert that to PCI. Additionally you will need to take the difference between the part position and the target position. Second, that expression returns a vector, and you can'twait untila vector. You need to use that vector in some kind of comparison to make it a boolean value (i.e.trueorfalse). To do this you will want to define some range limit, and then compare that with the the length of the resulting vector. Lastly you need to account for altitude, since I'm assuming you want to drop ordinance when you are above the target position (as opposed to dropping down to near ground level and dropping ordinance from point blank range). Given all that your instructions might look something like this:And you can actually drop the
PCI to Localentirely because it only affects orientation, and you're just checking length, so:[ [ [ [convert [ vec [-0.83], [-0.92], [ altitude |AGL| ] ] to position] - [ part [322] |Position| ] ] ] length ] < 500is what you want.I will leave adding adjustments to compensate for lateral velocity as an exercise to the reader, because if you release your weapons directly above the target while traveling at 200 kph you are probably going to miss the target. If you're lazy you can probably just assume a certain altitude and airspeed and tweak the range accordingly.
4.4 years agoThanks everyone. I'm excited to be able to help out here on the website.
+9 4.4 years agoRules > Don't abuse the voting system > "Don't beg other users to upvote your stuff."
It's very cute that your reputation happens the be a notorious http status code, but that is no excuse for misleading titles, or begging for votes.
4.4 years agoThis is done by editing the xml for the craft and setting the respective attributes to a value that is greater than the maximum allowed in the UI. My understanding is that there are apps for Android you can use to edit the craft xml files, but I'm not an android user so I don't know the details. You might find this guide I found on Reddit useful.
+1 4.4 years agoYou shouldn't have to use custom expressions for this, although they may be useful. If any of the notation I'm using below is confusing here is a guide. It will definitely be useful to have a solid grasp on vizzy fundamentals in order to complete such a flight program (although sometimes the best way to learn is by doing).
4.4 years agoIf you include a screenshot in your post it will be easier to see what might be going wrong. You can also try asking in the #vizzy channel on the SimpleRockets Chat Discord
+1 4.4 years agoIf what you are focused on is a transfer to the moon you are implementing a basic Hohmann transfer rendezvous. Luna's orbit is very slightly eccentric, so there may be a little error, but you can probably either ignore that, or make a small correction in your delta-v to account for it and still get a rendezvous. Executing a Hohmann transfer involves basically three things: determine the angle of departure, determine the amount of delta-v, determine the craft orientation for the burn. The last one can probably be skipped and you can just burn prograde. Determining the angle of departure requires you to determine the period of your transfer orbit (periapsis = your current orbit, apoapsis = average distance of Luna's orbit). Once you know your transfer orbit period, you know the number of degrees you need between your position and Luna's position:
4.4 years ago180 - [ [360 / $lunas_period] * [$transfer_period / 2] ]. To describe this in simple terms, you are going to make half of an elliptical orbit from your current altitude out to Luna's orbit, during that time Luna is going to rotate through a fraction of its orbit, you want to depart while Luna positioned before your arrival point such such that it reaches your arrival point around the same time you do. Determining the amount of delta-v is necessary so that you know how much time the burn will take so that you can start the burn slightly before the actual target angle. You can find the amount of delta V by comparing your current circular orbit velocity which should be constant to the periapse velocity of your desired transfer orbit. For a circular orbit velocity is|sqrt| [ $mu / $semi_major_axis ]and for your elliptical transfer orbit the periapsis velocity is|sqrt| [ [$mu / $transfer_sma] * [ [1 + $e] / [1 - $e] ] ]where$eis your transfer orbit's eccentricity. Give your delta-v requirement you can calculate your burn time, either rough approximation$delta_v / [ [ performance |Max Engine Thrust| ] / [ performance |Mass| ] ]or using a more accurate method. Then you can adjust your burn start angle to the following$departure_angle + [ [ 360 / [ orbit |Period| ] ] * [ $burn_time / 2 ] ]. That should put you on a transfer orbit for a rendezvous with Luna. You will want to time your burn cut off based on your orbit Apoapsis (you want to burn until your apoapsis is the same as Luna's average orbit distance). Getting an ideal rendezvous with a specific periapsis is@SmurfResearchX
+3 4.4 years agorelevant suggestions:
sharing scripts
screenshots
Here is a forum post about the mod from @14ROVI. I guess it's still in development since it has not be published to the Mods section.
4.4 years agoIn order to share a sandbox you need to be in the flight view (i.e. launch a new craft, or resume an existing flight). Then on the flight menu panel click the share button (box with an up arrow).
+1 4.4 years agoAlso here is the missile I was talking about. It plots the ballistic re-entry of a target ignoring drag, and does a ham handed job of projecting and guiding the trajectory of the missile that is fired at it.
+1 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 agoLooks pretty good. Releasing it soon?
+1 4.4 years agoYou need to be in translate mode to "go straight" with RCS, which you get to by pressing T or using the button icon with the four way arrow on the right hand side of the screen.
It's also important that you have your RCS thrusters correctly positioned around your center of mass (COM), and with sufficient monoprop tanks.
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 agoI'm on a Mac and have been able to set the texture of parts without difficulty. In quality settings if craft textures and normal maps are both disabled then you won't see any textures.
+1 4.4 years agoWhat do you mean by "harden" and "failure"? Assuming you mean it blows up on the launchpad, you could try adding landing legs or a launch tower.
+1 4.4 years agoReliability
Different parts should have different reliability scores. Reliability might be based on shape (like in the case of wings), the mass of things attached to them (like hinges), or their parameters (like engines with different fuel types/pressures/etc). A part should have a probability of failure curve that increases over time used/activated (for things like wings this would only count time in atmosphere, for engines it would only count time where the engines were firing). Parts could have penalties for cycling (i.e. slamming the throttle up and down over and over again should wear an engine out more quickly). At any point an active part could randomly fail (low probability early on, more probably as time and penalties increase). Parts should have different possible failure modes: becomes non responsive (i.e. an activatable part stops functioning), structural failure (one ore more of its part connections disconnects), or explosion (limited to fuel tanks and engines). Assuming there is some legitimate reusability component of career mode, crafts being reused should carry forward their time/use penalty unless money is spent to "refurbish" the craft thereby resetting the reliability scores. Assuming there is some sort of tech tree component to career mode, players should be able to spend R&D dollars to increase the base reliability of different parts.
This would encourage players to build redundant systems, have launch abort/escape systems, minimize stress/heat damage to parts, and avoid excessive throttle adjustment.
Related suggestion from @pedro16797
+3 4.4 years agoThere are a number of auto launch scripts out there, including one that I've made, so while I wasn't planning on including this it would be trivial to combine these given a suitable launch vehicle.
4.4 years agoGoogle Docs Link
Discord Link
I would suggest you rename this to "Community Campaign Mode" to avoid confusion in the future.
+1 4.4 years agoI could go on.
+4 4.4 years agoI'm actively working on this. I've come up with a solution that mostly works for circular orbits and I'm currently working on adapting it to work for elliptical orbits (but no support for inclined orbits) as well as refining the departure angle equations.
4.4 years agoYou have two options: 1) use a cargo bay, which will have a significant impact on the design of your capsule, or 2) make a hollow capsule using struts or panels, and then make a door by attaching one or more struts or panels to a hinge rotator. Constructing this kind of component requires some pretty meticulous work in the designer.
4.4 years agoList values need to be stored in list variables, which are created using the blue "create list variable" button at the bottom of the Lists toolbox. If you are just typing in a name as text when setting or accessing your list that won't work. While the requirement of creating variables that can be drag and dropped in place is an extra step, it adds the convenience of being able to quickly rename the variable everywhere it is used. It is possible there are other issues with how you are using lists, but it's hard to tell. It is always best to include a screenshot of your Vizzy. However I can assure you that lists do generally work.
4.4 years agoSo long as you are close enough to the surface you can determine the elevation of points on the surface by getting the getting the lat/long/AGL of a given point, dropping the AGL component to zero, and converting back to PCI. The difference between the magnitude of that vector and the mean sea level is the elevation of the surface at that point (not sure if this works for terrain below sea level). Here is a fighter jet that calculated the slope of the terrain directly below it.
+3 4.4 years ago
+1 4.4 years agotime % 60will give you the current second from 0 to 59 (1 to 59 doesn't make sense since there are 60 seconds in a minute, not 59). If you display this in a look with a short wait (0.1 seconds or less) you should have a display that is accurate to within a tenth of a second so long as you have ample CPU power. In theory the game engine may not run vizzy for longer periods of time if the CPU is bogged down by physics, graphics, or other processes.The Jester
4.4 years agoThis Falcon 9 has such a vizzy script. It defaults to 100km, but I believe it has enough Delta-V to make 150km without trouble, and tweaking the program should be trivial.
4.4 years agoThere are lots of things in the Vizzy program that will need to change such as the names of the planetary bodies to target, the apoapsis to reach the target (which is hard coded), the phase angle for the transfer orbit burn (which is dependent on the initial and target apoapsis), also the either the flight program or the craft will need to be adjusted because the program makes assumptions about when stages will be expended while reaching orbit which are not valid for Kerbin because it is smaller than Droo. The flight program is a little hard to get to because it is on a part besides the primary command chip, but you can use the part list (click the magnifying glass on the left hand side of the designer), the flight program is on a part called Vizzy Here. Go through the flight program, try to understand what it is doing on step ate a time and where you see planetary body names and related constants replace them with the Kerbol equivalents.
Note: this script should adaptable to Kerbin/Mun, but getting to Minmus will take some extra logic because of inclination.
+1 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 agoI have not experienced any issue with hinge rotators in 0.9.2xx - 0.9.4xx. Make sure the part is Active and your input is configured correctly. If the problem persists you should certainly file a bug report and/or share your craft, I would be happy to take a look to see if it's an XML issue..
4.4 years ago🎄🎁
+1 4.4 years agoSeriously though "better" is kinda subjective but I think Methalox with a full flow staged engine is pretty good for launch and Hydrogen with a nuclear thermal engine is good for orbital maneuvers. Part of the fun is learning what Isp is and exhaust velocity and engine cycles and TWR, not to mention experimentation and trying different designs for yourself. So you tell me, what are the best fuels?!
+1 4.4 years agoMissing option: Xenon 😅
4.4 years agoThere's no "official" Discord, but I think SimpleRockets Chat is probably the biggest.
4.4 years ago