Ser

@Veeltch Well, if it was you who answered let's go in order Any body? So that automatically means that biomes would be ignored 100%. We cannot afford that because we already have too much abstraction and cannot afford to abstract from biomes, as they are important IRL: during Moon missions astronauts were driving away from their LZ to collect samples from different places, the same purpose is chased by the martian rovers. Ok. What would we need to develop the next advanced wheels? The same experiments? So it would be enough to get to the same places and do the same things? Or would we need to do some additional things like, say, atmospheric experiments? Then what about the atmospheric experiments we have already done to develop, say, wings? Should they be performed once again to get more advanced rover wheels? I see that we end up here with the following: 1. We just wouldn't have enough experiments to perform. How much experiments do we have in KSP? We do not multiply this number by the number of bodies and biomes because they don't affect. And how many parts are there? Much more, and gets even more with every massive part mod installed. If every part requires several experiment types, say 3 per part in average, our number should be divided by 3. Thus we get just a few variants of "research process" and a bunch of parts to research. 2. If we'd require to repeat experiments for every next part that would be an abstraction as doubtful as having just science points. In the name of what should I collect the same science data to develop new parts? Ok, we may keep the stock mechanics when experiments can be done only once on the same body and biome. But that would be even more doubtful because we have researched simple rover wheels taking surface samples from Munar highlands and they work for every biome on every celestial body but we can't develop advanced wheels using the same samples as we need data from Midlands or Craters now to create wheels that would be able to operate on every celestial body though. And the same question: what would make me go to Jool if I can do all experiments at Kerbin/Mun? Rep? But how many experiments can be done on Mun for the time required to reach Jool? So the same abuse is possible: unlock majority of parts using Mun and go to Jool for rep in a simplest way. Hey, but what you think we do when we collect data and bring them back to R&D allowing to research a new tech? Yes the data aren't bound to the concrete experiments we've done, but that's an abstraction and can be explained by different teams constantly working. No. Have no idea why have you understood me that way. I've meant that in the process of research a lot of side results is generated, i.e. various theories and conjectures not having practical applications yet. They are accumulated as articles named like, say, "Theory of covergent combobulation" born from atmospheric studies. But then someone working on girders that should stand certain amount of twisting momentum recalls that there's such a beautiful theory, uses its applications in his work and gets astonishing results. In the game this process is abstracted in just some amount of science being consumed during insignificant winglet research, and then another research of girder that looks unconnected. Someone who gets paid and has appropriate data. As I've said, you never know what might give you a hint in your research. You may work on super durable synthetic fibers for spacesuits but some biologist suddenly finds that spider web is hundred times more durable then any fiber made by a human, etc, etc. You see, real life is much more complicated than any game, there are different ways where you're research may come: 1. Projects that never end, which prove the fact that in common starting a project you can't say how much time, effort, experiments, money and "science" will it require to accomplish. Examples are quantum computers and energy-efficient thermonuclear reactors. 2. Projects that are done in the following way: "we need new fibers for space". Scientists begin to think and read books and after some time give you a material to test in space. After several iterations you make something of it. But the research continues and during 15 years you take different materials to space to test them and sometimes get some improvements. 3. Suddenly you get an invention as a side effect of another project. Examples? Cosmic microwave background radiation, teflon, smart dust. Is your complain about that we don't pay for research in the game? That's an abstraction too. We also don't pay salary and insurance to astronauts, engineers, medics, astronaut training staff, taxes. I think if the game had all of these aspects we'd just got bored by accounting. I don't mind if research would cost funds, that's not the biggest problem we discuss here, is it? P.S. hell lot of text, to be continued

Deep space gives you knowledge of vacuum and low temperature environment properties that allow you to build more efficient tanks that can contain fuel in extra cooled state, for example. Also you get data to solve a RL problem: what materials and how much of them should be used to build structures capable to carry out required inner pressure while operating in space (Apollo-1 accident was kinda related to this). The more knowledge of space you have, the more efficient structures (incl. fuel tanks) you build. Anything can be explained, just need some imagination. Anyway science points or anything we would do in the scope of KSP is a great abstraction solving troubles and inconsistencies only to a known degree, just because the game is far from how things happen in RL. And science points aren't the worst model. You may think of them as of a common amount of un-systemized science data. Once you consume them for research they become systemized and continue to exist in the form of conclusions, scientific articles, blueprints etc, that are just not represented in the game but waiting behind the scenes for their time to be used to develop a new part. How data on Kerbin's high atmosphere help to build a new kind of girder? Imagine that behind the scenes there are several teams, one working on girders and materials, another on atmospheric stuff. Getting science data from atmosphere you help the team working on atmospheric stuff, but as a side effect they invent something that pushes girder research forward. There are plenty examples when, say, bacteria research suddenly helps to develop new plastics, for example. In RL you never know where exactly your amazing data really shoot. All those effects are just abstracted in science points concept. Can't agree. Playing the game in science mode I always asked myself "what stops me from overusing parts and resources and from crashing rockets in hundreds?". Obviously, when things have their price (as in RL) it forces you to play efficiently. But yes, career mode implementation isn't ideal.

Yea, I've missed this key all my life too and know what? Messing with API I've found that controllers seem to have an advanced configuration for the barking prake, but there's still nothing for keyboard. That's ridiculous.

Version 2.1.1 is out Available on Spacedock Changelog: Added a configurable extra hotkey for parking brake (Alt - <brake key> by default, release as usual by the <brake key>) Improved steering precision - no need to set Friction control to maximum, set it to your taste Fixed some settings saving

I understand, in general. That's interesting. But I don't understand the following: to develop a certain part you would have to do a certain set of experiments in certain situations, say to get yourself an advanced rover wheels you'd have to go to Mun and take surface samples there, right? But what if I ignore Mun and go to Minmus or Dune instead and perform similar experiments there, would I find "rover wheel blueprints" under the Dunian rock? If not then that would be weird because that would feel like parts are just spread across the world and certain ones could be found only in certain places. On the other hand, if there's no difference where to perform experiments then it would lead to exploits like gathering everything on Kerbin (or on the closest Mun), getting all the parts as easy as possible and then head to Jool on a supercharged vessel for rep. So it seems that to develop advanced wheels some experiment weight value would be needed, say I could take either 20x samples from Mun, 10x samples from Minmus or 2x samples from Dune. And what's that if not the same science points with body/biome multipliers as in stock, just differentiated and specialized by experiment?

Okay, you're first to land on Mun. And that's it? Mun is done, time to head to the next one?

I'd say KSP is a science game at heart, career has been introduced to increase motivation aspect. Sandbox is a "give me everything at once" mode, the furthest from "Space program" idea. As if you played a tycoon game and cheated yourself infinite funds to afford anything without any effort. That's still playable, but loses half of gameplay. I know that many people play like that but I still can't understand what's so interesting in having access to all the parts at once. To try how they work? To look how physics work on every celestial body? Ok, you'll try every single one in 50 launches. What next? Wait for the next KSP update demanding "moar parts"? For me, when you have to care about funds and look for science, and then make hard decisions to get more advanced parts that let you make another step forward gives the most thrill of exploration, and that is called to run your kerbal space program. Of course, if you already have seen and tried everything in 10 launches, there'll be no more thrill and only a stupid grind left. To not stay off-topic, the things I'd want to get rid in the stock game are strategies (I just don't use them), science rewards from contracts and some stupid contracts like kerbal rescue (from my pre-1.2 experience)

What would motivate us to send rockets to space then? Contracts? Eeew...

Since @Chronothan hasn't showed since 2014, I've continued maintenance of this mod in a new thread:

Version 2.1.0 is out Available on Spacedock Changelog: Some important features implemented: * Added control surfaces and steering response scaling - a pair of new settings for control sensitivity. Set your steered wheels friction control to maximum and you'll see that steering can be amazingly precise The feature is demostrated in this video: https://youtu.be/YwQB7irv5gs * Fixed steering wobble when close to the deadzone * Added control state persistence on quicksave/load - you don't need to quickly grab controls when loading right into the final approach anymore, now the mod will load with controls paused in the position that was when you saved. If you quicksave in a level flight then your vessel proceeds in a level flight after loading * Improved settings window

@ferram4, I have a modder's request: could you make the field timeConstant in FARControllableSurface non-static? When it's static it's impossible to alter control response only for certain surfaces, say ailerons separately from tail, and that takes effect for all vessels at once. It would be more flexible to have an ability to set that property per module instance.

Ok, if it doesn't break AJE functioning. I guess I should filter by ModuleEnginesAJEJet?

Haven't pay attention to that, but I was able to drive along the runway about a minute with no flameout. I will be able to test that a bit later. Yes, that in fact is a compressor. The word "Turbine" just sounds more epic for a regular player I don't understand why it is that complicated. I'm not going to simulate a real compressor with all the air compression maths. My one is just a ModuleResourceConverter that converts uncompressed air into Intake Air needed for engines at the rate 1/1. All that is needed is that engines require some insignificant amount of IntakeAir resource just to check if it is available, all the rest may work as it currently does. So an engine would require that 1. Intake area is enough 2. the engine has any amount of IntakeAir, doesn't matter how much. Otherwise it flameouts. That will be more an emulation than simulation of a jet engine but still more realistic than having a fuel tank between an intake and a nozzle. What do you think? EDIT: doing so will have an additional effect: engine would automatically require a proper flow of intake air, not allowing to place an intake on any strut connected to the vessel.

@blowfish, I've noticed that with AJE engines don't care about IntakeAir. First, I can place an intake everywhere on the vessel, even on 90 degrees rotated girder, the cosine (what is it, though?) still shows 0.98 and engines work. Second, I've used MM to replace intake's generated resource from "IntakeAir" to a new "Uncompressed air" resource and was surprised that engines still work. Stock engines flameout in that case with "Insufficient Intake Air" reason. But with AJE they flameout only if intake is closed or absent with the reason of "Insufficient intake area", otherwise they work regardless what does intake produce. So it seems that it is enough to have any hole of sufficient diameter anywhere on the vessel for engines to operate, and that's not right I think. Is it possible to check at least the fact that an engine has access to IntakeAir resource? I want to force a player to put a special "Turbine" part between an intake and an engine that would convert "Uncompressed air" into the old IntakeAir resource for the engine to operate, but the fact that engines don't care about IntakeAir ruins my effort.

Doesn't Engineer Extensions Redux mod help? To do it with Hangar Grid I'd suggest you to try the following, though it would require some eyeballing: hover the mouse over the girder that is already in place and press G on it. That will bind the grid to it. Then select another one. Now you have the grid originating from the center of one part and the guides from the center of the other one and can align them manually to match the lines. P.S. Guess I really need to do something about that translation alignment. EDIT: what stops you from using x2 central symmetry for that?

@diomedea @evileye.x @Murdox Try this build: https://github.com/SerTheGreat/G-Effects/releases/download/v0.4.0-rt-fix/G-Effects-0.4.0-rt-fix.zip and let me know whether bugs and FPS drops persist or not I just tried with G-Effects and without it using GCMonitor and hadn't notice any FPS difference.

Which mods are installed? And post your KSP.log file please.

Thanks for the report, I'll look into this. As I understood, uncontrollable are the vessels with lack of crew, right?

FPS? Haven't notice such problems, except for the cases when logs were heavily spammed which meant that per every frame there were several seek and write disk operations that would hurt performance. Normally this mod doesn't perform any heavy calculations or searches, nor loads any significant number of textures so there shouldn't be any FPS impact at all. If you notice something feel free to report. I haven't done anything about it to not delay KSP 1.2.2 compatible release any further. Speaking of stock settings integration, there are pros and cons. It would be nice to have G settings in the same convenient place but on the other hand if when Squad decides to move them or change the way they work that would break half of the mod and would require to get everything together again, do tests etc. So in terms of time that means to spend more time on integration in order to spend more time fixing it in the future. So settings are not of the highest priority, I'm satisfied that at least everything works at the moment. As for stock stats, initially I was against them because it's unrealistic to raise G tolerance based on experience. Real astronauts/pilots train for years to withstand G forces, actually being an astronaut means to have regular centrifuge training to keep an appropriate shape, not to get a star for just one flight and a great strength with it. What can really happen after a single mission is a significant shape loss due to continuous living in zero-G environment. That effect is simulated by the KeepFit mod and it was intended that G-effects should be used together with it to have varying G capability for kerbals in a realistic way. Also I have some doubts on KSP 1.2.2 new stats. "G endurance 2.12x" - what does that mean? Can you tell up to hundredths how stronger you are than your mate or exactly how stronger you became after a single event? I think if such numbers exist they should be hidden deep inside logic and we should see only some statistics on the number of missions, days in service or something like that. On the other hand, in KSP world many things happen instantly: rocket building, technology research and many other things. So gaining experience and G stats could fit that compressed time paradigm. "G endurance" numbers could be thought of as a result of a centrifuge test that a kerbal has already passed behind the scenes. Don't know. I'll look further on how stock stats work and think about that more, so discussion isn't closed yet.

A quick fix can be downloaded from Spacedock Removed unintentional log spam that could affect FPS. So the fix is recommended to download.

What can I say? You're good But what about smooth and realistic (with chance of survival close to 100%) landing with FAR? Or flying far away with 4x time warp without having your aircraft perform a 540 degree roll on a single key press? Analog Control has happened 1.5 years earlier than Mouse Aim Flight : http://forum.kerbalspaceprogram.com/index.php?/topic/89385-090-v15-analog-control-fly-smoothly-with-keyboard-and-mouse/ But more important thing is that (correct me if i'm wrong) Mouse Aim provides War Thunder-like control whilst Analog Control allows you to fly a plane in a flight simulator way. I'll explain: with mouse aim you point your mouse where you want to go and via some amazing logic computer flies there for you. Real planes aren't piloted that way. With Analog Control mouse is directly connected to control surfaces giving you a feeling that you are holding the stick. That's the difference.

Bloody hell, I missed that debug logging. Tomorrow (in UTC) a quick fix will be released.

@something Speaking of integrated graphics performance, 16GB RAM that you have on board are by far not perfect for graphics processing because integrated cards don't have their own video memory and utilize a part of regular RAM where your OS and all of loaded KSP data are and all of them use the same bus to transfer data. More of, your regular RAM is DDR3 I guess, whilst external card's own memory is GDDR5 with its own bus. Thus having 2Gb of RAM my laptop's integrated graphics perform similar to the ancient GeForce MX440 and are able to run software demanding not more than 128Mb of video memory. So integrated cards were always positioned optimal for office use. Don't know if some were advertised as suitable for gaming, but I wouldn't believe that.

As I've promised not so long ago Version 0.4.0 is out Available on Spacedock Changes: KSP 1.2.2 compatibility Integration with stock G indications Timewarp compatibility Fixed some sounds being audible during G-LOC Fixed epileptic blinking on wake up from negative G-LOC Stock g-meters and notifications correspond to the mod's state. If you don't need them you may disable "Kerbal G limits" in the game's settings, the main mod's behaviour won't be affected. Kerbal experience and other stock g stats are ignored. Under OpenGL greyout shaders still display nothing but a black screen so disable them in config file in that case

I haven't tried to bind specifically SPACE but there should't be any troubles. Use Alt-O window for that.