kubi

Members
  • Content Count

    77
  • Joined

  • Last visited

Community Reputation

13 Good

About kubi

  • Rank
    Bottle Rocketeer
  1. 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.
  2. Thanks for the hard work! I'm checking the changes in the code, but started to feel that I need to put together a dev environment. Can you point me to a howto (PM is OK too).
  3. No problem! This is the beauty of a beta (alpha?) version If you upload the latest to GitHub, I will have a look tomorrow.
  4. 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)
  5. 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...
  6. 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 outside of the SP iteration 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. 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? It is like Is this intentional?
  7. 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
  8. 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.
  9. 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...
  10. Hi, I'm on 1.10 ans Kopernicus 1.10 pre from R-T-B. Many mods too. The only issue I saw is that the non-retractable 1x6 solar panel does not break coming back to Kerbin from orbit.
  11. 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
  12. Thanks @Starstrider42! The trojans near the Mun are perfectly working based on the example configs. Now I have 10-10 of those. I was checking the code too and it seems to me that the spawning of asteroids depends on the facility level being able to detect them. Have you been looking into if it would be possible to use the telescope before upgrading the facility?
  13. And now a question Is there an example on how to position asteroids to/ around a lagrange point? Or, to make it simpler, some degrees before/after a planer or a moon.
  14. Just found this mod and I love it! I've created my own config. It is extremely simple to start with: The settings config file is untouched: 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.