Jump to content

kubi

Members
  • Posts

    81
  • Joined

  • Last visited

Posts posted by kubi

  1. Hi,

     

    First of all, thanks for the contracts!

    To trigger the launch station contract I need the hitchhiker cabin to be researched. Stockalike Station Parts provides similar parts in the tech tree (I have kiwi tt, but does not matter).

    Would it be possible to include some more parts besides the hitchhiker with _OR_ relation?

    (PAS-8R 'Pier' Station Core && PAS-5 'Sunrise' Habitation Module)

    (PMA-2 'Quay' Station Core && (PMA-5 'Dawn' Habitation Module || PMA-5B 'Evening' Habitation Module)

    (PPD-8 'Wharf' Station Core && (PPD-20 'Shanty' Habitation Module)) //Note, that the hitchhiker cabin would belong here, but maybe better to keep it separate for stock compatibility

    (SDV-3 'Minerva' Deep Space Control Module && (SDV-2B 'Titan' Compact Deep Space Habitation Module || SDV-2 'Atlas' Deep Space Habitation Module ))

     

     

     

  2. Hi again,

    Fresh install, now with 1.2.0.

    Still does not work, but differently :)

    On the loading screen the dependencies are green, and it seems that the log is fine with it too.

    KSC is white instead of pink now and it seems that there are issues in the log related to it. For example:

    [LOG 11:26:41.601] [Parallax] Validating /home/kubi/ksp/1.1GameData/Parallax_StockTextures/Kerbin/PluginData/low00.dds
    [LOG 11:26:41.601] [Parallax]  - Texture doesn't exist, skipping: _SurfaceTexture with filepath: Parallax_StockTextures/Kerbin/PluginData/low00.dds


    It seems that the path is broken.

    /home/kubi/ksp/1.11.0-kop/GameData/...

    The log is here.

    ----- Edit -----

    Some more testing of the interesting issue with the path.

    If I start KSP like this:

    /home/kubi/ksp/1.11.0-kop/./KSP.x86_64

    just adding a dot as CKAN would, the path in the log is different.

    [LOG 11:47:00.841] [Parallax] Validating /home/kubi/ksp/1.11.GameData/Parallax_StockTextures/Kerbin/PluginData/low00.dds
    [LOG 11:47:00.841] [Parallax]  - Texture doesn't exist, skipping: _SurfaceTexture with filepath: Parallax_StockTextures/Kerbin/PluginData/low00.dds

    ----- Edit #2 -----

    Ok, the path handling is quite faulty in the code (ParallaxSource.cs, line 2249 and around)

    Spoiler
    
    
    else
                {
                    actualPath = Application.dataPath.Remove(Application.dataPath.Length - 16, 16) + "GameData/" + path;
                }

     

    It seems that you try to cut a fixed length from the end of the string, but that results to totally different behaviour depending on the executable.

    In Linux we have "KSP.x86_64" (that I usually start) and "KSPLauncher.x86_64". Neither of them is 16 bytes.

    Starting the game from these two result in either

    [LOG 12:22:38.474] [Parallax] Validating /home/kubi/ksp/1.11.0-kop/KSPLauncher_GameData/Parallax_StockTextures/Kerbin/PluginData/low00.dds

    or

    [LOG 11:26:41.601] [Parallax] Validating /home/kubi/ksp/1.1GameData/Parallax_StockTextures/Kerbin/PluginData/low00.dds

     

    You could simply cut the string at the last index of (maybe with String.LastIndexOf?) "\" (Windows) or "/" (Linux) instead of a fixed length.

     

  3. Hi,

    Getting back to KSP after some months trying to use this great new terrain shader for stock.

    On the loading screen of KSP Parallax complains about dependencies (copy&paste from the log file):

    • Parallax has failed to meet dependency: Kopernicus
    • Parallax has failed to meet dependency: Parallax (Core)
    • Parallax has failed to meet dependency: Parallax (Stock Textures)

    I have clean & proper (I assume) installation of

    • KSP 1.11.0 (fresh install) on Linux
    • KopernicusBE_1110_Release58.zip
    • Parallax.1.1.1.zip
    • Parallax.-.Stock.Textures.1.1.1.zip

    Log file & screenshot

     

  4. On 7/30/2020 at 6:42 PM, firda said:

    OK, I now see there actually is some interest in this mod (exactly what I asked for), so I now feel obliged to do a release.

    Just saw your work yesterday. After a quick check of the documentation it seems really promising. I'll dig more into it over the weekend.

    My main use case is playing around with KSP APIs quickly without compiling code.

     

  5. 4 minutes ago, R-T-B said:

    So, this branch is buggy in regards to EC charging and will continue to be buggy until I have a reasonable fix for the problem.  I'd like to apologize to all the users eagerly wanting to play 1.10.1, only to find it not working, but I really need to crack this before I can justify another release.  Thank you for your continued understanding.

    No problem! This is the beauty of a beta (alpha?) version :)

    If you upload the latest to GitHub, I will have a look tomorrow.

  6. 47 minutes ago, R-T-B said:

    Rel8 is even worse off than that in some instances.  Don't go too far from home orbit... lol.

    It was indeed only one of many issues (this release actually has to redo how Kopernicus replaces solar panels entirely, so it will not fix existing craft in flight unfortunately), but it's the one issue I could not find...  sometimes we just can't see our own mistakes.  And now it's fixed.  Release incoming.

    Might be. I was only 0.5 to 2 AU in the vanilla Kerbol system (power of set orbit cheat). The table I've linked above shows quite constant 3x difference (with random errors and MechJeb was not there to help setting the craft's direction exactly)

  7. 4 minutes ago, R-T-B said:

    Actually, no, it's not.  That may just be the weird duplication bug I've been unable to track down, thanks.

    Most of the optimizations you mentioned have already been implemented I was just waiting to fix that to do a release.  Last release was kind of just a "well, it's bleeding edge and I'm tired" product... lol.

    You are welcome. It might be only one of the issues as in rel8 it is still 3x the rate than it should be, not only 2x...

     

     

  8. 19 hours ago, R-T-B said:

    I have identified the problem with the solar panels and EC math.  Surprisingly, my math was good this time.  The problem is the stock game was still running it's math, and screwing up the results.  I'll have this fixed in a little bit.  There'll be a hotfix today, and I'm hoping we can also implement solar-panel atmospheric extinction with OhioBobs help soon here.

    At the rate he is providing math and tests, I'm going to be putting him on the contributors list.  He's enabled a lot we could not of otherwise done.

    Great news. Reading this before posting to the stable thread would have been saving some digging work :)

    I'd get the in-orbit EC calculation straight first, then look into the in-atmo and the temperature efficiency curve.

    Anyways, some comments to the current dev1101 solar panel file. First code review after 20 years, so might be a total nonsense...

    Unnecessary iterations

    You go through all the solar panels and within that you go through all stars to find the home luminosity. It is not needed to do it for each and every solar panel. It would have been better to do it outside of the main SP loop. It does not cause any error, just a bit of a waste of CPU power.

    So, just move the first star iteration

    Spoiler
    
    for (Int32 s = 0; s < KopernicusStar.Stars.Count; s++) { ... homeStarLumaConstant = PhysicsGlobals.SolarLuminosity; ... }

     

    outside of the SP iteration

    Spoiler
    
    for (Int32 n = 0; n < SPs.Length; n++) { }

     

    Or make sure that it runs only once with a simple condition.

    Tracking body restoration

    For each SP iteration, you restore the original tracking body and run CalculateTracking then update the tracking body again but do not run CalculateTracking.

    Spoiler
    
                            // Restore the old tracking body
                            SP.trackingBody = trackingStar.sun;
                            SP.GetTrackingBodyTransforms();
    
                            // Run The MDSP CalculateTracking
                            SP.CalculateTracking();
    ...
                            if ((bestStar != null && bestStar.sun != SP.trackingBody) && (!_manualTracking))
                            {
                                SP.trackingBody = bestStar.sun;
                                SP.GetTrackingBodyTransforms();
                            }

     

    To me, having an unconditional update, then a conditional update is again a bit of a waste at least. You can simply move the unconditional update to the else branch of the conditional.

    Not running CalculateTracking after the conditional update might be a bit of a fault. I'm not sure if/what would it cause.

    Also, you restore the tracking body at the end of the nested star iteration cycle too. It seems a bit strange too.

     

    Flux & EC calculation

    The flux update seems fine to me. You just sum the flux from all stars (totalFlux) and load to vessel.solarFlux. I assume this is for the heat calculations, or whatever.

    But I'm confused a lot by the flow rate update.

    First of all, I'm not sure about the difference between SP's (float)flowRate and (double)_flowRate public attributes of Class ModuleDeployableSolarPanel. Is it only the chargeRate constant multiplier?

    You increase totalFlow twice, why is that?

    Spoiler
    
                                float panelEffectivness = ((SP.chargeRate / 24.4f) / 56.37091313591871f) * SP.sunAOA;
                                totalFlow += (float)starFlux * panelEffectivness;
                                totalFlow += ((float)starFlux * panelEffectivness) * (1360 / (float)homeStarLumaConstant);
                                _totalFlow += totalFlow / SP.chargeRate;

     

    It is like

    Spoiler
    
    totalFlow+= effectiveFlux * (1 + lumaRatio);

     

    Is this intentional?

  9. 9 hours ago, R-T-B said:

    We are presently advising stable branch users to revert to release 6, and just not use multistar packs if you care about proper ECs.  Release 7 and 8 have been officially pulled due to outrageously wrong EC production.

    Thanks!

    I assume that the above is only for the stable branch users as BE seems to be faulty both on rel6 and rel8, but differently :)

    In rel8 at the display info is correct, but the charging rate it totally off. In rel6 both are incorrect.

     

    KopernicusBE_1101_Release8.zip with Kerbol Origins 0.4.9 and Snarkiverse 1.2

    No multiple stars, Kerbin orbit and the Sun are unchanged.

    Launched a tiny probe to Kerbin orbit with two OX-STAT solar panels (opposite side of the craft):

    #1 Sun exposure 1.00, Energy flow 0.358, Direct sunlight, Tracking body: The Sun (auto).

    #2 Sun exposure 0.00, Energy flow 0.000, Blocked by Probodobodyne OKTO, Tracking body: The Sun (auto).

    On the resources panel the Electric Charge shows -1.26 charging rate.

    Full light: 1.00 / 0.358 / -1.26

    Half light (30deg) 0.50 / 0.178 / -0.62.

    The only consumer is the OKTO (1.20 / min = 0.02/sec).

    -----------------------------------

    KopernicusBE_1101_Release6.zip with Kerbol Origins 0.4.9 and Snarkiverse 1.2

    No multiple stars, Kerbin orbit and the Sun are unchanged.

    Full light: 1.00 / 0.428 / -0.84

    Half light (30 deg): 0.5 / 0.212 / -0.41

    **** Numbers might be off due to sunlight in the room :)

     

    More detailed google spreadsheet with hopefully correct numbers:

    https://docs.google.com/spreadsheets/d/1DWq3RpRZXtFjIuFRLOAmozwTNdtcuutAPAD-nxmaFdc/edit?usp=sharing

     

     

  10. 17 hours ago, R-T-B said:

    It's fixed now.  Just redownload from same link.

    @kubi, sorry for triggering a late spring-cleaning.

    Thanks!

    ... but still not good :(

    The System.cfg files are different now (-5.ori 8911 ->-5.new 8359 bytes).

    However, in -4 there was an extra file, Kopernicus/Plugins/Kopernicus.pdb (2907648 bytes) that is missing from -5. Not sure if it is the issue though.

     

     

  11. Something got totally messed up with my 1.9.1 install.

    https://drive.google.com/drive/folders/1AeSytzclHST2eVSCCPjZV8YXPfsbKK7C?usp=sharing

    Thought that it is Trajectories that I've installed, but not.

    Tried 1.9.1-5 first today, rolled back to 1.9.1-4 (logs are about -4).

    There were some fresh updates through CKAN (science alert, clickthrougblocker and planetary base systems), but none of those should interfere.

    ----- edit ----

    Or, it might be that -5 messed up something.

    Tried with a clean install. First -5, it was faulty. Then -4, it is fine now. But needed to do a quite big cleanup...

  12. Hi,

    First of all, thanks! Especially for the orbit editor :)

    I have moved around stock planets, tweaked a bit their mass too. Lots of fun without Kopernicus...

    I have found a bug, I think. I've tried the latest stable as well as the beta

    It seems that when Hyperedit calculates the orbit and speed, it does not always consider the updates of the parent body.

    ---------------- Test -----------------

    Dres

    Orbiting Sol "near" Kerbin

    GeeASL is increased by a lot (from 0.115g in vanilla to 0.7g)

    Minmus

    Orbiting Dres at around 16Mm

    Craft X

    Creating a simple craft

    Set orbit to Dres similar (below or above) Minmus's. Alternatively just arrive to Dres from Sol orbit and get to a similar orbit to Minmus's. Does not really matter...

    The "speed" of Craft X and Minmus are completely different. Minmus is really "slow".

    ---------------- /Test -----------------

    It seems to me that the orbit and orbital velocity calculation of Minmus is based on the original mass (1/6th of the new settings) of Dres. Or something similar, did not debug the code yet... :)

    If I touch Minmus in Hyperedit again (e.g., orbit editor), then it starts to use the correct mass of its parent body.

    I'm not sure about other bodies yet.

    Please find my settings (based on the beta currently):

    https://drive.google.com/drive/folders/1JVoMl37nr6xqFXHARU3DCNpwQd59NrI4?usp=sharing

     

    ---- EDIT 1 ----

    Yes, it seems that ApplyFileDefaults() goes through FlightGlobals.Bodies in one pass and applying config immediately, no changes to the parent body parameters are considered.

    So if the new parent body (here it is Dres) of the body (Minmus) is later in the list (and Dres seems to be), the orbit will be faulty.

    Suggestion:

    Read up all the config files and order the bodies in a tree (or at least an ordered list by depth) of the parent-child relation. Then apply the configs.

    Opened issue in GitHub: Ignored parent body relations #70

  13. Just found this mod and I love it!

    I've created my own config. It is extremely simple to start with:

    Spoiler
    
    AsteroidSets
    {
            // Handle for hooking MM scripts -- DO NOT use CustomAsteroids_ prefix in your own configs!
            name = KubiAsteroids_stock
    
            ASTEROIDGROUP
            {
                    name = kerbiners
                    title = title_here
    
                    spawnRate = 0.5
                    spawnMax = 5
                    centralBody = Kerbin
    
                    orbitSize
                    {
                            dist = Uniform
                            min = Ratio(Mun.sma, 0.55)
                            max = Ratio(Mun.sma, 0.65)
                    }
    
            }
    }
    

     


     

     

    The settings config file is untouched:

    Spoiler
    
    CustomAsteroidSettings
    {
            RenameAsteroids = True
            Spawner = FixedRate
            ErrorsOnScreen = True
            MinUntrackedTime = 1
            MaxUntrackedTime = 20
            VersionNumber = 1.7.0
    }
    

     

    I have started a new sandbox save (KSP 1.9.1). Entered the tracking station to have a look at what I've done.

    Asteroids start to spawn, reaching the limit of 5 (spawnMax) and disappear slowly as expected according to the parameters.

    Now, the strange thing is that if I do not start to track any of the asteroids, then after all 5 disappear, no new will spawn. If I exit the tracking station and enter again, then they start to spawn again (up to 5 spawn-diappear, then 0 forever). This behaviour is a bit strange, but generally OK as I can set MaxUntrackedTime to infinite (or a lot) so they do not disappear..

    If I start to track all the 5 no new will spawn regardless if I stay or exit - re-enter the tracking station. Good, I wanted this... However an error message pops up (top right corner, yellow text):

    • [CustomeAsteroids]: Could not create new asteroid. Cause:"Could not select population." Root Cause: "The weights of the options may not be all zero. Parameter name: weightedChoices"

    The log snippet that is repeated every time I replicate the fault.

    Spoiler
    
    [LOG 23:18:41.638] [FixedRateSpawner]: Asteroid discovered at UT 7287995.53156512.
    [EXC 23:18:41.772] ArgumentOutOfRangeException: The weights of the options may not all be zero.
    Parameter name: weightedChoices
            Starstrider42.CustomAsteroids.RandomDist.weightedSample[T] (System.Collections.Generic.IList`1[T] weightedChoices) (at <1497dc9bfca8493eb6cc0449773e5f22>:0)
            Starstrider42.CustomAsteroids.PopulationLoader.drawAsteroidSet () (at <1497dc9bfca8493eb6cc0449773e5f22>:0)
            Rethrow as InvalidOperationException: Could not select population.
            Starstrider42.CustomAsteroids.PopulationLoader.drawAsteroidSet () (at <1497dc9bfca8493eb6cc0449773e5f22>:0)
            Starstrider42.CustomAsteroids.AsteroidManager.drawAsteroidSet () (at <1497dc9bfca8493eb6cc0449773e5f22>:0)
            Starstrider42.CustomAsteroids.AbstractSpawner.spawnAsteroid () (at <1497dc9bfca8493eb6cc0449773e5f22>:0)
            UnityEngine.DebugLogHandler:LogException(Exception, Object)
            ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
            UnityEngine.Debug:LogException(Exception)
            Starstrider42.CustomAsteroids.AbstractSpawner:spawnAsteroid()
            Starstrider42.CustomAsteroids.FixedRateSpawner:checkSpawn()
            Starstrider42.CustomAsteroids.AbstractSpawner:asteroidCheck()
            Starstrider42.CustomAsteroids.<Driver>d__8:MoveNext()
            UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr)
    

     

     

  14. Have some questions (bug report?) on the training feature.

    As I understand correctly that the kerbals need to be trained to both crewed modules and to a whole ship too.

    How is the training time calculated?

    Build a ship_a with 1 x module_a, ship_b with 2 x module_a and ship_c with 5 x module_a. I want to train my kerbal to all ships.

    What I observed (might be totally wrong) is that the training time for s ship seems to me something like:

    Ttrain = Tship + Ti * Ni

    • Tship is a constant 20 days (?),
    • Ti and Ni are the time (complexity related?) and number of a given module on the ship,
    • i represents all, formerly untrained modules.

    So, the overall training time for all 3 ships is different depending on which ship I train to first:

    Ttotal = (Tship + Ti * 1) + (Tship + Ti * 0) + (Tship + Ti * 0)

    Ttotal = (Tship + Ti * 2) + (Tship + Ti * 0) + (Tship + Ti * 0)

    Ttotal = (Tship + Ti * 5) + (Tship + Ti * 0) + (Tship + Ti * 0)

    Why is this?

  15. 20 hours ago, Sir Mortimer said:

    This is a WOMM certified* guide:

    1. Install the default KerbalismConfig
    2. In KerbalismConfig/Parts, delete everything but ActiveShield, GeigerCounter and ShortAntenna 
    3. Change your KerbalismConfig/Settings.cfg to what is posted below
    4. Change your KerbalismConfig/Profiles/None.cfg to what is posted below

    Thank you!

    // Kerbalism enables radiation when there is a rule that uses the radiation modifier.
     // Same for shielding. This means that your Kerbals will suffer from radiation poisoning and possibly die.
     // This is the copy from the default profile, if you want to null the effects that radiation
     // has on your crew, set degeneration to a very small value.

    Do I understand correctly that I need to enable the radiation part with a very low degeneration (and variance accordingly?) if I want to see any of the belts or storms?

     

     

     

  16. 21 hours ago, theJesuit said:

    What features are you trying to turn on and off?

    Basically everything except the science related ones.

    I use Kerbal Health and TACLS, and do not really like part failures and part qaulity either.

    The ScienceOnly config is great, but it loses the belts and storms virtual biomes.

×
×
  • Create New...