@DasAbhinab
Copy this to clipboard:
%userprofile%\AppData\LocalLow\Jundroo\SimpleRockets 2\UserData\PhotoLibrary\Images
Hold down WindowsKey + R
Paste the text from above.
That should open the folder.
@crowxe - there's a separate block for altitude, and you have the option of ASL or AGL. It's just not grouped with lat/lon.
PCI coordinates are centered at the middle of the planet, but they ignore the rotation of the planet and stay aligned to the stars. Your spacecrafts don't care about the rotation of the planet, either.
Sounds like what you should focus on is the target position and target velocity. I think those might also be in PCI frame, so we can probably just subtract ownship position and velocity to get the relative vectors.
@crowxe - my question was about how you would use latitude and longitude for rendezvous and docking. I think you'd much rather have semi-major axis, eccentricity, inclination, argument of periapsis, right ascension of the ascending node, and true anomaly. I think you can get there with planet-centered inertial (PCI) frame position and velocity, but I have a feeling the math is a bit inconvenient (ovals described by rectangles).
The latest experimental update has target position and velocity, which should make docking feasible.
Maybe too many years of Matlab exposure, but I intuitively expected functions like abs, floor, round, etc. to work element-by-element on vectors and lists.
Seems like PCI is "planet centered inertial" coordinates. So the origin is the center of the body whose sphere of influence you are in, but orientation is fixed to the stars.
@MyCoolFace256 - I think clamp is like a saturation. If the input is less than the minimum, then the output is the minimum. If the input is more than the maximum, then the output is the maximum. If the input is between the min and max, then the output is equal to the input. I think another name is clipping, as in the input is clipped to the range between the min and max. Make sense?
@Xstep365 - I think the reuse bonus should be a percentage of the value of only the parts that are recovered.
Actually, maybe it shouldn't be an instant dollar refund like KSP, but more of a coupon to be used on a future launch, only if you reuse that part.
Players might better accept the scale if they are explainable. For example:
20% for refurbishment and inspection.
30% for salt-water decontamination.
Transportation costs that are a function of distance to the space center and mass and size of the part.
The costs are additive. So, fishing a huge, heavy booster out of the ocean on the opposite side of Droo may not be worth anything. But landing it softly at the space center would get most of the value back.
Players can team up to bid, or form teams after a bid is won. For example, one player builds the rocket and the other player writes the Vizzy script.
Dollar winnings have to be split among the teammates per their agreement. Maybe there's a prestige award (or penalty) that gets attributed to all teammates, no matter how large or small their contribution.
If the solution XML includes part groups that are identical to crafts posted prior to the customer RFP, then the cost of the launch should be discounted.
Parts recovered into the ocean get a 20% re-use bonus. Parts recovered on land get an 80% re-use bonus. (Adjust the percentages for better gamification.)
The customer chooses the lowest realistic bid and gives a deadline. If the deadline isn't met, the customer may choose a different bid, or cancel the RFP.
Personally I think the customer should only provide the payload object and the mission requirements. The player should leave the payload as-is and build a launcher around it. Solutions are craft files that include the flight program that can be executed by the customer for verification. Part of the verification is a check that the payload XML exists unedited somewhere within the craft XML.
Also, your post reminds me of an idea for a mod that adds somewhat realistic failures, based on actual historic mishaps. In some cases those failures just cause a degradation in performance, but in other causes the whole part explodes. Some failures trigger some kind of warning of impending doom, others happen suddenly.
I think it would be an interesting challenge for the design of the craft and the design of the automation.
Use something like this to calculate your flight path angle and compare it to what it should be. If you are flying sideways, might be a good time to abort...
@AndrewGarrison - I found my problem. I had copy-pasted from your clamp example, so both expressions had name="Test". Now that they have unique names, the expressions are working.
@AndrewGarrison - when I deleted the other custom expression it works fine. It seems to be whenever I have two custom expressions that I have the problem.
Meanwhile, you can assemble your own science probes from parts. Model a real science mission or invent one from imagination. Unlike KSP's library if premade parts, SR2 let's you resize & recolor parts to make just about anything.
@AndrewGarrison, I'm curious why you built your own visual programming language rather than pull in Blockly or something similar. Seems like functions, lists, etc. don't need to be reinvented, just the objects for SR2. I'm not really a developer, though.
Everyone should try building a lot of different things and find out what they like to build. Maybe landing an SSTO gives you a feeling of accomplishment that other projects don't.
@DasAbhinab
+3 3.7 years agoCopy this to clipboard:
%userprofile%\AppData\LocalLow\Jundroo\SimpleRockets 2\UserData\PhotoLibrary\Images
Hold down WindowsKey + R
Paste the text from above.
That should open the folder.
@AndrewGarrison - the log viewer has newer messages on top. This feels upside down. I get confused about which way a signal is trending.
+1 4.9 years ago@AndrewGarrison - will there be a way for mods to add custom Vizzy blocks?
4.9 years ago@crowxe - height is just the 2norm of the position vector? Well, distance from the center of the planet...
+1 4.9 years ago@crowxe - there's a separate block for altitude, and you have the option of ASL or AGL. It's just not grouped with lat/lon.
PCI coordinates are centered at the middle of the planet, but they ignore the rotation of the planet and stay aligned to the stars. Your spacecrafts don't care about the rotation of the planet, either.
Sounds like what you should focus on is the target position and target velocity. I think those might also be in PCI frame, so we can probably just subtract ownship position and velocity to get the relative vectors.
4.9 years agoAutonomous Orbital Rendezvous Using a Coordinate-Free, Nonsingular Orbit Representation
4.9 years ago@crowxe - my question was about how you would use latitude and longitude for rendezvous and docking. I think you'd much rather have semi-major axis, eccentricity, inclination, argument of periapsis, right ascension of the ascending node, and true anomaly. I think you can get there with planet-centered inertial (PCI) frame position and velocity, but I have a feeling the math is a bit inconvenient (ovals described by rectangles).
The latest experimental update has target position and velocity, which should make docking feasible.
4.9 years agoSeparately, I've requested an axes-conversion block.
4.9 years agoWhy would you use lat/lon for rendezvous and docking?
The lat/lon/AGL is clearly for landing guidance.
4.9 years agoLat/lon/AGL is useful for landing on the surface, of course.
MSL is also useful. But isn't there a position vector in PCI?
4.9 years ago@AtomicHopper - the loading time between the editor and flight takes a long time, but in spoiled by my gaming PC.
4.9 years agoI run the Android version of SR2 on Chromebook. I don't know the specs, but it's a 2016-ish Acer, nothing special.
4.9 years agoNED (north east down) is common in aerospace, but scientists tend to use ENU (east north up).
If the eventual career mode involves science, maybe an ENU option would be good, too.
+1 4.9 years ago@AndrewGarrison - does the vector class have a property for its own frame?
It might make it easier on most folks not to have to know the input frame for the conversion.
+1 4.9 years ago@AndrewGarrison - maybe an axes conversion block with options for the output frame:
Maybe I'm trying to make it too general...
+2 4.9 years agoMaybe too many years of Matlab exposure, but I intuitively expected functions like abs, floor, round, etc. to work element-by-element on vectors and lists.
4.9 years ago@AndrewGarrison - this is starting to look like and evil prank to trick me into re-writing LAPACK.
I'm trying to change the basis of the acceleration vector from PCI to body-axes...
Any plans for adding matrices and matrix operations (such as inversion) to Vizzy?
4.9 years agoIs
4.9 years agovelocity(Acceleration)in Planet-Centered Inertial coordinates?Velocity(Angular)tooltip says angular acceleration, but the units are angular rates (rad/s). I think the tooltip should say angular rates.The usual order is P, Q, R (roll rate, pitch rate, yaw rate), but the current order is probably a Unity thing.
+1 4.9 years agoLooks like Vizzy lat/lon is in radians when converted from nav(position).
4.9 years agoLaunchLocations.xml has lat/lon in degrees.
Seems like PCI is "planet centered inertial" coordinates. So the origin is the center of the body whose sphere of influence you are in, but orientation is fixed to the stars.
4.9 years ago@MyCoolFace256 - I think
4.9 years agoclampis like a saturation. If the input is less than the minimum, then the output is the minimum. If the input is more than the maximum, then the output is the maximum. If the input is between the min and max, then the output is equal to the input. I think another name is clipping, as in the input is clipped to the range between the min and max. Make sense?And a new decade starting tomorrow, the zeroeth of January! (0/0/2020)
4.9 years ago@Xstep365 - we need to have a common server in order to message each other on Discord. I think the main one is SRC.
4.9 years ago@Xstep365 - the Complex Rockets Discord server has a channel called #career-mode-suggestion
4.9 years ago@Xstep365 - I think the reuse bonus should be a percentage of the value of only the parts that are recovered.
Actually, maybe it shouldn't be an instant dollar refund like KSP, but more of a coupon to be used on a future launch, only if you reuse that part.
Players might better accept the scale if they are explainable. For example:
The costs are additive. So, fishing a huge, heavy booster out of the ocean on the opposite side of Droo may not be worth anything. But landing it softly at the space center would get most of the value back.
4.9 years agoPlayers can team up to bid, or form teams after a bid is won. For example, one player builds the rocket and the other player writes the Vizzy script.
Dollar winnings have to be split among the teammates per their agreement. Maybe there's a prestige award (or penalty) that gets attributed to all teammates, no matter how large or small their contribution.
4.9 years agoSome other ideas:
- If the solution XML includes part groups that are identical to crafts posted prior to the customer RFP, then the cost of the launch should be discounted.
- Parts recovered into the ocean get a 20% re-use bonus. Parts recovered on land get an 80% re-use bonus. (Adjust the percentages for better gamification.)
- The customer chooses the lowest realistic bid and gives a deadline. If the deadline isn't met, the customer may choose a different bid, or cancel the RFP.
4.9 years agoPersonally I think the customer should only provide the payload object and the mission requirements. The player should leave the payload as-is and build a launcher around it. Solutions are craft files that include the flight program that can be executed by the customer for verification. Part of the verification is a check that the payload XML exists unedited somewhere within the craft XML.
4.9 years agoAlso, your post reminds me of an idea for a mod that adds somewhat realistic failures, based on actual historic mishaps. In some cases those failures just cause a degradation in performance, but in other causes the whole part explodes. Some failures trigger some kind of warning of impending doom, others happen suddenly.
+2 4.9 years agoI think it would be an interesting challenge for the design of the craft and the design of the automation.
Use something like this to calculate your flight path angle and compare it to what it should be. If you are flying sideways, might be a good time to abort...
!flight path angle: gamma
4.9 years agoAlready included here, I think.
4.9 years agoAndrew said he would be updating the GUI soon so you can add the custom expressions without editing the XML.
+1 4.9 years ago@AndrewGarrison - I found my problem. I had copy-pasted from your clamp example, so both expressions had name="Test". Now that they have unique names, the expressions are working.
4.9 years ago@AndrewGarrison - when I deleted the other custom expression it works fine. It seems to be whenever I have two custom expressions that I have the problem.
4.9 years agoCan you show an example with more than one custom expression?
4.9 years agoThis video is a little old, but you can see the tweaking of the stabilator angle: Trim
4.9 years agoMeanwhile, you can assemble your own science probes from parts. Model a real science mission or invent one from imagination. Unlike KSP's library if premade parts, SR2 let's you resize & recolor parts to make just about anything.
5.0 years agoThis really made the "made for kids" issue more clear for me: Legal Eagle
5.0 years ago@TOMJeb117 - It was made in such an old version... I think it would be better to make it from scratch. I've got some free time coming up...
5.0 years agoMaybe I'll make HAL 9000.
(Because HAL is easier.)
+2 5.0 years agoSome things are different in the current version, but the basics are the same:
my video
5.0 years ago@AndrewGarrison, I'm curious why you built your own visual programming language rather than pull in Blockly or something similar. Seems like functions, lists, etc. don't need to be reinvented, just the objects for SR2. I'm not really a developer, though.
5.1 years agoGuido retired, so I guess a new programming language had to be invented.
5.1 years agoEveryone should try building a lot of different things and find out what they like to build. Maybe landing an SSTO gives you a feeling of accomplishment that other projects don't.
+1 5.1 years agoCraft Properties:
- x,y,z of a part, such as the grappler on the end of a robotic arm, relative to the craft datum.
- velocities of a part, relative to the craft datum.
+5 5.1 years agoHow about logging?
+3 5.1 years agoFlight data parameters, but also discrete events and user-defined text messages. Like "Show Message" but saved for later review.
Can the active Vizzy script use the nav-sphere without fighting with the built-in autopilot?
Maybe an instruction to disable the built-in autopilot would be useful.
Are Vizzy scripts going to be stored in parts, like a flight control computer?
+2 5.1 years agoBlock diagrams like Simulink?
!PID controller
+3 5.1 years agoWill there be user-defined variables? Arrays? Flow control?
+1 5.1 years agoUse-defined functions that are callable from other functions?