monamipierrot

Members
  • Content Count

    48
  • Joined

  • Last visited

Community Reputation

29 Excellent

About monamipierrot

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

659 profile views
  1. Hello, I just want to have you put an eye on a old thread of mine in which I suggested some overhauls for a new major release (KSP2?). A few of them are outdated and already implemented, but please check under "EXPLORE OVERHAUL", "ASTRONOMY / PLANETARY SCIENCE OVERHAUL" and "PROCEDURAL GENERATED PLANETS OVERHAUL" Thanks! https://forum.kerbalspaceprogram.com/index.php?/topic/125979-on-exploration-astronomy-random-bodies-and-other-overhauls/
  2. GREAT! This explains a lot of things and I think it comes perfectly handy for my purpose, which is both resize the atmosphere AND make it a little bit thickier in the toplayer to help crafts slow down on reentry before using chutes. (My goal is to have a atmosphere around 30% higher than original in a tiny 10% resized general environment as explained before) Question is: can I use BOTH atmospheric settings like this?: - setting atmoTopLayer to the desired atmosphere height (so value should be 3 cause when multiplied with the resized factor it gives 0.3) - setting atmosphere setting to a higher level e.g. the double i.e. "6" so in the top layer the atmosphere will be not that thin. (Around the double the pressure?) Thanks!
  3. thanks! Didn't get there was a link! ;D I was fiddling around with the mod and I have found a satisfying solution (at least for Kerbin) to mimic Toy Solar System: // Base Settings Resize = 0.1 Rescale = 0.1 Atmosphere = 0.3 dayLengthMultiplier = 1 // Advanced Settings landscape = 3 geeASLmultiplier = 1 resizeScatter = 1 resizeBuildings = 1 groundTiling = 1 CustomSoISize = 0 CustomRingSize = 0 atmoASL = 1 tempASL = 1 atmoTopLayer = 1 atmoVisualEffect = 3 scanAltitude = 1 This solution: resizes the Kerbol system to 1/10 Gives a atmosphere of 21,000m which is also in scale with terrain height (works perfectly with EVE) AND is still manageable for reentry. (need to be checked better) keep all buildings the natural size (but due to scaled down heights, island is not connected with KSC althou still VERY close). So the runway is still huge (important for kids or casual players) some easter eggs may be unreachable or "flying" didn't check most bodies, and didn't check asteroids didn't check the DAYLENGTH thing. Still I don't understand the difference between "atmoTopLayer" and "atmosphere" settings.
  4. I love Chatterer from the very inner of my soul, and I think it should keep being fun, and should keep being completely useless. HOWEVER, I would really love a mod or a chatterer extension that simply turns to audio the "events" we can read in the mission summary log as it is in current game version. "Lift off!" "Separation confirmed." etc. Nothing more, nothing less.
  5. I came to know this mod trhrou Toy Solar System, the Kopernicus-base mod which rescales everything to 1/10, which I wanted to use in order to have my kids play with KSP. However TSS is somehow broken cause: - the atmosphere layer is so thin (7,000m) that it is even impossible to use parachutes. - the unscaled buildings have a horrible look on the planet: the KSC is literally touching the insland runway - mun and other surfaces look horrible cause the mod exaggerates some features. However, installing Sigma I could mimic TSS with better results: my settings were - Resize = 0.1 (as TSS?) - Rescale = 0.1 (as TSS?) - Atmosphere = 0.3 (21,000m, so parachutes will work) - resizeBuildings = 0.3 (runway is still tiny but this way everything looks great) Landscape is still wild as in TSS but not that wild. Craters looks good. Any more suggestions? I can't find a usage explanation of all options. Thanks for the great mod!
  6. OOOOPS. I checked the wrong log: this is the correct one: Initialize engine version: 5.2.4f1 (98095704e6fe) GfxDevice: creating device client; threaded=1 Direct3D: Version: Direct3D 9.0c [nvumdshimx.dll 8.17.12.6874] Renderer: Intel(R) HD Graphics Family Vendor: Intel VRAM: 880 MB (via DXGI) Caps: Shader=30 DepthRT=1 NativeDepth=1 NativeShadow=1 DF16=1 INTZ=1 NULL=1 RESZ=1 SlowINTZ=0 So yes, the problem seems the same of @Racescort666
  7. Same problem here. Both old lightly modded 1.0.0 install or current unmodded 1.1 install work fine if launched with x86 executable, even with almost best graphic options: I just experiment time lag and few FPS when manouvering in atmosphere BIG +50 parts rockets. Of course I would love to build huge rockets and stations so I tried the x64 executable of new 1.1 install (installed and patched with GOG) hoping for the FPS miracle everybody is talking about. Well, this same new UNMODDED 1.1 when run with x64 executable (and even lowering graphic quality to average-to-low rates) is SUPERLAGGY and runs with FEW FPS EVEN IN MENU. In spaceplane reentry scenario, FPS is around 2-3 per second, while the "time" is slowed down some 3x or 4x. It looks like even controls are lagging so if you just press "q" for a fraction of second, the plane could roll a lot, or not roll at all. However. Map view seems to work much smoother. In the log file I can read dozens of errors, but I can't understand what are they referring to. I may post the whole log file but it is huge, maybe there's a way to cut it or produce a "cleaner" one. Please help us!!!! [BELOW IS A MISTAKE, I LET IT HERE FOR COMPARISON. THIS LOOKS TO BE THE x86 LOG. CHECK BELOW FOR CORRECT LOG] Not my case, it clearly reads: Initialize engine version: 5.2.4f1 (98095704e6fe) GfxDevice: creating device client; threaded=1 Direct3D: Version: Direct3D 9.0c [nvumdshim.dll 8.17.12.6874] Renderer: NVIDIA GeForce GT 555M Vendor: NVIDIA VRAM: 2014 MB (via DXGI) Caps: Shader=30 DepthRT=1 NativeDepth=1 NativeShadow=1 DF16=0 INTZ=1 NULL=1 RESZ=0 SlowINTZ=0
  8. kOS in stock KSP could convince me. Especially with RemoteTech ON and unswitchable
  9. Yep, that's my opinion: it is a silly thing. For this reason I both love it and doubt it would ever come to life, and even less in 1.2 If you think I am mad at you on the "silly incident", well, you may want to revise the "silly incident" in the other thread. Here I was just facing you with hard reality. If it sounds ironic or sarcastic, well, it's because life is ironic and sarcastic, and I want to laugh at it, not at you. Peace.
  10. Mechjeb yes. You just described it above. You basically want players to... write Mechjeb. Wait, as you put it "write the CODE" of Mechjeb. Do you ever thought that the best pilot/engineer out there could have NO IDEA of writing a few codes of a basic program? And, most important, NO INTEREST? I mean, Mechjeb is a complex piece of software, althou there's no AI involved. And in the code, rocket science and engineering would be 0,01%, while 99,99% would be just - you know - programming, coding, debug, etc. What I was thinking is something much more simple for everyone. To put it rough: once you prove you can do some standard manouever (e.g. rendez-vouz, docking, suicide land, hofman transfer....) the corresponding MechJeb manouever becomes available (throu a new hardware part, or some automatic "software" update on all existing vessels) and you can use at will. To make sure you don't just STOP making a specific manouever ever more, there may be layers, e.g. layer 1 is quite inefficient, buggy and inexact but you can improve this tech by manually performing better and better manouevers. Or, the current MechJeb CPU/software may be not compatible with some selected hardware config or body/biome situation, forcing the player to perform once again the manouever. Or there could specific "science" points for each kind of manouever "Docking science points", "landing science points" which you need to earn if you want to "purchase" the tech layer corresponding to the specific MechJeb software module for THAT manouever. I proved zillions of times I can do a proper hofman transfer, a decent rendez vouz, a efficient take off from Mun etc. etc.; it starts to be VERY ANNOYING to repeat dozens of times the same manouver. Of course, I also don't even want to start CODING it, for the same reason I don't want to design the details of a new engine (for a honest comparison to your proposal, I should have said "to phisically build a new engine in my backyard"). For these reason, some MEchjeb equivalent should exist. On the other hand, your idea of MULTIPLE vessels automation may prove to be vital. But still, please stick to some MechJeb thing, scaled down to the point it doesn't steal us the challenge and the pleasure of doing once in a while some manual manouver.
  11. Believe me, we don't differ a lot. I perfectly understand and almost completely agree on what you say, and couldn't say it better. The thread you are referring to is full of great ideas. I just believe that these kind of ideas are perfect for a marriage with my OP proposals. The spirit is the same, and I would say one would be incomplete without the other one. But again: we need Squad to be aware that a radical rethinking of this not-much-more-than-a-sandbox game is needed. Now. Hey, check this out: I think you'll love it (or at least your schoolmate will do!):
  12. It doesn't at all. Let me only stretch and insist that we don't need a "war of the poor" and that many proposals I found in this and other threads may sound very different and apparently in competition, but instead they should gang or lobby (if they can't merge) because all of them has this in common: they feel KSP is incomplete and that it is a pity given the inmense potential of this great game. If Squad grasps this concept ("we only have a incomplete masterpiece, a raw diamond, a embryo of a beautiful creature") I'm sure they will revise the development stream to add more work in a critical rethinking of the core game, and not only think about the last details, which I'm afraid is their next goal.
  13. In my OP I addressed the problem of AI (or should we say automation), to help the Player managing his growing fleet of vessels, but multiple spacecraft was not what I meant. I only thought that repetitive tasks should be automated. But for this some stock built in MechJeb-like utility should be enough. However, you're clearly referring to @AdmiralTigerclaw's vision of a entire ecosystem of fleets/colonies/bases/stations which are going to be the bonestructure of our exploration of the Solar system. If I'm not wrong, he didn't have in mind automated (real) operations, such as "having that rover mine, having the other taking the ore to a base, having a hopper store the fuel in a orbital station...", but something such a "virtual" ecosystem, in which you don't really physically SEE what's happening, but since you builded the right infrastructures, and provided the right conditions, things work themselves, invisibly, exactly as happen in a common 4X or RTS game: you builded a base, a vab, some mining unit, provided energy, an orbital communication system, and voilá, you can just build your first 100% munar rocket. That would be a lot easier to implement, althou yes, much less sexy. fog-of-war makes sense if you don't konw what's out there. I also would love to have a slave-army of programmers and designers which design beautiful worlds with same quality of stock ones, just for me, but unfortunately slavery is illegal. So we have 4 options: 1. Struggle to have quality procedural random generated universes 2. Find a workaround by randomly tweaking existing bodies/solar system within some few "safe" parameters, such as Kopernicus and related mods already more or less do 3. Have a prewritten online library of Universes, say half a dozen to start, hoping that developers can add more in the future. 4. "Stick to stock" and stare at a Men In Black torchlight each time we start a new career (might harm your mind if abused)