MNorman

I am beginning to think that being able to freely run experiments anywhere is begining to become part of the problem. This is particularly so for Kerbin EVA, where so many science points are available around the space centre. this combines with another problem that orbital EVA sciance is biome specific,requiring you to get Kerbals in and out of the capsule all of the time. I would replace the current science system with a system of 'academic' contracts, which would require specific experiments to be run in specific locations, and would be the primary source of science. These contracts could then be tuned, so that simpler contracts become less available as time goes on, to reflect the 'biome exhaustion' effect seen with the current science system. However, it is unlikely that with any system like this, a player would get as much science from Kerbin as currently available. One necessity of this, though is to make there a sufficient number of different contracts that a player is given options of a wide variety of different missions. On the other hand, it is quite easy to have more different contract types than there are experiements. While part tests can be included in this, I would ideally want part tests to be a slightly different approach. A part test would allow free use of a part without it's technology being researched. However, to reduce the possibility of abuse of test parts, the part would not be functional for other uses until tested (a tested engine, for instance would not activate when staged until in the correct location for testing). The ultimate developement of this, which mught be a bit excessive, would be to have 'technology demonstration' as an alternative to part entry costs, where to unlock any part (or group of similar parts, to avoid the system being too boring) when it becomes availble, you would have to do an associated contract. These contracts would sometimes be tests of that part, but not always. You could sometimes have special 'test' versions of similar parts (described as being modified to simulate the new part). You could have special materials bay tests (for example, one test for an LV-N would be to test the shielding material in low Jool orbit). One restriction on making this sort of system fun is to make the test mission make some sense. for example there is no value in testing a vacuum optimised engine on the launch pad, and there is no point in testing parts outside the Kerbin-Mun-Minmus system, unless tesing in an atmosphere or a high radiation environment.

I am not an expert in these either. My information on the fuel selections, inclding the attempts at large monoprop first stage engines, come from Ignition!, which is by far the best source of information on poor fuel choices.

Lots of monopropellant engines would make sense for the UK as they did investigate monopropellant first stages. Unfortunately, they used HTP, which is a heat-catalysed reaction, and tends to break down when stored for a long time in a large volume. This, of course led to several explosions, and never got used in a production vehicle. In addition, the only product of the UK since the abandonment of the Black Arrow launcher has been satellites. Given that, RLA would be ideal for 'UK' propellant mixtures. In addition, Black arrow was a small launcher, capable of putting only 135kg into LEO, but is had 8 engines on the first stage. I could only match this with RLA.

KSP can use 64-bit Unity in Linux, but there seems to be no advantages in memory use. Accoring to a comment I read in the Bug Reports forum, this is probably due to a bug in the Unity .png handler

Using the version released on 26th May, the functionality of the useRealisticMass option in RealSettings.cfg seems to be reversed for tank dry masses. Setting it to true results in normal KSP massess, while setting if to false results in the reduced, realistic masses. The engine masses, on the other hand are the other way around, with a values of false reulting in KSP masses and true resulting in realistic masses. The behaviour of the engine masses is the same as previous versions, while the tank masses are changed. While checking this I noticed that the additional dry mass for a Nitrous Oxide tank is much greater than for other tank types (3 time the additional dry masss for a Xenon tank, and 30 time that for a nitric acid tank). Is this intentional?

I am having problems with the interaction between realfuels this and the StretchySRBs. If I build a vehicle with stretchy SRBs of different sizes, if I try to launch the vehicle, or try to change the tech level, they are all set to the thrust of the most recently changed SRB. This did not happen without realfuels installed (removing the ModuleEngineConfigs from the stretchy SRBs)

I have been having some problems with the stretchySRBs. If I use them with the version of the modular fuel system without the real fuels I cannot change them, and cannot select them in Action group mode. If I put a stretchy tank above the SRB and mouseover the SRB in Parts mode, or select it in action group mode, then the game responds as if the mouse pointer was over the stretchy tank. If I then remove the ModuleEngineConfigs module (Which I understand to only be used by the real fuels version of the modular fuel system) from the cfg file, the SRB works as expected.

This is on Linux with a Nvidia 560; everything worked fine for the betas. I looked through the logs and didn't see anything, but in case they might be of use, they are available here. (The logs are from a run with the city lights dll removed; the clouds had the same appearance.) http://pigsandtoasters.com/Player.log http://pigsandtoasters.com/KSP.log I have been getting the same on Linux with a Nvidia 650 and release 1. If you look at the overlayed texture carefully, it is the bump map texture, which seems to be being drawn instead of being applied as a bump map. When I removed the bump map from the configuration file, the cloud texture showed up correctly. In addition all of the other cloud textures are visible with no problems, and these do not have bump maps.

If the plates are stainless steel then they actually become more resistant in an acidic atmosphere. There is additional initial corrosion, but this results in a thicker passivating layer of chromium oxide, which is then more protective.

I have been messing around with robots. This actually walks (drunkenly) Each joint is in a separate group with the joints on each side being mapped to keys opposite ways around (so that when the left hip goes forwards the right one goes back, and when the left foot goes up, the right one goes down). The whole thing is kept upright by a pair of reaction wheels. While it works, the wobblyness of the current SAS implementation makes it look a bit drunk, and it has a tendancy to fall over. On the other hand, only having one point of contact with the ground means it can turn on the spot.