Jognt

Note that experiment gain percentage is no longer like it was. It grows smaller with every measurement of the experiment. Due to the way the game calculates it now I'd honestly go for baseValue. As long as an experiment has collected its baseValue (so it's been run once) it's completed. Any other value is going to be arbitrary in the sense that it's "Am I done after 4 samples? 10? 3?" or "How many runs does it take to get to 90%?" whereas the user is either going to consider an experiment done when they've done it once (maybe twice, if it has a nice payoff, which it no longer has) or when they've done it as much as they need to to get the full scienceCap. Getting the scienceCap is not going to happen anymore, so you may as well go for the "have run once" value and allow the user to show experiments that have any remaining value. Ps. I've rewritten my trainwreck of a post 3 posts up. I hope it's more readable now.

Yeah I read somewhere that the auto "add to ckan" thing stopped working a while back, so it's basically the guys manually checking whether someone checked the box. I'll follow the thread, hadn't thought about that yet! Good idea

I'm pretty sure you can drop the "Sort of" bit in the OP after "I made a mod!" - Because ohmygod did you make a mod! <3 What's the best way to know there may be updates for this? As it's not on CKAN and my KSP.exe is kinda.. locked out of the internet. I'm guessing it's manual labor?

Cheers! You're an absolute legend!

Also true. But usually the topic title is the first to be updated IPoAC.. *shudder*

Honestly? I found the mod Science - Full Value years back, and I've not played without it since. (it makes it so you get the full value the first time, no need to repeat) So I really can't say anything about balancing. I did find that Squad changed Science a bit with 1.7.1 in that you can't gather the full science worth of an experiment anymore, which is what you're experiencing. [x] Science would need to be updated for this. Since this change defaults to being applied, it also affects every experiment we're used to. The cynic in me assumes this is one of those "Get our users to never be done" carrot-on-a-stick thing. =============================== If you want to go back to the old way of gathering science where 3 to 4 samples got you the max science for an experiment you'll have to edit the EXPERIMENT_DEFINITIONs for those experiments. The value you need to add is applyScienceScale = false. This will return the old functionality to experiments that haven't been run yet. Experiments that you have run are saved to your persistent.sfs with their DIMINSHING_RETURNS (not my typo) value. You can try and edit these values (asc = false & scv = 1), but that's at your own risk. Quick test results: I used 8x Mystery Goo and used them all in the same spot to see what the max science was that I could get with the new system (no applyScienceScale, it defaults to true): 10 data value 0.30 - 3.0 science 10 data value 0.02 - 0.2 science 10 data value 0.01 - 0.1 science The remaining experiments (5x) did not give any science at all, despite there still being science left to gather. I then added applyScienceScale = false to the Mystery Goo EXPERIMENT_DEFINITION and used the same craft to get Goo values from another place at the KSC: 10 data value 0.30 - 3.0 science 10 data value 0.07 - 0.7 science 10 data value 0.02 - 0.2 science The remaining 5x experiments were again not listed anymore, but this time we maxed out the Goo experiment with the first three. Like always. Conclusion: Without mods, you will always only be able to collect a part of the collectible science, never the whole chunk, no matter how small. ===================== With this new system Squad added a variable to the persistent.sfs savefile called "asc" which remembers the applyScienceScale value. Here are all the values the game saves to persistent.sfs with their meaning attached: Science { id = mysteryGoo@KerbinSrfLandedKSC // Identifier title = Mystery Goo™ Observation from KSC // speaks for itself.. dsc = 1 // dataScale. scv = 0.162092224 // Subject Value. Multiplier on the collected science AFTER the old multipliers are done. Is set to 1 for applyScienceScale = false sbv = 0.300000012 // Celestial Body multiplier sci = 3.26784039 // Amount of science already gathered asc = True // applyScienceScale cap = 3.9000001 // scienceCap for this experiment } I'm guessing that applyScienceScale utilizes the new DIMINSHINGRETURNS entries in Serenity/resources/deployedscience.cfg. Time will tell whether Squad meant to only use this new feature for the new experiments and forgot to add applyScienceScale = false for the old experiments, or if this is an intentional change across the board with only a few exceptions like the new ROCScience_ experiments. Pinging @Sir Mortimer, @SilverState, and @Tekaoh since this covers our recent chat in the Science - Full Transmit thread. Edit: Rewrote/cleaned up this post. It was a total trainwreck.

In that case, I think you could squish the above bit into @PART[dmSIGINT.Small|dmSIGINT.End|dmSIGINT|dmscope]:NEEDS[CommunityTechTree,DMagicOrbitalScience]:BEFORE[zzzUnKerballedStart] { @TechRequired ^= :miniaturization:experimentalScience: @TechRequired ^= :advScienceTech:longTermScienceTech: @TechRequired ^= :advExploration:miniaturization: } I haven't tested it but I think it should work, and it saves on lines edit: In case I'm totally missing something, let me know.. Because part of me is facepalming in the back of my head, so I'm probably missing something obvious..

Thank you so much. I've been wracking my brain on how to get the MeM balanced with RCS due to the built-in unbalanced stuff. I'm just going to give it a RW that uses monoprop

It's too bad some jokes don't work in english.. ( "Min" means "Minus" in Dutch, so I giggled about "min minmus" or Minus MinusMus.. I need to go grab coffee don't I?)

It's a good idea to tell users they can often try older mods on newer installs. It's a bad idea to tell users they should flip that safety switch to Off. Planetshine works on 1.7.1, sure. But @tsaven has a very valid point. Remember: Every time someone suggests to add older versions to the CKAN compatibility list, someone goes into a thread asking for support on a not-said-to-be-compatible version of a mod Until the mod has its metadata updated to reflect its compatibility, a manual install or widening the CKAN filter is an option. But the CKAN filter is there for a reason.

@kcs123 Y'know, I agree with your proposal to remove FINAL, but don't you think you should let the guy manage his own mod?

It looks like Squad changed Science with the most recent update. It's no longer possible to cap science the way we used to so if you're running an up-to-date client, could be that that's what you're experiencing.

Thread title says 1.7.1. It's not going to get more reliable than that :p

Ah cheers. I'll try switching scenes next time it acts up. If you can't easily find why the Control Panel is shy, it's probably easiest to just reset the Control Panel position when the user presses that R for resetting controllers. I think Bon Voyage will be all set for Bon Voyage-ing! Any plans to switch to the torqueCurve speeds or is that not a "easy to do" thing? By the way, is it possible to set BV controllers to Disabled by default and/or hide the Rotation PAW entry?

Just a heads-up: Updating via CKAN will also overwrite the user's configuration file(s). I was wondering why the game felt so stutter-y..

Out of interest, are you running any mods that interact with science?

Or, y’know: “No available storage for [wasteproduct], venting into space.”

vMax - Part vs Bon Voyage Wheel Part vMax (m/s) BonVoyage vMax (m/s) roverWheelS2.cfg 12 11 RoverWheel.cfg (MH) 25 42 roverWheelM1.cfg 34 42 roverWheelTR-2L.cfg 58 59 roverWheelXL3.cfg 15,5 14 About the bug; I've recorded and uploaded it. Timestamps: 1:16 - New Game nullref 4:55 - Spawning the KerbRover Centipede 5:07 - Control Panel decides to GTFO 5:35 - "Bon Voyage Control Panel" button not working (though it may be popping up off-screen due to 30 seconds earlier) 5:40 - Errors and duplicated Controller entries in the Bon Voyage main window after Reload Controllers The rest is faffing about and not being productive. Here are all the files I can possibly get you: Outputlog: https://www.dropbox.com/s/ndkoksvz3s96tdd/BVoutput_log2.zip?dl=0 KSP log: https://www.dropbox.com/s/z36gcs3ccrdilx7/BVKSPlog.zip?dl=0 Craft used in video: https://www.dropbox.com/s/ic6v4hehvabhby7/BV58m_s.zip?dl=0 BV config file after Control Panel ran off: https://www.dropbox.com/s/jc9q9rtxuqwd0bu/BVconfig.zip?dl=0 I got the speeds listed above from the respective part's torqueCurve. You can extract these speeds by targeting MODULE[ModuleWheelMotor*] and going for key[0] from torqueCurve/key,-1. That's always going to be more accurate than wheelSpeedMax (no idea why they added it, and only to SOME parts tbh). The massive wheels have the curve in ModuleWheelMotorSteering as they have no ModuleWheelMotor, hence targeting ModuleWheelMotor* Whelp, that's about all the detective work I'm doing today. Hope it's helpful.

Cheers! Thanks for popping in. I'm still not quite sure how this would matter for a mod as simple as this one though. I don't know whether the problem @Tekaoh mentioned is there without the mod but I'll assume it is, but this mod doesn't do grand things with science and like @Sir Mortimer said on the github Commit: "Usually this doesn't affect the game at all, because science usually is done in one chunk." So why would it influence ground experiments when their definition isn't even touched? Edit: Of course all this is moot if the problem is also there without the mod as the bug report could suggest, in which case it's a base game bug and the mod itself is working fine maybe?

Note that I was referring to Elite: Dangerous with that "Yup, looks the same" remark. With regards to "So enjoy the mod for what it is, because that’s all it ever will be." - That's how it should be. The best mods (and games!) are those that stick to the ideal/vision of the creators and don't try to cater to everyone's needs/desires.

@_Zee The DMagic parts are hidden/deprecated yes, but the following parts in US2 are ingame: GameData/UniversalStorage2/Parts/Science/AccelGravWedge.cfg GameData/UniversalStorage2/Parts/Science/ThermoBaroWedge.cfg GameData/UniversalStorage2/Parts/Science/FluidSpectorWedge.cfg They utilize a different MODULE for their science ("USSimpleScience") but utilize the regular experimentID/xmitDataScalar setup. And I'll certainly keep testing with my contract tweaks. As always it's not as simple as it seems. ================================ With regards to Breaking Ground: Only the few new parts that'd need placing, though Squad did 'something' to the way Science works that may show side effects later (hasn't yet afaik). ================================ Congratulations with regards to the job!

I understand you're burned out from the Kerbalism 3.0 work you've done as I cannot even begin to imagine the amount of work that took. I'm quite interested in seeing what can be done with this mod still. Because after all, I didn't work on Kerbalism so I still have quite a bit of energy to burn. For example, these science changes you mention, are they in 1.7.1 or in Breaking Ground? Because depending on the answer the mod can still be perfectly compatible with KSP going forward yet never be compatible with Breaking Ground. So while respecting the fact that you're really not looking to get back into this rabbit hole, I'd like to second Tekaoh's request for anything that may help understand this new behavior. Perhaps @Sir Mortimer or you can point us to where he found this information? Even if this specific patch/mod isn't going to work anymore, I have quite a few local/personal stuff that also deals with this. So I'd really like a better understanding of it.

Just tested the latest version. The NullRefs during the 'freak out' is gone, but the control panel itself still freaks out. I also got the controller window to do its 'offset dance' again where it moves each time you summon it, eventually going off screen. I'll see if I can get a solid repro method down (since I didn't get that offscreen dance the previous time) or if I can just record it so you can maybe decypher it. I also checked the wheels and their speeds: The first tiny wheels are listed as 12m/s max. BV lists them as 11m/s. The MH wheels: 25m/s part, 42m/s BV. (instead of the previous 120m/s) The old munrover wheels (inflatable ones): 34m/s part, 42m/s BV. The 'car' tires: 58m/s part, 59 BV. The HUGE construction wheels: 15.5m/s part, 14m/s BV. It's.. wonky.. I'll do some more digging and testing on a new new fresh install (just to be sure) and I will keep you posted.

As long as you keep in mind that it's enjoyable, it's all good. Just don't go too far into the Realism hole. I spent a LOT of time in Elite: Dangerous for example, only to sigh and come to the conclusion "Yep.. Same as all the other planets I've found and landed on." (though the sights.. oh man, the SIGHTS!) Oh, and don't go so far into Realism that you'd remove time warp. plz don't.

Cheers! Thanks a bunch! Regarding the other wheels: Can you confirm for me if the max BV speed should be equal to the listed max speed of the wheel parts? (No multipliers or something) Regarding the new game error: I'm not sure were talking about the same error, the installation I tested on was a fresh KSP instance from the GoG download, though it was still on the same disk. The error I referred to is this one: Exception handling event onNewGameLevelLoadRequestWasSanctionedAndActioned in class BonVoyage:System.NullReferenceException: Object reference not set to an instance of an object at BonVoyage.BonVoyage.OnLevelWasLoaded (GameScenes scene) [0x00000] in <filename unknown>:0 at EventData`1[GameScenes].Fire (GameScenes data) [0x00000] in <filename unknown>:0 (Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/DebugBindings.gen.cpp Line: 51) NullReferenceException: Object reference not set to an instance of an object at BonVoyage.BonVoyage.OnLevelWasLoaded (GameScenes scene) [0x00000] in <filename unknown>:0 at EventData`1[GameScenes].Fire (GameScenes data) [0x00000] in <filename unknown>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) EventData`1:Fire(GameScenes) <FireLoadedEvent>c__Iterator1:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) (Filename: Line: -1) Which has the following just before it in the previously linked log: OnLevelWasLoaded was found on BonVoyage This message has been deprecated and will be removed in a later version of Unity. Add a delegate to SceneManager.sceneLoaded instead to get notifications after scene loading has completed (Filename: Line: 380) Script error: OnLevelWasLoaded This message parameter has to be of type: int The message will be ignored. I doubt it's a huge deal as it only pops up when starting a new save, the first time the SPACECENTER scene gets loaded and it doesn't come back after that. Let me know if you're referring to the same error but can't repro it. One detail: KSP is blocked from accessing the internet on my PC, not sure if that'd impact it?