# Search the Community

Showing results for tags 'measurement'.

• ### Search By Tags

Type tags separated by commas.

### Forums

• General
• Announcements
• The Daily Kerbal
• Kerbal Space Program 2
• KSP 2 Discussion
• General KSP
• KSP Discussion
• Suggestions & Development Discussion
• Challenges & Mission ideas
• The Spacecraft Exchange
• KSP Fan Works
• Gameplay and Technical Support
• Gameplay Questions and Tutorials
• Technical Support (PC, unmodded installs)
• Technical Support (PC, modded installs)
• Technical Support (PlayStation 4, XBox One)
• Community
• Welcome Aboard
• Science & Spaceflight
• Kerbal Network
• The Lounge
• Making History Expansion
• Making History Missions
• Making History Discussion
• Making History Support
• Breaking Ground Expansion
• Breaking Ground Discussion
• Breaking Ground Support
• International
• International
• KerbalEDU Forums
• KerbalEDU
• KerbalEDU Website

### Categories

• Developer Articles

• 0 Replies

• 0 Reviews

• 0 Views

Found 4 results

1. ## 3D KSP Solar System Scale Model [Major Update: 05/20/2017]

^Model is not actually 8-bit After lots of research, lots more math, and lots more tinkering, I am proud to present this 3D model (version 2.0!) of the KSP solar system. This tool provides accurate visualization and measurement of KSP’s celestial bodies with respect to one another using GeoGebra, a free and open-source graphing software. Sure, it’s pretty to look at, but its real strength is that you, the user, can use it to model and/or measure just about anything in-game. All planets and moons are represented accurately in terms of scale, eccentricity, orientation, inclination... all of it. The base state of the model has all bodies located where they would be in-game at UT=0, and can be run forward from there to 1000 in-game years (and beyond if you really need). Scale is in megameters (1Mm = 1,000km = 1,000,000m). ^Applet screenshot All stock planets and moons are represented accurately on their orbits. Semimajor axis, eccentricity, inclination, longitude of ascending node, argument of periapsis, orbital period, phase angle, body size (including atmosphere), and sphere of influence are all modeled. All bodies start exactly where they would at the beginning of a game (UT=0), and can be run forward from there to 500 in-game years (and beyond if you really need). Scale is in megameters (1Mm = 1,000km = 1,000,000m). Some of the data have been extracted directly from KSP (v1.2). Everything else is calculated within the model using that raw data. See below for the code used for the extraction. To use: To use the base tool (a version that is not easily modified or customized), follow this link to view and use it in the GeoGebra web app. You can get the customizable version at this link. It is strongly recommended that users download and install GeoGebra to their computer, as it’s faster and more stable. You can download the source file for the model by navigating to the appropriate link above and clicking in the top right corner of the applet. Full Instructions on using/customizing the model are available at the wiki. This project was very much an adventure for me, so I would not be surprised if there are (still) things I've missed, inaccuracies, etc. Please don't hesitate to bring them to my attention, along with suggestions for how to fix them, if available. I'm also open to ideas about additional features. Licensing: Because I've published the model on geogebra.org, it is subject to the Creative Commons Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) license. Keep in mind that Geogebra is something altogether different. I have had no part in developing it, and it is subject to its own licensing, terms, and conditions. Updates: 05/20/2017: Major update with updated/streamlined calculations, fixed mathematical errors, improved accuracy (thanks to a script for the direct extraction of data from the game), new basic/customizable versions, and a wiki! 04/08/2017: Addressed crowding of AN/DNs & Pe/Aps by replacing the checkbox for each with a drop-down menu, allowing users finer control over what is shown/hidden. Added hide-able stats pane for body in focus, displaying orbital/physical parameters and time to AN and Pe. Changed auto-zoom levels to depend on body in focus. Original 2D model updated/converted to 3D. Known Issues: Body in "Focus View" drop-down often needs to be selected twice in order to display the target body at intended zoom level. Suggestions welcome. When focusing view, viewVector should orient camera to particular angle. It does not. Commented out for now. Discrepancy between JS syntax accepted by the web app and desktop versions causing error in customizable version's web app at launch. Not sure of reason, no "proper fix" at this time. Works fine in desktop version. Simple workaround is here. ^Joolian system
2. ## Did this mission actually happen?

During my Engineering Design seminar today, my teacher mentioned the Kerstan Blunder. That's the quote directly from his slide. My question to you is "Did this mission happen?" I did some research online, and it didn't seem like the U.S. launched a Vigor probe, and it doesn't look like Japan or the USSR did, either. But what did you find? Was this just a misname? Was there a mission like this, but to a different planet?
3. ## Imperial measure

Is there a mod or a way to switch the program (I don't call it a game it's too awesome for that!) to the imperial (feet/miles etc...) system? I already know metric is considered to be superior so I'm not interested in a million comments to that effect! I was born and raised in the Imperial system and it's my "native" system. I can't mentally picture Earths atmosphere extending 135000 meters, but 83.8 miles I can relate to. I know this is my handicap but almost every other program you use has both systems built in. I would like to try to create this mod if anybody can guide me to do this! Thanks.
4. ## What options are there in KSP for quantitatively determining the drag produced by parts

Hello, I have been performing some simple nose cone drag test measurements (affix nose cone to test vehicle, ballast out mass differences, launch and see what peak altitude is achieved). Although this has been successful for a simple part like a nose cone it is labour intensive, very sensitive to part mass (a different mass means different accelerations are caused and different speeds obtained) and positive feedback (less drag => more acceleration => higher speed => get to higher altitudes quicker => increased engine thrust => higher speed .......) and isn't a direct measure. Is there a better way to get quantitative drag vs speed information? The unrealistic ideal would be a set of drag (and lift for relevant parts) vs speed curves as functions of altitude and angle of incidence (but that would probably be far too complex to measure/calculate) Thanks for any suggestions, Richard