Jump to content

sebseb7

Members
  • Content Count

    47
  • Joined

  • Last visited

Community Reputation

4 Neutral

About sebseb7

  • Rank
    Rocketeer

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. BUG: The Kerbal Habitation Endcap is missing in the Connected Living Spaces configuration.
  2. 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?
  3. crashes with 1.3 https://github.com/neuoy/KSPTrajectories/issues/86#issuecomment-307634009
  4. Hi, the CXA_GymHab requires water for USI life support, while other modules don't. (Water is not required for USI) /seb
  5. 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 express
  6. 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.
  7. its not that I hate anything. I work with what I am given ;-)
  8. 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
  9. 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,
  10. 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.
  11. Hi, I would like to see cumulative power-consumtion/production per part in kOS. what du you suggest? /seb
×
×
  • Create New...