• Content Count

  • Joined

  • Last visited

Community Reputation

550 Excellent


About OHara

  • Rank
    Junior Rocket Scientist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. KSPs wheels produce a force (specified as 'torque' as it would be from the drive shaft) that falls off with speed. For the XL-3 wheels in particular the torque falls very quickly; at 6m/s it is just 12% (3 ÷ 25) of the rated torque. torqueCurve { key = 0 25.0 0 0 key = 1.5 15.0 0 0 key = 3 5.0 0 0 key = 6 3 0 0 key = 15 0.5 0 0 key = 15.5 0 0 0 I change the game to my own liking with a module-manager patch, just for these wheels as the others seem fine to me :
  2. Ablator makes very little difference (thread link). KSP includes radiative cooling in its thermodynamic simulation, and if you look with the alt-F12 thermal debug information, this mechanism dominates the cooling of heat shields when they start to get dangerously hot. Radiative cooling increases quickly with temperature, T4, so 20% additional heat raises the temperature in Kelvin just 5%. The heat shield survives a rather high 3300K, and has very low thermal conductivity so it protects further parts quite well. Given the physics that is modeled, reducing the temperature at which heat-shields fail would be a more effective way to increase the difficulty in this area of the game. I realize that that was just observations of the game, and you asked about rationale. I think @NathanKell adjusted the thermal model when he was working with Squad, after having experience with his Real Heat mod among other things, so you might look in that mod's thread for insight. I would not assume that he was able to put all that he wanted in to KSP, of course. Also, there are a few independent mods and suggestions on the bug-tracker in this area, so you are not the only one who finds KSP imperfect in this area.
  3. Are you using SAS ? If I understand your craft, the Thuds are pointing opposite their usual direction, relative to the control point. If a tiny amount of roll starts, then the SAS would gimbal the Thuds in a direction that makes it worse. (Pitch and yaw controls don't flip so don't have this problem.) You can turn off the Roll response of the Thuds (enabling the option in in-game Settings: Advanced Tweakables). Or you can change the 'control from here; part or select 'Control Point: Reversed'. Or you can leave SAS turned off. Or some better solution you'll probably think of. If it is not SAS, maybe one of the Thuds' exhausts is being blocked by the asteroid, which would cause a pitch or yaw. I can imagine the gimbal to correct that pitch/yaw with partially blocked Thuds could induce some roll.
  4. What do you think of a longer strip mowed into the grass ? Even better, I think would be to have KSC modeled to look like a tidal island, where geologic rebound has raised a former tidal flat to form a flat plain of bare packed sand. Then there is something that looks like a runway that we can try to land on if we find it fun to try, but a convenient alternative that looks appropriate for experimental aircraft. A couple years ago Kergarin (who is rather good at making craft with extreme capabilities) suggested a longer runway (forum link). The forum (which was somewhat less friendly then than it is now) was unable to convince Kergarin that he was playing the game wrong, but we found it rather easy to convince him that having a runway that typical aircraft find reasonably challenging, is often fun. Several of the basic parameters in KSP were adjusted when the game was first designed. Smaller planet, heavier engines and fuel tanks --- and air that feels thicker at low speeds. (Actually under the hood the density stays the same but the lift and drag forces are increased at low speed.) This makes KSP planes much heavier than the real-life craft they resemble, but perform very roughly the same. So you might consider the length of the runway to be one of the choices for game-balance. If you are using the mod FAR, this increase in low-speed lift is absent, so it is harder to use that runway unless you use other mods to get realistic masses.
  5. You are confusing me with @AHHans there, who by coincidence also was the first to note on the bug tracker that your former nemesis the targeting bug had been resolved. ( It occurs to me now that you might like to have the docking ports engage only when the rotation is square. I don't think you really need it unless you care exactly how the docking ports at midpoints are oriented. KSP has a mechanism to wait until the ports are rotated ('clocked') correctly before engaging the docking clamps, that we can enable using the patch in this post :
  6. Steering with alt-J/alt-L trim helps a little. That is, if you go into settings and assign IJKL keys for wheels. Using my right hand on IJLK for wheels, and left hand on WASDQE for the reaction wheels, and SAS holding prograde, made rovers fun for me --- s,till difficult to keep upright, but in a fun way more than a frustrating way.
  7. I've made smaller similar things, because it seemed like fun. Sir_frost has some self-assembling cages on kerbalx: https://kerbalx.com/sir_frost/craft The fine control mode on RCS, with [Caps Lock] on giving you the blue indicators, will approximately balance the thrust from RCS ports so that translation commands mostly translate, with just a little rotation; the approximation is better when the ports are well spaced out, as yours appear to be. The SAS targetting bug you might be thinking of 20513 is fixed in version 1.9.0 With those long beams, I think it would be more enjoyable to first rotate them square, then translate into position. The Navball Docking Alignment Indicator would help with the orientation if you like that mod.
  8. Part-search works for me with mods, including your Tokamak parts. Maybe some other mod you have is getting involved in the parts cataloging system.
  9. The 'title' is the displayed part name, so yes the intention was to include the displayed name in the search. (I found the more details in the thread linked below) Something is going wrong with that system and your installation of that mod with the inflatable parts. I noticed that the displayed name of the solar panel in your screenshot is is different to mine: this is the OX-STAT where your screen shows IX-STAT --- Edit: or maybe that is the version from Near_Future_Solar
  10. Aha! That's it. I looks like there is a 'tags' entry in each .cfg file, and the search mechanism looks at each part for + a word in the part's 'title' that begins with what you typed, or + a word in the part's 'tags' that matches the beginning of what you typed, ignoring upper/lower case. The inflatable airlock has, in the English version of KSP, tags = berth capture connect couple dock fasten join moor shield socket "Inflato Workshop" must have something odd about the 'title' of its parts, or their entries in the translation dictionary if it uses translations.
  11. Welcome to the forum, Dr. Monty. I happened to have screenshots from when I had a RoveMate directly under one of the Mun Arches. The RoveMate does show the anomaly 100% of the time, but you really have to be directly on top of the point where KSP marks the anomaly. The sensors have a field of view defined in terms of their viewing angle, which makes sense physically if you think of them as cameras. The RoveMate has a wide-angle (160°) view, but if it is only 1 meter above the point that marks the Mun arch, that view only covers a 11-meter diameter. Fortunately, KSPs markers for the anomalies are buried about 20 meters below ground (depending on terrain settings) so finding them on KerbNet from the RoveMate on a rover is at least feasible, if time-consuming. The images at right are all from a RoveMate under the Mun Arch, as I move by about 20 meters across the surface. The '?' is the point defined as the center of that anomaly. The elevation map covers 160° field of view projected down to the Mun's reference level, analogous to sea level, which is about 4000 meters below. So the same 160° field of view covers a tens of meters for finding the anomaly and 20 km for showing the elevation map. Some things in KSP are unpolished; some things are a lot of fun; opinions differ on which are which; this forum is a good way to find what other people find to be fun parts.
  12. Sorry no one has suggestions for you. Players have reported the bouncing with wheels/landing-gear on hinges here, https://bugs.kerbalspaceprogram.com/issues/24614 but there are no suggestions for avoiding the problem. You might have already tried enabling 'Advanced Tweakables' to set 'Spring/Damping: override' and increase the 'Damping' in the right-click menu on the wheels. I don't know if that will help but it is a guess. If you've used 'Advanced Tweakables' and auto-struts, that can cause similar problems, more jittering than bouncing, so you might disable those if you have used them.
  13. The keyboard commands (in default Windows keybindings) are F6 and F7 to switch forward and back through the sets.
  14. It is not just you, @Kerbalwerks This is a new bug since version 1.9.0 and it is on the bug-tracker (link)
  15. At one of the interviews, ShadowZone explained one use for a more general construction method, directly to the KSP2 team (link to time-stamp in the YouTube video). To build the desired craft from that video, in KSP1 we have to build from one docking connection along one of the legs and then back up the other, then bridge this second docking connection with a strut. In the image at right, the root part is at right to match the video, and I mis-aligned docking ports just to show which one is not directly connected. If the EAS-4 strut would have zero mass (KSPv1.2 already removed its drag) we would have the result we wanted. KSP1's simulation handles the resulting loop of physical constraints just fine. Placing and dragging an EAS-4 strut is the only way to indicate the second physical connection in KSP1. Does anyone know of a good example for a user interface, that allows users to connect subassemblies in more general ways? In KSP1 we place a part-or-subassembly onto a chosen part of the craft under assembly, with a single mouse click, which naturally leads to the single point of connection and tree structure. CAD software (used for designing automobiles and such) tends to use tree structures, plus various ways to add constraints that I think are too complicated for a game. The ReCoupler mod for KSP1 automatically joins additional nodes that are close enough, with some added highlighting and user interface tools to help see what is happening. Maybe those U.I. concepts can be streamlined into KSP2 without making it too complicated for new players. KSP2 would need some way to make clear when we are making two or more connections. It might be wise to store craft in a more general structure, directed acyclic graph instead of tree, so that multiple connections are truly equivalent. The nature of building craft by adding 'child' parts to a 'parent' or 'parents' gives the structure a natural acyclic order, so that if we offset a part it remains clear which parts are 'descendants' that should follow along with the offset.