Claw

Things like this would be great to add to the support forum with saves, so everyone can gather up info to help get to the bottom of these things.

But...I...already went! Idk, how about @Supernovy

Maybe not. What about @Vanamonde

No worries. It might still be some sort of interaction issue. If you manage to narrow it down, that might help out. It could also be certain ways of attaching are triggering a problem.

Well, I did fix the mirror so it properly works in stock (as shown a few posts above), so possibly one of the mods is conflicting with the recent change. Initially when the fixed gear was added, it was showing with the point back on one side and forward on the other. Was this a craft that was brought forward from 1.0.5? Or was it created new in 1.1.0? Does it properly mirror if you pull the gear off and reattach?

Nope, @max_creative?

It's currently not working in 1.1 (or 1.0.5), but I plan on updating it. It might still be a rough product (as it was) but enough for people to rescue their ships. Keep an eye on my bug fix thread for an update sometime this weekend.

If you could check the link on your map, that might help me follow the pictures better. I do like the looks of the rover, but I'm not quite sure I'm following the pics at the moment. Though I'll admit I'm quite tired, and I plan on reading it again tomorrow.

Well, I had migrated most of my code earlier in this release cycle and just now updated a bunch of bits (much of it is ready). It's now mostly a matter of updating all the necessary documentation to release. So keep your fingers crossed for this weekend. Other than SAS, there probably won't be a lot of new fixes yet, but I do have a few other new StockPlus bits that I think people will enjoy (called SettingsPlus, so let your imaginations run for a moment). Cheers, ~Claw I'll keep it in mind. I actually removed the control lockout bit because it was causing some folks a hard time. So it will stay out until I can find a more reliable, and uninstall friendly, solution.

So nothing that I know of changed with mirror axis, and the only thing that changed with control surfaces was with the deploy option. So I'm not quite sure here. So I'm at a loss for why it's working differently than in 1.0.5, though control surfaces shouldn't need the mirror axis anyway.

I've updated most of the code and moved some stuff over, including the SAS fix and the parachute spread. I need to go back and re-verify everything. I can't promise an exact date (because I still need to update documents and such), but should be less than a week. I'm also looking at updating the InFlightShipSave, though I might do that after an initial release to prevent delays for the core StockBugFixPlus.

I've not been on the official development side of things for nearly as long as most of the developers, but it's really amazing how much the folks on this side do care. And the most recent hires have been playing the game and helping on the forums for a very long time (i.e. multiple years). We are still actively looking at the bugs that were written up in the QA, Experimentals, and Pre-Release trackers. Just because 1.1 was released doesn't mean we've swept all of the remaining issues aside. As for wheels/landing legs/landing gear (which are all part of the same system now), we know they still need work. There are some known bugs with the Unity version we are using, and as Arsonide said previously, we are doing what we can with KSP to work within the system we currently have. The focus of the update was meant to be performance and UI (with the upgrade to U5), but that also caused issues with the existing 1.0.5 wheel system. We aren't ignoring them, we aren't intending to imply we are ignoring them, and we would certainly like them to be better. As another note, if you look in my signature...I'm the current maintainer of the Elcano challenge, which is all about doing full planetary/moon circumnavigations with rovers. I've done 11 (Eleven? Really) circumnavigations myself, so I certainly care about how wheels perform. I'd like to echo again back to my own bug reporting guide (which now needs some updating). The team here does care, and we are certainly working to squish bugs. The best help we can get is for people to be more explicit about what the issue is, which includes handing over logs, saves, and .craft files, as well as step-by-step instructions on how to replicate said problem. Something like pictures with markings are also incredibly helpful, even when someone might think "oh, this is just a static issue and should be glaringly obvious." A simple case of that was the multitude of writeups about the weird lighting-lines on the KSC buildings. Someone else wrote up a "z-clipping at KSC" issue with two pictures attached and no text (I'm not picking on this issue, just using it as an example). I didn't even bother looking closely at the pictures, because (in the absence of other information) I had assumed it was another lighting-line issue. That's my fault, but it's also important to note that the more time you can save for the developers to see and understand the issue, the less time we have to spend replicating and just trying to understand what the issue is...and more time we can spend on actually fixing things and troubleshooting. Cheers, ~Claw It's an issue with scaling the UI the first time. If you start the game and set something like 80% (or 120%), then restart the game, it'll show up properly. So you can use other than 100%, it just needs a restart to properly scale the orbital flags and icons.

Yes...I'm looking through them right now, still prioritizing, testing fixes, and closing things out.

We're stuck in what looks like a unity (or KSP-unity) bug for OSX (but not all OSX, just some). If you aren't able to get the game to start correctly and into the settings screen, it's probably easiest to edit the settings file.

Try changing the settings.cfg to enable full screen mode, then try starting up.

Hmm. Might be some compatibility issue with MJ anf the bug fixes. I'll try to remember to take a look after 1.1.

Yeah, hopefully it takes care of a lot of oddities. And I'm glad it'll fix things up to help with your addon. Thanks for digging around in there and helping track it down. There are several main reasons, but it's easy to derail a thread with this topic. There are actually several threads around with some of the rationale, or you could post the question in a new topic (so as to not sidetrack the addon thread). Cheers, -Claw

I haven't noticed, but thanks for pointing it out. I'll take a look (seems easy enough to replicate and fix). Also, thanks for the suggested values.

Dres was more enjoyable, though it still contains some amount of explodium. So beware. I actually had to change my route from equatorial to polar due to the lowlands I landed in.

I honestly had no idea that Pol had a terrain issue until I ran into it myself (pun intended)

That sounds perfectly fine. Perhaps @NathanKell can answer that question.

Rule 4 is really meant to be applied to the vessel that is doing the circumnavigation. That's what I meant to indicate earlier when I said "if he's doing a water circumnavigation." The boat needs to make it all the way around, which I believe is why Matuchkin was checking into the canals existing in RSS. The land vehicles can disembark, do some exploration, then back to the ship as a side trip to the main journey. If the expeditions could be completely ignored (i.e. as if they were never brought along) and the ship still complete it's circumnavigation, then the expedtions are incidental story. The land vehicles on the ship could not be used to, say, stop in at New York and drive to San Diego where it magically meets back up with the ship. The ship still needs to sail around one way or the other (probably through Panama), because the boat is the vessel doing the circumnav. So no "landmass hopping" is allowed. Though I can see how this is confusing. So if my meaning is not clear, please let me know. The least confusing thing would be to get back on the ship right where it was left, which is also the impression that I'm getting from this discussion, and should be fine. Unless I'm misunderstanding @Matuchkin?

Yeah, haha. That's why I can't see a good reason to categorically deny navigating around an RSS Earth. So for the moment, Earth is fine. Just need to look for loopholes, since they always get exploited.

Haha, nice! It's almost strange how easy it is to get sucked into hours of driving around. If all you need is pontoons, and you manually move them around as you describe...then I can probably accept that modification. Using IR would be more "technically correct." Do you maybe have a picture or concept prototype for what changes you will make? That might make it easier to see. Depends on exactly what you mean by "second vehicle." It sounds like you're planning a water circumnavigation. In which case, having an "exploratory rover" of sorts on the ship is perfectly acceptable (and I'd actually love to see that!), so long as all those vessel meet back up and continues traveling together. Yes, always. Only a few categories of mods are expressly forbidden. I'm trying to not maintain a list of acceptable/prohibited addons if at all possible. Also, the "no modded celestial bodies" is a carry over from the previous thread for this challenge, so I hadn't thought about that particular rule much. Edit: Oh wait, I think I see your meaning now. Yes, any modded celestial body entries will likely go into a single category of it's own. Just need to figure out if there are any add-on bodies that shouldn't be permitted. I suppose RSS is an easy decision, but I don't know much about the other planetary mods.