Jump to content

APlayer

Members
  • Posts

    159
  • Joined

  • Last visited

Posts posted by APlayer

  1. Another problem I encountered is figuring out the aerodynamic properties of a vessel. I have not found any direct command in the documentation which would yield, say, the drag constant given velocity, altitude and atmosphere for a prograde motion. The next step was trying to record it from the stock aerodynamic GUI as a function of Mach number, and from that function calculate it on my own, but I failed at that too, because there is no way to get the temperature (required for Mach number calculation) at a given altitude in a given atmosphere. So I am forced to record both, the drag constant as a function of Mach number and the temperature as a function of altitude in order to calculate basic aerodynamic properties of a vessel. Is there any efficient workaround to this problem? Or am I missing some actually existing command?

  2. 7 hours ago, Steven Mading said:

    I've been trying to wrestle with Unity's docs trying to figure out how to do the extremely simple task of drawing primitives directly onto a texture,

    Don't worry! :-) I will meanwhile try the button grid workaround, and see what "resolution" I may achieve before things slow down too much. And if that doesn't work I will simply skip this part - the already existing GUI offers alternatives to images and plots, even if they are not as visually appealing.

    Also, from totally zero knowledge on that matter - would it be possible to create a canvas from some element's background image by editing and reloading the image file/object/whatever during runtime?

  3. 19 hours ago, kcs123 said:

    I'm not sure about custom pixel draws, but some other stuff might be possible. Anyhow, worth to check GUI Style documentation about it.

    From this documentation, I derive, I can at most create a grid of buttons with colored backgrounds and this way plot an image and record click coordinates? I guess this is possible, if the large amount of buttons does not break something. Is there no better way to do this, though?

    If so, is perhaps some sort of JavaScript-style Canvas GUI element planned for the future of kOS?

  4. 17 hours ago, ShotgunNinja said:

    Oops. A mistake in the Experiment module. An operator should be required only if 'crew' is specified in the config node. I'll fix in next version.

    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 :P) 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.

  5. 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?

     

  6. 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?

  7. 46 minutes ago, Probus said:

    Well, that looks right to me.  You could always try:

    SET SHIP:CONTROL:PILOTMAINTHROTTLE TO 0.

    I have a similar setup as yours and mine seems to work.

    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

     

  8. 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?

  9. 10 hours ago, Daelkyr said:

    Is there some way to get a MM patch to be able to change a Supply amount on a part thru MM patch or is that not possible with Kerbalism?

    Try making the patch :FINAL. The problem may or may not be that Kerbalism overwrites your patch.

  10. I have used the Habitat Pack whenever there was a working version, since I found it ...and you just made a working version. :D

    Thanks as much as the internet can convey, man, you're really amazing for maintaining all those mods!

     

    31 minutes ago, VenDei said:

    Inflatable stationparts that don't bring in a hunk of unwanted mechanics are exactly what I have missed.

    This. Absolutely.

  11. 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'.

  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. 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...

  14. 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.

  15. 20 hours ago, Kobymaru said:

    Just so you know, the distinction between "drag" and "lift" is a bit silly, because as @Boris-Barboris likes to point out, drag and lift are just components of the same vector. That means you'll run into situations where ignoring "lift" will produce inaccurate results even when you're not classically "flying".

     

    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.

    20 hours ago, Kobymaru said:

    Thanks for the tips! I think implementing RK4 is not that hard (I believe I did that in C++ once for a class), but integrating it (no pun intended :wink: ) into the mod is the difficult part.

    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! :-)

×
×
  • Create New...