• Content count

  • Joined

  • Last visited

Community Reputation

17 Good

About Hacki

  • Rank
    Bottle Rocketeer
  1. Very nice, that did it! I added this conversion of TimeWarp.fixedDeltaTime to consumeFNResource() in ORSResourceSuppliableModule.cs and to OnFixedUpdate() UniversalCrustExtractor.cs, now it works! What i dont get is why that is necessary. Just for the fun of it i checked if float TimeWarp.fixedDeltaTime is equal to double TimeWarp.fixedDeltaTime - and the program says yes. So why does it introduce a delta when you use the typecast value to do some math, when it apparently is exactly the same? I think UniversalCrustExtractor could use some love in general, it looks like all of that code is run for each single drill present on a craft, which is also why every drill opens up its own mining UI. Shouldnt it be enough to run it once and multiply some values by the number of drills?
  2. I had a look at the drill-power-thing as well, and it looks like it's caused by floating point errors. This part of the code: private bool HasEnoughPower(double deltaTime) { if (CheatOptions.InfiniteElectricity || mwRequirements == 0) // is the cheat option of infinite electricity ON? Then skip all these checks. return true; double dPowerRequirementsMW = PluginHelper.PowerConsumptionMultiplier * mwRequirements; Debug.Log("dPowerRequirementsMW:" + dPowerRequirementsMW); // calculate the provided power and consume it double dPowerReceivedMW = Math.Max(consumeFNResource(dPowerRequirementsMW * deltaTime, FNResourceManager.FNRESOURCE_MEGAJOULES), 0); Debug.Log("dPowerReceivedMW:" + dPowerReceivedMW); double dNormalisedRecievedPowerMW = dPowerReceivedMW / deltaTime; Debug.Log("dNormalisedRecievedPowerMW:" + dNormalisedRecievedPowerMW); // when the requirements are low enough, we can get the power needed from stock energy charge if (dPowerRequirementsMW < 5 && dNormalisedRecievedPowerMW <= dPowerRequirementsMW) { double dRequiredKW = (dPowerRequirementsMW - dNormalisedRecievedPowerMW) * 1000; double dReceivedKW = ORSHelper.fixedRequestResource(part, FNResourceManager.STOCK_RESOURCE_ELECTRICCHARGE, dRequiredKW * deltaTime); dPowerReceivedMW += (dReceivedKW / 1000); dNormalisedRecievedPowerMW = dPowerReceivedMW / deltaTime; } return dNormalisedRecievedPowerMW >= dPowerRequirementsMW; } Is apparently inherently flawed, as dNormalisedRecievedPowerMW is always smaller than dPowerRequirementsMW by some minute fraction because of - i guess - floating point errors. I made a debug built that prints out various values and this is what i get for the different tweakscaled sized drills: [LOG 11:46:38.439] dPowerRequirementsMW:1 [LOG 11:46:38.440] dPowerReceivedMW:0.0199999991059303 [LOG 11:46:38.440] dNormalisedRecievedPowerMW:0.999999977648258 [LOG 11:46:40.983] dPowerRequirementsMW:8 [LOG 11:46:40.984] dPowerReceivedMW:0.159999992847443 [LOG 11:46:40.985] dNormalisedRecievedPowerMW:7.99999982118607 [LOG 11:46:42.741] dPowerRequirementsMW:27 [LOG 11:46:42.742] dPowerReceivedMW:0.539999975860119 [LOG 11:46:42.743] dNormalisedRecievedPowerMW:26.999999396503 [LOG 11:46:44.301] dPowerRequirementsMW:64 [LOG 11:46:44.302] dPowerReceivedMW:1.27999994277954 [LOG 11:46:44.303] dNormalisedRecievedPowerMW:63.9999985694885 The first two versions of the drill only happen to work because of that bit in the middle, which makes drills with less than 5MW eat electric charge instead of megajoules. Although that bit has me scratching my head as well, especially this line: I'm no programmer, i dont know how to deal with floating point errors like that. I could replace the >= check with something like "is the received power withing 99,9% of the requirements?", but that seems a bit hack-ish and like there should be a proper way. Edit: Nevermind, found it. The function MineResources takes TimeWarp.fixedDeltaTime as an argument, which is a float, but converts it to a double, so a very neat 0.02 becomes 0.0199999995529652. Edit again: This is where you notice i'm no programmer. convering from a float to a double shouldnt destroy any information, so whats going on here? I'm lost.
  3. This issue is not limited to Fluorite: Again no mining (of Alumina) in this scene even though resource scanners and mining ui says 9,9% locally. I have been poking around in the interstellar sourcecode a bit and cant really make heads or tails of this issue. It almost looks to me like a stock bug, why would the global abundances return 0 when there's something there locally? I could think of a fix; in this little bit here in UniversalCrustExtractor.cs: private double CalculateResourceAmountCollected(double minedAmount, double globalPercentage, double localAbundance, double deltaTime) { double resourceAmount = minedAmount * globalPercentage * localAbundance * deltaTime; return resourceAmount; } Just throw out globalPercentage and all should be dandy. I tried, and it works. But since since a <1 multiplier is missing, i believe mining is a tad too fast. Why exactly the game says "0" at that point is beyond me. Oh and i noticed another thing; more funny than a problem: The drill does not play any animation when mining on land. If its splashed down in water and extracting intakelqd it'll play the stock drill animation, kicking up dust. I think it should be reverse, right?
  4. I think something went wrong there, because i still get the same number of drill guis as there are drills on my vessels. Is it even necessary to have the GUI pop up any time the drill touches the ground or is activated? I noticed something else: Tweakscaled universal drills arent really usable. They always say "insufficient power", even if thats not true. At 0.1x physics timewarp it enables shortly and shows up in the UI with 64MW, which shouldnt be too much. Drill works with the infinite electricity cheat enabled though. Third, something's wrong with fluorite. I did a clean 1.3.0 install and only added the contents of your most recent interstellar zip-file (well, and hyperedit). Even though the Resource scanner, overlay and mining ui say there's fluorite present it wont get mined on most planets. What i noticed is that it will mine just fine when the UI shows a number under "global 1" and or "global 2", "biome" and "local" But on all planets except kerbin there's only a number under "local", and nothing gets mined. (The fluorite in the resources UI is from kerbin, i hyperedited the vessel around to check if stuff gets mined or not) Now the question is, why are the two global fields empty? I cant figure it out..
  5. Ah, but those are not the numbers i am talking about. I dont know where KSP pulls the numbers from that go into the savefiles. See https://wiki.kerbalspaceprogram.com/wiki/Orbit#Reference_code Gael for example did have the ID 5 and now has the ID 1
  6. That'd be appreciated! By the way - thanks for all the work. I usually get bored with KSP after having the mun and minmus explored, but GPP somehow has made it so much more interesting for me.
  7. Indeed, but i refuse to give up... The only problem i'm seeing is that the planets IDs have changed. I'm trying to fix my GPP 1.2.3 career save by replacing the IDs in the savegame. Do you happen to have a list of old / new IDs for all bodies? So far i found i need to replace: - "body = x" directives in all CONTRACT {} as well as CONTRACT_FINISHED{} sections - "REF = x" directives in all ORBIT{} sections That appears to be mostly it? The other thing is that due to terrain changes some, if not all landed vessels will be spawned above of below the surface, so keep hyperedit handy. Beats starting over when you're 25 years into a successful space program.
  8. Glad it worked out in the end
  9. Sure, here's an imgur album:
  10. Headscratching intensifies. I think you put the DLL in the wrong place, i just re-downloaded the file i put into my dropbox, added it to the KSP dir and it should look like this: If it doesnt show any Error:[IRSurfaceSampler] lines it's not using my DLL.
  11. The version i gave you should be a debug version, that is, it'll dump some stuff into the ksp log when you hit the button. Could you open the debug console with Alt+F12 and see what it says when you hit "drill surface sample"?
  12. I patched the sourcecode and compiled my own version of the surface sampler dll. The code changes are already in the main branch on github, but theres no updated dll yet. You can download my version here: https://www.dropbox.com/s/w13dbasuoshjpqj/IRSurfaceSampler.dll?dl=0 Drop it into <your path to ksp>\GameData\MagicSmokeIndustries\Parts\Rework_Utility\Plugins
  13. Hi, I just updated this mod for version 1.2.2 Source is available here: https://github.com/alismatales/KerbalSlingshotter Complete Plugin here: https://www.dropbox.com/s/6eb6jq1wvvl5vox/SlingShotter_1.2.2.zip?dl=0 Now consider yourself warned, i'm not a programmer. I just know how to screw around with code and hit the compile button. So it might make your game crash at some point. Report any bugs here, and i'll see what i can do. I wont implement any new features, that's a bit outside my abilities. Perhaps somebody who knows what they are doing (paging linuxgurugamer) feels like picking this up.
  14. The problem with the sampler not working was caused by my using galileo planet pack and the way the surface sampler code tries to determine if its touching something sample-able. I wrote a patch for that and made a pull request for it on github. The weird visual collision glitch remains, but the sampler works whether it "sinks" into the ground or not.