Claw

Thank you very much for sending me a craft file. And I agree that there is indeed a bug. I decided to post in here, because it's probably something worth pointing out to others. Also, it's not a bug I've seen yet. So the bug is actually triggered by in the editor based on what symmetry mode you have selected when opening a file the first time. I haven't previously run into this before, but that's probably because most people typically build mirror craft in the SPH vice the VAB. So, what does that mean to you? Your file is definitely "broken" but should be easy to fix. - Make a copy of the file first (just in case). Open up the .craft file and search/replace all the instances of "symMethod = Radial" with "symMethod = Mirror" (do not do a search/replace just "Radial" because you will break the file). Opening the File: - Now, when you go to open the file in the VAB, set down a generic root part (any root part). Then change the symmetry mode to Mirror (press R). Now go open your fixed .craft file and the parts should not reset to Radial. I will see if I can figure out what's causing this. I thought I knew initially, but seems I will have to dig a little more. That should hopefully be enough of a workaround that you can continue to work. Also, by the way, if you accidentally open the file before switching symmetry modes, it's not a problem unless you click "Save." Just switch the symmetry mode to Mirror and open the file again. Good luck! Cheers, ~Claw

Yes indeed. Ramping workload and a busy Kasper has contributed to delayed postings. It looks like Modding Monday is back on track. Cheers, ~Claw

Well, my mod actually does some conversion of part's symmetry status when building. It also sets single part symmetry status to Mirror in the SPH and Radial in the VAB (invisible to the player). I did try your steps above, but seriously, a picture would help. In stock KSP, the steps you provided did give a poorly built wing, but it was still mirror. It did not switch to radial, nor did it change when I restarted KSP. I tried several times and didn't see a difference. This is partially why I beg for pictures, .craft files, definitive reproduction steps, etc... Not because I enjoy inflicting pain on people (although it is fun ), but because it is much harder to see the issue you are trying to point out, and for me to understand and/or offer help (or build a fix). I want to help, really. But with the info above, I have no answers to offer. Cheers, -Claw

Well, the linux crashing bug that I fixed (confirmed) has to do with parachutes. So I wouldn't quite say "for no reason" on that one. And, unfortunately, there are a lot of "crash for no reason" bugs. So without more details, I'm not sure which you are referring to. Cheers, -Claw

It's been a little while since I've posted a version, so I thought I would post a short update. I've been busy with life events, plus I took some time to partake in a couple challenges (including posting a mission report). In any case, you're not here to hear about my woes. Most recently I've been working on the claw bugs. I have fixed the bug that eats ships if the ship in control is the one being clawed on. There is also the timewarp bug, where part of the ship freezes in place and the other parts rip off. I've managed to keep it from ripping the ship apart and allows you some time to save, but I haven't been able to halt it completely yet. I've updated the StockPlus parachute flare (pictured in the OP) a bit, and now includes flare for symmetrically placed stack chutes (like the Mk-16). Also, it StockPlus chutes now have a safe/risky/unsafe indicator on the stage icons. Finally, I'm starting work on the problems with fairings and service bays. Primarily the work is focusing on making sure parts don't stay disabled due to fairings, even though they aren't in them anymore. I think most recently someone else discovered there are drawbacks to simply resetting the "Shielded from airstream" flag. Cheers, -Claw

I suppose that's possible. Or maybe even not specifically that an intake is in the water, but maybe all that splashing around does something? The one that caught me off guard was the one that happened while swimming around. It was very sudden. I wasn't switching vessels, climbing on anything, or really doing much. Maybe the only unusual thing was one of the kerbals standing on the one of the intake floats. That happened naturally as the ship drifted around a little (I didn't put him on there). So Idk if that contributed. Cheers, -Claw

That's because there's a bug with the tweakables for rover wheels. If you right click on the wheel, you've basically ruined it's braking action. As for airplane wheels, their brakes seem to be more effective. So I'm not sure specifically which wheels and/or how much mass you're trying to stop. Keep in mind that high speed landings can also impact the braking action quite a bit. If you have a picture or .craft that might help us out. Cheers, ~Claw

Well, I haven't done any hard testing in regard to these. As far as memory consumption, they shouldn't really eat up too much. I'm not really shuffling around any memory or grabbing any memory for textures, parts, etc. So should just be code space, which is pretty small for most of them. SymmetryActionFix might be the longest plugin of the bunch. The rest are smaller modules. As for lag, it'll likely vary a little based on the module. Something like SymmetryActionFix will induce a small amount of lag when connecting a part if the part trees are large or are using excessive amounts of symmetry (by excessive I mean 64x, which is possible). Most of the "in-flight" modules use very little CPU overhead because they tie into the Stock modules and make some minor changes (so not a lot of cycles spent running code). There are a few modules that I had to increase the overhead on in order to maintain compatibility with other mods (ModuleControlSurfaceFix comes to mind). But other than that, I generally try to make efforts to keep the modules lean. If they have to run "slow" procedures, I try to limit the number of times they need to run, or try to run them at already slow times (like scene transitions, coming off rails, etc.). Not sure if that helps you out or not. Cheers, ~Claw

Well, I'd say we definitely need the logs to start with. KSP always generates an output_log.txt within the KSP_Data directory, even if the game doesn't crash. You can also bring up the debug log by pressing ALT+F2. See if anything shows up there. Two other things off the top of my head... Try increasing resolution slightly if you can. There is at least one other instance of a button not showing up due to resolution, but I doubt that is it. Have you had any video card driver updates recently? There have been numberous occasions where new updated drivers have cause graphics problems in KSP (or worse). One other symptom of this is that everything was working fine, then suddenly broke with no changes. Often that's fixed by reverting the driver to a slightly older version. Cheers, -Claw

The CG looks plenty low in that. There are a couple things that might be contributing to the flippy-ness.. - Make sure your rear wheel steering is off. At any appreciable speed for light vehicles, rear wheel turning will cause instability. - If you have any torque wheels hiding in there, it could be giving you troubles. If there is too much torque, it'll cause issues while you are driving because the drive keys are mapped to the same keys as rotating. So when airborne (or even a little loose on the ground) the torque can contribute to flipping. However, having some torque with stability assist on can be very helpful, so long as the torque isn't overpowering. Also, there will be a side effect from messing with the wheel steering. The bad thing about doing this, is that those wheels have a bug in the brakes where after you right-click the wheel, the brakes are virtually non'effective. You can manually fiddle with the .craft file to fix them which I can point out to you if you want to do that. Or, if you aren't opposed to add-ons, use the ModuleWheelFix from the stock bug fixes in my sig. Cheers, -Claw

Haha. I didn't understand why the broken was a problem till I read your thread. Thanks, and good luck! Cheers, ~Claw

Yes, pure stock install and default stock aero settings for v1.0.4. Cheers, ~Claw

Nice work. I was thinking about doing an Elcano on the Mun. Definitely helpful to read this first. Also, I think you have so much stuff in the HUD that some of your pictures look like a first person shooter with the top of the ship coming out of the right of the screen. Keep it up! Cheers, ~Claw

Yeah. This right here just about kills any thoughts I have on making something similar for pure ground transit (even non Kerbin). It's just soooo unwieldy to build a long range rover with this stuff on it. The extended leg setup I have on the Cockroach turned out to be fairly sturdy, but only because I was using the small landing gear bays. For a previous ground challenge (drive to the North Pole), I had built a small jeep looking thing capable of surviving a crash at 4x warp and full speed (about 23 m/s). You can see a picture of it in my Elcano Kerbin mission report (or spoiler below). It mostly consists of modular girders and the rover wheels. The wheels are actually pretty sturdy from a "blowing up" standpoint, but tend to break treads a lot. Especially under warp. The internal core has been pulled for the picture. This is from an old KSP version, where I was using probe cores for torque and battery (they were no small torque wheels in that version). Cheers, ~Claw

With this one, what is often happening is the pop-up dialog is being put in the wrong place. Try panning the camera around (and often up to see more sky) and right clicking again. I've had the tracking station dialog appear south and up numerous times, which makes it appear outside the default camera view. Cheers, -Claw

My attempt at a sea based circumnavigation of Kerbin is complete! (Full mission report here.) And the end result: The Cockroach Thanks for the challenge, Fengist! Cheers, ~Claw

“Complacency is a friend of fearlessness. When working together, they can make great and terrible things happen.†The pilots vow to never speak of this again. Travel Day 7 Day 7 is pretty uneventful, until the end. The crew decided to stop slightly early near an island within a day's travel of home, in hopes of squeezing in a relaxing victory swim. Things are going fine, until a Kraken from the deep shows up and swallows the whole ship. No kidding, the whole ship just blew straight into the water, pulling the swimming crew down with it. Most of the ship disintegrated, and the crew was pulled about 300m below sea level. After that, I decided to quickload and just timewarp to the next morning (sometimes this game can be a little buggy...) Travel Day 8 - Homecoming So, day 8 was actually a little bit of an eye opener, which contributed to the quote at the top of this post. In my Travel Day 5 & 6 day post, the crew learned that it's easy to set the autopilot and let the ship just drive at full speed. That nearly caused a problem when the ship was rounding the southern point of the main continent that KSC is located on. The ship was nearing the coastline and had been drifting to a northern heading. Only a slight heading correction was needed, but resulted in a nasty spinout since the CG had shifted and there was no electrical charge remaining. I actually don't have any pictures from that event. The reason being is that as it spun out, the crew started to panic since it sent the Cockroach hurtling at the shore bank. The pilots were frantically slamming the throttle between idle and 100% in an effort to use the gimbal thrust to point the Cockroach in any direction other than right at the shore line. It was nearly catastrophic... In any case, the Cockroach made a full recovery and was able to continue on home. The crew definitely payed attention for the remainder of the trip. And for documentation sake, here's the full route map. Thanks for reading! Cheers, ~Claw

Heh. That's pretty awesome. The things people can come up with in this game are incredible. Cheers, ~Claw

Not to step on Fengist's toes, but I think what your asking is within the rules. Specifically, noted below: That rule sounds like what you're asking about. Running into some sort of problem that requires some design changes, so long as it's very similar to the original. On a separate note, I've finished my run and will be (hopefully) posting my last bit in the mission report today. Cheers, ~Claw

Heh. Yeah, it's been a while since I have done this much ground coverage. I had forgotten about that little "feature."

“Anticipation of completion is nearly as exciting as the arrival itself.†Travel Day 5 After the seemingly rough trek through the land pass, the second half of the journey passed quickly by. The land bridge was a little less than half the distance of the trip, but marked the end of the most difficult phase of the mission. The crew now has a much better feel for how the ship handles. As a result, maintaining trim on the ship is a lot easier which ends up yielding a better average top speed, and (by extension) better fuel economy. The crew still stops for rest at night, but after three weeks of sitting around (refueling), they eagerly press ahead into slightly longer travel days. Except for a couple quickload hiccups, these travel days are relatively uneventful. During the day, the crew spent a little time exploring an island in the middle of the ocean they didn’t know existed. By the end of day 5, the crew has nearly made it to the main equatorial pass and drops anchor for the night. At this point, the Director anticipates the Cockroach will have to stop at the end of day 6 to refuel and select a peninsula which looks like it’ll be far enough along to be the final refueling stop. (Which I'd mark on a map, but it's in the pictures below). Travel Day 6 After traveling so much in the open ocean (for all but the land crossing), the crew follows the coastlines south then east, and head for the peninsula that harbors the final fuel stop. I found myself paying less and less attention to the craft as I was plotting and planning things out. Because of the design, it actually doesn’t take much attention to drive, but does require some attention to the systems. On at least one occasion, the ship ran out of LF because the crew forgot to convert more Ore when required. On another time or two, the ship ran out of electrical charge because the converter was left on. Not a big deal, but resulted in spinning out when trying to make a course correction. Not a lot of excitement on these two days, but here is a bit more scenery from Day 5 & 6... Cheers, ~Claw

This: [Part]: PartModule ModuleKerbalDebrisFix at kerbalEVAfemale, index 9: index exceeds module count as defined in cfg. Looking for ModuleKerbalDebrisFix in other indices... (Filename: C:/buildslave/unity/build/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 56) ...no ModuleKerbalDebrisFix module found on part definition. Skipping... But I see you have other EVA plugins in there. So I don't know if something is interacting badly or what. I'll have a poke around my code to see if I can find out, but this error makes me think the Fixer module was somehow deleted and can't find itself. Though I don't think this particular error is directly attributed to what you're seeing. Cheers, ~Claw

Looks like your save is corrupted by a stray kerbal. The kerbal looks like it was part of a rescue at some point, but now the information is orphaned in your save. Open up your save file with a plain text editor, such as notepad. Then look for the section below and delete it all. Make sure you don't leave any stray blank lines in between the information around this Vessel structure (KSP doesn't like that). It's probably easiest to find by searching for "Lagerigh" (the name of the kerbal). VESSEL { pid = 6cea22dd0f0a4320831ffc0b99d9fddb name = Lagerigh Kerman type = EVA sit = LANDED landed = True landedAt = splashed = False met = 2929699.37318032 lct = 2929699.37318032 root = 0 lat = -46.6888484719376 lon = -105.679574779086 alt = 2905.2595262384 hgt = 0 nrm = 0,1,0 rot = 0.3957458,0.04664666,-0.02013212,0.9169537 CoM = 0,0,0 stg = 0 prst = True ref = 0 ctrl = False ORBIT { SMA = NaN ECC = 1 INC = NaN LPE = 0.761612657810946 LAN = 129.371554957931 MNA = -8.40714670366795 EPH = 3190749.34396434 REF = 2 } PART { name = kerbalEVA cid = 0 uid = 528772138 mid = 528772138 launchID = 0 parent = 0 position = 0,0,0 rotation = 0,0,0,1 mirror = 1,1,1 symMethod = Radial istg = 0 dstg = 0 sqor = 0 sepI = 0 sidx = 0 attm = 0 srfN = None, -1 mass = 3.125 temp = 0 tempExt = 0 expt = 0 state = 0 connected = True attached = True flag = Squad/Agencies/MovingPartsExpertsGroup rTrf = modCost = 0 } ACTIONGROUPS { } DISCOVERY { state = 21 lastObservedTime = 3163350.81598186 lifetime = 163919128.32893 refTime = 163919128.32893 size = 0 } FLIGHTPLAN { } CTRLSTATE { } } Cheers, ~Claw

Huh. Thanks for the log file. I don't see what's obviously wrong, but I do see some unusual things. Hopefully I can figure it out. Was that kerbal involved in a crash? Or did he just suddenly end up that way? Cheers, ~Claw

I don't recall hearing of this problem lately. It would be helpful if you could include a little more info, such as a save file and log file. You can check here to see where to find those files: http://forum.kerbalspaceprogram.com/threads/92230-%21%21%21-PLEASE-READ-BEFORE-POSTING-%21%21%21-Stock-Support-Bug-Reporting-Guide Also, welcome to the forums! Cheers, ~Claw