APlayer

Members
  • Content count

    152
  • Joined

  • Last visited

Community Reputation

54 Excellent

About APlayer

  • Rank
    Spacecraft Engineer

Profile Information

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

Recent Profile Visitors

715 profile views
  1. 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
  2. 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?
  3. Try making the patch :FINAL. The problem may or may not be that Kerbalism overwrites your patch.
  4. Yes, yes and yes. What do you mean by semi-transparent? What should the opacity be? And what buttons are needed for the GUI?
  5. 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.
  6. 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'.
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. Are there any up to date IDE packs for kOS? I see there is that old GitHub repo (https://github.com/KSP-KOS/EditorTools), but it was last updated two years ago, and the language has changed pretty significantly since then. What do you guys write kOS with today?
  12. MM 2.8.1 breaks the game on my extremely heavily modded install, that is, at least sometimes on launch, the vessel doesn't work, because at least some modules don't get patched, plus the date is set to Y999 D499 5:59:59. Switching back to 2.8.0 fixes it. The log is 4 MB large, so here is a Google Drive link: https://drive.google.com/open?id=0B7ucLuOwxKVYN2JyOERsdms5ZEU Also, feature request: Could MM move the cache, checksum and similar files to some folder in GameData? I may be alone with this, but the bunch of files at the end of my GameData folder do bother me...
  13. How feasible would it be to implement own failure modes configuration? That is, a place where you can specify what kind of module should fail and how it should fail in some cfg file? I am asking, because I believe it should be possible and it will allow custom support patches for virtually anything.
  14. The problem here is, the lift calculation requires much more precise knowledge of the vessel shape while being a comparably small effect, and I don't think implementing that outside of KSP itself would be feasible and worth the trouble. What I could possibly do is create this tool in kOS rather than JavaScript, which could account for lift and be precise with drag, though. On second thought, this seems to be the only feasible way to do it, actually. I am sorry, but I don't think I can help with that. I will be glad to help if there is anything I can do, though! :-)