[1.2.2] Crew Light : An automatic Light manager [1.0] (12 Jan 2017)

[Boomerang]

7 hours ago, Li0n said:

@Boomerang done, available on spacedock.

Thanks so much, I'll test it out!

 

Edit - Works perfectly for me now!

Edited October 26, 2016 by Boomerang

[Li0n]

Version 0.5 is up :

Quote

KSP 1.2.1 recompile
        Add support for all the Wild Blue Industries mods (M.O.L.E. Buffalo, etc...)
        Enhanced support of the passengers cab from USI Karibou
        Enhanced support of the Orca command module from USI Freight Transport Technologies
        New functionality : Toggle Lights action from all crewable parts are no longer automatically put in the "Light" action group. Only applied to newly assembled ship.
        From now on ModuleManager (by @sarbian) is a requirement and is bundled

 

The "New Functionality" remove the light toggle of crewable part from the Light action group so you can easily turn on/off the front lights of your rover without putting yours kerbals in the dark.

The passenger cab and the Orca were lighted when transferring crew but not when switching to an unlighted vessel, now they do.

Hope you enjoy and please report any issue, lights don't turning on, etc...

[fourfa]

Cool mod!

[Li0n]

So after playing on my main save (80+ mods) for some hours with CrewLight everything seems good. But I do have a feature I want to add before launching it on the add-on release section of the forum.

At first I planned to light crewed parts on distant (close range) vessel, after more thinking it don't seem useful because they should already be lightened (unless a player switch them manually off).

But, still thinking of distant vessel and light, why not make the light (on the distant vessel) blink as you approach ? Like a welcoming beacon after years of travel in the dark immensity of space Sound cool right ?

Well I did it and it work but I'm a bit worried about performance as I check every part of the vessel searching for light-able one. I run KSP on an i7 @ 4.5Ghz so no problem for me but still... Here is the culprit :

System.Diagnostics.Stopwatch stopWatch = new System.Diagnostics.Stopwatch();
				stopWatch.Start ();
				List<Part> partWithLight = vessel.Parts.FindAll (p => 
					p.Modules.Contains<ModuleColorChanger> () ||
					p.Modules.Contains<ModuleAnimateGeneric> () ||
					p.Modules.Contains<ModuleLight> () ||
					p.Modules.Contains ("WBILight"));
				stopWatch.Stop ();
				Debug.Log ("[Crew Light] : Time elapsed : " + stopWatch.ElapsedMilliseconds);

I use System.Diagnostics.Stopwatch to measure the time it takes but it return 0 even with a 300+ part vessel. Do I misuse Stopwatch or is this a less intensive action than it looks ?

@Nereid said earlier in this thread that it was a bad idea to check for every part in a vessel but no strange physic stuff happened to me so far...

If you want to try by yourself you can find it on GitHub (click on "Clone or download").
I've upload a save with 2 scenario to test : a huge ship at the runaway with a rover near by and a huge ship (the same) at LKO with a little probe on a rendez-vous orbit.
The blinking thing happens when you are at 200m of the target, please report any strange behavior at this point (crash, freeze, whatever...) and send me your log, or just the line "[Crew Light] : Checking all the part on vessel name takes XXX".
If you want to test on one of your personal save please do a backup.

I'd really appreciate any advice or feedback on all this.

[Nereid]

On 9.11.2016 at 6:54 PM, Li0n said:

 

@Nereid said earlier in this thread that it was a bad idea to check for every part in a vessel but no strange physic stuff happened to me so far...

Question is: How often do you check all vessel parts? Every few seconds? That doesn't matter. Several times a second? Well then it depends what your are scanning (even PartModules?)... and if there is not a larger vessel around (a lot more than 200 parts), it does nothing of harm. But I got reports from people with larger SSTO spaceplanes that were not able to get them into orbit anymore a while ago as NG had done similar things. I have checked this (in KSP 0.90 if I remember it correctly) with some of their saves and they were right (the SSTOs and their engines just behaved differently for some reasons). Polling every part multiple times a second is a bad idea anyway from an architectural point of view - it just do waste CPU and there ist just no need to do it.

But there is a simple solution: Build a class that does the scanning once, add all parts of interest in a list. If the vessel change or gets modified, scan again - once. In between just scan the few parts you are interrested in. There is no need to iterate over all parts over and over again just to check if they can hold any crew - most of them can't. Scanning ten or less parts and its PartModules even 100 times a second is negligible.

A better approach would be some kind of listen/notify paradigma. But I don't think there is any for property changes on part level in KSP.

List<Part> partWithLight = vessel.Parts.FindAll (p => 
					p.Modules.Contains<ModuleColorChanger> () ||
					p.Modules.Contains<ModuleAnimateGeneric> () ||
					p.Modules.Contains<ModuleLight> () ||
					p.Modules.Contains ("WBILight"));

If this takes 0ms and you don't do it 100 times a second, it doesn't matter. StopWatch is used correctly. But I would suggest to accumulate the used time of the whole flight and calculate an average.

Edited November 11, 2016 by Nereid

[Crzyrndm]

I don't think you can get much better than you already have. It only runs a single search when a vessel loads into physics range, it filters those parts down to the lightable ones, and then runs only four times over the lightable parts  at your blink rate. If you have to further decrease this, you could delay the search until after the vessel is physics enabled (ie. wait 0.1 at the start) and/or enumerate only a set number of parts per vessel per frame

Otherwise if anything is going to be hitting performance harder than it needs to be, it'll be the debug logging 

[Li0n]

20 hours ago, Nereid said:

But there is a simple solution: Build a class that does the scanning once, add all parts of interest in a list. If the vessel change or gets modified, scan again - once. In between just scan the few parts you are interrested in. There is no need to iterate over all parts over and over again just to check if they can hold any crew - most of them can't. Scanning ten or less parts and its PartModules even 100 times a second is negligible.

I scan only once when onVesselGoOffRails is triggered, not sure your solution is needed for this case, it maybe end up doing more scanning than my current method.

@Crzyrndm enumerate a set number of part per frame sounds like a good safety measure, 200 should be good ? Can I ask you why searching through the part is quicker after the physics is enabled ?

[Nereid]

31 minutes ago, Li0n said:

I scan only once when onVesselGoOffRails is triggered, not sure your solution is needed for this case, it maybe end up doing more scanning than my current method.

If this is the case there is nothing to worry about. I was thinking you are using Update() to do the scans.

[Crzyrndm]

2 hours ago, Li0n said:

Can I ask you why searching through the part is quicker after the physics is enabled ?

Not quicker, just not coinciding with other tasks (ie. stuff has to run when something becomes physics enabled). Just another way of spreading the load over a larger time slice. In this case I really wouldn't bother (it's a single pass loop doing very little work), I just included it for completeness

Edited November 11, 2016 by Crzyrndm

[Li0n]

@Nereid, @Crzyrndm thanks for your answers. It reassure me to know I won't screw others people game

[wasml]

Installed this mod and it's working well. Makes it much easier to locate crew on a large vessel. Thanks for sharing this.

[Li0n]

@wasml you're welcome. A very useful mod to find crew member is Portrait Stats, when you hover over the portrait of a kerbal the part is in gets highlighted, it also provide a transfer button for each kerbal.

[Li0n]

v0.6 The MORSE edition

As mentioned earlier I wanted distant vessel to blinks theirs lights as you approach them, I take it a step further : they now send you a Morse message when you come close

This is fully adjustable, you can change the message, the distance at which it begins and the duration of the "dit" and "dah". More info in the OP.

Others changes include an option to disabled the removal of crewable part from the Light action group and a few improvement to code readability (still need some more...).

 

You can grab it on SpaceDock or on GitHub (delete the old CrewLight folder before updating)

As always please report any issues/bugs or suggestions

[JeffreyCor]

There is no settings file as indicated. Does the settings file get created when first run, or did it get missed?

[Li0n]

3 minutes ago, JeffreyCor said:

There is no settings file as indicated. Does the settings file get created when first run, or did it get missed?

The game needs to run once for the settings file to be created.

[RealGecko]

Hey, man! Does your mod turns on lights when ship dives into darkness of celestial body shade?

[Li0n]

11 minutes ago, RealGecko said:

Hey, man! Does your mod turns on lights when ship dives into darkness of celestial body shade?

Nope. Lights of crewed part are on until there is no more crew in it (Kerbal are afraid of dark, no matter if the sun shine or not ) and I don't touch others lights (on the active vessel).

Good idea tho, not sure if there is a stock event that I can use to check if the sun is shining on the craft but I'll look into it.

Edited November 30, 2016 by Li0n

[RealGecko]

2 minutes ago, Li0n said:

Good idea tho

I have this idea for some time, but I'm too lazy to develop YAKSPP (Yet Another KSP Plugin)

[wasml]

11 hours ago, Li0n said:

not sure if there is a stock event that I can use to check if the sun is shining on the craft

Would you be able to hijack the solar panel module for this? OK - maybe a bit of a kludge but....

Edit: On second thought if the transform was facing the wrong direction you could get a false negative.

Edited December 1, 2016 by wasml

[Li0n]

8 hours ago, wasml said:

Would you be able to hijack the solar panel module for this? OK - maybe a bit of a kludge but....

Edit: On second thought if the transform was facing the wrong direction you could get a false negative.

That was my first though when @RealGecko voices the idea, I'd take a look at ModuleDeployableSolarPanel and I think I can use the field "hit" (return the last RayCast from the panel) or the method "CalculateTrackingLOS()". Does "LOS" stand for "Lose Of Sight" ?

For the false negative relative to the transform direction, maybe just create the solar panel as a spherical one (panelType = panelType.SPHERICAL) ?

Here is a link to the ModuleDeployableSolarPanel, if you find any other ideas

[RealGecko]

1 minute ago, Li0n said:

return the last RayCast from the panel

I think you can simply raycast from ships position to Sun position every N seconds and if something is on the way, then turn on lights.

[Li0n]

Just now, RealGecko said:

I think you can simply raycast from ships position to Sun position every N seconds and if something is on the way, then turn on lights.

Why do things simple ?

Is there some sort of layers I can use when raycasting so the ray don't get stop by the ship ? Sorry for the probably dumb question, I never use raycast.

[RealGecko]

Just now, Li0n said:

I never use raycast.

I never did either . But after googling for 30 secs I got this. It says:

Notes: Raycasts will not detect Colliders for which the Raycast origin is inside the Collider.

And there's also this, with

abstract bool 	Raycast (Vector3d source, Vector3d dest)

That

Does the raycast from source to dest hit the occluder? NOTE: all positions in worldspace. Requires occluder position (and any other members) to be up-to-date.

And also something inside Remote Tech sources.

I think analysing RT sources may help a lot

[Li0n]

@RealGecko thanks for those links. I didn't think about Remote Tech nor the stock Commnet but they obvously deal with occlusion / raycasting. I'll take a look at that.

[Skalou]

Hi LiOn,

 I would like my mode to be compatible with yours, but it doesn't work as it,

ii adds an other model with a ModuleAnimateGeneric tweaking it's own emissive,

the .cfg:

Spoiler

//MK1CabinHatch.cfg
@PART[MK1CrewCabin]
{
@noAutoEVAMulti = False //noAutoEVAAny disables auto EVA always, whereas noAutoEVAMulti allows it if there is only one part on the vessel.
    MODEL
    {
           model = MK1CabinHatch/MK1CabinHatchMDL
        texture = Mk1Cockpit, Squad/Parts/Command/mk1Cockpits/Mk1Cockpit
        texture = GLOW, Squad/Parts/Command/mk1Cockpits/GLOW
    }
    
    MODULE
    {
        name = ModuleAnimateGeneric
        animationName = Emissive
        defaultActionGroup = Light
        actionGUIName = Toggle Lights Hatch
        startEventGUIName = Lights Hatch On
        endEventGUIName = Lights Hatch Off
        layer = 1
    }
    
    MODULE
    {
        name = ModuleAnimateGeneric
        animationName = AirlockAnim
        //actionAvailable = false
        //animSwitch = false
        eventAvailableEditor = true
        eventAvailableFlight = false
        eventAvailableEVA = false
        //instantAnimInEditor = true
        startEventGUIName = Add Top Hatch
        endEventGUIName = Remove Top Hatch
        actionGUIName = Toggle Top Hatch
        //allowManualControl = false
        showStatus = false
        layer = 2
    }
}

 

Only the stock lights are working, not the one in the hatch:

what can i do/change for it to works?

thank's