r_rolo1

Couldn't agree more. I'm also in a non English Keyboard ( Portuguese ) and suffer from the exact same issues: some native keybindings do not work ( exactly the same one you mention, next and previous craft in flight view ) and special chars are not even usable ( in my case ç ). Ok, unlike olden days we have a significant latitude in remapping keybinds, but it is still a issue .

That is a fair point, mostly because, due to the nature of physics, there are only three ( or four ) real dificulty bumps in space exploration for non-ageing beings that don't need to eat, drink or breathe : getting to orbit, docking and make a return mission ( the fourth is getting functional IRSU ). Tailoring a dificulty curve out of a curve with a couple of cliffs is hard, especially if you add the assumption that parts in general have to get better with time ingame ( gamers absolutely loathe "Dark ages" in game progression, where stuff doesn't progress or even regress ). That said, note that the current interaction of the game tech also does not work very well in keeping the game enjoyable and challenging after you have managed to dock and have 2,5m parts ... and it is discussible if it does that before as well, so it is not really a defense point for the current interaction of the tech tree

Well, the issue is that there is a not so fine line between having parts strategically placed to various places of the tech tree and having them scattered around the tech tree to force players to go everywhere. The second is the exact oposite of any normal game with a tech tree or equivalent does ... most games ( and RL, I might add ) make very that you reap rewards of specializing in between some very distinct branches ( also in most games you have at all times between 5 or 6 choices in the tech tree at all times to promote diversified game play and keep the player with the feel they can actually choose ... ) and yet it is what KSP has at this point: we have both parts sneezed out through the tech tree to basically force the players to go everywhere even if they don't want to ( note that this is not my words ... just rewind to the pre-1.0 dev notes and see what SQUAD says about how the current interaction of the tech tree was chosen ) and basically a railroaded best aproach to it, dictated by the fact that most science gatherers are in a conga line through the tech tree... Besides that KSP is suposed to be a Tycoon-like game ( BTW SQUAD, I still want to train my astronauts after all this years, and with that I mean something diferent than going to Duna to learn how to change a tyre ) and any Tycoon game worth his salt has their progression bunched in discrete untis that unlock similar upgrades. Say, using OpenTTD example, you don't start the game with rails and buses and only some years later you learn to make trains and roads ;), Yeat in KSP nowadays, you can easily get locked in a situation where you have to choose between having X m fuel tanks but no X m engines or X m engines and no X m fuel tanks ( again, let me point out this is a deliberate ( and IMHO stupid ) choice to make the players go in fetch parts quests through the tech tree ) and we get stuff bunched in the same tech that has no business going together ( say, that nice tech that unlocks 2 extendable stairs ... and a Mobile crewed Science lab :| One of those things is not like the others, methinks ... ). OFC that being a tycoon like game would also mean that the price structure of parts making and unlocking would also have to be sane, something that it also isn't ( Good ol'Mammoth vs Vector example ... ). P.S I : Getting this balance between having diferentiated branches and keeping the player with 5-6 choices at all times while still keeping a somewhat coherent experience is HARD. There is a reason why game design is a job, and a well paying one I do not criticize SQUAD for not being able to get it right, but SQUAD made the conscious choice of making people go around the tech tree to fetch parts that were scattered all along with the exact propose of making the players to wander around ( BTW the same strategy they implemented to their comunications with the fanbase: one tidbit in twitter, one on reddit, a crumb in Squadcast ... maybe marketing people think in everything that way nowadays? ( and before someone says anything, this is the official position of SQUAD, by KasperVld mouth, in this forum ) ), a aproach that was doomed from the start to produce the kind of results we have. Well, TBH, in all of this years KSP never really had a game designer that knew it's trade ( with all respect to Harv, but we all know that even Harv agrees that he would had not made some choices he did if he knew what he does today ), so maybe I was expecting too much ... P.S II On the manned vs unmanned issue some others brought out: the current state of career mode makes that the whole "we need green animated ragdolls in first flight " a little moot , since we can't see them in flight until we upgrade a KSC building. Sure we can see some animated portraits in the bottom right corner in the first flight, but in gamewise visuals it makes very little diference if Jeb is the capsule or sipping coffee in the Mission control reading telemetry in the first flight, because you can't EVA You could even plast the same portrait in unmanned flights if you really , really want to see kerbals and say that the kerbal you have there is the Flight controller for that mission More seriously, the fact that SQUAD chose against all clamors to stick to manned first ( not even manned OR unmanned first ) aproach has has some IMHO bad repercusions on the rest of the game, including on the parts avaliable in game. Say, the RT-5 "Flea" only makes some sense in existing compared with some other probably more useful SRB options ( say, a RT-10 lenght 0,625 m SRB ) because SQUAD wanted to have a SRB for the first flight that could basically send a MK1 capsule to 10 Km if finely tuned ( like the RT-10 did in the soupsphere of old ) and obviously you must have a 1,25m SRB under a 1,25m capsule ... ( again, not my words. In this case Scott Manley and NathanKell ones ). So we ended up stuck with a part that , while useful, probably is taking the place of ther even more useful parts just because Jeb had to be in the first flight. Other issue is that, IMHO the unmanned rockets are having too much of a nerf already even without forcing the players to not using them in the first flight: manned flights can get more science collecting options than unmanned ones ( crew reports, EVA reports and samples ), 2 of them that can be dialed home without losses. More, most probe bodies are ridiculously underpowered in terms of actual control force even compared with the weakest capsule and even probes + reaction wheels ( that also come somewhat later in tech tree than desirable IMHO ) normally lose to a capsule of the same weight, probes bodies can't store RCS for fine control and , probably the worse, manned missions can reuse two experiments that unmanned missions can't and the data crunching you can do on the science labs if manned to get even more science you simply can't have in unmanned missions. EDIT: You can also put all of your collected science in a nice reentry worthy manned capsule to 100% recovery in Kerbin, something that you can't do in unmanned missions ... and we know how heat sensitive some science parts are :/ It is really needed to push usable probes to the 4th tier of techs vs the fully controlable manned capsule in 1st iter on top of all of this to balance the rocket equation tyranny? I wonder...

But SQUAD named it It is not that they chose to keep the star unnamed , right? They just chose a name that it was not the name the community had chosen back in ol'days and for some reason ,most of the community decided to ignore the devs about this particular name ( it is not that we see people asking to name Kerbin Kearth )

Well, I described succintly what stock burn time does in the post you quoted, but I can obviously do it in more detail ... First of all, you are half wrong, since the stock burn time is not necessarily a instantaneous measurement and it does not use the current acceleration. What it does is to get the maximum acceleration you got in your current map session since your last staging event and use that for the burn time calculation. So the value the stock burn time is only right if you're at your max thurst all the time and will only self correct if your thrust is increasing ( if you don't believe me , just boot the game and decrease your thrust after creating a manouver node ). In other words, the current stock burn time, unlike you state, assumes stuff about your ship in the future: it assumes that you'll not stage during the burn and it assumes that you'll never decrease your thrust in between staging events. Those are quite heavy assumptions and the reason I brought it to this discussion. It was SQUAD that defined the level of what is to be expected in terms of gauge quality by doing the quite hacky burn time meter we have since manouver nodes exist and it is somewhat intelectually dishonest to pretend we have some kind of high quality bar for a dV meter when both devs and players have been OK with a low quality gauge elsewhere.that shares pretty much all the same potential issues a stock dV meter could have :/

Well, on your a) ... well, I definitely don't need it, but I also don't really need manouver nodes, burn times, close aproach markers or even SoI change signaling since I learned the game before any of those things were even in the game at all ( and people earlier than me don't even need map view, since they learned the game when they had to do math to know they were in orbit ). Other people mileage might not be as long as mine or yours, mind that and OFC, not needing a thing is not the same as having that thing not being a plus On your b) ... well, that is pretty much why I brought the burn time to the fray. As you said , the burn time calculator uses the max thrust of your map session to calculate your burn time ( that alone is problematic by itself, because it does not save the time to burn if I get out of map session and go to the VAB or something, but that is not my point here ). That brings errors everytime your burn is made at diferent thrust than max session thrust, as you point, but ,unlike you assume the errors do not self correct ( they would only self correct if your thurst either flatlines at max thurst or if your thrust is ever increasing 100% of the times, hardly a certainty ). I also must point out that the game burn time is also increasingly not assuredely correct as your ship increases in complexity ( besides more engines being a source of more variable thrust levels, more parts normally also normally means more losses to mechanical deformations of the ship ), effects that are not taken in account in the stock burn time meter ... not mentioning that it doesn't care if you will have to actually stage in between the burn My point in here is that it was SQUAD that lowered the bar in what is to be expected in terms of quality for stock. You can't drop something like the stock burn timer, that gives almost always bad answers and it gets worse with more complicated ships, leave it there basically unchanged for years, and then be all prude and saying that you don't want to make ( in case of the devs ) or want to have ( for the rest of the mortals ) a stock dV meter because you don't want to put in game a possibly inacurate dV meter that can get more complicated ships wrong. That is incoherent at best .

Well, by that logic, we should also take the burn time of the game, because that thing will spit nonsense numbers a lot of times, when it simply does not throw a N/A on you ... I really, really, don't get the whole " if it can't be perfectly accurate, better don't have it" line of thought some people showed in this thread. RL doesn't work like that and TBH, games also don't work like that ... and in case of KSP it is even worse because the whole game is built on top of a not so accurate representation of orbital mechanics that will always get things wrong

To not lose a lot of time typing it all again ... So, I assume that you want to make Kerbin Kearth again as well, right ?

Yeah, I have to agree that "Sun" is a very flareless name, but well, "Mun", "Eve", "Duna" , "Pol" or "Ike" are not exactly exotic or space-sounding , so it is not that Sun is somewhat not fitting with the theme ...

Because you're speaking english If you speak Spanish or Portuguese, we call Sol ... Sol

Short awnser: the star in KSP planetary system it is called Sun . Not Kerbol, regardless of what people say to you Slightly longer awnser: Originally in KSP neither the planet or the star in KSP were named in game and so people in the the comunity, in what would be the beginning of the quite ol' tradition of "adding K to the beginning of each word" named the planet Kearth and the star Kerbol ( you can still find some 2011 youtube videos using that naming scheme, like "The Dark side of Kearth" by Scott Manley ). When the devs finaly decided to name both bodies , they went with Kerbin and Sun and , while people dropped Kearth quite fast, they continued to pretend that the star was named Kerbol. And here we are 4 years later still saying to people that "Kerbol" does not exist in game ...

And OFC, we have take in account that the modder said that he is not sure he can pull it out in Unity 5, because the function he was using in Unity 4 for this was heavily changed and is no longer a fit for this...

Well, as I said this week to a streamer that got the same issue, this is not SQUAD fault, while it's true that the devs here are guilty of both corner cutting ( by using crew capacity alone to determine if a part is avaliable for the rescue contract ) and by, in this case , not providing the modders tools to deal with this issue... well, the modder was ( or should be ) well aware of those limitations when he created the parts, I assume ( being the modder in question Roverdude ), so he chose to put parts that would give problems in his mod. That said, and again, if you ask me if I think SQUAD "solution" here is a good one ... well, it reminds me of the warnings of my programming teachers of almost 20 years ago to always check if your checks are being done on the right variables ( and also to never use magic numbers, another thing that SQUAD does a lot ). If a part realistically requires both crew capacity and a way of getting out for a contract to be fulfilled ( barring some dubious Klaw usage ), the code should check for those two things, not only one

Well, I do not speak for the devs, surely ( neither of us, TBH ). I do know their thought process partly, though, because the devs fortunately can speak and type, and Harvester was always very, VERY adamant that he wanted to smooth out the game for newer players in his public interventions either here or in other media. OFC intentions do not always beat with final results and my point in this discussion was always that while the devs tried to make the entry of new players in the game easy, some of their actions worked in reverse. About the game being a learning tool, yes, it is .I already used it to tutor high school kids about physics. But letting the players happily crash stuff until they got it right, while it is a learning experience, is probably not the optimal way of doing stuff, because while they can learn to do stuff right, they are not learning how to do it or why it worked this time and not the other. For a quick example, I can say to a kid that the reason his rocket is not taking off is because the weight of the rocket ( pointing out ot the number in the flight engineer menu, maybe also taking the cue to explain the diference between mass and weight and how to get one from the other ) is bigger than the thrust of the engine ( pointing out to the parts menu number and maybe explaining other details depending of the age ) ... He could probably discover it by itself by taking out weight ( or adding boosters, most likely ), but I ,as a tutor, might point out exactly what he is doing right or wrong without much fuss because the numbers are there ,even if somewhat hidden ( more on that below ). OTOH when a kid asks me what is that number that appears in manouver nodes, I can explain what it is and where it comes from ( it is actually a good starting point to introduce velocity as a vector ), but then the inevitable next question is "How do I know how much dV I have in my ship?", while I can talk a little about the general idea ( most of the times I can't really enter in much details because they don't know log tables ), I can't really do like in the above example, because the number simply isn't there , in plain sight or not. I can't simply say: "Do you see? If you put this part here, your dV decreases because you're adding mass that is not fuel. Now if you take that part off and add a fuel tank, you're adding dV because your initial fuel load is bigger. So this ship might go where you wanted and the other one will not ...", while I can do this in the above mass of rocket vs thrust ASL example. All of the above already happened to me, so I think I can talk about it I'll not enter in the discussion of simulation vs game or about what is fun. Both are highly subjective and I assume our positions are quite divergent on both issues. And it would be even more off topic than most of this discussion... Let me point out that a variable, besides being in plain sight or hidden, might be acessible. Or in other words, besides throwing him information or not, I have the option of saying to him "I leave this intel here. If you feel like it you want or need it, give it a look. But you don't actually need to see it at all times" .Every program that displays any kind of intel in it's UI has variables that are visible, others that are hidden and others that while not visible at the moment , can be acessed at the user will, normally under a submenu or another tab. Say, let's look at the flight scene on KSP by default and the intel it is there. You have exactly 3 numerical variables displayed: Mission time, Altimeter and Velocity relative to surface and a couple more non-numerical variables ( thurst percentage, g-meter, the thermal gauges, fuel in tanks, ... ). Those are visible without any more interaction with the UI and this is what a 1st time player sees and barring some random clicking or some self or assisted tutoring, this is all he will ever see on that screen. Now note that the flight scene has far more intel more or less acessible , under sub menus of the already displayed intel ( say, you have speed relative to target and orbital velocity in the same UI part of the surface speed if you click it ), on click in some UI parts ( say fuel quantity in total and per state and rate of consumption/generation ) or via documented keyboard keys ( the drag/lift/thrust vector display ( F12 ) or the flight log (F3) are good examples ). This intel is avaliable to the player, but only on command by the player. That is, the player wants to see it and has to take a conscious step to see it and the game itself provides the way to get that intel. If you don't want a certain intel to be seen by most players, you can always let it only acessible via game console, like KSP does with a lot of variables. It is assumed most players will not go there without a good reason, right? Then there are hidden variables that are never stated in the UI. Say, the game never states the densitity of Kerbin oceans or the air viscosity, but has surely variables inside that represent them and if you really, REALLY want to know them, you can only know them via trial and error in game or check the source files. My point of view, that apparently I was not able to pass to you, is that the dV number should be acessible in game, like, for example, the wet mass of a in flight rocket or the lift vector on a part are. That is, the number is there and if I want to, I can go check it. I don't want or need the dV number in sight all the time or even most of the time, like the mission time is, but I would like that, when I want it , I could check it, like the ASL thrust of a engine in the VAB. In resume, there is a middle ground in between thworing intel to the player and withholding that same intel in the depths of the source files. I think a ship dV fits there nicely.

IIRC there were some parts up to 0.25 ( that in my head is 3 versions away ) that had not exactly 5kg per unit of LF due to most like some rounding errors of the devs. It was nothing very serious, though

@MailletC You make 2 points. Let me adress them separately. First, when I was talking about inverted dificulty not being intended behaviour, I was talking from the devs point of view, because games with high initial dificulty curves tend to sell less . My point about the dificulty curve was not on the dificulty curve in itself, but that locking features out at the begining of the game added dificulty to a already dificult situation in this game particular design choice ( while it is a perfectly valid way of scaling dificulty in other games, though ). I do understand your point about piloting ( actually a good one ), but it is not really aplicable in here because KSP has nothing like a flight instructor helping you along the way in those hard moments where you're learning to go to orbit ( I suggested that years ago. Devs aparently thought tutorials were enough for that ), a thing that in RL smooths the learning of piloting a plane a lot compared with dropping a completely untrained person in the pilot seat alone Your other point is about perceived dificulty and information overload. I'll chime on the perceived dificulty in the awnser below to other forumer , but on the information overload issue ... well, that is a UI design matter more than anything. It is perfectly aceptable in game design to toss stuff that you find that the player might need to but that is not immediatle needed or maybe intimidating in a second UI or under a advanced Tab. KSP already does that with a good bunch of the aero and thermal variables ( both via F11/12 or the Alf-F12 menus ...or even that tiny side menu on flight mode that gives you the wet mass among other things ), so I don't really see how a dV number can be any worse than the lift vector on one part or it's thermal emmisivity... @HebaruSan First , let me point out that launch windows are more sugestions that hard physical contraints. They are just the best times dV wise for a Hohmann transfer ( so they might not be even the best option dV wise in general ) and they actually might not the best times to launch if your mission profile includes a return from target ). Second, note that going to the Mun also has launch windows and that you can also give 15 Km/s to a noob and he can also fail the Mun as well ;). In fact the more likely scenario for a noob player without any guidance from the forums is to miss the Mun even if with enough dV ... Third, from the point of view of a noob the game gives you exactly as many clues about when to launch to the Mun as when to launch a interplanetary flight. You can eyeball it because you either made the math ( like I, Scott Manley and others did back in the days the Mun was added to the game ) or heard about the "Burn when the Mun rises above the horizon" rule of thumb either in the forums or on some RL Apollo missions related source. Note also that the stock game gives you enough intel to plan any transfer window you need interplanetary or not as long as you have acess to manouver nodes , as I describe here ( I agree it is cumbersome, unituitive and definitely not noob( or anyone )-friendly, but it was not me that designed the game ). That leaves point #4, the fact that interplanetary feels harder than Kerbin mini-system stuff, while actually it isn't like that necessarily in anything besides number of oportunities to get stuff right per hour of game ( something that also depends of the top warp speed , so again UI issues ). That is a typical example of a diference between perceived dificulty vs actual dificulty , something that happens when there is a mismatch between how the game looks hard against how hard it really is. That might be desirable at times, but in general when you have something like that happening it is because either the gameplay or UI are lacking and IMHO in this case it is mostly the case that the UI does nothing to dispel the outside of game based idea that just because a trip is longer , it must be harder ( not even in RL that is true, but oh well ) and in fact in some areas the game reinforces that view ( the contract reward structure, for a example ).This is yet other area where IMHO the game UI is lacking ... On the point of Mun with LV-30 and 45 and low level KSC vs Eeloo or Moho with unlocked everything ... my point was that a good rule of thumb regarding game design is that the highest perceivable short term goal dificulty should be somewhat constant during a game ( to avoid bottlenecks ) and that like the highest dificulty goal you can perceive in game in terms of doing a actual trip is going to Moho or Eeloo , the highest dificulty goal a noob player can see in it's short term list is going to the Mun ( the game literally opens with either kerbals in Kerbin orbit with the Mun rising in their backs or with a Kerbal in the ( fake ) Mun with a crashed ship, your first launch with occur at Munrise as seen from KSC, the contract structure puts it as the obvious target after going to orbit ... any normal person would assume that going to the Mun is on the short term menu list ). IMHO due to that those two goals should have similar dificulties to not create bottlenecks in perceived dificulty just because the game puts literally a shiny goal in front of your eyes that you will find yourself hard pressed to acheive with the starting tools. More, doing stuff with only LV-30 and 45 with low level KSC buildings is literally the situation you are in the current game demo, so, unlike in the previous demos, it is quite hard to land on the Mun in them... So due to bad management of this issue in the full game, KSP is probably the only game I know it is harder in the the demo than in the full game , and I can't see how that is noob friendly

But arguing against that was my point KSP natural dificulty curve is that the hardest step is going to LKO ( both by the dV requirements as per the contraints put down by the aerodynamics ) and that after you get to orbit, interplanetary stuff is comparatively easy ( also, note that going to Duna or Eve is easier than to go to the Mun, land and back in dV count, ship complexity, and actual required piloting skills , so your Easy vs Challenging distinction between Kerbin mini-system and interplanetary is blurry , to say the least ) ... and if you add the typical restraints we see in other games like the ones you hinted out, you get a inverted dificulty curve, that is not intended behaviour , I assume ... In other words, for a in game example, it is harder to get to the Mun on LV-30 and 45s on the intial VAB and launch pad contraints than to do a Moho or Eeloo and back with the fully unlocked Space center and science ... basically, we already have a inverted dificulty curve as it is. You don't need to coumpound that by adding yet another forced initial relative dificulty , like only having a dV meter after unlocking stuff

Well, I didn't said they didn't tried But again my point was that KSP natural dificulty curve is heavily slanted towards the beginning of the game ( due to the inherent relative dificulty of launching to LKO compared with the interplanetary stuff, atleast until you're trying to return stuff to Kerbin ) and that adding the typical "bad stuff for newbs, good stuff for pros" in top of that actually made the dificulty curve to be inverted :/ and those before LKO goals don't do much dent on that, unfortunately You awnsered your own question. You don't have acess to the dry mass in flight unless you have it on your own memory ( and TBH up until 2 or 3 versions, LF, Ox and Mono were not of consistent weight across parts ). You could argue it should be there, sure, but it isn't

Ok, let me chime on this part of your argument and on the previous part you argued about creating a learning curve, since I see this one around a lot ... For argument sake, I'll go to the same example you pick: that FPS games normally don't drop the best weapon on your hands at first, but first give you a pistol or a crowbar or any kind low level item. That might be true, but notice that they do that inside deliberately toned down levels, with low level enemy goons. The devs don't drop you with a pistol against the end boss on the first level, they drop you with a low level gun in a easy level that you can adequately mow down with some trial and error and maybe some tutorialish narrator/NPC text. Now let's look at KSP, a game that is all about space exploration. You can't really make a space game exploration game with the easy stuff first, mainly because , by virtue of our old good friend Physics, the arguably hardest part of any space flight is to get to Low orbit first ( this until you can build and fuel your ships up there, but since KSP has no outbound ship build , that is not even a half-argument ). So you can't make a easy level first in KSP, period, and without that , the typical " let's give them the bad stuff first, and the good one later" game design strategy devolves in a inverted dificulty curve, with the hardest stuff being on the beginning and the game getting easier as you start getting the good stuff, that I assume is not the intended behaviour for most people In fact, if you peruse this same sub forum , you'll see a lot of complaints about people playing career ( or the new demo ) expressing their bafflement/anger about how hard the first steps of the game are or how utterly hard the new demo is compared with the previous ones ( or even stock ) because the SQUAD devs tried to create a learning curve by the method you're defending ( locking good parts, limting the size and weight of rockets, locking out action groups, mistaking a rover test facility with a landing strip for planes, making decouplers more expensive than ICBM capable rockets, locking out manouver nodes ) on top of a natural dificulty curve that is tilted in reverse of normal expectations , inadvertedly leading to making the game even more dificult at the beginning than it naturally was, and this without considering that you at first are suposedely less experienced than later ... My point, in resume, is that the method you're describing to create a learning curve is a bad fit for KSP as it is now, a sandbox space exploration game where the hardest step is naturally to get to orbit aka the first thing you need to do in game. If KSP was some kind of episodic maps with a lot of Space centers scattered around the planetary system and you started in Gilly and that you progressed around the centers by order of dificulty of launching from them, yeah, bad Space center facilities and a small assortement of not as good parts would probably fit well and trial and error would peobably not be frustrating. But on a open map and launching from the second hardest planetary surface to launch from in game at day 1 ... well, it is not Anyway, this is a wild tangent to the topic. In topic, I can't really see how the absence of a dV meter in VAB can be defended when all the intel needed to calculate it is literally displayed at the distance of a click ( unless you want to give a hand to players that have more math and physics backround ). A dV meter on flight is another beast, though ...

Well, that is a crazy idea. Doing it in a rover is crazy enough, but doing it on foot, with no brakes? You're a brave man That said, if you aproach the mountain from the north, you can rover out easily up to 3000m. The rest ... it is hard even on rover.

Well, Daniel, the software that the late Space Shuttle used was made in Coimbra by a start up incubated there ( Critical Software ) , so there is hope for you

Thanks for your hard work, malah Now the only one left is QuickGoTo

Title : Name of biome Body: Name of kerbal, name of mission, science recovered, ore concentration if appliable at the time. It helps a lot remembering what is still to be done, especially because apparently having a list of stuff that is still to be done in a biome would spoil the game according with SQUAD ...

Nah, the ground is too uneven and dry for that

A perfectly circular orbit on a captured comet? Well, if you believe in that, I have a nice Eifell tower in Paris to sell you ... Seriously, my take on this is that Minmus atleast on the surface of the flats it is made of glass. That IMHO is the only explanation possilbe. About it's origin? Well, maybe it is a consequence of fragments coalescing around Kerbin after a colision with a big celestial body ( like RL Moon is acording to nowadays theories ) that formed before the Mun, that is a consequence of a later collision. Minmus started to diferentiate in layers ( like RL Moon ) but as it was so small the internal heat was not enough to do the whole work ...