[1.3.1] Aviation Lights v3.14 [use MOARdV's version instead!]

[Deadweasel]

Nope, no joy. They seem to be permanently bugged now.

Time to go rummaging and pull mods one by one until I find the culprit.

[BigNose]

Nope, no joy. They seem to be permanently bugged now.

Time to go rummaging and pull mods one by one until I find the culprit.

I'm sorry to say that I have no clue what happened there. I have multiple complex ships in different orbits around multiple planets by now, including space stations. The stations consist of multiple modules which were docked together while the lights on both sides were active and out of sync, still I never ran into this problem.

Even after this and launching more than two dozen flights, the lights on my first orbiters work as usual, as I just rechecked to make sure.

My game is also running several mods by now, listed here:

AviationLights (obviously)

CrewManifest

FerramAerospaceResearch

FixedCamera

InternationalFlags

ISA_MapSat

KerbalLiveFeed

Kethane

MechJeb2

Mk3ExtensionPack

Mk3Internals

Mk4FuselageSystem

ModularMultiwheels

RemoteTech

(all in the most recent version at this time)

Added alot of PART{*stuff*} in the config files to make them all 'GameData' compatible, as I didn't want to put them in the old Parts/Plugins folders. Nothing else.

No problems whatsoever, every mod works like a charm.

[Deadweasel]

I'm sorry to say that I have no clue what happened there. I have multiple complex ships in different orbits around multiple planets by now, including space stations. The stations consist of multiple modules which were docked together while the lights on both sides were active and out of sync, still I never ran into this problem.

Even after this and launching more than two dozen flights, the lights on my first orbiters work as usual, as I just rechecked to make sure.

My game is also running several mods by now, listed here:

AviationLights (obviously)

CrewManifest

FerramAerospaceResearch

FixedCamera

InternationalFlags

ISA_MapSat

KerbalLiveFeed

Kethane

MechJeb2

Mk3ExtensionPack

Mk3Internals

Mk4FuselageSystem

ModularMultiwheels

RemoteTech

(all in the most recent version at this time)

Added alot of PART{*stuff*} in the config files to make them all 'GameData' compatible, as I didn't want to put them in the old Parts/Plugins folders. Nothing else.

No problems whatsoever, every mod works like a charm.

Well nuts. :/

I'm running a few of the same mods as you, including:

• CrewManifest
  
• ModularMultiWheels
  
• Quantum Struts
  
• Protractor
  
• SubAssemblyLoader
  
• ActionsOnTheFly
  
• AviationLights (natch!)
  
• and, like you, a whole grip of parts like KW Rocketry and B9 Aerospace
  

Digging around, I did discover a redundant, probably out-of-date quantumstruts.dll in the legacy Plugins folder, so I'm going to dive back into the game in a bit to see if that might have been the cause.

EDIT:

No joy. There's apparently another plugin somewhere that's messing with this, but there are no conflicts showing in the logs. This is going to take some time, looks like. :/

Edited May 27, 2013 by Deadweasel

[Deadweasel]

Okay, still disabling plugins and playing around to find anything that messes with it, and I did find something interesting:

If I set the KSP.exe process to an affinity for just one core of my quad-core CPU, the rampant flashing actually slows down. Something in the way either the game or the AviationLights plugin is apparently affected by processing availability, which is confusing, because isn't the AV plugin attached to a timer in KSP? Why would having a core affinity affect the flash rate? Is there something else it hooks into that I can take a closer look at amongst other system processes?

[BigNose]

Okay, still disabling plugins and playing around to find anything that messes with it, and I did find something interesting:

If I set the KSP.exe process to an affinity for just one core of my quad-core CPU, the rampant flashing actually slows down. Something in the way either the game or the AviationLights plugin is apparently affected by processing availability, which is confusing, because isn't the AV plugin attached to a timer in KSP? Why would having a core affinity affect the flash rate? Is there something else it hooks into that I can take a closer look at amongst other system processes?

That indeed is really interesting.

The timer of the lights measures all intervals based on the ingame UniversalTime value.

To my knowledge the Unity3D engine doesn't support Multithreading, so I doubt it ever used more than one core before you changed your setting, according to this thread: http://forum.kerbalspaceprogram.com/showthread.php/25508-The-Future-of-KSP-and-Unity3D?highlight=multithreading

To this point I do not even understand why the interval timer fails in your case, as it does nothing else as requesting the UniversalTime value and checking if more time passed then what is given by the values in the .cfg file.

It just checks and waits until this condition is ture and starts another flash cycle, which is in turn again defined by the .cfg file.

Some part of this seems to go nuts after you launched too many flights, but I've no idea why. Also I can't seem to reproduce this bug as much as I try (for the last 3 hours).

Edited May 28, 2013 by BigNose

[GeorgeT93]

I'm seeing the return of the "old" bug where the flashing mode would go spastic instead, like a crack-riddled strobe light. They flash incredibly fast for a moment, seize up for a second or two, flash madly again, seize up, rinse and repeat.

...

I'm experiencing the same thing. My first flight, everything worked great, and every subsequent flight I've had issues with the flashing mode where it will flash very rapidly for a few seconds, then it stops flashing for a couple of seconds, then the cycle repeats. I'm experiencing this behavior on both my laptop and my main pc. For the time being, I've stopped using the flashing modes and just turn the lights on or off.

Installed Mods:

MechJeb 2.0.8

Aviation Lights

some FusTek Parts (Karmony, MUNOX, Common Berthing set)

ISA MapSat x4r1

Anyhow, I just wanted to post as I'm also having the same issue as Deadweasel, and wanted to confirm that he's not the only one experiencing this odd behavior. I'll be keeping my fingers crossed that if it's happening to more folks, that they'll post too, so we can try and find out if it's a problem with the lights themselves, or just a conflict with another mod. I'll be honest though, even without the flashing capability working right for me, I still have to use these lights (just in solid "on" or "off" mode) because, well because they're so darn cool!

Thanks!

-George

[BigNose]

This is kind of concerning, as I

a) Can't reproduce the bug, and

I can't imagine how this can happen codewise.

I'm really moving on thin ice here, but maybe it's a problem within the engine. A plugin that works for a few launches and then suddenly goes crazy is really odd.

Edited May 29, 2013 by BigNose

[GeorgeT93]

The ONLY thing I can think of, though it doesn't make sense to me, is maybe it's related to either symmetry or action groups. I know the first ship I built using the new aviation lights (after 0.20), the lights worked perfectly. On that ship, I placed each light individually, and didn't bother to set up action groups for the lights. Even now, if I switch back to that particular satellite, the lights seem to stay flashing normally. All the other craft I have launched since (about 4-5 launches), have had the lights put on using symmetry mode, and had their "flash" turned on via action group. I doubt this has anything to do with the issue at all, but thought I'd mention it just in case. When I get a chance, I'll throw together a quick rocket, and launch 1 with lights individually placed (versus using symmetry mode), and I won't assign any action groups. Then I'll launch the same rocket a second time, but this time I'll use symmetry mode and still won't use action groups. Then for the third launch, I'll try with symmetry and action groups assigned, and then I'll see if there's any correlation between any of the combinations of symmetry and action groups, and the odd flashing behavior. I'll post back my findings later on after I've had a chance to test.

Off-topic: Do you have any plans to release any other lighting packs? I'd personally love to see some neon lights that we could stick on our ships (obviously, just for "cool factor" lol.) I'm thinking they would be like the same length as say the 1x1 steel sheet, and in two widths, really thin, and moderately thick. So the thin one would be like:

|L|

|I|

|G|

|H|

|T|

and the thick one would be something like

| L |

| I |

| G |

| H |

| T |

and the could be available in, well pretty much any color. Anyhow, just a thought.

Back on topic:

Thanks again for this light pack, and again, I'll report anything odd after I test my ships to see if symmetry and/or action groups have anything (or nothing) to do with the odd flashing intervals.

-George

Edited May 29, 2013 by GeorgeT93
Tried to give a better representation of the neon lights idea, I didn't realize whitespace would be removed! :P

[Deadweasel]

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.

[Deadweasel]

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.

[BigNose]

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.

Interesting idea, but I think they have much bigger fishes to fry.

Regarding the flash mode problem, I'm interested in the results of GeorgeT93's experiment. Maybe he finds something we overlooked.

[Deadweasel]

Interesting idea, but I think they have much bigger fishes to fry.

Regarding the flash mode problem, I'm interested in the results of GeorgeT93's experiment. Maybe he finds something we overlooked.

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.

[Talisar]

]Strobes do the crackhead flash dance, regardless of symmetry placement mode

This made me laugh so hard I had to walk away from the keyboard for a minute

[Deadweasel]

This made me laugh so hard I had to walk away from the keyboard for a minute

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

[GeorgeT93]

Well I just finished testing, and unfortunately can add nothing further beyond what Deadweasel has already stated. I started a clean install with only the lights added, and regardless of configuration, they worked fine. I then added ISA MapSat and MechJeb (one at a time), and retried all the tests. No matter what I did, the lights worked correctly. Finally, I loaded up my original save game (in my original install, and again in the new "fresh" install), and the flashing for a while very quickly, then no flashing for a bit, then a return to the fast flashing was back. I then moved the .craft file with the lights that were bugging out into the fresh install, then loaded it up in the VAB and launched. The lights worked perfectly.

So like Deadweasel has stated, with my original save file (I started over completely when 0.20 released), the lights don't work properly. In the new save, loading the exact same .craft, the lights worked perfectly. So I'm really at a loss as to the cause. Sorry I couldn't provide more information.

Tests were done using individual placement, symmetrical placement, and symmetrical placement with Action Group toggles. Tests were then repeated with ISA MapSat installed, with the dish added to each craft before launch. I then completed the tests a third time, this time with ISA and MechJeb both installed, and with the dish and control box added to each craft prior to launch. Results were the same across the board, all light modes seem to work fine in the new savegame that I started today for testing, but they don't work using my old savegame that has an unmanned rover on the Mun, a mapping satellite that has been landed on Minmus, a mapping satellite that has landed on Eve (thanks to parachutes), and random debris from each of those missions, plus debris from a number of missions that were not successful at all lol.

[Deadweasel]

Well I just finished testing, and unfortunately can add nothing further beyond what Deadweasel has already stated. I started a clean install with only the lights added, and regardless of configuration, they worked fine. I then added ISA MapSat and MechJeb (one at a time), and retried all the tests. No matter what I did, the lights worked correctly. Finally, I loaded up my original save game (in my original install, and again in the new "fresh" install), and the flashing for a while very quickly, then no flashing for a bit, then a return to the fast flashing was back. I then moved the .craft file with the lights that were bugging out into the fresh install, then loaded it up in the VAB and launched. The lights worked perfectly.

So like Deadweasel has stated, with my original save file (I started over completely when 0.20 released), the lights don't work properly. In the new save, loading the exact same .craft, the lights worked perfectly. So I'm really at a loss as to the cause. Sorry I couldn't provide more information.

Tests were done using individual placement, symmetrical placement, and symmetrical placement with Action Group toggles. Tests were then repeated with ISA MapSat installed, with the dish added to each craft before launch. I then completed the tests a third time, this time with ISA and MechJeb both installed, and with the dish and control box added to each craft prior to launch. Results were the same across the board, all light modes seem to work fine in the new savegame that I started today for testing, but they don't work using my old savegame that has an unmanned rover on the Mun, a mapping satellite that has been landed on Minmus, a mapping satellite that has landed on Eve (thanks to parachutes), and random debris from each of those missions, plus debris from a number of missions that were not successful at all lol.

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.

[Deadweasel]

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.

Edited May 29, 2013 by Deadweasel

[Deadweasel]

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?

[BigNose]

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.

DUDE!! Awesome find!

I'll look into this real quick. The 65,535 indicates the variable occupies only 2 bytes. This could be it.

[BigNose]

Ok, Planetarium.GetUniversalTime() delivers a 'double' value, which the plugin transforms into a 'float' value and therefore looses bytes. That's the problem, I update real quick!

[Deadweasel]

Ok, Planetarium.GetUniversalTime() delivers a 'double' value, which the plugin transforms into a 'float' value and therefore looses bytes. That's the problem, I update real quick!

WOOHOO!

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

[BigNose]

V3.2 Released

Thanks to the great find of Forum user 'Deadweasel', a bugfix was possible:

CHANGELOG

Fixed

- Flash/Interval timer failed due to overflow if UniversalTime gets too big

DOWNLOAD

Get it on SpacePort or from Mediafire!

Edited May 30, 2013 by BigNose

[GeorgeT93]

Awesome news!! Great job Deadweasel and BigNose! I was just returning here to deliver results of further testing, but I guess that shouldn't be needed now that you guys already figured it out!

Downloading and updating now!

[GeorgeT93]

Installed, loaded up the last save where I was able to force the lights to freak out (for me it was right after T+: 400 days). Well the crazy flashing is gone! Thanks for such a quick fix, it's working great now.

[BigNose]

Installed, loaded up the last save where I was able to force the lights to freak out (for me it was right after T+: 400 days). Well the crazy flashing is gone! Thanks for such a quick fix, it's working great now.

Glad to hear that, now there shouldn't be a problem with the flash timer overflowing any time soon. (Well, maybe after a few million ingame years )