toadicus

Rumchiller and hjrrockies, please try the latest version of ToadicusTools from KerbalStuff and see if it solves your problem. I'll try to repackage things and get a proper fix out soon. praise the suuun, I put some logic in a while ago to make that configurable, but at second glance I think it's wrong. I'll fix it before too long. In the meantime, if you're going to recompile the plugin to accomplish this yourself, take a look at lines 202-208 in ModuleTweakableDockingNode.cs: Tools.InitializeTweakable<ModuleTweakableDockingNode>( (UI_FloatRange)this.Fields["acquireForce"].uiControlCurrent(), ref this.acquireForce, ref this.dockingNodeModule.acquireForce, prefabModule.acquireForce ); You can add multipliers to the method call, thus: Tools.InitializeTweakable<ModuleTweakableDockingNode>( (UI_FloatRange)this.Fields["acquireForce"].uiControlCurrent(), ref this.acquireForce, ref this.dockingNodeModule.acquireForce, prefabModule.acquireForce[B], 0, // This number reflects the multiplier on the prescribed value used to determine the lower bound on the tweakable. Cannot be less than 0. 200 // This number reflects the multiplier on the prescribed value used to determine the upper bound on the tweakable. Cannot be less than lowerMult.[/b] );

rumchiller, first off: I'd recommend against using that upload site in the future. I've got an adblocker going, and there were still so many fake download buttons that it took me like 5 tries to find the one that actually downloaded your file. The rest redirected to phishing sites or downloaded executable files deceptively named like your file (e.g. output_log.txt.exe, which on most Windows installations would just look like output_log.txt). The log that I was finally able to download, though, stops during the spacecenter load; it doesn't get as far as the editor or flight modes. Maybe the upload site truncated it, or maybe you quit the game before going to the editor? If you can get me the whole log I'll try again. Good to hear, LostOblivion! I'll get a maintenance release out soon. I was hoping to have the skill-based in-flight engineering stuff ready before the next release, but I've got enough outstanding dev at this point that I'm not sure it's worth continuing to wait.

Rumchiller, if you can get me a debug log (Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log) I'll take a look and see what's up. It's almost certainly a mod incompatibility or installation problem.

I'll see about adding a check box to change those columns to reflect sea level, or similar. I've added time to equatorial An/Dn to the extended info in the Orbital tab internally. Thanks for the request! As you've discovered, the Source folder is not necessary. It's there to fulfill a rule or two about distributing mods on the forum. Welcome aboard!

Any career game taking itself seriously should have engineering data (says the guy who writes a mod that presents engineering data; I might be biased). That said, if a "hard mode" game is going to have relatively low profit margins and high costs for failure, optimizing ships will (finally) be important, and optimizing ships without real engineering data is a tedious chore. That is an intentional effect of my proposition, or actions like it. The purpose of slowing down progress with upgradeable buildings is -- presumably -- to promote education and keep beginner players from getting in over their heads too quickly. "Hard mode" should have steep costs for failure, but success in the early stages of the game should be swiftly rewarded with rapid progress. I'll be sure to post here with my thoughts once I've had a chance to play with the cost modifier some. I can write mods at work sometimes... but I still need to find time at home to play the game. I don't want to open that can of worms, so I'll just say that I don't consider part tests for low-efficiency launch boosters on the Mun to be a good example of a meaningful "hard" contract. If that needs discussing, let's make another thread for it. I do use KCT to regulate time, so I won't get 1000 ships before the Duna window. I could get several dozen, though. But again, that's another issue. Boosting "big story" contracts is probably a good idea, provided the penalty for failure gets a lot higher. I completed the Mun story mission in a 15k ship; if I'd lost it there would have been no impact on my space program at all.

ghpstage, it's true that my numbers center around a single contract, and it may be that the satellite contracts need to be nerfed. At this point, though, it would be madness not to use them when making money is what you want to do. Also, no other contracts are going to get buildings unlocked in less real time, so in general reducing the amount of grinding is a good thing. That said, I'll happily admit that my numbers were exemplary in nature and someone with easy access to all of the real data should definitely have a look at things before taking my word for it. That said again, I've written a little mod to do what I proposed, and am going to play with my numbers and see how I like it. As regex said, reducing the amount of grinding is the most basic method of addressing grinding. If you want to more strictly look at ensuring that a single task need never be repeated, then Squad will have to completely reinvent their career mode. Deciding to play the game with nothing but probe cores is a fine choice for you and occasionally interesting. However, based on basically everything Squad's ever done to date, that's almost certainly not their vision for gameplay. That it is a frequent symptom of the current system implies that the current system is not fulfilling their goals for it. I feel like you and I are actually generally agreeing on the big picture items, and disagreeing about semantics and subjective assessments. "Too much grinding" for you might be more grinding than "too much grinding" for me, and that's fine. We both think the game is too grindy -- you to a lesser degree than I, it seems -- and we both think funds are unbalanced. I'd love to hear your suggestions! CaptRobau, ghpstage#2, ObsessedWithKSP, actually-challenging contracts well outside the scope of those currently in the game definitely sound good to me. As long as funds are balanced, too. ghpstage#2.5, let me say that for my part I don't like skipping a whole bunch of time waiting for the Duna window; I like to keep my space program constantly active. As soon as it's open, I'll send something wherever I am in the tech tree / building upgrade game. Also: only 250k? I mean, that's a fair bit more than a satellite contract, and especially for a place like Duna would not be expensive to perform... but still, something as momentous as landing on another world is only worth a third of a single R&D upgrade? I don't know what body is funding these Kerbals, but those guys are some real misers. Thanks for listening and discussing, folks; stay civil and keep it up.

LostOblivion, I looked into the procedural fairings incompatibilities and, after some searching, tracked it down to this line in ProceduralFairings: mj.jettisonName=null; e-dog is clobbering the jettisonName string to null when removing the engine fairings... which I'm pretty sure is superfluous, but either way, I have been keying a few things based on jettionName. So, I've added null protections against jettisonName to ModuleTweakableJettison, and both the poofing and the exception messages go away. Also, I followed your steps for the older procedural fairings incompatibility and nothing bad happened. I've made a few tweaks here and there since you reported it... maybe I fixed it accidentally? If you could, please try the updated ToadicusTools from my link to OWKSP above, and this development version of TweakableEngineFairings, and let me know if the problem goes away. Do note, because of the way ProceduralFairings does its thing, I can't turn back on fairings that it disables. Glad it worked, ObsessedWithKSP! Good luck canning Moho.

ObsessedWithKSP, will you try the latest ToadicusTools version from KerbalStuff, or confirm to me that you're using it already (perhaps via CKAN download)? I added a bit of extra null protection in the last revision that will probably protect against what you're seeing. It might cause things to operate funny, though, because by the time this is running all of the parts should really have their .Modules fields properly assigned. I'm pretty sure this is a symptom of a whole bunch of mods resulting in load times long enough that KSP or Unity starts to do things out of order. If that does stop the exceptions, but leaves things operating strangely, please let me know; there might be some re-ordering I can do to help that as well. *EDIT* Also, thanks again!

The fact that interplanetary missions are feasible at this stage isn't really the point. I know that they are, but it's a bit impractical and doesn't invalidate complaints about "lack of risk, spammability and huge ROIs of several Kerbin SOI contracts", which I am specifically addressing. Also, is Squad's intent for us to run a swath of interplanetary contracts while stashing enough science to finish the entire tree without unlocking 2/3 of the parts? I don't think so. I'm not saying "I can't do anything," I'm saying "my available options are not good ones, and the current gameplay is wrong." I do agree that science costs in general should skyrocket, to devalue the science in the Kerbin SOI relative to the rest of the system, but again, that's another issue.

I agree that to genuinely offer a "hard" mode, the game needs improvement to offer "hard" challenges. Perhaps the science game could be revisited to be more than just "get there and click", or new contracts could be offered that pose a genuinely difficult challenge. But, that's a bit off-topic for this thread, as I'm suggesting a specific improvement to an existing system.

There have been numerous threads before discussing the imbalance of Funds and Science; specifically that the amount of effort required to upgrade buildings at higher difficulty settings is disproportionate to the amount of effort required to unlock science. This leaves players with large but unusable stockpiles of science while they grind through funds-heavy contracts. I want to look briefly at why this is bad, and why this is failing to provide a meaningful "hard" mode. In my current career game, I am playing "Moderate" difficulty with the two "Hard" toggles unchecked (no reverts, no quickloads). I've got a handful of buildings upgraded once, and am staring down the barrel of the first R&G upgrade at 785 kilofunds. I have science->funds and rep->funds strategies on, have unlocked all of the tier 1 science, and have a 90% profit margin on Kerbin-orbit satellite missions. I can complete any Kerbin-orbit satellite mission with a 10k craft, and get over 90k in reward. This means I need to do 8-10 satellite missions just to unlock the R&D center, so that I can get the tech I need to reasonably move on to interplanetary missions. At my very fastest, a satellite mission takes at least 5 minutes to do, and usually more like 10. This means I've got an hour or two of monotonous grinding to do in order to move on in the game. I thought I'd left that behind when I quit World of Warcraft. So, what is the purpose of the funds currency? It seems to me that funds probably has two basic purposes: Penalize failure by sinking funds when missions are performed inefficiently or are failed, and Restrict scope in the early game to promote education Currently, Funds are failing at both of these goals on harder difficulty settings. With a profit margin of 90%, failing a mission is effectively no penalty at all. Considering the price disparity between my satellite craft (10k) and the progress gate (785k), losing a ship costs me about 1% of my goal. This is not a meaningful penalty; losing the 5-10 minutes of real-world time that it took to execute the mission was way more painful. Too, "hard mode" is something that is ostensibly undertaken by more expert players. Expert players need less time sink in the name of education, not more. Lengthening the early game in the name of "difficulty" is frustrating to expert players, not rewarding. I suggest that -- at least in hard mode -- the price of rocket parts be increased substantially compared to contract rewards. A 90% profit margin is unrealistic, and a unit cost on the order of 1% of the cost to progress in the game trivializes the penalty for failure. Further, I suggest that the price of building upgrades -- especially upgrades that are effectively mandatory to continue progress within a game -- be substantially reduced. A ratio of 10:1 or even 5:1 would probably provide a more natural feeling. If part costs were increased by a factor of 5, satellite missions would still be 45-50% profitable. If building upgrade costs were reduced by a factor of 4, this would achieve greater parity between mission costs and upgrade costs. The 785k R&D upgrade would instead cost 196k, reducing the number of missions to 4 or 5. At this ratio the loss of a 50k mission vehicle will be a more noticeable loss of 25% of the goal. This is a meaningful penalty that requires an entire mission to overcome, instead of the current "nothing but lost time" feeling that accompanies a mission failure. In general, "hard mode" is intended to offer a feeling of reward for more-expert players who can overcome risk in order to more efficiently perform a difficult task. Currently, the funds balance in "hard mode" does nothing other than lengthen the early stages of the game -- the educational portion meant for beginners -- and as such has the opposite effect. Discussion is welcomed.

Nope, no such requirement here. Happy to answer the question, though!

Welcome aboard, Idleness! I'm glad you're enjoying things so far, but I confess I'm not really sure what you're asking for. AntennaRange antennas do not require activation at any point, either before or after launch. For use as a comms link they always "just work", and for use as a transmitter you just transmit data as in stock. What step are you hoping to skip?

As the only plugin developer behind AdaptiveDockingNode (used for the NADPs) and TweakableEverything, I can confidently tell you that a problem I can't duplicate will never be fixed. I'm happy to help, really, but I can't do so without a little more information. If you can get me a log, or if you can offer complete steps to duplicate (including a full list of all the mods you have installed, the version of KSP you're using, and the platform including bit-width that you're playing on), I'll take a look straight away.

cat-the-cat, can you get me a log to look at? Windows: \path\to\KSP_win\KSP_Data\output_log.txt; Linux: ~/.config/unity3d/Squad/Kerbal\ Space\ Program/Player.log; Mac: ~/Library/Logs/Unity/Player.log

SmashBrown, in order to use RemoteTech parts with this mod you need a patch for them, like MeCripp's here: https://github.com/Mecripp/AntennaRange-Patch/blob/master/RT2-AntennaRange%20Patch Just copy the contents into a .cfg file anywhere in GameData. I've never used it, but many others here have.

CollectOnlyOwnData is the one I know the least about, and I'm guessing that it prevents the container from storing an experiment that originated from another part. So, you could put it on a thermometer to make sure the player doesn't stash a bunch of barometer data on it. That's mostly a guess... but I'd leave it at "false" for now.

Kip, for the science pod you could probably eliminate the need for multiple parts by assigning allowRepeatedSubjects = True in the ModuleScienceContainer definition. Since it's possible that could be considered a little cheaty, you could make sure that once science goes in, the only way to get it back is via recovery or transmission using dataIsCollectable = False, or give it an absolute capacity using capacity = N, where N is an integer describing the maximum number of experiment runs (not data) it can hold. Here are all the fields you can define for a ModuleScienceContainer: [KSPField] public bool dataIsStorable; [KSPField] public bool CollectOnlyOwnData; [KSPField] public bool dataIsCollectable; [KSPField] public bool allowRepeatedSubjects; [KSPField] public float storageRange; [KSPField] public bool dataIsRecoverable; [KSPField] public string collectActionName; [KSPField] public string storeActionName; [KSPField] public string reviewActionName; [KSPField] public int capacity; [KSPField] public bool evaOnlyStorage; Most of them are pretty self-explanatory, but if you want any info on the specifics I can try to help out.

Welcome, Aivoh! I'll try to get some screenshots and explanatory material up soon. In brief, Quantum Struts are parts that "project" a strut in a ray out from their point of placement, based on the rotation you assign in the editor. The first part on your ship that is intersected by that ray will be attached to the strut's host as though there were a regular strut there, with the caveat that you can turn it off and on as you see fit. This makes it useful for adding rigidity to composite vessels built in orbit (like space stations or big interplanetary motherships), or for vessels that change configuration (e.g. with Magic Smoke's Infernal Robotics), where a standard strut either could not be applied at all, or would prevent the actuated parts from moving. HTH!

I've added the option to wait for launch to start logging. It'll be in the next release, after I've finished testing various other changes.

ObsessedWithKSP, I like this idea. I'll look in to it.

Gaiiden, the logger can be started before launch now by request. I can add an option to wait until launch, though. I'll take a look at the resource mass calcs. Yeah, I've noticed that the precision numbers go funny sometimes also. They necessarily have to refigure themselves to avoid ludicrious behaviour (e.g. reading altitude in Gm while sitting on the pad), but it is a little unpredictable sometimes. I'll try to chase it down and make it more reliable.

WaylandSmith, I've got similar reports in the past, and will try to find time to look in to it. Xobotun, glad you like it! Welcome aboard.

Randyre, no there is not. Many of the tweaks I've added are intentionally "editor only" tweaks, because they are things that I image would be resolved in the design and construction of the craft, and would not be readily alterable on a ship in flight. If you'd like to refute my opinion, go right ahead.

Is there a reason both parts need one? You can give science containers more-or-less unlimited capacity; why not just put a science container on the top bit?