Jump to content

taniwha

Members
  • Posts

    4,051
  • Joined

  • Last visited

Everything posted by taniwha

  1. @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).
  2. @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).
  3. 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.
  4. @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).
  5. @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).
  6. I've released TINU 0.2.3. Changes from 0.2.2 Add mouse sensitivity setting (effective only when TINU is enabled as it is for the "trackball" control) Improved orbital chase camera behavior Improved behavior when switching modes (fewer sudden angle snaps)
  7. Your kerbal has to be carrying a hose end and close enough to the connector. The old connector-connector functionality is long gone. As for why, one of the reasons is documented in section 4.2.1 here (I wrote that section shortly after figuring out the nature of the base Kraken, but long after @IgorZ made the change: with respect to KAS, it's more an explanation of why the old functionality invited trouble, and why leaving the current hose functionality in docked mode can be trouble).
  8. Biggest help I can give is "logs, or it didn't happen". I don't know if @blackrack prefers KSP.log or Player.log, but the former is probably easier to find. This is a general rule for all mods: without logs, us modders have no way of knowing what is going on on your machine (visuals aren't enough, nor is a screenshot of the debug window).
  9. I have released verion 6.99.2 of Extraplanetary Launchpads Changes from 6.99.1 Minimum KSP version is now 1.12 (might be able to use in 1.11). Check for missing flag textures. Fixes stuck UI (visible symptom is a white flag icon). Better consistency on the UI toggle button (maybe a bit small now, though). Update resource manager correctly on vessel switch. Don't interpolate single-point efficiency curves (fixes exception in converter module) Add ModuleCargoPart to most parts (sorry @zer0Kerbal, not your PR: i'd already done it, but I plan to get to that), but only if KIS is not installed (based on the assumption that if KIS is installed, its storage options are considered to be superior) Tweak the rocket builder's eject vectors, making exiting a "seat" less weird. Add recipe (not used by EL) for sintering rocket parts. This allows direct scrap metal -> rocket parts production. Note that this needs a LOT of EC, but two fuel cell arrays (as modified by EL), or 10 gigantors in LKO, are sufficient to power a default unit (10g/s). However, it is very material efficient. UI strings localized (always were in the new UI, but not in a config file: they're now loaded). Add Brazilian Portuguese translation (many thanks to @Steven Marinelli) Add agency localizations from @zer0Kerbal. Add "hidden" +Z marker to the micropad. It's visible when placing the part using KIS, +Z chosen as that is "down" in the SPH, and the marker makes the orientation marker look weighted. Many thanks to @Rodger for his feedback. Add support for subdirectories. I had over 150 craft files in my VAB (1.9.1 save). This... makes a very welcome difference. Add construction drone and workshop as ISRU parts (for station and base contracts) Wait for work sinks (currently just the various pads) to become ready before doing catch-up. This prevents an NRE in the build control code that I was not able to reproduce myself. Many many thanks to @Rodger (who ran into it) for his patience in testing (heavily modded JNSQ... load times are looooooong). Add support for stock inventory parts to the resource manager. This means that resources stored in tanks stored in cargo containers are now counted correctly (only one level deep, though, so tanks in containers in containers won't be counted properly (same as KIS)). This is the reason for abandoning older versions of KSP. As always, feedback and bug reports are welcome. Preferably github for the bug reports, and logs (KSP.log, make sure LOG_INSTANT_FLUSH in settings.cfg is True. Player.log accepted only if KSP actually crashes as it is normally an unreadable mess (and doesn't have timestamps)) or it didn't happen. While this is still in the .99 series, I would say that EL is pretty stable and can be considered late beta or even final pre-release. It's more I have a few more things I want to get in before going to 7.0. Many many thanks to everyone who as given feedback and bug reports, and for putting up with my absence (gallivanting between The Bubble and Colonia, mostly in a DBX, both above and below the galactic plane, and a lot of work done on QuakeForge).
  10. Rustle some candy wrappers. The parts will come running (they can hear candy wrappers at 50m).
  11. I don't know what KAS's resource manager is like, but EL's resource manager will let you start a transfer and (while the window is still open, I think) keep going so long as there's something to transfer (ie, even when it drains the source tank set, it will wait a bit before stopping in case more resources show up to transfer), and EL's resource manager supports KAS connectors (and is nice because it works on sets rather than individual tanks, making transfers between large vessels much more pleasant).
  12. Oh, dear... flashbacks to crashing into the surface due to KAC having inverted mouse coordinates for its input blocker and my mouse being over such a random spot and not being able to modify my throttle on time.
  13. I'd just like to say that implementing sub-directory support was both easier and more difficult than expected. Easier because I had already done the hard work elsewhere for another mod (the tree view used to show the sub-directories). Harder because there was a twisty maze of path string manipulation required for dealing with craft thumbnails.
  14. @Nils277 shouldn't have to do anything. Sandcastle uses EL (for non-inventory builds) and EL builds most parts without issue.
  15. I can't agree with this more. I'm inclined to say that docking shouldn't be an option for this particular part (or at least give users a way to disable the option (SC settings menu?)). For me, the problem isn't so much wheels (though that's there), but rather landing a ship on a base doesn't end well when I accidentally click docked mode.
  16. I have released version 0.11.0 of Kethane. Built against KSP 1.9, tested in 1.12. Changes from 0.10.3: Don't request drills on a station. Update particle system to use shuriken (ie, particles are back). There are some minor niggles with particles: sometimes they're emitted in an unexpected direction, and taking off from an active site will cause the particle system to follow the ship. However, I figured it's better to get a release out for those who still enjoy Kethane.
  17. What's wrong the the current recycler? Size is no issue: it will eat anything (except its own vessel). And that's the little one. The big one I made only because the little one didn't work as a truck bed. If your problem is bits of ship flying off in all directions, well... that's because there's a certain probability that a non-leaf part is eaten before all leaf parts have been eaten. The actual probability is difficult to calculate (it varies by the ratio of leaf to non-leaf parts), but there is a way to drive it to 0. The recycling bins have been part of EL for long enough: the way to drive the probability to 0 is to have a vessel productivity >= 0.75. The way parts are chosen to recycle is as follows A part is chosen randomly. If the part has no children, it is recycled If the part does have children, a die is thrown and if the throw "fails", the part is recycled. If the throw "succeeds", a part is chosen randomly from the current part's direct children Loop to step 2 Where vessel productivity (v) comes in is step 3: it controls the probability (p) of the parent part being recycled: p = 1 - (sqrt(v * v + 1) + v) / 2, which ranges from p = 1 at v = -infinity, 0.5 at v = 0, 0 at v = 0.75 and -infinity at v = +infinity. Some might recognize the heart of asinh in there. Now, there are some issues with the recyclers: They move mass too fast (previous post). However, after further play, I've become aware that's not the entire story as I've had to find ways to brace my station's tanks despite not recycling (it seems PhysX doesn't like 30t tanks hanging off size 1 nodes even in micro-gravity (Recoupler to the rescue, and autostruts until I could get the required parts built (I despise autostruts*, particularly due to the lack of control and the inability to send them where they're needed))), but it certainly doesn't help the situation. (* I might despise them, but EL respects them: it won't alter your settings) They are very difficult to use with KIS (I have had very mixed (usually undesired) results attempting to drop parts into a recycling bin). There's no indication of whether the recycler is active (PAW doesn't count: the kerbals (and you) need to see the indication even without knowing the recycler is there (do you remember everything about all your stations and bases? I don't, and my current game has only 4 total (a previous one had 9, and two mother ships)). This is part of why recycling bins shut themselves off when the scene is loaded (and I have no plans on ever changing this) They can't be paused. This wastes a lot of material when your storage capacity is exceeded.
  18. While I imagine others may have encountered this, I have discovered (the hard way, of course) that recycling large, massive ships into modest-sized (and rather flexible) not so massive stations is a good way to summon the kraken. I think I know what's going on (too much mass transferred too far too quickly causing the CoM to shift too far resulting in... some unpleasant physics), and I'm working on it. In the meantime, be cautious feeding EL's recycling bins: kraken lurk therein.
  19. Why oh why didn't I think of this. Can even make it so the stake is visually in the ground and can mentally write it off as the tip is weighted (to explain the offset CoM). It can even make for some fun (those rebounding push-over toys).
  20. @Steven MarinelliI've added your translation and fixed up the issues you pointed out, thank you (and pushed) @zer0KerbalI took a quick look in SimpleConstruction's git repository, but didn't see anything. I hope you get your computer up and running again soon.
  21. Awesome, thank you. Especially the above-and-beyond of finding non-working translations. I'll look into doing those properly.
  22. I suggest keeping an eye on the logs. They can be quite informative sometimes.
×
×
  • Create New...