When I tried Wasp 2.0, I didn't have any aileron control with Q/E (I'm using the default mapping.) I found the Control Chip buried in the fuselage, but I was surprised by the orientation of the chip -- which I think defines the orientation of the control axes. I thought the chip would be flat on one of the fuselage stations -- so the longitudinal axis would be normal to the chip, like in a rocket design (flat on top of a fuel tank.) Any diagrams or documentation about how the control axes are defined?
@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.
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.
The experience of a sonic boom depends on where the observer is. You hear booms when the shocks cross over you. The shocks are created continuously while the craft is supersonic.
I think there should be two kinds of automation from the player point of view.
An advanced avionics chip that executes scriptable missions (cheap mode: commands on timers, mid mode: feedback control, expensive: commands like "hohman transfer to target")
Astronaut characters with skills developed from relevant flight experience
Anyway, this stuff only matters if/when career mode is a thing
Also, I wanted to use a controller for RCS during docking, but I couldn't find a way to map XYZ translation commands separately from PQR rotation commands.
@GabetheDoge - I did some tinkering with the mapping. If I remember correctly, I used the sticks similar to an RC airplane controller with the analog sticks, except for throttle which I mapped increase/decrease throttle to the shoulder buttons on the controller.
The big problem I had was managing the camera angle. If/when SR2 gets a chase camera mode or a cockpit view, it will be much easier to fly with a controller.
When I tried Wasp 2.0, I didn't have any aileron control with Q/E (I'm using the default mapping.) I found the Control Chip buried in the fuselage, but I was surprised by the orientation of the chip -- which I think defines the orientation of the control axes. I thought the chip would be flat on one of the fuselage stations -- so the longitudinal axis would be normal to the chip, like in a rocket design (flat on top of a fuel tank.) Any diagrams or documentation about how the control axes are defined?
+1 5.3 years agoI want an X-43 and X-51!
I want a Blackswift!
+1 5.3 years agoSo no ramjets, scramjets, or combined-cycle hybrids? 😮
+1 5.3 years ago@AndrewGarrison - will there be a way for mods to add custom Vizzy blocks?
4.3 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.3 years agoAutonomous Orbital Rendezvous Using a Coordinate-Free, Nonsingular Orbit Representation
4.3 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.3 years agoSeparately, I've requested an axes-conversion block.
4.3 years agoWhy would you use lat/lon for rendezvous and docking?
The lat/lon/AGL is clearly for landing guidance.
4.3 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.3 years ago@AtomicHopper - the loading time between the editor and flight takes a long time, but in spoiled by my gaming PC.
4.3 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.3 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.3 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.3 years agoIs
4.3 years agovelocity(Acceleration)in Planet-Centered Inertial coordinates?Looks like Vizzy lat/lon is in radians when converted from nav(position).
4.3 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.3 years ago@MyCoolFace256 - I think
4.3 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.4 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.4 years ago@Xstep365 - the Complex Rockets Discord server has a channel called #career-mode-suggestion
4.4 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.4 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.4 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.4 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.4 years agoUse 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.4 years agoAlready included here, I think.
4.4 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.4 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.4 years agoCan you show an example with more than one custom expression?
4.4 years agoThis video is a little old, but you can see the tweaking of the stabilator angle: Trim
4.4 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.
4.4 years agoThis really made the "made for kids" issue more clear for me: Legal Eagle
4.4 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...
4.4 years agoSome things are different in the current version, but the basics are the same:
my video
4.5 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.
4.5 years agoGuido retired, so I guess a new programming language had to be invented.
4.5 years agoThe experience of a sonic boom depends on where the observer is. You hear booms when the shocks cross over you. The shocks are created continuously while the craft is supersonic.
4.6 years agoHow about visible sonic booms (shocks) also?
Visible shocks suggestion
4.6 years agoDo a ~~barrel~~ aileron roll!
4.7 years agoBuild a robot arm with hinges, rotators, and pistons.
4.9 years agoI think there should be two kinds of automation from the player point of view.
An advanced avionics chip that executes scriptable missions (cheap mode: commands on timers, mid mode: feedback control, expensive: commands like "hohman transfer to target")
Astronaut characters with skills developed from relevant flight experience
Anyway, this stuff only matters if/when career mode is a thing
4.9 years ago@NathanMikeska - it sounds interesting, but I probably won't have an opportunity to tinker with it for a few months.
4.9 years agoI think it's a good mod idea.
4.9 years agoAlso, I wanted to use a controller for RCS during docking, but I couldn't find a way to map XYZ translation commands separately from PQR rotation commands.
4.9 years ago@GabetheDoge - I did some tinkering with the mapping. If I remember correctly, I used the sticks similar to an RC airplane controller with the analog sticks, except for throttle which I mapped increase/decrease throttle to the shoulder buttons on the controller.
The big problem I had was managing the camera angle. If/when SR2 gets a chase camera mode or a cockpit view, it will be much easier to fly with a controller.
4.9 years agoThis posting confuses me.
4.9 years agoIt's been a long time since tried that.
4.9 years agoI've used PS4 and Steam controllers for flying spaceplanes.
My recollection is that the PS4 was best. The Steam controller touch pads were unacceptable for control, if I remember correctly.
4.9 years ago@PurpleSeba888 - looks like KSP 1.2 Loud & Clear introduced the comms networks as a stock feature in Oct 2016: https://steamcommunity.com/games/220200/announcements/detail/992307425716418792
The mods before that were RemoteTech and AntennaRange (maybe others).
4.9 years ago