taniwha

Two or more survey stakes having the same name make for a survey site. Within a site, all stakes of the same type are grouped together to produce a point that is the average of all their positions. Stake [sets] of different types interact in different ways to produce lines (direction stakes, for creating axes), or planes (bounds stakes). Origin stakes are special in that there's no difference between direction and bounds origin stakes (limitation in the PAW UI). If multiple stakes with the same name are giving you trouble, I want to know what that trouble is so I can either clear up any misunderstandings or fix it.

Get the KSP.log file, too.

This doesn't tell me much of anything at all. What does "bug out" mean? Do insects arrive on the scene and abscond with the stakes? (Not sure I blame them, stakes are tasty).

No, the point of my post is that if going through an inventory broke parts when building with EL, something is very wrong.

So long as the parts are spawned "correctly" (ie, such that in the end, KSP thinks it spawned them normally), it shouldn't matter how EL (or any other mod's parts) get into the game. Something many may not realize is that (at least pre stock inventory KIS) even just placing a part using a kerbal spawns the part into the game: the part doesn't exist at all when in the kerbal's inventory, and I'm pretty sure only the model itself exists when strapped to the kerbal's back.

Actually, I fixed the addon to work with Blender 3.2.0 alpha (as of a git pull last night). May or may not work with 2.83, please let me know.

I don't have any new official builds. If you can take care of it, that would be great, thanks.

I just had a quick look at that code and it seems the vessel has specified a flag that doesn't exist, or things have changed in how to fetch a flag texture, but either way, I forgot to check that GameDatabase.Instance.GetTexture() didn't return null.

EL doesn't actually do that. Rather, it finds the base of the vessel's bounding box and uses that to place the vessel. There are two possibilities: the bounding box is wrong (or really, the bounding box of at least one of the parts, since EL builds the box from the part bounding boxes), or there's a bug in the placement code. TweakScale has always been a thorn in my side: when I went to add support for TS to EL, I found that it broke KSP's camera after reverting to the VAB (or SPH), and when I reported the issue, I was told it was a KSP bug and the TS author (at time time) refused to do anything about it. Thus I abandoned all pretense of supporting TS. Sorry excuse, sure, but that's the way it is. I'm pretty sure I haven't changed the orientation of the micropads, but rotations can be a tricky thing, especially if it's a 180 degree rotation (rotation axis is undefined in such a case when you have only the two reference vectors (current and desired direction): rotations are intuitive only in 2d (ie, there is no 3rd dimension)). It's for this reason the pads have extra geometry internal to them making their orientation semi-apparent (can't tell which direction is which, but you can tell when you've rotated 90 degrees) when placing them using older versions of KIS (before stock inventories, haven't tried with more recent KIS). Ie, build goes wrong, load before building, reorient pad, try again. However, I don't think I've ever been out by 90 degrees, only 180 due to top vs bottom node selection. Hmm, actually, I might have changed something: it looks like I tried to ensure that starboard (VAB door side of default orientation) stays starboard when flipping, and starboard is aligned with the red arrow (yeah, a bit weird when the port navigation light is red). This code always has me scratching my head (and some of my git log messages aren't so great in hindsight). What was the bug? (next commit does fix a bug that's related to nodes and orientation, but...) On top of that, I haven't worked on the code since November 2020, and everything I knew about it has been pushed out of my head. This shouldn't be that hard: just include all the .cs files mentioned in Source/Makefile.and KodeUI.inc (note: I use a symlink in Source to the KodeUI source directory, check README.txt for KodeUI related instructions), and I directly reference the dlls in KSP's KSP_Data/Managed directory.

@cineboxandrewI have no problem with any of my stuff being on CKAN, I just don't want to have to deal with it myself.

I've got my server limping along: http (not https yet) is working, so all my mods can be downloaded again. Sorry about the inconvenience and delays. A combination of a few mistakes with the fiber model config (tried defeating some of its stupidity to no avail), working out how to get arcane configs right, waiting for DNS to sort itself out (after a few false starts), and rampaging around the Forbidden West I hope to get https going soon, and with a proper cert this time. Not that I know of, but see my above message [edit] https is working now, and is now actually the "only" option (http redirects to https), and the certificate is legit rather than self-signed, so it should be hassle-free.

Just a heads-up that my server is down for a little while. My firewall had a drive failure (after about 11 years of service) and I'm in the process of getting everything configured again (had to reinstall the OS, no data loss though (separate drive)). I expect to be back to normal by next week, hopefully sooner. Sorry for the inconvenience.

I'll need the FULL KSP.log file (because knowing what to look for takes a lot of experience, and without the log file, even I couldn't say just what to look for). However, having the debug console up and typing something into the command line (so it shows in the log) just before causing the problem is a big help, especially for a "this one works, this one doesn't" situation.

Thanks. My head is currently full of bivectors, so wedging KSP stuff into the mix is more likely to result in a NaN than anything else.

That's a good find. Could you please put it in an issue on github?

I have released vesrion 6.99.1 of Extraplanetary Launchpads Changes from 6.99.0: Fix .version file to cover 1.8-.1.12 Update settings window for the new UI Move global settings into PluginData (instead of in the save files) Add a button to load settings in-game (you can edit the settings file and then reload the settings without having to restart KSP) Ensure all created vessels (built and temporary) have a valid orbit. This fixes some nasty pseudo-crashes that for me happened only when building a survey stake. It might be related to the crashes that occur for people using Principia: please test and let me know. Thanks to @Angel-125 for finding such a nicely reproduce-able issue. Survey site ranges can be configured on a per-part basis (for @Angel-125)

No, they are completely separate. Yes, the disposable pad is a little tricky to use, but that's what the colored arrows are for (and internal mesh, though I don't know if that still shows in recent KIS, I haven't played for a while).

Diamond Grid is not done yet, and I don't do CKAN stuff anyway. That said, The NoLaunchClamp uses EL's ELExtendingLaunchClamp (with which EL replaces the stock launch clamp module on the stock launch clamps) which has working support for disabling staging (the option is stock, but I seem to remember stock's not working properly). I suggested Diamond Grid because it would be a low-fuss setup.

You can use the NoLaunchClamps in my Diamond Grid parts mod.

It'll be fixed next time I upload a release, as I don't actually maintain the file at all: it's all automated (and when I do a release, the file that's in the zip gets uploaded with the zip, so they're always in sync (except now).

I sort of thought I had (or thought of it then forgot). Done now, though. Good for 1.8 through 1.12.99.

This has been fixed in git, but I don't know when I'll be able to get out a release. You'll find the info you want in section 2.5.3 Micro Pad. But in brief, the colored arrows follow the RGB standard of XYZ, with inverted colors for negative axes. and +X on a part with default placement points to the VAB door.

Nothing should have been broken. If so, I'd count that as a bug.

Thanks. I'll take a look, but I can't promise when I'll get it done.

Oh, dear.I goofed in my instructions, sorry. You DO need the UI (style cfg and pngs) and probably Texture (app buttons etc) directories. Oh, however, if you edit the paths in UI/DefaultSkin.cfg, you can move that into SC's directory.