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.

This feature is already implemented on PartWizard: Posting in this old thread since it was the very first one that I found on my search. Since I found my answer elsewhere, I'm posting it here in the hope to being of use when someone reaches here as I did.

"Closed/Fixed". Thanks!

I just downloaded the file linked, but while installing I found no "Pathfinder" subdir in the zip's GameData/WildBlueIndustries. Just the auxiliary ones. Is this correct?

There's an automated or easier way to apply the changes on a pre-existant vessel? I'm building a somewhat big one, and it will be somewhat cumbersome to reconfigure all that parts...

My FPS enhanced a bit, but my KSP is being killed by a Unity bug that happens on high memory load. So, I have the feeling (but I don't have any actual information about) that the guys trimmed the GC (or something like that) to favor normal gaming, and crazy "mods gallore" like us are taking the bad side of the situation. Check the GC. The sad true is that most mods are written without caring about GC-friendly coding style.

Kerbin? Which Kerbin? =P

If you are on Steam, you can download the depot for any published version. See more about it here.

How about replacing the eye's texture for a transparent one?

I NAILED THE CULPRIT. And the problem is Unity (as usual). There's a issue on Unity when running on Macs with multiple monitors (exact my case). Not a well known issue, but it's old - I found reports dating since Unity 5.4.5. Since the problem is somewhat related to memory consumption, I'm guessing that using multiple monitors demands multiple framebuffers (obviously), and someone, somewhere inside Unity is not asking correctly about how much memory it can use from there (assuming a single monitor setup).

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.

By the same reason we add more resources to be harvested, then processed, then finally used on something (as oxygen on TAC-LS). Too add a bit of "realism", and force me to add R&R and Sleeping areas to my vessels using some kind of constraint, and not only my mood on the time. How many sleeping areas I would need? What would be the ideal common R&R dedicated area? How the mission length would affect these issues? In the first Apollo mission to touch the Moon, the guys just sit on the ground for sleeping (where they could), took some sleeping pills to withhold some sleep on all that mess, and that's it. It worked fine, but they spent just some days on the Moon. Now try to figure out what wold happen on a 10 days on Moon? 30?

Uh... We gone offtopic. Would be better to create a new thread to keep the discussion, without polluting the CrewR&R one. :-)

My understanding is that a full "day" in Kerbin is 6 hours, so we have 3 daylight hours and 3 night hours. But since Kerbals lived for a long time underground, they don't have to have their circadian rhythm "tidal locked" to it. Even us, Humans, appear to have a circadian of about 25 hours. And God knows my one appears to be 30 to 36. =P But, anyway... I think that the duty cycles is not important as the feature itself. And this can me tailored by the user. Essentially what my friends that are doctors does on their shifts. :-) (and me, when I screw up my project's deadlines)

CrewR&R works on Editing time. Such a module I'm searching would work in "runtime". But, yeah, should be nice if they could interact somehow - kerbals that spent more time in duty (bigger workshifts, for example) would need more time for ground R&R

OFFTOPIC - or not? I'm searching for a module that does this, but inside a vessel. The Kerbal "works" 4 hours in the a workstation that matches his/her skills, then goes somewhere else for 4 hours of "rest and recreation", then goes for a hab or sleeping chamber (if available) for the next 4 hours - and them everything restarts.

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.

It's a Easter Egg from Module Manager. It's a way to remember that 3.0.6 is still in beta status. It's annoying, but harmless.

On the other hand, it appears to exist a memory leak after all. I loaded a very part heavy craft, played a little and then leave the computer for the night. In the next morning, KSP had crashed and the report said it run out of memory. The process already had 14G of memory allocated (it had about 10 when I left the computer).

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.

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?

Blew up some really, really big and expensive fireworks. =P

I just remembered that I also had this behaviour switching from Local to Global coordinates while using the tools.

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.

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").