Jump to content

Padishar

Members
 View Profile  See their activity

  • Posts

    2,669

  • Joined

  • Last visited

 Content Type 

Posts posted by Padishar

    [1.3.0] Kerbal Engineer Redux 1.1.3.0 (2017-05-28)

    in KSP1 Mod Releases

    Posted

    Wooo!! The test version of KER worked like a charm! That's super exciting. I'll let you know if I run into anything else goofy.

    I presume the thrust values it shows for the solid boosters is correct. I've not actually tried HotRockets but it sounds like it adds a dummy ModuleEnginesFX (that just defines the exhaust and has zero thrust) to existing engine parts. The current release of KER doesn't support engines with multiple engine modules correctly (except for multi-mode engines) and this means that if the engine originally used a ModuleEnginesFX then KER would find the original one and work but for engines that use a ModuleEngine it would see the newer ModuleEnginesFX and look for one of those getting the dummy smoke generator.

    The new test code supports any number of engine modules of either type (and correctly support modules that use different propellants).

    [1.3.0] Kerbal Engineer Redux 1.1.3.0 (2017-05-28)

    in KSP1 Mod Releases

    Posted

    I'd like to confirm that KER does not work correctly with Hotrockets installed. Specifically the 2 stock solid boosters do not report any deltaV information etc. I tried this from a fresh install with only those 2 mods. KER only stopped calculating the SRBs once Hotrockets was installed.

    I suspect it has something to do with the ModuleEnginesFX specifically for the SRB because the other engines calculate just fine. Nazari1382 said that the SRBs are handled the same way as the other engines so he's not sure why KER doesn't work for them.

    Is this with the current release version of KER 0.6.2.3? Would you be able to try the test version (see this thread) and see if it has the same problem (or a different one)?

    Test of continuing KER developments [0.24.2]

    in KSP1 Mod Development

    Posted

    One thing I noticed was that during launch and ascent, the dV updated quite slowly, probably about once a second. I could attribute this to gameplay lag that occurs anyway, but looking at the dV display in the ALCOR pod I was using, it was updating much faster. Probably about normal for it, actually. So there's that..

    Yes, it is a bit sluggish. It isn't at any sort of fixed timings. It runs the simulation and times how long it takes. Then it waits for at least 10 times that long before it will run the simulation again. So if the simulation takes 100ms then it will update approx. every 1.1 seconds. This delay strategy is left over from when the simulation ran in the foreground thread and it can probably be changed to update more quickly now that it runs (a large part of it) in a background thread.

    Also, it still has a problem with docking calculations. While it's usually ok (and pretty fast at updating the display), I did manage to confuse it with this:

    http://i.imgur.com/z3sMK4b.png

    It's not calculating for dV for the currently burning engine, since that's staged after separation of the capsule (which would leave the engine on the docked probe left). This meant that the dV displayed is for the probe engine, and obviously increased as I continued burning. Granted, this was obviously a test case with manually activated engines (staged on, turned off, then on before and after docking etc) and if you're paying attention, it's not a problem, but it's not implausible to happen IRL.

    All that said, I can't remember if this was an issue with the 6.2.2/3 or not. So yeah, there's that too.. but the first point I made still stands, it updates dV quite slowly.

    I suspect this was an issue with the old code too. The code simulates the normal staging process and doesn't make any effort to work out issues like this. It isn't easy to decide what it should display in this sort of case...

    This was the rocket I used (fairings decoupled for visibility), using a mix of KW and stock engines. Despite looking like it has major oomph, it's got a **** poor TWR, but this was just slapping as many bits on to confuse KER. As it stands on the launchpad, stage 1 is separation, stage 0 is probe engine.

    http://i.imgur.com/6eiRjAl.png

    I presume the stages have sensible burn times in the VAB.

    Test of continuing KER developments [0.24.2]

    in KSP1 Mod Development

    Posted

    Did that effect with the window happen with the latest version of the code? Are you certain you don't have more than one version of KER installed?

    I'll try out switching from runway back to SPH (and pad to VAB) a bit more. When testing the code I usually go to VAB, load a craft, check build window, fiddle with ship a bit checking window, go to launch, check window, launch and check window update, revert to VAB, load another craft, repeat. I don't generally keep the same craft through multiple cycles so this may have something to do with it. I'll have to take a close look at how the PartModule is being called on scene changes.

    Incidentally, I've enabled the issue tracker on my github fork.

    Test of continuing KER developments [0.24.2]

    in KSP1 Mod Development

    Posted

    Since issues are disabled on GitHub, I'll report this here. I had a crash switching from the runway to the SPH, and while looking for the culprit, I found the following in the log:

    There are three other log entries after that, so maybe KER didn't cause the hang (KSP didn't really crash, I had to force-quit it), but I thought you might want to know about this.

    I'll look at enabling the issue stuff on github. Thanks for reporting this problem, it looks like adding a Part to the Part->PartSim dictionary is failing because it is already in there. Should be easy to fix.

    This shouldn't have caused anything to crash but I'll take another look at the exception handling to make sure...

    There should be another update later today with various optimisations and code cleanup/commenting and I'll try to roll these fixes in too...

    Test of continuing KER developments [0.24.2]

    in KSP1 Mod Development

    Posted

    Just wanted to let you know that there are some old .dlls in the output folder in both of your branches over on github. Judging from the reported dates, they don't seem to have been touched in a while. Maybe you should better remove them to avoid confusion.

    Other than that, the current build from the first post is running fine over here.

    Yes, I've only created the fork to prepare (and update) a pull request to Cybutek's version. I haven't been updating the compiled versions (I don't think they should be in the github repository really) but I will do from now on to avoid any confusion.

    [1.3.0] Kerbal Engineer Redux 1.1.3.0 (2017-05-28)

    in KSP1 Mod Releases

    Posted

    I presume it is around the other side of the capsule (that's where I usually put it on Mk1 pods). The window should only be showing if the part is present (unless you've done the "add BuildEngineer module to all command pods" tweak).

    Does the window update when you add and remove parts? If not then the calculation code has stalled and it will probably not update again until you quit and restart KSP. If it does update then it is failing to detect the engine as being active. Are you sure it has fuel (2565kg looks a little light)? Has the engine been tweaked accidentally to zero thrust (or disabled)? Do you have any other mods installed?

    You should probably try the test version of the new simulation code I have been working on as it should fix all stalling issues and improve the calculations in a number of other ways. You can find it here.

    Note: To use the test version you will need to update KER to version 0.6.2.3 first before following the instructions in that thread. See the links in the first post of this thread to get 0.6.2.3

    Test of continuing KER developments [0.24.2]

    in KSP1 Mod Development

    Posted · Edited by Padishar

    I have updated the zip linked in the first post to include the fix for engines with multiple modules. The Horizon Zenit engines should all work correctly now.

    The fix basically treats each individual engine module as a separate engine. This allows modules to use different propellants which burn out at different times (if such engines exist anywhere) and should be easily expandable to account for the thrust vectors in the future.

    Note, there is a potential issue with the overall stage isp if a stage contains engines that burn out at different times. The isp displayed is the overall stage isp at the start of the stage and not the effective isp over the whole life of the stage. So, if you have a stage consisting of a long running liquid engine with a good isp and some non-detachable solid boosters with a poor isp then the displayed isp will be that including the solid boosters and will be less than the effective isp as the solid boosters will not be running during most of the stage. This shouldn't really affect anyone as the deltaV calculations will be correct because the isp is recalculated for each phase of the simulation (a phase is as long as it takes to completely drain the quickest draining fuel source). The stage isp simply needs to be recalculated from the overall stage deltaV and the starting and ending masses but it's late and I need to get some sleep so I'll do it tomorrow...

    The official unoffical "help a fellow plugin developer" thread

    in KSP1 C# Plugin Development Help and Support

    Posted

    Storing references to core game objects (e.g. Part) across calls to your plugin (or for use by a background thread) is dangerous as you can't be sure that the core game engine doesn't change the objects between the calls. E.g. what would happen if a Part you have a reference to is removed from the rocket (e.g. the user stages or something blows up on your craft) and your code goes on to treat it as still being a part of the ship then unexpected things will happen. I have been modifying the KER vessel simulation code to avoid such problems, mainly by creating my own data structures for the background thread to use so it doesn't have to access any core game data when it might be changing...

    The official unoffical "help a fellow plugin developer" thread

    in KSP1 C# Plugin Development Help and Support

    Posted · Edited by Padishar

    In pseudo code, I'm after something like this:

     "DisplayString" = AGXVessel.First(AGXPart.agxP.name);

    I'm currently working around it as follows (pseudo-code):

    AGXPart1 = AGXVessel.First();
    "DisplayString' = AGXPart1.agxP.name;

    but I'm pretty sure there should be a way to do this without having to instantiate an AGXPart object just to get the data string out.

    Firstly, when you assign an object like this it actually only assigns the reference to the object, it doesn't create a new copy of the object.

    Second, you just have your expression a bit mixed up, you need:


    String name = AGXVessel.First().agxP.name;

    ...though, actually, your other solution is better as it enables you to test if First() returned an object (if the list is empty it would return null and you would get an exception). If you've already tested if the list is not empty then you can safely use the shortcut version...

    Test of continuing KER developments [0.24.2]

    in KSP1 Mod Development

    Posted

    I tried your fix but the delta-v calculation is wrong. My craft shows a 0.77 TWR for the main stage, but it has no issues getting off the ground. I updated my craft to remove RT, but I still use TAC Life Support and TAC Fuel Balancer so idk if that will mess things up.

    https://www.dropbox.com/s/pamhv9r90eddl9l/Broken%20Craft.craft

    Yes, I haven't fixed the issue with engines that have multiple engine modules yet. Those engines only read as 100kN thrust rather than the combined value of 850kN. The deltaV values should still be reasonably close (unless the much longer burn time causes a difference in staging behaviour)...

    What mod do i want?

    in KSP1 Mods Discussions

    Posted · Edited by Padishar

    To make KER work without a part you can use a simple module manager config file. It is explained in the main KER thread here.

    If you really don't want the three extra parts in the science parts tab then you should be able to just delete the three folders out of GameData\Engineer after installing it.

    Calculating Orbital Velocity =(

    in KSP1 Gameplay Questions and Tutorials

    Posted

    Well, mu = GM and both mu and the mass are given on the wiki so you can calculate G if you need to but it should be the same as our standard G. Using the values from the wiki gives:

    G = 6.6739999530952885842606573050885e-11

    The reason this is slightly different is that the gravitational parameter on the wiki is only given with 5 significant digits and was presumably calculated using the real value of G and the "real" mass of Kerbin...

    Calculating Orbital Velocity =(

    in KSP1 Gameplay Questions and Tutorials

    Posted · Edited by Padishar

    Well, the first thing that jumps out at me is that your value for a is in the wrong units. 700km is only 700,000m.

    v^2 = G * M / a

    v^2 = 3528430000000 / 700000 (only used 2 decimal places for G and M)

    v^2 = 5040614.3

    v = 2245 m/s

    Edit: G*M is the "Gravitational parameter" value quoted on the wiki's various planet pages (for Kerbin this is 3.5316000x10^12 m^3/s^2) so all you need is this...

    v = sqrt(3.5316x10^12 / 700000)

    v = 2246.1 m/s (this should be more accurate than the above)

    First Time Docking!!

    in KSP1 Mission Reports

    Posted

    To my surprise, not that bad. Small craft and lowest possible settings make it work fine, even on my laptop. Anything larger than what I did here, however will hurt. Like stations, probably impossible!

    Actually, it is possible to dock pretty complex craft on fairly dodgy hardware. I did these on a Core Duo 2.16GHz laptop. A bit painful at 3 - 5 fps but still doable... ;)

    Pointless spam in output_log.txt

    in KSP1 C# Plugin Development Help and Support

    Posted · Edited by Padishar

    Does everyone else's output_log.txt have the following written after every call to MonoBehaviour.print?

     
    (Filename: C:/BuildAgent/work/ea95e74f6e5f192d/Runtime/ExportGenerated/StandalonePlayer/UnityEngineDebug.cpp Line: 54)

    That's 1 line with just a space, 1 with the filename and linenumber stuff and 1 empty line. This greatly increases the size of the file and makes it a lot harder to find the output you are looking for. If it does happen for everybody and isn't just a strange quirk of my installation (I presume not) then we should ask Squad to get rid of it. Debugging plugins without a sensible debugger is hard enough without having to wade through megabytes of spam to find your info or regex replace it so you can fit more than 20 lines of your output on the screen...

    There are also a couple of messages that come out as:

    WheelCollider requires an attached Rigidbody to function.

    (Filename:  Line: 167)

    So, no filename and a different line number. Presumably that particular bit of code is using a different routine to write to the log than everything else does...

×
×
  • Create New...