Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by Hacki

  1. @FreeThinker .. couple of things.. I'm currently working on fixing some stuff with the direct cycle nuclear turbojet, candle engine, molten salt reactor and the open cycle gas core reactor. Namely: Swapping fuel is broken. From the way the code is written i can only assume it worked in earlier versions of KSP and is now broken in 1.3 I wrote a fix that works for me, you can check it out on my github I'M not 100% satisfied with it though, whenever you click "swap fuel" the old fuel indicator travels to the top of the context menu, and any time you click it again it adds a new fuel indicator to the context menu, making it ever longer. This seems to be a display bug since everything looks OK when you reopen the context menu. Now.... I'm thinking that could be fixed if there's some way to force-redraw the context menu. Do you have any idea how that could be accomplished? Oh, while i was at it i also implemented a little bit of code that'll hide the "switch mode" button in the context menu if there is only one mode available. Some other unrelated stuff... : - Using "swap fuel" as an Engineer on EVA works on the candle, turbojet and molten salt reactor, but fills up the new fuel type to full, essentially creating resource out of nothing. Should we keep it that way? Should we empty the new resource after a fuel swap? That would run the risk of people accidentally dumping their fuel. OR remove the EVA fuel swap option altogether; i dont see much use for it anways. (Also i just noticed that clicking "swap fuel" on EVA when the fuel is empty you get a nulref exception.) - There does not seem to be a way to create Plutonium-238 in situ. Plan on adding one? (This was the reason why i started fixing the fuel swap bug... I really like the candle engine, and found it a shame that i couldnt built it with extraplanetary launchpads) - Interstellar adds a huge amount of clutter to the context menus. I'd like to simply remove some of the lines. Some of this stuff looks like it was built in for debugging purposes? - There are a lot of resources that arent used or arent obtainable outside the VAB/SPH. - Spodumene isnt used at all, even though you can mine it. Its chemical composition in real life is LiAl(SiO3)2; so it should be processable into lithium, aluminium and oxygen? - Sodium, Carbon, Caesium, and Boron can be produced, but seem useless after that. At least i didnt find anything you could do with them. - Decaborane, Hexaborane, Lithium Hydride and Lithium deuteride are used in some fusion engines/ reactors, but there dont seem to be any ways to obtain it with some ISRU process either. Do you plan on doing anything with them in the future? I dont think we should be able to produce any materials that dont have any use, that only adds complexity and confusion. If there is no use for a resource, we should remove it. And i think it should be possible to produce all usable resources off-world in one way or the other. On that note, community resource pack adds a whole bunch of useless stuff. I'm aware that is partly for compatibility with other mods, but couldnt we write a module manager patch that removes the stuff it if isnt used? I dont need gypsum, dirt, exotic minerals, karbonite, karborundum, minerals, raremetals, substrate, ... etc. It only clutters up the UI and makes the already complex ISRU chain more confusing. Soo... what do you think?
  2. So i have taken it upon myself to create a chart for all the IRSU ISRU processes in interstellar. This magnificent subway plan is the result: I created this on https://www.draw.io/ - you can load this XML file to edit the chart - in case anyone feels like cleaning that up. Water gas shift and reverse water gas shift are missing, solar wind and regolith process dont have input resources on the chart (forgot). Theres only so many hours of playing around with a chart before you'll go insane, and i'm afraid i've reached that point for today. Maybe i'll create a cleaner version over the next couple of days..
  3. I'd love to, but i'm afraid i dont have the time to immerse myself in something larger than hunting some small bugs. In any case here https://github.com/alismatales/KSP-Interstellar-Extended/commits/master you can find the changes i did over the last two days to make the universal drill a bit more usable. You might not want to pull that straight to the master branch, but at least you'll find where the issues are easily with that.
  4. 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?
  5. 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.
  6. 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?
  7. 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..
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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"?
  13. 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
  14. 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.
  15. 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.
  16. Try lowering the shuttles rear landing gear and drive up the wing?
  17. Well, i just ran into it because i got the bright idea to do this: That is; drop little science-packages all over the planet to get Science from all the Biomes without having to actually land a plane there. FMRS is quite handy for this type of missions since your plane will either crash and burn when you're not controlling it or quickly fly out of range and get deleted. I only ran into this problem since neither auto-recovery nor manually recovering the dropped stage worked properly before. Since manually recovering the stage immediately after dropping works properly now, its not an issue anymore, for me. I'll see if i can find out why autorecover doesnt seem to work on my modded install.
  18. Did you run an experiment that you havent run before? Error only occurs under that condition. Video:
  19. Almost; works as expected with F3, the Escape key still triggers it since it pulls up the UI again. No idea if there are other buttons that can pull the UI back up. Why dont you use: GameEvents.onShowUI (); GameEvents.onHideUI (); So you wont have to worry about individual buttons but let the game handle wheter the UI is hidden or shown. Indeed! Very nice. Unfortunately not. I just tried in Stock and i noticed something else; with my mod-pregnant KSP instance the auto-recover function does not work. Ok so i have learned something new about the science bug: When using auto-recovery, no science is lost. When directly retrieving the science-probe by clicking "recover vessel", no science is lost either. ONLY when you go back to the main mission by clicking "Return to main mission" in the FMRS window and then retrieve the science-probe from the tracking station or space center screen does the science get lost: [ERR 20:00:17.878] [Research & Development]: Experiment in sensorBarometer has scienceSubject [email protected] defined, but no such subject exists. Heres the logfile; stock game: https://www.dropbox.com/s/myf6zzyre31gkuy/KSP.log?dl=0 (15MB) Two flights in there, one with auto-recover enabled where everything works as expected and the second where i tried to force the science-bug by disabling the auto-recover function. Theres something else i found, sometimes when recovering a vessel unrelated to your FMRS-flights, the popup window showing your returned funds etc. immediately disappears. Cant reliably reproduce it though. Maybe its even a stock bug.
  20. Yes this works but have you watched: Those videos are the only reason i expect this functionality.
  • Create New...