kubi

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

Yes (with KSP.x86_64, not tested with other methods), thanks! Jeb is standing on a bump!

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

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

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.

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

No problem! This is the beauty of a beta (alpha?) version If you upload the latest to GitHub, I will have a look tomorrow.

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)

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

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?

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

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.

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

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.

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