(Drop Support)[1.6.1] Crew Light : An Automatic Light Manager [v1.19] (29 Jan 2019)

[Archan79]

I have founded some bug. When I Turn on Motion Detector on part (Surface Mounted Light) all controls freeze. I can rotate camera or show up rmb menu, but nothing works. I can't add/rotate etc new parts, I can't use any rmb menu controls, even leave VAB or launch vehicles. And I cant give log because only way to leave game is to kill it. I have try twice.

 

Update. I have tryed also make it MANUALLY on Launchpad. It doesnt work. In this case from eva i can walk around and nothing happends (set motion detector to ON and range to 8 meters). After returning to VAB, Game Again freezed the same way like before.

I use KIS/KAS, SURFACE MOUNTED LIGHT, and play on 64bit version. Also CHOP SHOP, MECHJEB2 (Dev build 762), WAypont MAnager, [x]Science, And Kerbal Reusability Expansion (Firespitter included, CCK, CRP).

FIXED

Something was meesed up with unpacking archive. Mising files inside. After reinstaling mod everything was back to normal

Edited March 11, 2018 by Archan79
Update

[Li0n]

9 hours ago, Archan79 said:

I have founded some bug.

[...]

FIXED

Those are my favorite bugs reports

Seriously, glad to hear you manage to got everything on tracks. And welcome to the forum

[Bob Jub]

Oh wow, this looks awesome!

[Li0n]

Crew Light v1.13 is up on GitHub, and SpaceDock as soon as the 1.4.1 tag is available

Quote

* fix EVA light not turning on when the Kerbal is already on EVA when loading
* recompile for KSP 1.4.1
* remove workaround for the MK1-2 pod, no longer necessary
* bundle ModuleManager 3.0.5

It also works good on the extension.

Enjoy

[Li0n]

Crew Light v1.14 is up on GitHub, and SpaceDock as soon as the 1.4.2 tag is available

Quote

* recompile for KSP 1.4.2
* bundle ModuleManager 3.0.6

Enjoy

[Burning Kan]

Thanks @Li0n

can i ask for a future ec consumsion when the lights on?

tryed the mm-patch for this but worked only for jetcapsules-cabines

maybe its not to hard to implement it

again thx 4 this nice little must have mod

// Add electric resource consumption to cockpit lights
// Author: Alshain

@PART[Mark1Cockpit] 
{
	@MODULE[ModuleAnimateGeneric]
	{
		@name = ModuleLight
		%useAnimationDim = true
		%lightBrightenSpeed = 2.5
		%lightDimSpeed = 2.5
		%resourceAmount = 0.01
		%useResources = true
	}
}

 

[Li0n]

11 hours ago, Burning Kan said:

can i ask for a future ec consumsion when the lights on?

Nope, for two reason :

• ec consumption change the gameplay/balance, I don't want Crew Light to do so
• there's already a mod that do it :
   
  (scroll down to Electric Light)

Edited April 3, 2018 by Li0n

[Burning Kan]

@Li0n thx  for the hint

i dont know it even exist

Thank you a lot sir

 

 

[Li0n]

Crew Light v1.15 is up on GitHub, SpaceDock and CKAN soon

Quote

* recompile for KSP 1.4.3

 

[Beetlecat]

Fantastic. Thank you for maintaining this-- and keeping the lights on for us!

[Lisias]

I have a suggestion/request :-)

What about a part that should be attached to the vessel to allow the automatic control? In some of my vessels, I want the Crew Light controlling everything. In others, I don't - I want a somewhat finer graining control instead of throwing everything on the "U" button.

I'm using AGEx, for example, and I can change the active "Control Group" to cope with the vessel's attitude (a key can do something when parked, another when flying and a third on landing, for example), and then Crew Lights bites me.

Wth that part, one can customize what should be done and when - without the part, default behaviour to keep things compatible. If you attach the part, you configure it to do what you want. Being compatible with AGEx would make things even more convenient (but it's not necessarily a functional requirement - just a "nice to have").

[Beetlecat]

7 minutes ago, Lisias said:

I have a suggestion/request :-)

What about a part that should be attached to the vessel to allow the automatic control? In some of my vessels, I want the Crew Light controlling everything. In others, I don't - I want a somewhat finer graining control instead of throwing everything on the "U" button.

I'm using AGEx, for example, and I can change the active "Control Group" to cope with the vessel's attitude (a key can do something when parked, another when flying and a third on landing, for example), and then Crew Lights bites me.

Wth that part, one can customize what should be done and when - without the part, default behaviour to keep things compatible. If you attach the part, you configure it to do what you want. Being compatible with AGEx would make things even more convenient (but it's not necessarily a functional requirement - just a "nice to have").

Another approach to that could be an on/off/auto(crew lights managed) switch for lights in general, but crew cabin lights particularly?

[Lisias]

1 hour ago, Beetlecat said:

Another approach to that could be an on/off/auto(crew lights managed) switch for lights in general, but crew cabin lights particularly?

That will do, but it would create another "hardlock". 

Crew Light already manages on/off events for three useful situations: first crew in/last crew out ; sun in/sun out; engines on/engine off (for the strobes). If one could "program" what should be do on that new part (something as a LightJeb), you will have a powerful, automatic and simple solution for a lot of things (as deploying/stowing solar panels).

The "hard" part is already done. The boring part is to do a user interface for the thing.

[Li0n]

@Lisias & @Beetlecat thanks for the suggestion.

As for the UI something like this should do :

       | CabinLight  |   SunLight     | EngineLight | ...
---------------------------------------------------------
Landed | on/off/auto |	on/off/auto	  |	on/off/auto |
Flying | on/off/auto |	on/off/auto	  |	on/off/auto |
Orbit  | on/off/auto |	on/off/auto	  |	on/off/auto |
...

A way to add/remove light from the Light action group will be necessary too (for the sunLight), add a button to the right-click menu on light, but only visible when the "main" UI is up so it don't clutter the menu.

Maybe a system of preset for the option, so you don't need to re-do it for each similar flight.

On how to bring the UI I see three solution :

• add a button to the right click menu of lights/cabin (easy to do but I don't like to clutter those menu if I can avoid it)
• add a button to the toolbar
• add a part just for it (that's a nice solution, if someone don't want the extra feature the UI bring just don't use the part, but it involve making a new part...)

Unless someone is willing to make me a light controller part I'll go with the toolbar button.

 

Now the not cool part : I don't have the time to do it, at least not in the foreseeable future. I'll make a GitHub issue to keep track of it and if you have more suggestion please share but don't expect to see it in game anytime soon. As free-time goes my priority is to Antenna Helper which need (another) big rewrite. (plus I'm busy being a knight lately ).

 

[Lisias]

The part option, IMHO, is the way to go. And it can be done in a way that would allow "third party" parts to receive orders from Crew Light - and then I can build "my" part later. This sounds doable?

[Li0n]

2 hours ago, Lisias said:

The part option, IMHO, is the way to go. And it can be done in a way that would allow "third party" parts to receive orders from Crew Light - and then I can build "my" part later. This sounds doable?

Not sure what you mean, what do you referring to by "third party parts" ? Lights/cabin from mods ? This is already covered.

[Lisias]

1 hour ago, Li0n said:

Not sure what you mean, what do you referring to by "third party parts" ? Lights/cabin from mods ? This is already covered.

Nope. A mod that consumes your mod's events to do their our business. By example, a Mod that uses AGX buttons to do the actions.

Essentially, CrewLight would provide an Interface where the event handlers are called. On Startup (and on the vessel changed event), the core will traverse the vessel parts enumerating everything that realizes its interface, feeding them on a list.

When your mod detects a event, it call the handler on every known part that realizes your interface.

"Your" part will implement the current behaviour with tweakables (default being the current behaviour).

In the case the core doesn't find anything, it instantiates internally your part - and then everything will work as always did.

This will allow, for example, that a space plane with its own custom part, when docking on a space station without crewligh parts (and so, using the legacy behaviour), would have its own rules executed instead of the space's ones.

Edited May 4, 2018 by Lisias
better explaining the idea

[Li0n]

3 hours ago, Lisias said:

Nope. A mod that consumes your mod's events to do their our business. By example, a Mod that uses AGX buttons to do the actions.

Essentially, CrewLight would provide an Interface where the event handlers are called. On Startup (and on the vessel changed event), the core will traverse the vessel parts enumerating everything that realizes its interface, feeding them on a list.

When your mod detects a event, it call the handler on every known part that realizes your interface.

"Your" part will implement the current behaviour with tweakables (default being the current behaviour).

In the case the core doesn't find anything, it instantiates internally your part - and then everything will work as always did.

Got it.

I think it's doable. I need to think more about it. But again don't expect it to happen anytime soon.

3 hours ago, Lisias said:

This will allow, for example, that a space plane with its own custom part, when docking on a space station without crewligh parts (and so, using the legacy behaviour), would have its own rules executed instead of the space's ones.

When in docked position ? That's more trouble, for KSP at this point there is only one vessel so in order to keep the two behavior I need to store which lights belongs to which ship. It's doable but I probably need to change the "base logic" of CrewLight, as of now the list of lights is cleared and re-populated when a docking happens.

[Lisias]

3 hours ago, Li0n said:

When in docked position ? That's more trouble, for KSP at this point there is only one vessel so in order to keep the two behavior I need to store which lights belongs to which ship. It's doable but I probably need to change the "base logic" of CrewLight, as of now the list of lights is cleared and re-populated when a docking happens.

That's the nice part. That part of the logic belongs to the part.

The present crew logic goes to your default part. People who wants another behaviour, creates a new part and use it instead of yours.

[Beetlecat]

1 hour ago, Lisias said:

That's the nice part. That part of the logic belongs to the part.

The present crew logic goes to your default part. People who wants another behaviour, creates a new part and use it instead of yours.

I think what Li0n was getting at is that if you have a craft with the "crew light component part" and dock it to anything, then that takes over everything it's docked to. light a virus.

[Lisias]

36 minutes ago, Beetlecat said:

I think what Li0n was getting at is that if you have a craft with the "crew light component part" and dock it to anything, then that takes over everything it's docked to. light a virus.

Yep. I understood. :-)

But this is a problem to be cracked by the "third party" (me, in the case), not by him. ;-)  [NO!!]

You both are right!  One 'light part" must communicate to the other the parts it's controlling, to avoid collisions. Besides the callback methods for the event, the interface must provide a "don't touch this parts" method too.

Edited May 4, 2018 by Lisias

[JH4C]

Just started fiddling with this mod as I do love my lights and having some of them automated will save me remembering to set up action groups for them.

Small thoughts regarding the Morse Code implementation:

1. When describing how to encode characters, you talk about "ti" and "taah", yet when you set the duration for the signal flashes you refer to them as "dit" and "dah". The latter is much more conventional, but consistency between both methods would be great for newbies regardless of which convention you settle upon.
2. Common written convention also uses spaces between letters, slashes between words, which is the reverse of your chosen notation. Anyone using an online translator would get skewed results, and/or have to edit the output to match add-on requirements; I realise this app's been in the wild for a long time now so any change here might cause as many problems as it solves, but thought it worth mentioning.
3. It would be nice if there was some way to encode a per-vessel ID code, so that the greeting imparted not just "hey, I see you" but also "you've reached (vessel X)". Probably way too difficult to add this compared to the pay-off...

Thanks for a lovely little mod that adds some extra flavour to the game 

[Lisias]

Hi.

I  submitted a pull request with some of the changes proposed by JH4C. Please revise!

The 3rd item is still RiP (Research in Progress). We would need to create a new attribute for this, stored on the Vessel file - storing this on that proposed part would be the best solution.

Edited May 7, 2018 by Lisias
typos again

[Li0n]

On 5/7/2018 at 2:21 AM, JH4C said:

When describing how to encode characters, you talk about "ti" and "taah", yet when you set the duration for the signal flashes you refer to them as "dit" and "dah". The latter is much more conventional, but consistency between both methods would be great for newbies regardless of which convention you settle upon.

"ti" and "taah" are the french convention (I'm french). You're right I'll change it to be more consistent.

On 5/7/2018 at 2:21 AM, JH4C said:

It would be nice if there was some way to encode a per-vessel ID code, so that the greeting imparted not just "hey, I see you" but also "you've reached (vessel X)". Probably way too difficult to add this compared to the pay-off...

I like the idea but my concern with it is about the time it take to send a morse message. The default message ("KSP") is already 27.7 seconds long, IMO anything longer will get boring. If you want to play with the timing settings and find something quick enough but still readable that will be awesome

Following this idea : what about a list of random, short, message. Something like : "Welcome", "Copy", "Roger", "Busy Signal", "ALIEN SPIDER !!"... etc. It will add some variety and I'll make sure to not include something that make the light blink for half an hour (I don't want to finish my docking manoveur before the message has ended...)

 

On 5/7/2018 at 11:34 AM, Lisias said:

Hi.

I  submitted a pull request with some of the changes proposed by JH4C. Please revise!

The 3rd item is still RiP (Research in Progress). We would need to create a new attribute for this, stored on the Vessel file - storing this on that proposed part would be the best solution.

Thanks a lot

I don't know when I'll have time to review it, probable not before next week.

[Lisias]

21 minutes ago, Li0n said:

Thanks a lot

I don't know when I'll have time to review it, probable not before next week.

Welcome. :-) Take your time, and please don't hesitate in asking for any changes you need - including code style and whitespacing (I think I messed up the tabs vs spaces, I will check it on my next time window).

Edited May 9, 2018 by Lisias
eternal typos of the englishless mind.