JH4C

Addon list, log file, inside leg measurement? Check the "how to get support" link pinned at the top of the forum/handily provided in LGG's forum signature. I believe if you don't have any mods that support this, then it won't display its button as it would be redundant. If you do have mods that support this, are they showing their buttons or are they throwing up errors? We need data!

How are you trying to put the Kerbal in? In the SPH/VAB, on the runway/launchpad, in space? By "fresh vanilla" do you mean the latest version? More details and log files please - a full guide to how to submit errors and requests for assistance is pinned at the top of this forum. If you think KerbalVR may be the issue, have you at least tried removing it and seeing if that works? If so, then you'll need to take the problem up with them.

Small, simple, stockalike. Perfect.

I'm confused. The thread title suggests this mod is for 1.3.x, but the fact it was made for Making History by default implies 1.4.x. Which is accurate?

@linuxgurugamer just FYI, the Spacedock link is a direct download link to version 0.1.0, which I believe has been superseded by the Github version 0.1.1?

You could always use Kerbal Foundries wheels and select the smallest size? The KF Small Rover Wheel at 0.10 scale is even too small to lift an Octo2 off of the KSC runway: Seen here parked next to a runway light for scale, I had to use the 0.25 ratio KF Small Rover Wheel in order to convince the game's collision detection that it shouldn't just drop the Octo2 immobile on the tarmac. With a single solar panel, there's more than enough juice to run the wheels and the core!

Very glad this has been bumped up the forum; I've been using the mk1 Cargo Bay (which uses Talisar's model) for a while, and now I can have bigger versions of the same part, as well as a load of others that looks really cool too! Especially looking forward to playing with the toroidal tanks! One thought: wouldn't it make more sense to use MM to define the extra tank variants dependant on whether the mods they support are installed?

Well, the old soccer ball had solid pentagons, but I think that looks works really nicely!

Perhaps the soccerball might be available in black and white, like an actual old soccerball? White hexagons and black pentagons used to be the style, and it would fit in with a lot more stock stuff that way. +1 for switchable textures if you can figure them out! Oh, and don't forget to update the version number in the original post's title when you're updating it @Katten; it helps make it more obvious that there's a reason to look at the thread.

Can confirm the occasional double-entry of ToolbarController in its own menu: seems to occur during first-runs; recreation of the scenario requires only that you delete the ToolbarController.cfg file. Also confirming that entries for removed mods remain; quit game and manually removed Fusebox and AGX by dragging their folders out of GameData then reloading and they were still listed. Additionally, it's always displaying the first-run help window, as the setting for showWindowAtStartup is always being left set as true despite my closing it; setting is retained during the game session across saves, loads, or changes of game type (quitting sandbox then entering career, for example) but resets on exit. I have now manually edited the value to false and it has remained as such. I'm not entirely sure, but based on the file's "last edited" timestamp it looks like it's saving settings on load rather than on exit, but that can't always be the case as it does remember if I change the "display on toolbar" settings for any of the mods. Maybe it's saving only if there's changes to those settings? The only mention in KSP.log of a problem with ToolbarController is this one: [ERR 17:39:52.156] ToolbarControl: stockButton is null, , namespace: ToolbarController_NS And that only showed up once that I saw during the multiple tests I loaded, which was after removing Fusebox and AGX. ETA: While playing later, long after I re-installed Fusebox and AGX, and after experiencing a new issue with another addon, I discovered similar entries to the one above for I think all the mods I have that are using ToolbarController. None of these errors appear to affect functionality in any way but there's obviously something hinky going on. Log attached here: https://expirebox.com/download/482a768e3f62e15cfcb37f43909185af.html

With the decouplers forming cradles, I think it makes sense from a realism perspective to have little or no explosives firing off when separating, as it might cause damage to the delicate components in-between. However having the option to set a charge when building, much like the other stock decouplers, would be nice because not everything needs to be super realistic. Whether you choose to use it depends on your playstyle, and this would accommodate both kinds of player. Now to install the new pod, and build something with it. It looks like it'd make a fine Munar picnic hamper...

If you use the Curseforge link and click the Files tab, you can find all the old versions including 1.3.x

Well, it's gone to Silicon Heaven now, but it was installed according to the in-app Add-On list, yet not an option under Import, hence my befuddlement. As for the other stuff about Git and Blender: Yeah, I know there's reasons within reasons, like everything; just being a grumpy Gus. Could say more, but this is not the time nor place. Your continued support and encouragement is definitely appreciated.

Well I did eventually get my copy of Blender to recognise that I'd installed the addon, but could not convince it in any way to load a .mu file. (I get that some things are more acceptable in free software when they're for the programmer's convenience, but when an app starts out by ignoring the system toolbar, fonts, and file loading dialogues for ones of its own invention I just find it really frustrating to deal with, especially if it ends up ignores my accessibility requirements in the process.) It's no longer installed because I set fire to that segment of my hard drive. I do feel like I'm gaining a better understanding of MM patch though, so I'm not throwing in the towel just yet. Sorry to keep posting about what's essentially dev work in a release thread.

Plugin link for others wishing to pursue the Blender method. My eyes started glazing over at the mention of "cloning repos" (if they mean "download source files in a zip" why can't they just say that?), and the version of Blender I've just downloaded from their site doesn't have any folders for scripts or addons and my brain's just about melting and I think I accidentally flew an SSTO to Eeloo and back while trying to understand all this. I also don't understand how things work with the .cfg files, everything refers to MODULE but never with any form of identification so how does it know which module I'm trying to edit? I think I'm just gonna use some Sharpie highlighters on my screen instead... Wait, I think I was looking at poorly structured files; now I've looked at the MKS patch and it explains things much more clearly. I'm still very confused by the Blender thing though. I may just try to brute-force a couple of simple parts just to get a feel for writing .cfg patches; I figure if I write a patch that adds a dozen lights in varying positions, I can tweak, trim, and tune based on a lot more datapoints in a single reload - a shotgun approach, rather than sniper-like precision, but it'll still get the job done maybe?

@Snark: yes, that's exactly right. Sorry, still learning the forum codes & things for linking pages. @Beetlecat: I was just thinking that, for a testing environment, only having the one (or in this case two) mod(s) necessary would make it much faster; shouldn't be surprised there's a program to automate that! As for what means what, I know that the second of the three co-ordinates are positive going from the centre to the front/top, and negative going from the centre to the rear (worked that out from my own Mk1Cabin patch and the one included in this) so that's Y... I'm gonna assume the first digit is X (left/right) and the third is Z (in/out). I'm not terribly busy right now, so I'll see what I can come up with for SXT over the next few days - any kind of cheat sheet to explain/confirm what means what, and guidelines for positioning that may exist, gratefully received.

I'm not suggesting full sentence messages or anything, just short ID codes. Navigation beacons used to broadcast their 3 or 4 character identifiers so pilots could tell where they were, I'm just thinking that if you have multiple satellites in orbit then each one could have its own signature - KEO1-3 for a minimal Kerbosychronous trio providing relays to the KSC, for example. The timing of the signals: for a commercial US radiotelegrapher's licence, a speed of 20-25 words per minute is expected. Using special test words, this leads to an approximate "dit" length of 50-60 milliseconds, which would also be the time between "dits" & "dahs" in the same letter. Each "dah" should be three times longer than the "dit," the gap between letters should match the length of the "dah," and the gap between words should equal three "dahs." At that speed, "KSP" or "_._ ... .--./" would only take between 2 and 3 seconds. Obviously this is significantly faster than the defaults, and excessively fast for the small amount of information being proposed - depending on your framerate, it may not even be visible. It does show though that there's plenty of room for adjustment within the system you've already built to allow for a longer message that should still be legible enough for semi-skilled amateurs to have a little extra fun with their blinkenlights. Random messages would be equally fun, especially for those learning the code. It'd be great to pull up to a station in orbit only to get warned off due to alien spiders!

Having just installed mk1CabinHatch, I realised the IndicatorLights were in a bad spot and started to move them. Knowing that I could edit the base file but that it's bad form in case of future updates, I started looking for MM patch guidance... and found this instead, which works just as well but saves me doing the tinkering. Yay! One question: I don't suppose there's any way to have the IndicatorLights in one set of positions when the hatch is visible, and a different (their original?) positions when the hatch is hidden, without simply making it so the cabin with hatch is a separate part? ETA: Okay, two questions: Has anyone looked at extending this to include SXT?

Works perfectly in 1.4.3, which is good because I have no clue how you'd go about updating it. Now I can get some real use out of the 0.625 prop engines from SXT!

It's barely a bug, more of a larva, but I found a thing today: if you use the EAS-316 "Meadowlark" Observation Pod (open-sided glass helicopter-style 1.25m cockpit), it offers a Crew Report science experiment, but no matter which seat(s) are occupied it says that a report is unavailable as the pod is unmanned. I'm assuming this is a game limitation, as the stock jumpseat doesn't offer crew reports; such a shame, it makes a lovely rover command pod. I guess it'd make the most sense to just remove the Crew Report listing from the item description and right-click menu?

*insert Stephen Colbert "give it to me" gif here* This looks utterly awesome, and I'm really looking forward to seeing how this progresses.

Just started fiddling with this mod as I do love my lights and having some of them automated will save me remembering to set up action groups for them. Small thoughts regarding the Morse Code implementation: When describing how to encode characters, you talk about "ti" and "taah", yet when you set the duration for the signal flashes you refer to them as "dit" and "dah". The latter is much more conventional, but consistency between both methods would be great for newbies regardless of which convention you settle upon. Common written convention also uses spaces between letters, slashes between words, which is the reverse of your chosen notation. Anyone using an online translator would get skewed results, and/or have to edit the output to match add-on requirements; I realise this app's been in the wild for a long time now so any change here might cause as many problems as it solves, but thought it worth mentioning. It would be nice if there was some way to encode a per-vessel ID code, so that the greeting imparted not just "hey, I see you" but also "you've reached (vessel X)". Probably way too difficult to add this compared to the pay-off... Thanks for a lovely little mod that adds some extra flavour to the game

Ah yes, I'd clicked the link LGG posted to the Blizzy re-release by mistake. I'd kept the old 001blah folder to one side just in case, and have reverted to it with only a small amount of chagrin (I'd even read that bit and made sure I understood it, then clicked the wrong link anyway...)

I saw this had updated and installed it, assuming it was an update for the bundled "001_ToolBarControl" i got with one of @linuxgurugamer's other mods, but this uses a different folder name ("000_Toolbar") and structure, and therefore breaks compatability with those mods. Have I misread the intention behind this package?

This oversight also struck me as odd when I started building aircraft; I dislike that the stock game has so few "liquid fuel only" tanks, and this helps redress that balance for the vehicles most likely to use just liquid fuel, so thank you for your efforts!