• Content Count

  • Joined

  • Last visited

Community Reputation

287 Excellent

About OHara

  • Rank
    Sr. Spacecraft Engineer

Recent Profile Visitors

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

  1. 1) The new Terrier has variants, one of which is 'bare' with no shroud. However, the 'bare' variant still takes up the space for its shroud. In applications like landers where things undock or dock near the engine, we need to allow this extra space. (Each lander at right damages the rover upon undocking.) Only the Terrier has this invisible collider; the Spark for example rolls around on the ground in ways consistent with the visible shape of the variant you choose. (The new Poodle is also missing a collider for its truss.) I posted bug 20930. I can see no Module-Manager patch or easy workaround (so I'm using Spark engines). Please comment if I'm missing an easy solution. 2) The new Terrier variants (like most of the Making History engines, the Engine Plates, and Structural Tubes) cause extra drag when they are inserted into a stack. Foxster already mentioned this for Making History engines (forum link) but now it affects stock engines Terrier and Spark. The 'shroud' version, behaves nearly as well as the old version. Or, we can just Advanced Search to get the old version. Or, copy the old Terrier's drag definition into the new Terrier (Module-Manager patch in the forum link above). In former KSP versions, there were individual 'drag cube' drag configurations for shrouded vs bare engines, telling KSP aerodynamics that the shrouds filled the space between tanks in a stack. I am suggesting Squad restore that distinction, in bug-report 20683.
  2. Mods are not recommended with version 1.6, or at least no mods that depend on Module Manager or change PartDatabase.cfg.
  3. @KSPJoe, the SAS function is like an autopilot. Usually you do not change trim while autopilot is in control. Players are also frustrated that normal control inputs do not interact smoothly with SAS; and there is discussion about what players want in this thread Squad has a bug-tracker (where you have to register yourself on first use) and there is an item about this there 16117
  4. [edit: removed, wrong thread]
  5. I've been trying your suggestion with a module manager patch to change the five relevant parts: @PART[mk2Fuselage*] { !mirrorRefAxis = delete %node_attach = 1.25,0.0,0.0, 0.0,0.0,1.0, 1 } I used a different initial orientation so that we need just one 'q' keystroke to bring the tanks in the usual orientation. We should not recommend this hack with orientations, though, as a solution. It makes the physics asymmetric by putting the surface-attach joint in the wrong place on one of the tanks. The same problem is present in the stock game with the Mk2 Crew Cabins. The orientation numbers in node_attach do something strange; they are not rotation angles like the wiki says; if I treat them as vector components then KSP usually orients the child so that its parent part is along that vector, but there are exceptions. For some cases of those orientation numbers, and in mirror symmetry, the mirror image of the part just placed is rotated 180° about its center, putting its joint to the parent part on the wrong side. This makes the craft flex in an asymmetric way, with the port cabin flexing about its inboard joint and the starboard cabin flexing strangely about its outboard joint. Experimentally, the rotation tool is drawn at the point where the physics engine seems to place the joint, so those mark the joints in the image at right. If you make a plane with wings mounted to surface-attached Mk2 crew cabins it won't fly straight. Almost all surface-attachable parts in KSP have a plane of symmetry through their attachment points. Excluding trivial asymmetry like text labels on batteries, the exceptions are Mk2 crew cabins and the fixed landing gear. The crew cabin has hatch on top, and surface-attachment point on the right. In order to place two with mirror symmetry we would need a left- and a right-handed version. mirrorRefAxis seems to be an attempt to mirror the textures of fixed landing gear and Mk2 tanks, so that they look like they have left- and right-hand versions. The problem is that mirrorRefAxis unnecessarily mirrors in-line attached parts, and mirrors parts based on their orientation in the VAB, rather than by their role in a mirrored pair. The desired solution would be to limit the effect of mirrorRefAxis to only surface-attached placed in mirror symmetry, and to only one of the two mirror-symmetry-placed parts.
  6. OHara

    The 1.3.1 Club

    The mods that existed during version 1.3.1 probably still have the matching versions of their releases available where their source code is published, most often github. Then finding the right release is a matter of looking through the release notes for the first one compiled for 1.4.0, then backing up one, or just the last version before March 2018. The *.version files inside the release remove any doubt. For questions, I would expect mod authors will not be able to remember when various fixes and improvements were made. So you will do more reading through forum threads and release notes, but be likely getting the correct answers more quickly. A lot of people delay upgrades, so your situation is not unusual. If you have a new question, where the version might matter, you should probably use past tense: "how did you, in version 1.3.1, ..."
  7. Raptor9 already reported this one, 19079 back in version 1.4.3. At least, when I try your craft (flies very nicely, by the way) the z-fighting behaves exactly as described in the posted bug report. Same in version 1.6.1 as in 1.5.1. For me, moving down the runway is not the key to starting the shimmer, but rather moving into the 2.2-km range of another craft so that it is loaded into the physics simulation. F5/F9 removes the z-fighting until you leave and re-enter the 2.2-km zone. Maybe you have a targetting flag at far end the end of the runway? I had to move my captured-asteroid decoration from the runway out to near the monolith because of this issue.
  8. That works for me, thanks for sharing it here, but then when we surface attach the tanks in mirror symmetry to a central stack, they start off in a funny orientation, just like the crew-cabins do. I can imagine someone saying "only the hard-core players will notice the textures on the tanks, but everyone making a 'cool-looking' SSTO will try mk2 tanks alongside a central stack and get confused". I'm not saying I agree, but I can imagine it.
  9. No, and I would have noticed that by now. My only guess is that a mod has not gotten a needed update, or maybe the modder doesn't yet know the need. Similar things happened with HyperEdit a few versions ago. Maybe ask over on whichever Tech Support subforum fits the best.
  10. OHara

    Root and... Kraken??

    I tried your craft, using two boosters, and had no problems. (I never do, it seems the Kraken is afraid of me.) This sounds like a problem with autostruts. I hate autostruts. When you decouple they automaticaly lock rigidly to a different part that might be flexed, preventing it from flexing back to neutral. This can over-stress other joints, or over-stress the physics simulation while two auto-strut constraints argue with each other and exert large forces. The new engine-plates force everything attached to them to auto-strut to their grandparent. The identity of the grandparent depends on the root (image). If you turn on the option alt-F12:Physics:visualize-autostruts, I bet you can find what is causing you trouble. Edit: I have seen the orange lines disagree with the autostrut settings while in the VAB. They make sense, though after re-loading the craft file or going to the launch pad.
  11. OHara

    Realism in Stock KSP

    Remember that having Kerbin one-tenth the radius of Earth, with the same surface gravity, cuts the time to orbit by 1/3, for a given G-force on the astronauts. That makes the player's early try-fail-retry experiences much more enjoyable. It also forces other unrealistic factors, like the weak engines, to make rockets look somewhat like Earth rockets. You can see a consistency, though, as if they are all some type of hypergolic-fuel engine that restarts and throttles, in exchange for low efficiency. But, the numbers in re-entry heat are not so consistent: one-tenth the orbital energy does not require a system with 3000K heat-tolerance. I can see the wisdom in making a game with immortal Kerbals that do not eat, so that players can concentrate on the more fun aspects of getting them to Jool. The strong reaction-wheels rather confuse me, though. I find it more fun to fly with engine-gimbal and aero-surfaces, turn in space with RCS, and use only weak reaction-wheels for fine-tuning orientation. But I can simply build that way, so I do. Where the deviations from reality are simple, make the game more fun for beginners, and leave a self-consistent set of rules, I like them, especially when KSP lets mods easily change the rules when you get bored with them. More new players to support KSP and eventually recruit into RSS.
  12. OHara

    How to install KSP ?

    It is your choice where to install the game -- at least when you get it packaged the way Squad supplies it from their direct store. Version 1.2.2 (a good version) sounds like GOG ? You probably want to change the name of the folder to KSP122 or something like that, and then remove the folder holding the demo after you're sure the new installation is working.
  13. Good question. I can demonstrate the inflated heat-shield and ignited NERVAs problem, using blowfish's method of deleting partDatabase.cfg in a stock 1.6.0, without Making History. That might narrow down the problem, so I'll update entry 20758 on the bug-tracker.
  14. OHara

    NERV Problems in VAB

    I meant that if your KSP installation does not use Steam, you can skip the first four steps in the 6-step process from ShadowZone that I quoted above. I'll edit above to clarify.
  15. OHara

    Stock part edits

    Some rules and limitations make an interesting game, so you play the game trying to succeed within those rules. Some rules are frustrating. Frustration is subjective so which which ones are frustrating varies from person to person. Those are rules to change. Often, we post our changes on Suggestions/Development thread or the community list of Module Manager Patches