Claw

Also (as with the other thread)...If you aren't opposed to add-ons, there's a fix for it here: http://forum.kerbalspaceprogram.com/threads/97285-0-25-Stock-Bug-Fix-Modules Cheers, ~Claw

If you aren't opposed to add-ons, there's a fix for it here: http://forum.kerbalspaceprogram.com/threads/97285-0-25-Stock-Bug-Fix-Modules Cheers, ~Claw

Sorry folks, I've been away for a bit. Due to life events, it might take me a week or so to catch up on all the things that have been fixed. The good news is that I am pretty sure the core fixes (such as wheel fix, frozen kerbal fix) will still work as advertised. In fact, they should all be compatible, though I have to dig around a bit to see which are no longer needed. Cheers, ~Claw

Yes, a known issue. Though some details are still missing. Moved to the support forum. Cheers, ~Claw

I agree. Which nearly every thread that has any level of debate eventually devolves into. I've seen so many of these "why not" threads on so many topics. Regardless of how many facts are stated, they "why not" remains a mystery to some. In all of this x64 business, I see no reason to point fingers or blame at anyone. It's unfortunate that "trying something out" that fails inevitably results in the absolute driven passion to find someone responsible for it. Rather than accepting the fact that an experiment was attempted and it fell totally flat. Here we are, many Mun's later, still lamenting over who did what. This is a common theme for so many things in KSP. So many add-ons, so many "stock things that are broken," so many "why can't person X do something so simple?" Because we are all humans, and we all have different things going on, and eight bosses Bob. Eight. And, my own observations after living on so many borders of the KSP world, it saddens me the combative environment that happens constantly around such a great (utterly fantastic) game. The constant pokes, jabs, and outright harsh criticism over the same things grows quite old...regardless of where it comes from or who it's aimed at. I'm not just referring to "Squad hate," but all if it. It just gets really, really old. My non-moderator thoughts. Cheers, ~Claw

Quite frankly I think it has to do with the fact that there are quite a few of us (on all sides of this) who are worn down on the whole x64 debate. I see your post as factual, and sometimes we moderators like to post personal thoughts. I would say that, as a moderator myself, it would be nice to be able to display my own thoughts on a subject from time to time without it being construed as some sort of official forum stance. Regardless of what we think and how we frame our own conclusions, our personal posts are often interpreted as some sort of official stance. I nearly always steer clear of any conversations involving the standard debates on the forum for this very reason. While not trying to speak for him, I think that Vanamonde's post is reflective of his own personal viewpoints. It would be nice if more people understood that slight subtlety, thought I acknowledge that it can be difficult to discern our personal postings from official stances. That's probably a roundabout answer. So, to answer your questions more directly. No, it's not. Cheers, ~Claw

Awesome, thanks! I will check them out. Thanks for the tip. I'll give that a try. Excellent, I'm glad you like it. I still need to get off my lazy back side and implement spread for stack mounted chutes placed symmetrically. That sounds like a generic docking problem on the surface. Although you might also have some variant of one of the docking bugs. Have you tried backing the pieces away from each other and approaching again? You might also need to do a little save file editing to reset the port. You can check out this thread and see if it helps: http://forum.kerbalspaceprogram.com/threads/78863-FIX-Dock-Undocking-Bug-in-0-23-5 Cheers, ~Claw

Yep, I understand. The rover wheels work just fine, so long as you never right click on them. As soon as you right click, the brakes get messed up because of a bug in the tweakables. So theoretically has a workaround, so long as I never have to right-click on a wheel (to adjust steering or fix a flat). I'm not trying to convince you otherwise, but might be handy to know about for those participating in a challenge involving rovers. Thanks for the clarification. So now I'm trying to figure out if I want to try to build an amphibious rover, or a land-capable boat. As for max speeds of a boat... I'm new to boat building myself. I've managed to get about 120m/s before my pylons disintegrate. I've not had luck with wing panels (like in the video). They seem pretty fragile to me, only getting to about 30m/s. Cheers, ~Claw

I did release a fix for this a couple days ago. You can find it in the usual place. I've added it to the ModuleProceduralFairingFix. http://forum.kerbalspaceprogram.com/threads/97285-0-25-Stock-Bug-Fix-Modules It's not perfect, since there might be some edge cases with strange combinations of EVA and fairing jettison, but should work pretty well for regular rocket flying. Cheers, -Claw

Closed, per user request. Cheers, ~Claw

Indeed, here's an existing discussion thread. So I'll close this, unless there's some different angle that's being aimed for. http://forum.kerbalspaceprogram.com/threads/116406 Cheers, ~Claw

I know it can be modded...but with the exception of my bug fixes and MJ for stats, I play all stock. I'm more than happy to dump MJ for this challenge, but wanted to know if the bug fix modules disqualify it as a stock entry. Specifically, the wheel brakes... Also, I will have to show some of my ignorance here: I don't catch your joke. Cheers, ~Claw

Fengist, I'm considering doing this challenge (I've not done one in a long time) but wanted to ask...(and maybe this has already been answered in the last 35 pages) Are my bug fixes acceptable "stock" qualified, or would they still put any entries into the "modded" category. I ask because stock brakes are broke, so this puts a damper (or lack of damper) on rover challenges. Thanks, ~Claw Here is an old rover challenge entry of mine, which will need some updating to go amphibious. 4x warp capable and 4 crew. So I'll probably do something similar.

This is actually a pretty daunting task, which basically requires rewriting the control surface module itself. The stock module does the individual channels inside the code, and doesn't have any hooks to individually flip them. This means any "simple" plugin (that doesn't replace stock behavior) can only flip the response for all channels, or none. Incidentally, flaps do have an invert function. But that only flips the flap functionality (which I assume isn't what you're referring to). You are very welcome. And I was concerned that this might occur. I did test with several larger rockets and they worked okay. This is that "I need help with more testing" part. So if you could provide a craft (if it's stock) or some pictures that would help me refine the code. Cheers, ~Claw

Well, I try not to do general debugging in this thread. I haven't had time to go back and research this bug for replication steps (which greatly speed up building a fix). It takes time to first replicate the problem, then poke around to see where the problem is. This is in my list. It's not quite something that stops gameplay like stuck fairings and non-functional brakes, but I understand that it's annoying. You are very welcome. I appreciate your request/frustration. The mechanization with the .cfg files is something I've been struggling with, since some people like pure stock behavior, some don't care and will mod to the hilt, and others do things in between. Perhaps I will steal your syntax from above, and test it out/implement in the next major release. Seems safe enough, and I can pull all the StockPlus bits into one file. Cheers, ~Claw

Version 1.0.2e.3. Apparently some Work in Progress code snuk into ModuleProceduralFairingFix. Which isn't a huge deal, except it causes excessive log spam (and lag). If you downloaded 1.0.2e.2, please redownload 1.0.2e.3. Sorry for the inconvenience. Cheers, ~Claw

Ah, I think I understand your problem a little better now. Let me see if I can offer another two things that might be the cause... 1) Check your trim input after you drive a bit and make sure you aren't accidently adding trim. The indicators are in the lower left. Press ALT+X to zero it out. or 2) There is a "stuck key" thing that happens with kerbals where holding the SHIFT key and pressing forward, then releasing SHIFT causes the kerbal to keep walking forward. Possibly this bug happens with rovers (unconfirmed). Do you do any other keypresses when you drive? I suppose lastly, if you are using mods, might want to see if any of those are causing problems. Or at least keep an eye on the log file and watch for errors. Cheers, -Claw

Those options are StockPlus options (from my mod) and not pure stock. Glad they help a little. On that subject, I just added a fix for the stuck fairings to my fixes (ModuleProceduralFairingFix). It should do slightly better allowing fairings to clear close in parts...and if they do get hung up on the ship, you should be able to time warp or quickload/quicksave out of it. As a side benefit to how I fixed it, other mods should hopefully not start freaking out about being in a biome. Cheers, -Claw

Necro is okay if the information in the thread is still relevant, and your post adds substance. Thanks for the description. No, no real headway in figuring out what causes this one. Your save should be okay except that one ship. However, it will spread if you visit that vessel and have the bug, then visit other ships. The only way to prevent spread once you encounter the bug is to restart the game. Cheers, -Claw

Version 1.0.2e.2. Added some additional fixes in ModuleProceduralFairingFix, which should help with fairings getting stuck on ships. There should be a small amount of time for jettisoned fairings to clear close in obstructions (very small)...and any fairings that do get stuck on ships will not cause problems saving. So you can now quicksave/quickload your way out of the fairings if needed. Cheers, ~Claw

It looks like your kerbal is missing some state information. This is very unusual, so it makes me wonder if you are using mods, or if this part of the save file has changed in 1.0 (I haven't confirmed). However, this part is missing from the snippet you posted above. MODULE { name = KerbalEVA isEnabled = True [COLOR="#FF0000"] state = Ragdoll step = 1.208333 packExt = False lightOn = False flags = 1[/COLOR] EVENTS { Keep a copy of your save. Put that information in and load it up. See if that fixes your kerbal. As a minimum, you need the state information. Try setting him as Ragdoll. Then when you switch to him, press some keys and that will (hopefully) revive/reset him. Cheers, ~Claw

It's a bug with the stock tweakables. If you place the wheels without right clicking on them, then they will usually work just fine. However, if you ever right click on them (such as to repair, disable steering, etc) then the brakes will be forever "broken." The workarounds/fixes: 1) Never ever right-click on the rover wheels 2) Edit the save file (or .craft file) and change the wheel torque option to something higher than the default 30 (some of the rover wheels are upwards of 200, with the ruggedized wheels up at 500). 3) If you aren't opposed to add-ons, you can install my fixes. The specific one you are looking for is ModuleWheelFix. Cheers, ~Claw

Ahh, I see what you are asking for here. I haven't tried doing as you ask in my fixes (enabling the "Pack Chute" as an action group), but I think that without further programming, it wouldn't work as currently set up. Since (as mentioned above) action groups apply to the vessel. And the "Repack Chute" option is actually attached to the chute, although marked as available for EVA usage (which allows the right-click menu to be accessible when EVA). So the way the stock code is written, I don't think one could simply "unlock" the action group and it would be ready to use. There would be some other work involved, namely attaching the functionality to an EVA kerbal which looks through nearby parts and repacks chutes that are close enough. Cheers, ~Claw

You are very welcome! Possibly, seeing as how it's happening on the Tier 2 launch pad...except that bug causes the rocket to stick, rather than having the smoke effects. Have you tried it on the Tier 3, to make sure it isn't a career problem? Really, it looks like you might be having some mod interaction problems. Are you able to do any narrowing down to see what might be causing it? Two things that I can think in my mod that might be interacting would be the StickyLaunchPadFix and possibly the ModuleGimbalFix. They both fiddle with engines, and the SLPFix is connected to Tier 2 launch pad issues. Sure, I could do that. Although I don't know if I will spend the time to write individual baseline and maximum values for each engine, but I can put the mechanics in there to accept default and maximum values via .cfg. Quite frankly, I'm surprised to see how many people want the gimbal response time feature. Cheers, ~Claw

I'm not sure how easy this would be. Also, this might fall into the classification of "annoying and poor mechanization" rather than a gameplay bug. If I do get to this, it'll be a bit since there are several others I'd like to get to first (such as some of the fairing problems). It didn't seem to be doing much for small ships, and (if anything) causes some problems. So I found it was easier to scale down the other parameters. Quite frankly, I didn't want to program a full feedback loop (since I'd also have to redo a good portion of the stock RSAS). I have no idea what the stock values are based on... Yeah, that "should" be easy enough. I'll probably make it a StockPlus addition, similar to the flight controls. (Although every time I think something is going to be easy...) Removed on purpose. It's controlled within the module itself now, so that I could enable it as a StockPlus feature. That's a good idea. But I don't know if I will implement the pilot skill, since it's not quite in the same flavor as the rest of my fixes/StockPlus. Something to think about though. Cheers, ~Claw