@Shmexysmpilot I suggest you pin the answer from zzazza which appears to have been the most useful to you, that way it will be easier for others who see this thread to find the answer.
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.
@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.
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.
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 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
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.
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.
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.
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..
Can you share a craft or some screenshots of your vizzy program? Also try asking in the SimpleRockets Chat Discord in the #vizzy channel, it's easier to share screenshots there.
There is a set activation group instruction int the "Craft Instructions" section of the toolbox. This instruction takes the number of the activation group and a boolean value (true or false). You can check the current state of an activation group with the activation group expression in the "Craft Information" section.
To switch back to the latest stable version, if you're using Steam, go to the game page in your library, click the gear icon on the far right of the page, select the "properties" menu option, go to the "betas" tab, change the "select the betas you would like to opt into" dropdown to "NONE."
It does sound like there are some breaking changes for mods in this beta. Some mods (mine included), use unsupported internal features of the game engine which Jundroo cannot guarantee backward compatibility for. As a mod maintainer it is difficult to support the experimental branches because we have to switch back and forth between beta and stable (especially in this case because the mod API actually got updated, so it's a new version of Unity as well). I think you can expect to see mods get fixed around the time that the new version (9.40x.x) becomes stable/officially released.
I'm only speculating, but perhaps the fact that your recent Rotating Lunar Station is flagged as built with a beta prevents it from being on the home page. That is a very cool craft by the way.
TLDR; simplerockets.com interprets pairs of _underscores_ as italics which will break plain text URLs that have underscores. To add a link to your post use something like this: [Corrected link](https://www.reddit.com/r/simplerockets/comments/gt61so/simple_rockets_2_new_marker_location_concept/?utm_source=share&utm_medium=web2x)
PCI stands for Planet Centered Inertial, which is a coordinate system that is centered at the center of mass of the planet whose sphere of influence you are in, and is otherwise fixed with respect to distant celestial bodies (i.e. the stars). It is basically the same as Earth Centered Inertial except for arbitrary planets including Droo.
The green line represents the target satellite's position vector. The red line represents the launch vehicle's position vector. In order to find out the green and orange angles you have to know some things about your vehicles flight path: how long it takes, and how far it travels laterally. Once you know those things you can figure out what that red angle should be when you launch. If you do this you should wind up in orbit close to your target. The most reliable way to do all of this is to automate everything with Vizzy. Having an automated launch helps you have a consistent flight path, and doing this vector math and launch timing manually is a pain. However, if you don't want to use Vizzy as at least an aid for timing your launch you can always resort to doing the math on paper and slapping a protractor on your screen to time the launch.
Assuming your target is in an orbit with zero inclination and you are launching from near the equator it is pretty simple. Estimate (or experimentally determine) the time it takes your rocket to get to your desired circular orbit, and the number of degrees of rotation in PCI terms that you travel during the launch. Wait until the angle between your craft's position vector and your target's position vector is equal to the number of degrees you travel during launch minus your target's angular velocity (degrees per second of rotation around the planet, aka 360 / orbit period) multiplied by the time it takes your launch vehicle to reach orbit. This angle will probably be negative, meaning that the target will need to be "behind" your launch vehicle at launch time, and you will have to account for that when waiting for the correct angle since the angle operator always returns a positive number, however depending on the launch vehicle this could theoretically be positive.
There are several examples out there of automating this procedure:
One way to do this would be to list all the crafts orbiting your current planet, and find the one that is closest. This isn't 100% guaranteed to work since there could theoretically be another craft hovering nearby that would actually be closer than the one that just separated. Another approach would be to enumerate all crafts around all planetary bodies (including the sun) in order to predict the next craft id that will be assigned. Here is an example of the first method. You could add extra checks like making sure the craft's name starts with the name of the current craft.
I forgot to mention, I uploaded a version of your craft with the Vizzy working. You will still need to add activation for stage 2, final pitch adjustment, and engine cutoff.
This code is built into the game, it is in the Assets.Scripts.Craft.Parts.Modifiers.Fuselage.FuselageScript class in the GetMaxFuelCapacity method. There is no way to alter or circumvent this code without a mod. Using a mod, such as Realistic Engine Overhaul you could introduce new fuel types with different storage overhead. Alternately you could create a mod with a custom fuel tank part that used different math.
It is possible to edit a craft's XML so that its fuel tanks are filled beyond capacity, or to increase the capacity (using the fuel and capacity attributes on the FuelTank element), but be aware that the minute you touch this part in the designer it will have its capacity reset to the default.
As I have pointed out here it would be nice to be able to get Keplerian Orbital Elements for an arbitrary node (planet or craft) instead of just the current craft.
I don't suppose you are on a Mac with Time Machine enabled? I you were you could look at previous versions of your com.jundroo.SimpleRockets2/UserData/CraftDesigns/__editor__.xml file to see if you can recover a version of your unsaved craft from before it was overwritten by the downloaded craft.
I feel your pain, I think it would be a good idea for SR2 to warn you 1) before exiting the editor without actually saving your craft, 2) warn you when downloading a craft that you are about to lose unsaved changes if the __editor__.xml file has changed since the last save. Feel free to link a suggestion and I will upvote.
You can make links like this with the following text: [link plain text](https://www.reddit.com/r/Kos/comments/azfc05/impact_location_without_trajectories_mod/)
Ah, I see, so you're basically introducing some additional constraints on what craft can be taken control of. That sounds more doable. As long as the player abides by the rules you could have the flight programs orchestrate switching of control like so:
Player targets a particular craft.
Player toggles an AG or activates a "button" part
If the target is reachable via communications link player control is transferred, if not an "unreachable" error is displayed.
One limitation I can think of if you're not making a mod is verifying that a particular craft has a communication device that makes it part of your network. With a mod you could do things like check for reachability via a system of relays as opposed, and flip control back to the previous station (or the root station) when the player craft goes out of range of the network.
This is a neat idea and would be an interesting basis for a set of challenges.
My question is: what is the effect you want to achieve when the craft qualify as "communicating"? I think it is feasible using vizzy alone to come up with a list of crafts that meet your criteria, but then the question becomes what to do with that? There is a mod in development to do some sort of communication network, discussion in the Complex Rockets discord, perhaps @pedro16797 can invite you.
I don't think what you are describing is possible without a mod, but since you've upvoted my inter-craft communication mod perhaps you are planning to use that or something similar? When you say "the craft is within range" and "the player can control the ship" what do you mean exactly? While we do now have the ability to transfer control to other craft, there is no way to remotely control a craft. Regarding range, it is also important to note that the 10km limit for other crafts running vizzy is currently a pretty hard limit. I have looked for ways to create a mod that hacks this but the distance checks and craft-unloading code is pretty locked down, so even using private internal members I don't think it is possible to tweak this with a mod.
You can adjust the autopilot settings on you command pod/chip to account for sluggishness in the autopilot (I think this is usually done by increasing either the proportional and/or the integral components). However if your craft is difficult to control manually because it is sluggish to respond to inputs it may not be possible to compensate with autopilot settings. You may need to make changes to your control services, engine gimbals, or other aspects of your craft design.
Just so you know planetstudio is an experimental prototype, not a finished feature, and the planet xml is undocumented, so doing this is not for the faint of heart.
The default key to open the dev console is ~ if this doesn't work check your controls in settings (I've heard that it may be unconfigured by default in newer versions)
@Shmexysmpilot That's correct. A wait 0 will wait just until the next frame (how long that is will depend on settings and CPU).
4.4 years ago@Shmexysmpilot I suggest you pin the answer from zzazza which appears to have been the most useful to you, that way it will be easier for others who see this thread to find the answer.
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 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.I'm excited to see some good SR2 machinima. I used to love Red vs. Blue back in the day.
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 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 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 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 isHere 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 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 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 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 agoThe 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 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 agoMissing option: Xenon 😅
4.4 years agoThere's no "official" Discord, but I think SimpleRockets Chat is probably the biggest.
4.4 years agoCan you share a craft or some screenshots of your vizzy program? Also try asking in the SimpleRockets Chat Discord in the #vizzy channel, it's easier to share screenshots there.
4.5 years ago@AndrewGarrison can I get an update on this bug regarding buttons not being clickable after changing screens? It's very annoying and I thought it would get fixed before this shipped.
4.5 years agoThere is a
4.5 years agoset activation groupinstruction int the "Craft Instructions" section of the toolbox. This instruction takes the number of the activation group and a boolean value (trueorfalse). You can check the current state of an activation group with theactivation groupexpression in the "Craft Information" section.To switch back to the latest stable version, if you're using Steam, go to the game page in your library, click the gear icon on the far right of the page, select the "properties" menu option, go to the "betas" tab, change the "select the betas you would like to opt into" dropdown to "NONE."
It does sound like there are some breaking changes for mods in this beta. Some mods (mine included), use unsupported internal features of the game engine which Jundroo cannot guarantee backward compatibility for. As a mod maintainer it is difficult to support the experimental branches because we have to switch back and forth between beta and stable (especially in this case because the mod API actually got updated, so it's a new version of Unity as well). I think you can expect to see mods get fixed around the time that the new version (9.40x.x) becomes stable/officially released.
4.5 years agoI'm only speculating, but perhaps the fact that your recent Rotating Lunar Station is flagged as built with a beta prevents it from being on the home page. That is a very cool craft by the way.
4.5 years agoI think you can probably achieve this without a mod by tweaking the XML for the engine part. Here is a guide to the XML elements.
4.5 years agoCorrected link
See the formatting guide
TLDR; simplerockets.com interprets pairs of _underscores_ as italics which will break plain text URLs that have underscores. To add a link to your post use something like this:
4.5 years ago[Corrected link](https://www.reddit.com/r/simplerockets/comments/gt61so/simple_rockets_2_new_marker_location_concept/?utm_source=share&utm_medium=web2x)PCI stands for Planet Centered Inertial, which is a coordinate system that is centered at the center of mass of the planet whose sphere of influence you are in, and is otherwise fixed with respect to distant celestial bodies (i.e. the stars). It is basically the same as Earth Centered Inertial except for arbitrary planets including Droo.
Here is a diagram that should help explain
The green line represents the target satellite's position vector. The red line represents the launch vehicle's position vector. In order to find out the green and orange angles you have to know some things about your vehicles flight path: how long it takes, and how far it travels laterally. Once you know those things you can figure out what that red angle should be when you launch. If you do this you should wind up in orbit close to your target. The most reliable way to do all of this is to automate everything with Vizzy. Having an automated launch helps you have a consistent flight path, and doing this vector math and launch timing manually is a pain. However, if you don't want to use Vizzy as at least an aid for timing your launch you can always resort to doing the math on paper and slapping a protractor on your screen to time the launch.
4.5 years agoAssuming your target is in an orbit with zero inclination and you are launching from near the equator it is pretty simple. Estimate (or experimentally determine) the time it takes your rocket to get to your desired circular orbit, and the number of degrees of rotation in PCI terms that you travel during the launch. Wait until the angle between your craft's position vector and your target's position vector is equal to the number of degrees you travel during launch minus your target's angular velocity (degrees per second of rotation around the planet, aka 360 / orbit period) multiplied by the time it takes your launch vehicle to reach orbit. This angle will probably be negative, meaning that the target will need to be "behind" your launch vehicle at launch time, and you will have to account for that when waiting for the correct angle since the
angleoperator always returns a positive number, however depending on the launch vehicle this could theoretically be positive.There are several examples out there of automating this procedure:
If you are trying to rendezvous with an inclined or elliptical orbit, or you are launching from higher latitudes, then things are more complicated.
4.5 years agolet me google that for you...
4.5 years agoAlso https://www.simplerockets.com/Forums/View/37070/How-can-I-set-up-a-Satellite-in-geostationary-orbit
@SelectAKey if that's true they could have just asked 😅
4.5 years agoThis could use some more explanation. What's the objective? Droo orbit? What altitude? Limits on eccentricity?
How does the "least launches" thing work? Are you asking people to report how many tests launches they have to do to get their program working?
4.5 years agoOne way to do this would be to list all the crafts orbiting your current planet, and find the one that is closest. This isn't 100% guaranteed to work since there could theoretically be another craft hovering nearby that would actually be closer than the one that just separated. Another approach would be to enumerate all crafts around all planetary bodies (including the sun) in order to predict the next craft id that will be assigned. Here is an example of the first method. You could add extra checks like making sure the craft's name starts with the name of the current craft.
4.5 years agoI forgot to mention, I uploaded a version of your craft with the Vizzy working. You will still need to add activation for stage 2, final pitch adjustment, and engine cutoff.
4.5 years agoThis code is built into the game, it is in the
Assets.Scripts.Craft.Parts.Modifiers.Fuselage.FuselageScriptclass in theGetMaxFuelCapacitymethod. There is no way to alter or circumvent this code without a mod. Using a mod, such as Realistic Engine Overhaul you could introduce new fuel types with different storage overhead. Alternately you could create a mod with a custom fuel tank part that used different math.It is possible to edit a craft's XML so that its fuel tanks are filled beyond capacity, or to increase the capacity (using the
4.5 years agofuelandcapacityattributes on theFuelTankelement), but be aware that the minute you touch this part in the designer it will have its capacity reset to the default.Here is a quick review of your vizzy
Issues
- Use of
- No
- Use of
4.5 years ago=instead of>=Lock Headinginstructionset [Pitch]instead ofset craft [Pitch]Here's another way to get this information: Vizzy++ Mod
4.5 years agoAs I have pointed out here it would be nice to be able to get Keplerian Orbital Elements for an arbitrary node (planet or craft) instead of just the current craft.
4.5 years agoI don't suppose you are on a Mac with Time Machine enabled? I you were you could look at previous versions of your
com.jundroo.SimpleRockets2/UserData/CraftDesigns/__editor__.xmlfile to see if you can recover a version of your unsaved craft from before it was overwritten by the downloaded craft.I feel your pain, I think it would be a good idea for SR2 to warn you 1) before exiting the editor without actually saving your craft, 2) warn you when downloading a craft that you are about to lose unsaved changes if the
4.5 years ago__editor__.xmlfile has changed since the last save. Feel free to link a suggestion and I will upvote.Corrected link to the referenced reddit post.
You can make links like this with the following text:
4.5 years ago[link plain text](https://www.reddit.com/r/Kos/comments/azfc05/impact_location_without_trajectories_mod/)Ah, I see, so you're basically introducing some additional constraints on what craft can be taken control of. That sounds more doable. As long as the player abides by the rules you could have the flight programs orchestrate switching of control like so:
One limitation I can think of if you're not making a mod is verifying that a particular craft has a communication device that makes it part of your network. With a mod you could do things like check for reachability via a system of relays as opposed, and flip control back to the previous station (or the root station) when the player craft goes out of range of the network.
This is a neat idea and would be an interesting basis for a set of challenges.
4.5 years agoMy question is: what is the effect you want to achieve when the craft qualify as "communicating"? I think it is feasible using vizzy alone to come up with a list of crafts that meet your criteria, but then the question becomes what to do with that? There is a mod in development to do some sort of communication network, discussion in the Complex Rockets discord, perhaps @pedro16797 can invite you.
4.5 years agoI don't think what you are describing is possible without a mod, but since you've upvoted my inter-craft communication mod perhaps you are planning to use that or something similar? When you say "the craft is within range" and "the player can control the ship" what do you mean exactly? While we do now have the ability to transfer control to other craft, there is no way to remotely control a craft. Regarding range, it is also important to note that the 10km limit for other crafts running vizzy is currently a pretty hard limit. I have looked for ways to create a mod that hacks this but the distance checks and craft-unloading code is pretty locked down, so even using private internal members I don't think it is possible to tweak this with a mod.
4.5 years agoAt the moment I believe the only game type is "sandbox." Someday there will also be "career."
4.5 years agoYou can adjust the autopilot settings on you command pod/chip to account for sluggishness in the autopilot (I think this is usually done by increasing either the proportional and/or the integral components). However if your craft is difficult to control manually because it is sluggish to respond to inputs it may not be possible to compensate with autopilot settings. You may need to make changes to your control services, engine gimbals, or other aspects of your craft design.
4.6 years agodisclaimer: experimental pre-release feature, good luck.
4.6 years agoOpen the dev console by pressing the
~(tilde) key, then typePlanetStudioand hit enter.If the
4.6 years ago~key doesn't open the console check your control settings (it's the last one under "Other Controls").Just so you know planetstudio is an experimental prototype, not a finished feature, and the planet xml is undocumented, so doing this is not for the faint of heart.
4.6 years agoThe default key to open the dev console is ~ if this doesn't work check your controls in settings (I've heard that it may be unconfigured by default in newer versions)
4.6 years ago