alexustas

KSP does not provides us data about temperature, humidity and pressure inside the Pod. Almost all on the panel "environment" - are fake. indication of occupied seats and heating the capsule body are only useful .

Ok, let’s try explaining. You need to use the “perPodPersistenceName†parameter. It allows you to connect the state of one prop with other props by making them use the same storage variable for their state. (The main RasterPropMonitorComputer module on the pod model takes care of keeping these variables around and making them persist.) If you don’t give this parameter, every button has a uniquely generated parameter name that keeps it’s state, but if you do, multiple animated elements can share state. Let’s take, for example, the mechanism of turning on cockpit panel lights. Everything is turned on with the “CockpitBackLightSwitch†prop, which has a config like this: PROP { name = CockpitBackLightSwitch MODULE { name = JSIActionGroupSwitch animationName = SwitchLightAnim switchTransform = SwitchPUSHcollider actionName = dummy [B][COLOR="#B22222"]perPodPersistenceName = BackLight[/COLOR][/B] needsElectricCharge = true switchSoundVolume = 0.6 reverse = true switchSound = ASET/ASET_Props/Sounds/buttonbeep . . . } Pressing this button starts the animation of the button press itself (“SwitchLightAnimâ€Â) and changes the state of the “BackLight†variable, without doing anything else. In the graph above, it’s “MASTERâ€Â. Now let’s take a look at the configuration of the “PanelDivider†prop, marked as “Slave†in the same graph: PROP { name = PanelDivider MODULE { name = JSIActionGroupSwitch animationName = PanelDivider01TurnON [B][COLOR="#B22222"]perPodPersistenceName = BackLight[/COLOR][/B] actionName = dummy switchSound = ASET/ASET_Props/Sounds/beep-21 switchSoundVolume = 0.001 } } In this configuration, “animationName = PanelDivider01TurnON†is the animation of the actual color change, and notice also the “perPodPersistenceName = BackLight†parameter. This is what connects the fact of pressing the “CockpitBackLightSwitch†button with the animation of color change of cockpit panels. ALCOR has 74 parts like this, and they all turn on when you press a single button. The lighting of joysticks and other inner lights are done in the same manner. Opening window shutters on the top porthole is done using the same mechanism, but the animation module configuration is given in internal.cfg rather than prop.cfg, because the shutters themselves are not props -- they’re elements of the internal model itself. Animation of the exterior model elements is done using the same mechanism as well. This is the button configuration that turns on airlock lights: PROP { name = AirLockLightSwitch MODULE { name = JSIActionGroupSwitch animationName = SwitchLightAnim switchTransform = SwitchPUSHcollider actionName = dummy [B][COLOR="#0000CD"]perPodPersistenceName = AirLockLights[/COLOR][/B] needsElectricCharge = true switchSound = ASET/ASET_Props/Sounds/buttonbeep } MODULE { name = JSIActionGroupSwitch animationName = AirLockLightsAnim actionName = dummy [B][COLOR="#008000"]animateExterior = true[/COLOR][/B] [B][COLOR="#0000CD"]perPodPersistenceName = AirLockLights[/COLOR][/B] } . . . The first module starts the animation of the button itself and changes the state of “AirLockLights†variable. The second module reacts to the change in the variable and runs “AirLockLightsAnim†on the exterior pod model. JSIActionGroupSwitch module knows that it’s on the exterior pod model because “animateExterior = trueâ€Â. More info HERE

Thanks, ObsessedWithKSP "HEAT" light up if the temperature of the pod itself is over 85% of it's maximum temperature "RESERVES" - Turns on all resources that were disabled by the player (for instance, by right-clicking on a monopropellant tank, and clicking on the small icon next to the tank's capacity to prevent it from being used). The button is 'on' when there is at least one resource whose flow was disabled. from 0:25 http://youtu.be/N02qEVuJFFA

hmm... module fit but with zero clearance

ok. I'll try to do it

Here's another way to delivery and assembly of modules

Not as much as I’d like. I spent a lot of time messing with colliders for SM and SMA. Also I added another, unanticipated part: ASET Attachment point. It’s completely analogous to the stock BZ-52 Radial Attachment Point, but has a different design, sizes and has a decoupler module. I also did a test KONQUEST delivery mission using a super-skycrane, I’ll post a video soon.

I tested the new version a bit, and that’s exactly what I wanted! Thank you! Just one more little feature request: The stock G indicator is not very readable. Could we have an on screen warning that we’ve reached 0.9 of the smallest MaxGee on the vessel? (Because different modules might have different MaxGee).

You mean something like that?

In theory, yes. But for microgravity environments, the inner space of the modules can (and should) be set up completely differently. For example, the CAM module could comfortably contain six or even eight separate rooms instead of four without reducing crew comfort significantly... and cargo modules would have no need for a ramp.

Yes, it is a simple probe core, oriented vertically so that I could get the correct retrograde vector on the navball when in the final stages of descent. At about 2000m, I zero out vertical and horizontal velocities, drop the descent stage, switch ‘control from here’ to the probe core at the top, rotate the module horizontally and turn on the landing engines. By the time this is done the altitude is about 1000m. - - - Updated - - - I don’t quite understand your question. Could you rephrase that, maybe?

KONQUEST is a part mod, not a plugin mod, I can model and texture but programming is not among my skills. What each particular part will be able to do depends on the third party plugins you use. If TAC-LS or some other life support system plugin have such a function that I could just write a module config for, I don’t see a problem.

Check your installation paths: \GameData\ASET\ALCOR_LanderCapsule \GameData\ASET\ALCOR_IVA_patch \GameData\ASET\ASET_Props

So, I've clean copy of KSP with this mods installed: ALCOR w/IVA (OP) JSI: RPM and MechJeb2RPM ( OP, v0.16) MechJeb (OP/SpacePort, v2.2.1.0) SCANsat and SCANsatRPM (from here, v6.0) VesselView (OP, v0.5) ModuleManager (from here, v2.1.5) All works fine

well ... for some unknown reasons I have stopped receiving notifications about new messages in this thread. I will try to answer your questions asap

test launch

Ok, many thanks! But if are not too late, are it possible to add a couple of features: 1. The ability to set the maximum G value in config files instead of the hardcoded value of 2G. This will make the plugin more versatile i guess 2. Also the ability to specify the probability of death because of overload for each Kerbals onboard. Let's give them all the some chances MODULE { name = GeeForceKiller [B][COLOR="#FF0000"]MaxGee = 2[/COLOR][/B] [B][COLOR="#0000FF"]DeathProbability = 0.8[/COLOR][/B] }

Oh, well, misunderstanding has happened. Did you mean this one? Sure, it would be very useful for servicing Conquest, but I cant do multiple projects simultaneously and I chose "Konquest" now. MCCTS would be follows i guess.

nope, i have not stopped ALCOR, I still can not solve the problem with the collider, and this stops me from relise

SM and SMA with KAS Container 'Type B'

new part "SMA" and now i can to build something like this : see more images in the WIP gallery in OP

I can envision an inflatable habitat, but an inflatable laboratory full of equipment feels possible, but something of a stretch. Even a module with landing legs is not too far out. But an inflatable service module, greenhouse or cargo module feel silly to me. :-) Besides, you already have the excellent inflatable modules from PorkWorks.

Mun Landing

Konquest Service Module (SM)

K3|Chris Many thanks for advise