Jump to content

Search the Community

Showing results for tags 'mechanics'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP2 Dev Updates
    • KSP2 Discussion
    • KSP2 Suggestions and Development Discussion
    • Challenges & Mission Ideas
    • The KSP2 Spacecraft Exchange
    • Mission Reports
    • KSP2 Prelaunch Archive
  • Kerbal Space Program 2 Gameplay & Technical Support
    • KSP2 Gameplay Questions and Tutorials
    • KSP2 Technical Support (PC, unmodded installs)
    • KSP2 Technical Support (PC, modded installs)
  • Kerbal Space Program 2 Mods
    • KSP2 Mod Discussions
    • KSP2 Mod Releases
    • KSP2 Mod Development
  • Kerbal Space Program 1
    • KSP1 The Daily Kerbal
    • KSP1 Discussion
    • KSP1 Suggestions & Development Discussion
    • KSP1 Challenges & Mission ideas
    • KSP1 The Spacecraft Exchange
    • KSP1 Mission Reports
    • KSP1 Gameplay and Technical Support
    • KSP1 Mods
    • KSP1 Expansions
  • Community
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
    • KSP Fan Works
  • International
    • International
  • KerbalEDU
    • KerbalEDU
    • KerbalEDU Website

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Skype


Twitter


About me


Location


Interests

Found 6 results

  1. One thing I miss when creating machines and other stuff with robotic parts are cogwheels, gears, screw gears, chain gears, etc... Basically ways to redirect rotational movement and amplify speed or torque. This would open a huge variety of possibilities. I don't know how hard would it be to program this in game or in a future DLC, or if it would be too much to ask for, but it would be awesome!
  2. TL;DR: Is there any kind of formula which allows to calculate whether I'll have a plasma blackout on a given altitude (or atmospheric pressure) and speed? Hey folks, I'm planning a scientific mission to Laythe to gather as much data as possible (so I plan to visit all biomes with one vehicle). Given that Laythe has an oxygen-rich atmosphere, I don't want to wait multiple hours to travel through half a planet, and I will probably have to land on small spots of hilly terrain as well as in see, the obvious choice is to build a hypersonic plane with vertical takeoff and landing with a tiny mining rig onboard. Unmanned, for the sake of realism. Flying with J-X4 Whiplash on 4 Machs and 25-30 km altitude looks good. The problem is that sometimes my plane encounters plasma blackout, with consequent loss of control. I try preventing that by flying higher and slower. How can I check that I'm safe on a given altitude and speed? I tried experimenting, and the results look inconclusive: I experience blackout at 830 m/s, but a couple minutes later I fly normally at 1350 m/s, at a lower altitude.
  3. Okay, I wanted to try and find a way to apply circular motion and gravitational field calculations to elliptical orbits to prove why all orbits must have opposite periapsis and aopsis and only one of each (as oppose to for example two opposite aopsis and two opposite periapsis) but I couldn't do it. Anyone with more experience give me a hand, it would be handy if the derivation tried to use relatively simple mechanics because I'm second year A level in the UK. Cheers
  4. At its core, the suggestion to add weather and clouds is simple. Clouds, wind, perhaps even storms. Its easy to imagine how interesting it could be. But before we can really delve into the suggestion, we need to consider different ways weather could be implemented, and figure out what the best way would be for KSP. But first, lets talk about the elephant in the room: The fact that it can adjust difficulty: Weather and Difficulty: The way I see it, there could be a number of basic settings for weather. -Full disable: Weather is disabled. It is always clear. -Visual only: Weather does not actually effect you. -Storms only: Weather only effects you when you are in a "storm" like scenario. -Full: Weather, winds, etc, will effect you any time. Depending on the level of simulation, there could also be toggles/sliders for things like wing icing, damage from dust storms, or "gustiness". Also interesting would be a Sandbox option to add a weather system of your choice to a location (presumably your current one). Core Mechanics and Weather Simulation: The first question to ask is simple: How do we design the weather with regards to the game? I do not speak of merely how wind works (it would presumably be a form of modifier to the current aerodynamics), but rather where it comes from. KSP is a physics heavy game, and adding some full-blown weather simulator to it would not be very good for gameplay purposes. So what, then, is the best way to add weather? Three options come to my mind, and perhaps you can imagine others. I'll start with my ideas on the matter: 1. Exceptions to Standard. In this setting, the all-clear weather on Kerbin is still the "standard weather", and any other weather events are things that generate randomly, move across the planet for some time, and then disappear. For other planets, the "standard" could also be clear, or it could be a set windspeed and direction (i.e. if you wanted to give Jool a saturn-like atmosphere) or just being cloudy instead of clear (i.e. if you want to make Eve a little more Venus-like in appearance). These events would be storms, areas of wind, perhaps even benign weather like partly cloudy and drizzles. Whenever one disappears, a new one would generate at a semi-random location, and would randomly generate its path based on some planet-defined directional preferences. Some weather events could also follow a pre-determined pattern of changes over their path (i.e. a "hurricane" might have a building phase, an main phase, and then just be a normal storm on the last leg of its path) This results in a reasonably viable set of weather mechanics that shouldn't require too much processing power to simulate on a global scale. Values worth noting would include the max number of weather events per planet (a value that can change based on the planet), which weather systems can generate on any give planet, and perhaps "seed spots" which are the only region on a planet that can generate certain weather events (i.e. maybe only weather events that generate in certain sea areas have a chance of being generated as a Hurricane event, and only storms that are generated in northern areas have a chance of generating as snow storms). If two weather events overlap, one of them can simply take priority over the other as they pass through each other for simplicity sake. 1b. Permanent weather events: It would be good in this case to have a permanent type of weather event possible. These events would be designed into applicable planets. They would be used for things such as Jool, where you might want to have an equivalent to Jupiter's Great White Spot. 2. Extremely simplistic, low power weather sim. The idea here is to split a planet into a set of "cells" and have the simplest, easiest simulation you can that still causes a reasonable variety of weather, perhaps intermittantly "seeding" it with an effect to get things moving if need be (or to simulate seasons). One option would be to take the "exceptions to standard" idea listed in 1, but just replace weather events with randomly generated air masses with semi-random values for speed, humidity, and temperature (semi-random because they could be influenced by the location they are generated). Any time two of these masses meet, they are replaced with some weather event, based on the values of the air masses. By themselves, these air masses would generally just have some wind, temperature, and humidity, and some form of cloud cover ranging from zero to full. 3. Pre-decided weather patterns. Rather than worry about dynamic weather in this scenario, the developers simply "design" the weather on Kerbin (and each other applicable planet) for a set amount of time, such as a period of 1-4 of that planet's years, and then run it. When it reaches the end, it loops back to the start. The upside is that you can have some good weather variation without actually needing to simulate it. The downside is that the weather is predetermined and thus will repeat. You can get around this somewhat by starting each planet at a random point in its weather "track" upon starting a new career, so you at least don't find yourself seeing the same couple days of weather every time you start a new game. What effects can weather have? The first and most obvious effects are the visual ones. There will be clouds. You can fly through them. They may be simply rendered, but they can still be clouds. Also, there can be rain, snow, and lightning. When you are in space above a storm at night, you might see some occasional flashes from the storm from lightning. There would also be a simplistic fog effect too (perhaps most notably on Duna, where it could be used for sandstorms). If the weather isn't impressive enough visually, then I imagine mods will help fix that. Next we have mechanical effects. -Wind can, of course, cause some ruckus during launches and take-offs. It might be a good idea to add another runway to KSP, and to allow you to choose which one to launch aircraft from (and which end of the runway to do it from). You could display this choice while in the aircraft hanger when you click launch, along with the current direction and speed of the wind. -Wind gusts are another potential one. For simplicity sake, I assume that rather than worrying about what causes such turbulence and attempting to model it, that some weather systems or air masses may simply have a value indicating a chance of encountering gusts of somewhere between X and Y strength intermittently, and that when this happens the wind affecting your vessel rapidly changes for a couple seconds. -Icing could be something that occurs in fairly water-heavy worlds such as Kerbin and Laythe. If whatever Eve has can also freeze and snow, you could perhaps have it there too. -Being a Mars analogue, Duna could of course have sandstorms. These could be windy, reduce vision, and could be at risk of damaging some equipment if it is not protected or put back into its stored configuration (Engineer astronauts could fix them if you forget). -Planets with active volcanoes could have a permanent weather effect near them with an ash-plume storm, and wind direction matching the plume direction. The priority could be set such that this effect disappears whenever another weather effect is in the region, resulting in the volcano appearing to sometimes be erupting, and sometimes not (when in actuality, not erupting just means another weather effect is overriding it). -Given how weird Eve is (its SORT OF a venus analogue, but not really), you could probably imagine some interesting things for it. Dense but slow-moving and harmless fogs (insert Purple Haze joke), small tornado-like storms that look almost more tornado than storm (but which actually only have a small "real" tornado in the very center). -Weather effects could have their own science equipment associated with them. This equipment would gather science based not on location, but rather what kind of weather they are in (for these instruments, all vacuum areas would be considered the same "weather" pattern, unlike the current thermometer and barometer). -Some more major weather effects could temporarily override the biome in the region they are affecting for some instruments. These would generally be major things like hurricanes, or permanent weather systems like the "Great Jool Blot" (has a nice ring to it, actually). -Planets without atmospheres (and maybe those with really, really thin ones) would of course not have weather. Misc other thoughts and comments: -If the SUN is granted some weather, it could have "sunspot" events, along with rare "eruption" events. The sunspot events could just act like a biome for purposes of near-sun spacecraft science gathering, but eruption events could have other effects too. If one of these happens to be pointed towards a planet, you could generate an aurora effect around the poles of that planet. It could also cause a notable additional heating effect when a spacecraft near the sun is above its "biome." -Meteor showers are not weather (and should not be considered such mechanically), but could potentially be an interesting visual effect that occurs on planets with atmospheres at set points in their year, independent of weather. -I wonder if Jebediah Kermin has any type of weather he especially enjoys. Knowing him, probably hurricanes. While in an aircraft he designed himself. With an exterior pilots seat. During re-entry. With boosters ignited. And poor Bob in the cockpit screaming in panic about how horrible an idea this was.
  5. I want to do an Apollo-style mission, with one difference: the Lunar Module launches first, unmanned, and enters Munar orbit. Then, the Command Module launches and docks with the Lunar Module in Munar orbit. The astronauts transfer to the Lunar Module and proceed as in Apollo, with the LM being used for descent and ascent and then being discarded. My question is this: where should the two spacecraft rendezvous for greatest overall efficiency? Should they aim for a high orbit or a low one? A low orbit takes advantage of the Oberth effect, but a higher orbit means it will be easier for the Command Module to return. If such a mission was carried out in real life, would it be better to use a place like L1 or L2 for the rendezvous?
  6. I have re-posted an earlier post in hopes that KSP 1.1 may include this feature in current version or at least in one of near future updates. Long time ago (a year maybe) i suggested a plugin for monitoring mechanical stresses between parts of vessel. I have recevied a useful reply that this was not possible because physics engine did not support this. Technically, physics engine did not send events to each physics time frame with part stress, only the part separation from normal attachment node positions and final breakdon event. No measurable data whatsoever. To those who have a deja vu, this was posted before . I just hope that PhysX / Unity 5 have allowed this kind of data to be read so dev team could at least take a shot at this idea. Thank you all for continued support and development of this game !
×
×
  • Create New...