Ryu Gemini

So is it actually possible to mess around with the "building/structure" objects in this game much via mods?

Indeed. We may not be able to have what would effectively be a scaled down weather prediction program in KSP. But I don't think we really NEED one if we just want weather conditions in our simulator, and there is likely a way we can get weather that is "good enough" for being reasonably sensible in the way it works. Hence some of my thoughts on possible ways we might be able to implement weather in a way that is at least more complex than the weather in a typical game that has visual weather effects in it (which basically amounts to "every X minutes, randomly generate a value and set the weather to that type without caring where you actually are").

In theory, you could also use something that adds a Kerbal version of the Lockheed compact fusion reactor, if such a mod exists. By which I mean, having electric jet engines. Which you power with a fusion reactor small enough to fit on a large cargo plane. Then, you would switch to plasma engines or something like that which use lots of power to eject its fuel with more energy than you'd get from just burning it with oxidizer. Seriously, if Lockheed's Reactor, or for that matter any other compact fusion reactor comes to be, it will open a whole new set of possibilities for spacetravel in real life.

This is just a funny idea I had, but what if you had a mod that you could toggle on and off while on a mission. When toggled on, it would purposely add a user-defined number of seconds of input lag. It does take time for signals to move the sorts of distances involved in space after all (from Earth to the Moon is what, about a second?) If you wanted to make it a more automated "challenge" mod, rather than a just-for-fun thing you toggle, you could have it add some amount of time for any vessel in a sphere of influence without a manned vessel it can connect to. Naturally, to avoid the problems that would occur with signals taking multiple hours to get around the Kerbol system, you could act like the signals still do travel much faster than the speed of light in our universe, or just do something like add one second each time the signal has to change sphere-of-influence on its way from a manned ship to the unmanned vessel you are controlling. Or, you could input some controls, then hit a button to carry out what you input to simulate having to wait a while for the signals to reach the target. I mean, yeah, the assumption is that most unmanned KSP vessels have an onboard AI that operates them to a partial extent, but sending of actual commands should realistically take time and add to the challenge, right? Speaking of challenges, I could totally see there being challenges to launch a rocket to the mun and back with something like 2-3 seconds of input lag or something the whole way. Much crashing I imagine.

In the spirit of the necro, anyone have kerbals survive things they really, really shouldn't have lately?

No pics. But for those who have used the airship mod? Apparently those balloon-parachute things can summon lesser kraken forces if placed too close to each other. Spent a good half hour trying to figure out why my science plane started to suddenly fly off sideways in circles after lifting off before I figured it was the fact that I replaced the conventional parachutes with newfangled balloonachutes that are apparently made of krakenskin. ...what? I didn't want to have to get out and repack the darn parachutes every time I took back off in the thing, okay?

PC Flight simulators have been simulating wind, storms, and such things for 15+ years now. But they do not actually simulate how weather systems interact with each other and all that. So really then. Why do we assume that KSP has to? As long as weather can happen, and can move over the launch site and then move away from the launch site (and, well, any other sites we might have a loaded craft on planets with atmospheres), that will satisfy many players of the game. Design-wise, it also just comes down to a simple question: "What is it people actually want to do with weather?" Now, I can only speak for myself, but for me it comes to something like this. -I'd like to see weather that may change conditions at a particular place from time to time. On planets with atmospheres anyway. And even if wind and wind gusts are the only thing that have actual mechanical effects on your craft, having clouds, rain, snow, and lightning as visual effects can be fun too. I want to be able to have to delay a launch to wait for a storm to pass. Or to just launch anyway because its urgent, or because Jeb is overconfident in how many struts he put on his rocket. -The clouds or other visual effects do not need to look that awesome. Modders will make them look better for those who want fancier clouds. Stock clouds should though be 3D in some way, even if it is just as boxes like Minecraft's clouds. And when far away, or looking down from orbit, clouds can be rendered as 2D layers to save performance and I won't care. The important thing to note (at least, if other people are like me) is that I never once said I want a full-blown planetary weather simulation program. As long as it is possible for weather systems to exist and move, I don't care if its just sending randomly generated groups of clouds along straight lines across the planet's surface, or actually having interactions between airmasses and so forth. Thus, my suggestion is to just keep it simple. You can get at least a semblance of reasonably realistic weather without having to simulate a weather prediction program. Locally, weather doesn't usually change directions anyway so just having the weather itself move in a straight line actually doesn't hurt realism as far as the game's players would be concerned. So yeah. If most other KSP fans are like me, then they want rain, storms, wind, clouds, fog, and so forth because it adds a new dynamic to designing craft and making sure you launch at a proper time. NOT because we just want to simulate what kind of weather Kerbin would actually have on a supercomputer.

Another reason we haven't seen much on the weather front is in part due to the expectation of a full-on weather simulator. Like, with an actual, simplified weather dynamics simulation with cells located across the planet and generally acting like a substantially scaled down version of simulators that actual weather prediction software uses. Those weather prediction programs tend to run on supercomputers. So even a significantly scaled down and simplified one WOULD indeed be a MAJOR processing power concern. And such, as Gaarst is concerned, it would only be usable by people with better computers. That's why, after some thought, I decided the most realistic approach is the route I numbered as "1" in my original post, and expanded in a subsequent post. It does not seem like it would need too much processing power to do what it would do. The whole planet (or just each biome) would have a single, consistent and unchanging weather "pattern." And some regions that have a different weather pattern would effectively generate and move across the surface in a straight line at a set speed for a set time, almost like it were just moving in a low altitude, slow "orbit" as far as the game is concerned. The game is able to fairly easily handle us putting hundreds of satelites (and pieces of debris) into orbit without issue, so 50-100 weather systems (depending on how many each planet with an atmosphere gets) shouldn't be too bad. Like satelites, only 1 or 2 would be "loaded in" at a time. Hence my theorizing that with this system, the big leap to make is to introduce the actual weather itself. Namely, wind, and the necessary physics engine changes to support wind. Well, ok. Wind, and the necessary graphical changes to see clouds, and visual effects like rain and snow and lightning. The stock graphics should of course be fairly low power as is viable without reverting to 2D images (you could even imagine having boxy minecraft clouds), but at the very least it would be a visual thing and thus something that can be offloaded to the graphics card. Modders can then make the clouds (and other visual effects of weather) look awesome, like they have with other visual aspects.

Ah. In my naivety, I guess I figured it would just be something like "change it so you get all possible science from transmitting," which is usually less than the full 100% from recovery, so I made the assumption that would make it so that it gives you all the science a transmit can give you from a single transmit. Which means that you would then need to adjust all stock science transmit values from their various 30-100% so that they all are 50% instead. Which may well be more than mere config edits (although, if its just in a different config could it be doable with just the caveat that it won't effect non-vanilla science parts?). But yeah, this is just me acknowledging assumptions and making some new ones in hopes that there is a simple way to achieve the basic effect.

One thing that could be neat is if transmitted science can transmit, say, 50% of the total science, but cannot transfer any more. In other word, transfer would tranfer ALL the science it CAN transmit at once, but it would be limited to 50% of the total (for the other 50%, you'd need to recover it).

No one expects the Kerbish Inquisition!

If someone does take it up and considers multiple resources, then I would suggest maybe 3. Silver, Gold, and "Crystals" (which could mean anything from diamonds to corrundum-type things like saphires to whatever weird and possibly valuable things you might find elsewhere in a space setting). Three seems like a good number for sake of balancing rarity and value with distance.

Could also set it so that Engineers can repair some effects that result from damage, depending on their level. i.e. an engineer past a certain level can completely repair a leak. Additionally, if some damage completely disabled something (like a control surface's ability to act as a control surface, or the gimbal effect of an engine), a good enough engineer could potentially repair that part to partial effectiveness.

To give some further thoughts/clarification on how idea Number 1 in the first post could work, mechanically: -(Before this, of course, you need to get the hard part of getting wind support in the physics engine out of the way, which would probably entail "just" taking the resulting vector of the vessel and the wind and treating the aerodynamics for the vessel using the resulting vector). -For purposes of performance, it can be considered to set it up so that wind (and other weather effects) would not be applied to all loaded vessels. Perhaps instead, it would be only the current vessel and any objects that are fairly close by. Naturally, the system doesn't need to be running when no loaded object is actually in an atmosphere either. Step 1. Default Weather. You do one of two things. Either, you set the entire planet to have a "default" weather, or you set each biome to have a "default" weather. If you take the biome approach, then you don't need to worry about the "1B" section of the original post since you can just use a biome to create a permanent weather effect (such as a "Great Jool Blot or some other Great Red Spot analogue). It will also allow science parts that deal with weather to potentially get biome-specific data if you want. Regardless of the approach, the default weather would be unchanging. For Kerbin, it would generally be sunny skies with no clouds. If taking the biome approach, a biome like mountains could have some low level gusting effect if you want to make things interesting, but each biome would generally just be a clear skies, no wind, and a temperature that fits the biome, with no changes of any sort, ever. No processing power would be used for any form of dynamic weather simulation or anything. Step 2. Introduce the weather systems. These weather systems would generate at a random location on the planet. Upon their generation, they become a random type of weather system, with the odds of each (and which ones are possible) being weighted by where on the planet they generate. At this point, it then randomly generates a direction, speed, and length of time. The random generation for each of these three values could be weighted based on latitude and what type of weather system was generated. At this point, the weather system is generated, and proceeds to move in a straight line in the generated direction at the constant speed that was generated. When the amount of time that was generated ends, the weather system disappears. Each planet would have a "weather system value" allocated to it, which is the number of weather systems it has at any given time. So when one system disappears, the number of weather systems is now below that value, and thus a new weather system is then randomly generated. -For simplicity, the weather systems are divided into distinct, preset types, the same way biomes are. Aside from the randomly generated values, they would generally be identical to other weather systems of the same type. i.e. a "humid partly cloudy" system would not differ much from any other "humid partly cloudy" system. -Some values could be randomized a bit for each individual system, such as the wind direction and strength, so that different systems may have different speeds and directions for their wind (the values for any given system remain constant for its lifespan though). Step 3. Weather system mechanics. A weather system would simply overwrite the wind and weather data of the region within its area of effect. It would also either overwrite or apply a modifier to the temperature. The modifier is preferable, so you don't get a thunder storm near the poles making it 20C and raining in a snowy biome. The visual effect of rain/snow (i.e. which one it is) can simply be based on the temperature. Other values that the weather system can overwrite, if they are included in the weather engine, could include: -Humidity and pressure. These would mostly be important for science parts. -Lightning. Mostly for visual effects. Could have some mechanical effects if a vessel is struck (i.e. disabling controls for a couple seconds unless it strikes a "lightning rod" part, and possibly destroying/permanently disabling any parts with a "vulnerable to shock" tag if they are struck directly, i.e. sensitive electronics). -Gust Values. These effect how frequently/strongly the wind direction will have sudden, randomly generated changes. Said changes would last up to a few seconds before returning to normal, and would not have any positional value. They would simply affect all vessels that are currently being effected by wind, regardless of location (naturally, vessels that are not loaded are not effected by wind). -Icing. I could see ice effects being a hassle to code for an effect that would see fairly limited use, so we could probably just rely on modders for that. Otherwise, some weather systems could simply include a value that indicates what altitude the icing is at, with the altitude varying linearly (to keep things simple) with temperature, and only being present between specific temperatures. Icing could work similarly to the heat system, with it building up while in the icing region and slowly dissipating while out of it. Its effect would be reducing the lift of effected lift surfaces, and reducing the power of control surfaces. This about covers the basics. If you want to make things fancier, you can consider some of the following things as well. Step 4 (optional). System interactions. Each weather system type could have some possible interactions it can have. These interactions would generally work as follows: If the weather system's location (likely its center) either enters a particular planetary biome or goes above/below a certain latitude, then the system undergoes some predetermined change. Examples could include: -The "humid partly cloudy" type weather system, if its center enters a mountain biome, randomly transforms into either a "mountain rainy" type or a "mountain storm" type weather system, and changes its wind, rain, and etc values as fitting. It still remains on the same path, moves at the same speed, and has the same time before despawn remaining. -A "mountain rainy" or "mountain storm" system could transform into a "fair cirrus" type weather system upon entering any biome that is not mountain, if you want to "simulate" rain shadows. -A "hurricane" system could transform into some form of standard storm type system upon its center entering any biome other than shore or ocean. -To prevent sudden, strange changes to appearances, the clouds themselves do not change if there is a loaded vessel in or near the weather system and remain the way they are until the player either goes away, or unloads the vessel by returning to KSC or something. Alternatively, when a system changes, clouds could simply have a gradual change that takes place over 10 or so minutes, rather than being applied immediately like the rest of the changes. Step 5 (optional). Local Effects. Severe weather events like tornadoes, microbursts, thermals, etc. Stuff like microbursts and thermals would be a localized effect where a fairly small area is effected by effectively either a downwards or upwards wind. Tornadoes would be a bit more extreme and would require a definite visual effect. A dust devil would require a visual effect, but could just cause a slight updraft and some constant gusting effects while in it. Static biomes could also potentially have these occasionally occur. For instance, a volcano could occasionally have an "eruption" local event that basically just affects, well, the part that does the eruption. -Much like how weather systems overwrite/modify the biome's default atmospheric values, local effects could have an even higher priority. -Some of these effects could have a chance of spawning when certain weather system types are in certain biomes. Step 6 (optional). Seasons. The easiest way to put these in would probably be to just set some biomes to have some different default values for each quarter of the year (namely temperature, but you could also have some biomes that have a consistent wind in some seasons too). Each biome effected by this would need a value that indicates whether it is "north" or "south," so you could use the same biomes in different hemispheres and have them just be offset from each other. If you really wanted to go nuts with visuals, you could set some of them to even change textures based on the season. -Using this, you don't need to worry about the planet's tilt. Which is probably good, since there aren't really any with that for the sake of simplicity. .

I meant more with regards to the way people like Randal uses the word "kerbal" as an adjective. In his case, he uses it to describe the concept of... well, this. https://what-if.xkcd.com/139/ You cannot argue that it would be quite kerbal to stick a heat shield on a submarine, and drop it into jupiter's atmosphere. The rabbids seem to base their entire "space program" on that sort of style. Mixed of course with a hefty dose of "there is no way that would EVER work in reality." At the very least, they need more struts. .