taniwha

Members
  • Content Count

    3,829
  • Joined

  • Last visited

Community Reputation

2,400 Excellent

About taniwha

Recent Profile Visitors

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

  1. @Tonka Crash It seems that part doesn't use EL's module at all, so I'm surprised my advice helped. I guess the stock module has a similar setup, but I haven't looked at it for years (probably since KSP 1.0)
  2. @Tonka Crash Thanks, I'll look into that later. In the meantime, I've updated EL's manual to give details about ELExtractor configuration and requirements (section 5.1.4 on page 26 (version as of this posting)@SuicidalInsanity)
  3. @SuicidalInsanity note that I was assuming the parts had been modded to use EL's extractor module (due to the message) I was about to suggest the EL manual for what's needed, but it turns out I haven't documented ELExtractor. Oops.
  4. @Tonka Crash Thanks for the update. I will have to take a look at the model myself when I get some time. Would you mind filing an issue on EL's github (marked investigate) so I don't forget? I"m knee-deep in the code working on a fairly significant update to EL (ひみつ ). And very nice base and station.
  5. While this is probably the general case, I myself prefer a more ad-hoc approach. However, I do generally start with a reasonable "foundation" and then build off that. You should have seen the fun I had getting the first crane onto my base foundation (several years before the micro-pad came into being). I used the survey system (on a rather steep crater side) to spawn the crane directly over its target docking port and let the crane fall onto it. That took a few goes (getting the -Y bounds stake at the right height and the origin stake directly under the port), but it worked well in the end. In fact, that's the base on the previous page (and the EL manual cover). For my own bases, I think the largest I've gotten so far is about 6-7 Diamond Grid balloon tank lengths from end to end. So far, no trouble (1.9.1, Minmus), unless that old THSS foundation (plastered to the side of the VAB) was bigger, but that was last used in 2017. However, that doesn't count extending my bases by building a second one nearby and connecting them via KAS hoses. Don't remember any trouble with that. However, weird motions is something I try to keep an eye on. I do get a lot of weird sliding of loose parts (including Kerbals) on Minmus's surface (despite the terrain being nearly dead flag (JNSQ, so the flats aren't quite as flat as stock Minmus)).
  6. Yes, this will be the cause. My plugin prioritizes ModuleManager.ConfigCache so that parts created via MM can be used. Thus, yes, the mystery comes down to why those parts are not in the cache. @blowfish do you have any suggestions? As a workaround, you can remove the cache file (it will be regenerated the next time you run KSP), but if your craft files use any parts created by MM patches, then you'll still have problems. Reading both the raw part config files and the MM cache file would make loading the first craft file even slower than it is.
  7. @Hohmannson I can't rule that out, but that sounds rather unlikely. I can see it happening at certain places (eg, I found a step in the ground colliders on Duna where the visible ground and the collider doesn't match: a drill there that looks like it's penetrating the ground might not). Anyway, a simple test is to have a kerbal go out and inspect the site: if the kerbal starts walking into the ground near the drills, then that may be the problem. However, that would mean that the collider is sloping down while the visible ground is sloping up (thus my thinking it's unlikely).
  8. @wetwetwet First, that stack trace is horrible: I suspect something got corrupted as the line numbers are out. Anyway, the craft you are attempting to import is looking for a part named "f5jet". It appears you have no such part in your GameData. Likely from a mod that is not installed.
  9. @Tonka Crash first, to answer what's wrong: the two rightmost drills are too deep. Now to get to why... The test for ground contact is done by doing a ray-cast from the tail transform to the head transform (as named in the config file). If this hits the ground (ie, the surface is somewhere between the two transform points and the part is not upside down), then ground contact will be made. For EL's auger, the head is even with the very edge of the digging end, and the tail is at the mid-point of the yellow housing. I can't say exactly where the transforms are for those (rather cool looking) drills, but my guess is the tail is a little below the axle of the digging scoops. I recommend asking @SuicidalInsanity to raise the tail transform somewhat (maybe well into the motor housing). BTW, love your base. looks awesome (as mentioned to @pmoffitt, the lighting helps no end). Also, I like the mix of support styles, and that tubing... (just overall a very nice base)
  10. @pmoffitt Yes, the non-stackability of ReStock parts is due to their nodes being insided the colliders (and thus a KIS issue). However, I am working on a PR for KIS to deal with the embedded nodes (by adding an auto-offset when dropping parts). I ran into some issues with it while testing and have a pile of things on my plate, but things are close.
  11. I have released version 6.8.2 of Extraplanetary Launchpads. Changes from 6.8.1: Hopefully fix interaction with InterstellarFuelSiwtch tanks Fix BoM not updating correctly when changing selected craft Fix support for ReStock launch clamps: they should now extend properly when built at a survey site. PR sent for rotated clamps. Vessels touching an EL pad (launchpad, orbital doc, landing pad) are forced to take on the landed status of the pad's vessel. This works around a problem in KSP where vessels landed on another vessel (particularly after scene load) are suborbital instead of landed. Keep track of the selected pad between vessel switches. This fixes a (to me) major annoyance with multiple pads on a base or station (ie, EL forgetting which pad was selected when a build is finalized). No new save-breakers in this release, but do check the release notes for 6.8.0 or 6.8.1 if upgrading from an older version.
  12. @Nicky21 Awesome!!! Thanks for the feedback. Let me know when you get to 16 builds
  13. @pmoffitt youch. I got some weird shifting of parts (in 1.9.1), but not that bad. However, they had been placed using EL's micro-pad. Also, that particular vessel seemed to be quite cursed: I remember having a terrible time with it trowing itself into space (off the surface of Minmus) on scene load until I managed to hack something (I don't remember what) in my save file. However, I am not using KJR or any robotics parts (IR or BG). I do remember a couple of times in KSP 1.6 my entire base shifting several meters (despite using launch clamps) when starting/stopping (don't remember) timewarp, but it happened only the one time to each of two bases. The first time, the "damage" was minor and I needed only to fix the placement of a bunch of small parts (drills, batteries, fuel cells, etc). The second time, the base actually broke in two and I had to bolt them together using the old KAS pipe (that is now gone, grrr @IgorZ). Also, recently, I've had a lot of trouble with vessels landed on an EL landing pad popping up on scene load, falling back to the pad, then KSP thinking the vessel is still sub-orbital until I actually fly the ship up about a meter and let it land again (I've now got test code that causes any vessel touching an EL "launch pad" (orbital dock, landing pad, etc (ie, the build and release parts)) to take on the same situation status as the parent ship. However, I very much doubt this is related. I suspect that we (you, me, @Tonka Crash (skewed parts counts just as much as shifted), @IgorZ and anybody else that runs into similar issues) will all need to keep an eye on this issue and hopefully we can compare notes and preferably before and after save files.