Deadweasel

W00t! *bows graciously*

Awesome Sauce! Yeah, it was bothering me that it always seemed good ONLY with a new save file started, so I started thinking about what I did during the average game that would still be present in the persistent file even if I "retired" every ship in action, and it hit me: "How does the game know how long each ship has been active for anyway?" *click* Just re-downloaded, installed and had a go with the regular save file. All is well with the world once again, and Nelnie Kerman is dancing in the cockpit on the runway right now in gratitude for saving him from his predecessor's horrible fate. Ardy had to be removed from the program when he suffered epileptic seizures after turning on the strobes for the previous testing series.

WOOHOO! Glad I could make a helpful contribution to this. I really do love having it on my ships!

Okay, looked up the API, and I'm almost certain this is the problem. <member name="M:Planetarium.GetUniversalTime"> <summary>The simulation time, in seconds, since this save was started.</summary> <returns>Universal time, in seconds</returns> So Planetarium.GetUniversalTime() references time since the simulation started. This is not a good way to keep time for simple flashing lights, I think, because you're inevitably inviting overflow issues if it runs long enough. Isn't there a way to reference system time *right now* instead of watching the save file's time increase?

I'll be damned.... In persistent.sfs: FLIGHTSTATE { version = 0.20.0 UT = 65913550.4759087 activeVessel = 3 ... Changed UT = 0.0 Everything is fine again. It's the accumulated UT (UniversalTime) that's doing it! EDIT: OMG... BigNose, what is the vartype you're using for the light timing again? uint16_t in C (had to look that up) maxes at 65,535 before it overflows. I will bet that the variable is freaking out because it's getting a much bigger number than it can handle from the UT in the persistent file. I could be way off in my interpretation of what's happening here, but editing UT in the file definitely fixes the problem and explains why new saves don't have the issue.

"Holding heading... Holding heading... Holding headi-SQUIRREL!!!"

There's definitely something going into the persistent file at some point during play that's causing the lights to freak out. I'm going to have to do some detailed "vulching" of the file as I start from a fresh save and watch for the instant the lights start freaking out again. Because of how these lights reference UniversalTime, I'm starting to suspect this bug has something to do game time, or more specifically, reaching a certain point in time from 0-hour (the point at which the new save world starts). That's the only thing I can think of that the persistent.sfs file would be tracking, and that would be consistent enough to create this weirdness even if all other vessels and debris are cleared from the save.

Ah, programmer humor. /lol'ed quite a bit, actually

I do strive for some levity when I can, so I'm glad I could put some laughter in your day!

Because I had it running and handy, I tried that myself. NEW SAVE: Strobes work as intended, regardless of their placement method. They flash properly whether they were placed with symmetry or with just one placed without it. CURRENT SAVE (4 flights in progress): Strobes do the crackhead flash dance, regardless of symmetry placement mode. Even just one placed singly still does the weird flashing. There's something happening with the game when other flights are in-progress, and doesn't seem to be reversible by simply ending every other flight and launching just the one with strobes, as evidenced by the video clip I posted earlier. In case it helps, here is a snip of one of the relevant lights on the demo ship as it is built in the persistent file that is having the issues: PART { name = lightstrobe.white uid = 2398733203 parent = 190 position = 1.37998735904694,1.1790052652359,-5.56451988220215 rotation = 0.01066774,-0.7069897,0.7070646,0.01056421 mirror = 1,1,1 istg = 0 dstg = 0 sqor = -1 sidx = -1 attm = 1 sym = 272 srfN = srfAttach, 190 mass = 0.01 temp = -199.9841 expt = 0.5 state = 0 connected = True attached = True flag = Squad/Flags/satellite EVENTS { } ACTIONS { } MODULE { name = ModuleNavLight isEnabled = True navLightSwitch = 0 EVENTS { FlashEvent { active = True guiActive = True guiIcon = Flash guiName = Flash category = Flash guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } IntervalEvent { active = True guiActive = True guiIcon = Interval guiName = Interval category = Interval guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } OnEvent { active = True guiActive = True guiIcon = Light guiName = Light category = Light guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { LightToggle { actionGroup = None } FlashToggle { actionGroup = Custom07 } IntervalToggle { actionGroup = None } Cycle { actionGroup = None } } } MODULE { name = PMActionOTF isEnabled = False EVENTS { editAction { active = False guiActive = False guiIcon = guiName = Edit AG : Light toggle category = guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { } } MODULE { name = PMActionOTF isEnabled = False EVENTS { editAction { active = False guiActive = False guiIcon = guiName = Edit AG : Flash toggle category = guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { } } MODULE { name = PMActionOTF isEnabled = False EVENTS { editAction { active = False guiActive = False guiIcon = guiName = Edit AG : Interval toggle category = guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { } } MODULE { name = PMActionOTF isEnabled = False EVENTS { editAction { active = False guiActive = False guiIcon = guiName = Edit AG : Cycle modes category = guiActiveUnfocused = False unfocusedRange = 2 externalToEVAOnly = True } } ACTIONS { } } } Nothing seems out of place, but then again, I'm not experienced with mod creation for this game, so I could easily be overlooking something critical.

Yeah one way or another I'm still using these lights too. The navigation lights alone make it worth it for the look. The glitch where they turn off if you hit the Esc menu and go back is a bit annoying, but it really is a minor thing. It's really fun to have those lights on during docking procedures. Which reminds me: I wonder if there's a way to "hook" into that, so that when a ship becomes a set target, some of its lights could be triggered on. Sort of like a special action group, like Abort. Hmm... this might be one for the suggestions board.

For now, the best I can offer to help with debugging is my current hardware specs: Motherboard: MSI 870S-G46 Processor: AMD Phenom II X4 925 RAM: 10GB dual-channel DDR3 @ 666MHz (9-9-9-24) VIDEO: nVIdia GeForce GTX 550 Ti (1GB VRAM) HDD (Boot): Western Digital WD800HLFS Velociraptor 80GB (AHCI mode) HDD (Game location): Western Digital WD1600HLFS Blue 160GB AUDIO: M-Audio Audiophile 2496 OS: Windows 7 64-bit Ultimate I'm going to run a fresh install and use AV Lights as my only mod to eliminate mods and parts as potential conflicts. I do currently see odd behaviors with the other add-on lights from B9, where lights flicker or "fight" for dominance when two of them are near one another, so maybe there's something having an effect there. The B9 Utility lights are also the only ones in the collection that have a fade effect when turning on and off. There's a possibility that having those present might be throwing a different timer method into the works and causing a conflict.

Uhh... Unfortunately you've gone far over my head with that, as I do not code C/C++/C#/ObjC at *all*. I have the barest notion of what you're getting at, but see, the thing is, most of the gripes have nothing to do with how well or badly the mods are coded, and everything to do with player expectations. The player doesn't care about how well or badly something is coded (heck, look at Minecraft's popularity for the real litmus test), only that it does work. My point was that KSP plays VERY well and has a very polished feel for an alpha, and that tends to skew the mindset of the players who have little care for the code behind it all. Unfortunately because of that very polished feel, they also come to expect that things that have been working fine for quite some time will continue to do so across updates, regardless of where the functionality came from. To their minds, there's no difference between the mod or the game; it's all the same thing, and the thing that changed (the game update that broke the mods) is the thing to blame for disrupting their play. They don't get that mods aren't officially vetted by the game devs, and that there's no internal review process to guarantee they'll work as advertised. The see something they like, and if it works before the update, it should just work after as well, no excuses. Sadly that simplistic view is far too common, and For those particular aspects, I thank Apple and what it has become most venomously. As I have a lot of public interaction in the field of technology, I understand their interpretations of how things work, which is why I've been putting so much effort into trying to help others through education and walking through the process of finding a culprit where I can.

While I'm completely with you on this, unfortunately the concept goes way beyond the scope of what most players are able (or in many cases actually willing) to comprehend. Sadly this is just going to be the state of things, and is actually a complement to SQUAD's work that people are so vehemently crying out over perceived bugs and game-breaking issues. From those peoples' viewpoints, this game is already good enough to be considered a finished product in their minds. The other unfortunate aspect is that because it actively supports modding, it tends to engender the mindset that mods being broken by an update is somehow the developers' responsibility to correct, and so results in all the rude backlash, instead of the sensible behavior that some of us would rather see. It never enters some peoples' minds to make a backup and try the new releases as-is to see if it's a "good" update before rampantly copying over all of the changes they've made to the game themselves (through mods and parts packs). The expectation that that will actually work is -while a positive commentary on the solid work that's been done- is pretty much an unfortunate given these days.

Looks like this is getting some attention http://forum.kerbalspaceprogram.com/content.php/179 "We fixed the cfg file loading, so people can use odd resolutions and edit the values outside of game again."

Needs either smaller font, limited characters, auto-scaling in the div for ship names in the Camera script for vessel/mod names. "Jupiter Armored Exploration Vehicle" is overrunning itself in the slideshow.

THAT did the trick. It worked for you because the images were uploaded by your browser in the first place, which causes weirdness sometimes. Just remember that sites like this that use BBCode will more often than not refuse to offer WYSIWYG posting without the tags, once in a while because of shoddy coding, but most often for security and safety. Speaking of which, you might have noticed that the tag isn't working anymore either. Apparently there was an exploit in its code that triggered its removal. Anyway, back on-topic: Man I really wish I could run that dock in orbit. It would make building ships feel so much more... I don't know... grandiose? Especially when it came time to launch. I can just imagine a cupola or two within the construction area, and watching a launch from inside, almost like one of the Spacedock scenes from the Star Trek movies.

Also needs tags because all I can see (without copying the URLs to a new tab) are broken images. /Still looks absolutely badass, wish I had the patience and CPU power to build something like that! I'm all for Utopia Planitia

A suggestion for you to help get around the site opening the .craft files instead of actually downloading them: http://webdesign.about.com/od/php/ht/force_download.htm Of course, I'm assuming you're using PHP, but the core of the technique applies universally. Also may I suggest you set the images for each listing to link to their details pages as well? It's a behavior that a lot of experienced web surfers will have come to expect, and will make the site that much easier for a broader audience to use.

"Let no joyful voice be heard! Let no man look up to the sky with hope! And let this day be cursed by we who ready to wake…the Kraken!"

Well of course, but there are no currently endangered species that immediately evoke the same mental image.

Third-ed. That really is an awesome bit of work there. It's got to be rather interesting to land it nicely.

Check your log guys, especially when you have complex mods like MechJeb installed. At the point things start going weird, hit [ALT]+[F2] and see if you're getting errors that could be accounting for the game becoming "distracted" and generating lag while it tries to deal with the errors. This was a big thing during first few hours of .20's release, when people just started copying over entire mod/ship/save profiles and expecting the lot to just work as if Squad hadn't done any of the big changes to the engine that they'd been talking about long before the release. I promise you, unless you have a crap-tastic 10 year old Celeron or AMD AthlonXP, you shouldn't be experiencing such insane and horrible lag, and indeed that kind of thing is proving to be the exception rather than the rule in this update. There are lots of people here who'd like to help others enjoy this awesome game as much as possible, so if you're having issues that are making it a pain, we'll need more to go on than simple symptoms descriptions. You're going to have to make some effort on your part as well if you're looking for help. ...unless you're just looking to gripe -which everyone's bound to do now and then, of course!

Also a good practice to turn it off before staging if you have wings on your discarded tanks. Took me a few mid-flight "profile deviations" (read: horrible fatal explosions on ascent) to realize that the whatever full deflection the wings were at at the moment of staging, that's what they were stuck on as the tanks left the vehicle, usually guiding the tanks to careen right back into the rest of the ship and blowing everything apart.

Well, this may not be an apt comparison here, but I went looking at related stock components, compared to the one I'm considering trying to "fix". The delta wing has this in its config: // --- general parameters --- name = deltaWing module = Winglet author = C. Jenkins fuelTankSmall has this: // --- general parameters --- name = fuelTankSmall module = Part author = Mrbrownce The B9 HW21 Heavy Wing has this: // --- general parameters --- name = B9_Aero_Wing_HW21 module = Winglet author = bac9 The "module = " lines in particular are what had me believing there's only one type allowed, and that type declaration determines what a part can actually do. So a "part" has general capabilities, but no aerodynamic properties other than drag. A "winglet" has nothing but aerodynamic properties, bringing in deflection drag, lift coefficient etc. I don't suppose it's possible to declare multiple module types in that line, is it?