Jump to content

taniwha

Members
  • Posts

    4,045
  • Joined

  • Last visited

Everything posted by taniwha

  1. I do not recognize those "orbital assembly docking port"s, what mod are they from? I note they lack a "Show UI" button, indicating they do not have an ELLaunchpad module, which will be the cause of your problems. The toggle next to the dropdown controls whether the selected pad is highlighted. With no pad to select, it will have no effect.
  2. I'm glad to hear you got things working, though I'm still concerned about what broke in the first place.
  3. The resource manager has nothing to do with your build. It is for managing resources in your active vessel: ie, it makes it easy to transfer resources between modules. A module is defined by separation parts: docking port, decouplers, KAS connectors (docked or undocked). All tanks (for a resource) within a module are grouped together and appear as a single "tank". The modules can be viewed by clicking on the "circular" icon (it's a toggle button) to the left of the resource name. Mousing over the modules will highlight the parts that are in the module. You will also see a series of toggles beside the module names (which, btw, are determined from the vessel name when a docking node (port or KAS connector) is specified, or decoupler/separator otherwise), with "hold", "in", "out", and an unlabeled one. Hold/in/out are for transfer control. The unlabeled toggle is the enable/disable tank toggle you see in a part's PAW, but it indicates/controls all the tanks in that module (on if any tank is enabled, off if all are disabled). I added the resource manager because dealing with all those PAWs was a pain, and TAC Fuel Balancer, while an improvement, just wasn't enough (the resource manager was very much inspired by TAC Fuel Balancer). Also, the resource manager is always available, no need for any sort of construction pad. The build manager is quite different. Before building, the resource bars indicate the required or default amounts of the resource needed for the build, and how much of that resource is available on the mother ship. After building, any normally transferable resources will have sliders that allow you to control how much resource to transfer to the vessel when it is released. This applies only to vessels built using a regular pad (orbital dock, landing pad). The disposable/micro pad is irrelevant since the built "vessel" becomes a permanent part of the mother ship, and survey builds cannot transfer resources to the built vessel.
  4. That's only by default. I don't know the details, but there are configs in USI to either enable or disable so you cause use EL and USI together (others know).
  5. It shows patches being applied in the loading screen. If this is the case, then check that the ELConstructionSkill has been added to the Engineer experience train (look for EXPERIENCE_TRAIT in ModuleManager.ConfigCache) The workshop in particular should not have problems with productivity with 5-star engineers unless some other mod is interfering (which USI is known to do). If things remain a mystery, send me your KSP.log as it might have some clues.
  6. Is ModuleManager installed and working? That is the usual cause of productivity being 0. MM is required for adding the construction skill to kerbals (engineers, but that's tweakable via cfg).
  7. Thanks, that got the info I needed: typ.mumatprop.color.properties[2].name Now I need to figure out what's going on.
  8. Yup, that's what you need. Yes, exactly like that. Unfortunately, the line is not in that output. Unfortunately, I don't know where to find it in windows. In linux, since I start blender from the command line, it's just there in the terminal window from which I started blender.
  9. Just add a collider (via the add menu), then tweak the tag and layer in the object properties (look for Mu Collider). There's no shortcut for ladder/hatch specifically. Ugh, no idea. can you add the following just ABOVE the exec line on line 205 in export_mu/animation.py and get me the result? print(f"XXX exec: {str} locals:{locals}") Be sure to keep the same indentation or the whole thing will break (syntax error) The XXX is just to help you find the string in any output (you'll probably need to find the blender output console)
  10. Hey, congrats! May you and your partner have a long and happy life/friendship together. What is this edge-case? I'll keep an eye out for it (and who knows, might even submit another PR).
  11. Fixed. Thanks. I had run out of space, tried to fix it, but must have done something wrong when I re-uploaded as I didn't see another error message. (probably uploaded the wrong file)
  12. As implied by the release notes, they're in 6.99.3 (just making that very explicit).
  13. I have released version 6.99.3 of Extraplanetary Launchpads. Changes from 6.99.2: Fix hiding EL's launch clamp (Louis Bach) Fix incorrect vertical offset (5m) for survey builds Fix inconsistent directory tree indentation Japanese translation (Yark-Aki). Only partial due to the PR being before I did a release with the UI localization. Survey stake CoM put underground (@zer0Kerbal, @Robin Patenall), and some tweaks to make it have the correct height offset for the build. Thanks to @Rodger for initial testing of the PR. Allow survey station when KIS is not installed. Patch Kerbal inventory mass limit to include the Kerbal's mass (ModuleInventoryPart massLimit is TOTAL mass, not just inventory mass), allowing kerbals to pick up stakes after they've been placed.
  14. I've applied the PR @zer0Kerbal provided (based on @Robin Patenall's patch) which puts the CoM underground (and made suitable tweaks to EL's placement code), so they no longer fall over.
  15. Not so much a quick hotfix, but I am working on a release. I'm just trying to sort out some issues stock-inventory-placed stakes (they get ludicrous mass). Once that's sorted, I will do a release.
  16. See section 5.2 of the manual (link in OP, or pdf in GameData/ExtraplanetaryLaunchpads)
  17. There's a "bug" where survey builds have a 5m vertical offset. Quotes are because I think I was doing some testing and left the offset in by accident. This will be fixed in the next release. In the meantime, I suggest taking advantage of non-flat terrain where possible.
  18. It is a magnetic field joystick (TM T.16000), but about 5 years old.
  19. @Nicky21 I've got myself a whirling dervish, and it won't stay stopped. However, while it does have an EL part in it (the dock), it was not built using EL. But it does have some cubic octagonal struts between the root and the rest and, with a small amount of twist between some of the struts. And the direction it wants to spin is the same as the twist. [edit] It is not the twist. Nor does it seem to be the cubics. [edit 2] sorry, no data points at all. Turned out to be my joystick wasn't quite centered (input invisible in the PYR indicators). Got that sorted and the spinning stopped. Rather embarrassing (I need to get better deadzones set up).
  20. @Fisherman I'm pretty sure most mods (and even stock for many things) assumes 1u = 1kJ. I know for absolute fact EL does (btw, if you want some help with EL recipes for RF, holler).
  21. If this is actually the cause (not saying it's not), then this is good information. However, as EL does nothing fancy (it's using the same mechanisms as docking ports), I know of nothing that I can do about it other than suggest avoiding clipping. You say that the released vessel inherits this rotation. If the released vessel remains stable (off rails and without SAS) after killing the rotation (via SAS or going on rails), then for now at least, I suggest just being aware of the rotation (especially if it's predictable) and keeping it in mind the designs you launch from this particular station. I have seen some weird rotations myself, all permanently canceled by killing the rotation one way or another (as mentioned above), but when undocking, not releasing from a pad (that I remember for certain; it may have happened, but not often enough to remember). However that station (or those stations, may have been more than one) have since stopped inducing such odd rotations, but they have been heavily modified since then: rather large chunks undocked and recycled (had some fun with this on one station, more later), and restructured to have some loops (via ReCoupler) to provided additional stability to my stations. All my releases (docking port or orbital doc) for the last while have been "rock solid stable" and the released vessel has drifted away as expected under micro-gravity. As for that additional fun. I mentioned the issue earlier, but I have since discovered that it was not so much the shifts in mass (though I am unable to rule that out), but rather just PhysX joint instability, possibly coupled with SAS instability (again, more later): that particular station got exponential wobbles the moment I took it off rails unless I put a single auto-strut between a single part (a 5400u spherical tank full of scrap (so not quite as mass as one with LFO) and heaviest (nearby similar tank) or grandparent). KAS cable joints helped only briefly (one scene change). As I despise auto-struts, I create I experimented with a parts-loop (facilitated by compatibly sized parts and station hubs) to lock the offending tank with a second support. Worked like a charm And now for unstable SAS: to understand this one, you probably need to understand l"linear systems and control" (this was the name of course I took (twice, flunked first time) in university for my engineering degree). SAS works well enough (its tuning is horrid) for single parts, or very small vessels when the extra parts just can't drag things around with their own momentum (every physical part in KSP has its own momentum, both linear and rotational, and they are all (within a single vessel) connected by springs, usually in a tree). This means that a simple vessel (eg command pod, chute, heat shield) will be nicely stable under SAS control (neglecting aero forces, of course), since the masses of the chute and heat shield are low enough compared to the command pod, and you have only the two springs (even more stable with just one or the other, but in such a vessel, getting the kerbal home becomes rather dubious). Now, what happens when you start connecting comparable masses by springs? You get a finite element approximation of a tight string (or a singly supported beam (that support may be the center of mass, so even a free beam)). That is, tap anywhere and you get a wave propagating from that point to the ends, bouncing off (wave-guide stuff, btw), returning to the tap point (possibly at different times) passing through each other and repeating until damped out (assuming the spring connections have damping (friction)). This is a one dimensional. An easy two dimensional example is ripples in a small body of water where the ripples can bounce off walls cleanly (and is very good for seeing the mess you can get). Note that the tap can be linear (eg, RCS thruster, impact) or rotational (torque: reaction wheels or balanced offset thrusters). Place a control reference (just directional will do (and is all KSP provides), though a positional one results in the same) anywhere and a torque source (reaction wheels, RCS, doesn't matter) anywhere: you've now set up a feedback loop, with built-in delay lines (due to the wave propagation and reflection: this is why it doesn't matter where control reference and control actuation are placed). Introducing delay introduces non-linearity (if your vessel's behavior wasn't non-linear before, it is now), and there's no going back. Non-linear systems are notoriously hard to control, especially with linear control systems, such as SAS's PID (Proportional, Integral, Derivative) control. PID can control some non-linear systems, even those with delays, but only if that non-linearity (especially delay) is small enough, AND the PID is correctly tuned. If KSP does any auto-tuning of the PID, it is woefully inadequate (just look at trying to vessel with only four significant parts: it wobbles (as a whole) like jello), and I don't know where the knobs are for manual tuning (if there are any, stock). Get that delay (main source of non-linearity in KSP) too large, and all bets are off: SAS alone will shake your vessel to pieces, especially if that delay is "just wrong". If there is sufficient damping in the joints (dubious) or on the parts (aero), you might get some help. The above is for PERFECT PhysX joints. That is, no floating point round-off, no integration errors, both of which are unattainable (former because it requires infinite precision: 24 bits doesn't get even close, latter because there's no analytic solution and numerical methods are required, thus integration errors). However, joint imperfections can be considered as micro impulses, thus can be damped (in theory), but will normally act as impulses to "tap" that slinky that is your station. Finally, what I think was the cause my induced rotation after undocking: I suspect my station was busy vibrating like a violin string, but such that I couldn't see it (sufficient damping such that the oscillations never got out of control... exceptions above). Then, when docking (note, not undocking), the oscillations caused the two docking port colliders to intersect when KSP joined the two vessels together, but as the two vessels had become one, the "no same-vessel interaction" kicked in and removed that source of corrective force. The intersection would have been too small to be obvious, but sufficient that when the two vessels were decoupled, PhysX kicked in and forced the two colliders to no longer intersect, but because the intersection was small, the force was small and thus the induced spin on my ships was not overly dangerous. It was always such that it looked like an offset (from CoM) linear force: the undocked ship was pushed away from the docking port (at about 1m/s) and spun a bit (pitch and roll: mk2 inline docking port) indicating that the intersection somewhere either side of the ship's center-line and fore of the CoM: thus likely the docking port, just either side of it. Thus, my only worthwhile suggestion is to ensure your station is stable. That is, oscillations (due to any cause) die out with SAS enabled or disabled. Struts, loops (recoupler), even auto-struts (despite my loathing for them, but they must be strategic) can (but might not) help by shifting your station's natural frequency somewhere less sensitive and thus poles (control theory stuff) to the negative half-plane.
  22. @Booots I've sent a PR that allows ReCoupler to work across inline docking ports in recent KSP versions (whenever IJointLockState was added to ModuleDockingNode).
  23. @TriggerAu I've sent a PR fixing KAC's AN/DN (both targeted and equatorial) calculations for 1.12 (should be compatible with older versions, but I don't know if KAC is).
×
×
  • Create New...