APlayer

Members
  • Content count

    156
  • Joined

  • Last visited

Community Reputation

55 Excellent

About APlayer

  • Rank
    Spacecraft Engineer

Profile Information

  • Location Germany
  • Interests Maths, Programming, Chess, KSP, Astronomy, Physics

Recent Profile Visitors

901 profile views
  1. [1.3.0] Kerbalism v1.2.9

    Okay, good to know. No worries, it's not too bad. While you're at it on this module, may I also suggest a thing? I think many players make sounding rockets in their early career games for a small science boost. But the experiment module prevents this by requiring lots of time to gather the science. I think it would make more sense to split the experiment modules into two pieces of data (the kind of data that you see when you click "Data" on a probe core): The "initial" data - which is collected immediately and makes up say, 1/3 or 1/4 of the total experiment's science value and 1/10 or 1/20 of the total data size (I am not sure, something quickly transmissible anyway). And once this initial data is collected, there would be the "Long term observation" data, which makes up the rest of the science value and data size. This would happen per biome, that is, if you enter a new biome and the experiment switches to observing it, it creates another piece of initial data. What this is for, are suborbital rockets in the early career game and fast flybys (Moho, hehe ) later. Currently, one cannot collect any meaningful science from those, which may prevent or at least discourage this kind of missions. The proposed system, however, would ensure an immediate science gain, but still encourage longer term observation missions by reserving most of the science for them. This also adds some realism - you get some knowledge about a place by looking at a momentary set of data, but you truly learn about it when you observe it over some time. And I believe it will only require comparatively minor changes to the experiment module's code to implement.
  2. I tried this with KScale64 and the clouds seem to be an altitude of about 30 km. Obviously seeing clouds in almost space is not nice. Unfortunately, I do not understand the configs myself. What value would I change to adjust this?
  3. [1.3.0] Kerbalism v1.2.9

    If I recall correctly, Kerbalism creates ModuleManager patches on the fly. Changing settings would not work in-game - you need to do it when unloaded, for them to take effect once KSP starts up again and Kerbalism creates the new patches. Also, I believe my last question went unnoticed. I tried looking in the settings and the Wiki on modules and found that the science experiments should not require a crew (there is an option to do that, but it is disabled). Is it me doing something wrong?
  4. [1.3.0] Kerbalism v1.2.9

    I am currently trying out the "Experiments" extra. I have a probe in orbit which is basically a command pod, reaction wheels, solar panels, a battery, an antenna and three science experiment parts: Radiation Scanner, Barometer and Thermometer. Whenever I try to run one of those experiments, I just get a yellow text "no operator", but it did work on an earlier craft with a crew, which unfortunately was only suborbital. Do I need a crew to run those simple experiments? Is there a way to disable that, for at least some of them?
  5. [1.3] kOS Scriptable Autopilot System v1.1.3.0

    This didn't work either, but, taking a closer look, it seems that the throttle actually gets set to 0 for a second, but immediately resets back to 1. With the help of oren on IRC, who reminded me that WHEN blocks finish running in one physics tick, I managed to fix it by moving things around: // Falcon 9 second stage script // Launches the rocket LOCK THROTTLE TO 1. LOCK STEERING TO HEADING(90, 90). WAIT 1. STAGE. WAIT 1. STAGE. SET launchProfile TO LIST( LIST(500, 90), LIST(5000, 65), LIST(10000, 45), LIST(25000, 30), LIST(40000, 20), LIST(50000, 10), LIST(60000, 0) ). SET prev TO LIST(0, 90). FOR pair IN launchProfile { SET a TO (pair[1] - prev[1]) / (pair[0] - prev[0]). SET b TO prev[1] - a * prev[0]. UNTIL ALTITUDE >= pair[0] { SET targetPitch TO a * ALTITUDE + b. LOCK STEERING TO HEADING(90, targetPitch). IF APOAPSIS >= 75000 { BREAK. } IF STAGE:NUMBER = 3 AND STAGE:LIQUIDFUEL < 2600 { LOCK THROTTLE TO 0. WAIT 2. SHIP:PARTSDUBBED("s1-CPU")[0]:GETMODULE("kOSProcessor"):ACTIVATE. STAGE. WAIT 3. LOCK THROTTLE TO 1. } } SET prev TO pair. } // circularize
  6. [1.3] kOS Scriptable Autopilot System v1.1.3.0

    So, I'm making this automatic launch vehicle and programming it with kOS. But I am having trouble with the code - a thing that definitely should work, for some reason does not. I asked a few people on IRC and they couldn't help either. What am I doing wrong? // Falcon 9 second stage script // Launches the rocket LOCK STEERING TO HEADING(90, 90). WAIT 1. LOCK THROTTLE TO 1. STAGE. WAIT 1. STAGE. WHEN STAGE:LIQUIDFUEL < 2600 THEN { LOCK THROTTLE TO 0. // this line is not working WAIT 2. SHIP:PARTSDUBBED("s1-CPU")[0]:GETMODULE("kOSProcessor"):ACTIVATE. STAGE. WAIT 3. LOCK THROTTLE TO 1. } SET launchProfile TO LIST( LIST(500, 90), LIST(5000, 70), LIST(15000, 45), LIST(30000, 30), LIST(40000, 15), LIST(60000, 0) ). SET prev TO LIST(0, 90). FOR pair IN launchProfile { SET a TO (pair[1] - prev[1]) / (pair[0] - prev[0]). SET b TO prev[1] - a * prev[0]. UNTIL ALTITUDE >= pair[0] { SET targetPitch TO a * ALTITUDE + b. LOCK STEERING TO HEADING(90, targetPitch). IF APOAPSIS >= 75000 { BREAK. } } SET prev TO pair. } // circularize The line I commented as not working is, obviously, supposed to stop the engines from burning during staging. But the throttle just stays at 1. The line does get reached, I checked that with a HUD message. Also, it is not a matter of using SET or LOCK, both don't work. The rest of the code performs as intended too. Could anyone help me out?
  7. [1.3.0] Kerbalism v1.2.9

    Try making the patch :FINAL. The problem may or may not be that Kerbalism overwrites your patch.
  8. Yes, yes and yes. What do you mean by semi-transparent? What should the opacity be? And what buttons are needed for the GUI?
  9. I have used the Habitat Pack whenever there was a working version, since I found it ...and you just made a working version. Thanks as much as the internet can convey, man, you're really amazing for maintaining all those mods! This. Absolutely.
  10. So, I had a look at the icons. They seem alright, so I believe we only lack an immediate indicator for the current mode (body fixed/normal). As I said, this could be accomplished by changing the background. If you give green light, I would fill the currently transparent background with yellow to indicate body fixed mode, this should take less than five minutes. And, while we are at things like that, if I may make a feature request... So, I personally lack a display of orbital data after aerobraking. It would be nice if there was a display of apoapsis, periapsis and things like that after the first time leaving an atmosphere, which would probably greatly help planning aerobraking maneuvers that require a specific target trajectory. This data would be nice to expose to kOS, too, if this is Trajectories' job and not kOS'.
  11. Feel free to PM me the original existing icons, if any, and what modifications to make to them or what new things to create. I will do my best.
  12. The option that allows selecting Body-Fixed mode could have a third option, "Automatic", which would do exactly that. The icon could change background color when Body-Fixed is enabled, whether explicitly by the user or internally by the automatic mode. While this does not make immediately clear what the background change does, it could be mentioned in the Readme and be a useful and well visible indicator for users that know what it means. I would be glad to provide an edited icon for this.
  13. I simply rolled back yesterday's mod updates and it seems to have fixed the issues. I probably shouldn't have done this, now that I think of it, but I have also removed the file from Google Drive, that's why you couldn't see it. I'm sorry for the disturbance, the error was on my end.
  14. If so, I presume it is some mod compatibility issues somehow dependent on the MM version... Could anyone give me a hint on what to look for in the log to see which mod breaks things?