sebseb7

available on CKAN for current KSP or how to install ?

BUG: The Kerbal Habitation Endcap is missing in the Connected Living Spaces configuration.

Question: how do I lock steering, relative to a specific part, independend of "control from here". Problem: my spacestation sometimes turnes around when something docks, because the contolpoint changes. I image somelike like lock diff to ctrlpart:facing * mypart:facing. lock steer to prograde * diff. but thats wrong, how to do this?

1.3 with kos docking gui

crashes with 1.3 https://github.com/neuoy/KSPTrajectories/issues/86#issuecomment-307634009

I can do german translation.

Hi, the CXA_GymHab requires water for USI life support, while other modules don't. (Water is not required for USI) /seb

Any idea why those fonts are blurry? /seb

every microcontroller has a counter that gets decremented by x per cycle and calls a function when reaching zero. Such timers allow the dynamic chance of the sleep period (decrements per cylcle). So something like: set delay to 0.5 every delay when true then { set delay to new_delay. return true.} would be nice. usually you have at least 4 registers (the address of the function, the counter, the decrement and the configuration register (on/off,up/down,etc)). for debugging power consumption a statistic info where I can see all currently active triggers with their expressions would be great.

to conserve power I now do: until false { test_for_key(). wait 0.5. } on (event) call() could be a feature of the architecture, not of the compiler. then it would be "cheaper". but in the end this is not really an issue.

its not that I hate anything. I work with what I am given ;-)

again. I don't observe anything incorrect, no need to look at specific code Its just that I made my code very power-efficient, and the last remaining big power consumer is: the triggers. Of corse I could use my own trigger system, where I have one big loop with a dynamic wait. that sure consumes much less power. if all my code would be: on ag1 {stage.} this consumes way too much power compared to other operations (It does draw exactly as much has expected). Its just my feeling that this is unbalanced. A loop with a wait would be cheaper, but this would be normally the job of the trigger. to deliver a more efficient method than looping. the way it is implemented now leads to a lot of dirty hacks to conserve power. for example: on ag1 {stage.} would be much cheaper to have just "stage." in the boot script and to power up the core using the ag1 action group. This way no power is consumed while waiting for a keypress but still I have my action on ag1. it had nothing to do with the gui.

if I let the ship just do its housekeeping task it consumes just 0.1EC per hour. If I also activate a trigger to wait for a single key input it consumes 10EC per hour. any active trigger consumes >= 0.001/s (depending on the length of the expression), the trigger is never really executed, just the "on ag1" part. I observe totally expected power consumption. The point is: over the long run, is feels unbalanced that waiting for a keypress consumes 99% of the energy. suggestion: events you don't have to poll. or some kind of powersave mode, where you can "underclock" the cpu, if you're just waiting for input. If you open a gui window with a lot of "on buttonx:pressed" triggers, power consumption goes way up, just to watch for the buttons. is up-to-date. difficult to compare kerboscript. the concept is weird, but fun. it feels a little bit like microcontroller software development. I started learning kerboscript a few weeks ago and now launch, deorbit/chute sequence, land on mun, ascent from mun, node exeution, etc. etc. is working fine already. plotting in realtime is also fun:

simple example: I have a battery with 100 EC in a given period of time all the code I run consumes 1 EC, while the ONE trigger that is ALWAYS active on ag1 consumes 99 EC. so all the launch, transfer, landing, deorbit, etc, etc code, consumes 1%, and the one trigger for opening the gui consumes 99%. So most of the battery of the vessel is not there for all the calculations, but just for the one trigger for user interaction.

Hi, I would like to see cumulative power-consumtion/production per part in kOS. what du you suggest? /seb