Tig

The new Zen architecture coming from AMD is supposed to be a pretty massive improvement. They're saying something in the range of 40% faster per clock. Sounds like it won't be out till Q4 now though... I hope they come through, more competition means better prices for everyone. But, yes, with the current offering for gaming even an i3 will beat most 8 core AMD cpus because of the lack of multicore usage. Fingers crossed that 1.1 with Unity 5 makes better use of computers with 4+ core systems. Edited: For clarity, those 8 core systems will smack an i3 silly if you're say encoding video, compressing files, etc. My comments are just for most (not all) games. Furthermore, most games don't really care about amd/intel as they are typically limited by your gpu; Kerbal is one of the less typical games where the cpu can become a limiting factor.

If you need a decent cheap mic, Zalaman makes a really reasonable clip-on mic for about $10. Works well, especially if you have a nice set of headphones already.

So you admit that people posted mostly negative things about Curse? As I said, "The majority of people registered and somewhat active on this forum don't like Curse" So now, you admit what I said is true, but have decided to dismiss it for a different reason which is that the results are skewed...? AND I'M THE HYPOCRITE? lol. Calling someone a hypocrite, especially when incorrect, is nasty. [snip] Proof is nothing more than evidence, its not definitive. However, the proof I have supports my conclusion. You can disagree with my evidence - I truly don't mind that - but instead you incorrectly and rudely told me I had none. You were then dismissive of @Aperture Science posts in the same way. I read everything you wrote and tore it down bit by bit. You've now admitted that the things that you bolded in my prior post are in fact accurate, but now try to hide behind the skirt of entirely different argument. [snip] Go ahead and reply, no one but you will care or read it; I've made my point and wipe my hands of you. Good day, sir.

Yeah, my post however does respond. So did many users when Curse was announced. "nor do I believe" so, you just think AS made it up? And it fails your personal standard? sigh...

Perhaps you could read this entire thread? Perhaps you could read the entire thread when Curse was announced? The response was so overwhelmingly negative that there is simply no reason to count the posts. Feel free to engage in the exercise if you wish... I believed it to be so well know that I didn't need to provide the link, but I guess I do. Very well: http://forum.kerbalspaceprogram.com/index.php?/topic/71567-the-curse-thread/&page=1 Suffice it to say that from reading these threads, including the 59 page one, there is ample evidence that people don't like Curse and aren't just a "vocal minority", as opposed to what the person I was responding to was writing (which was utter conjecture and theorized that the boards are not representative of the greater KSP community.) My objection was not to the theory he proposed... but that he then assumed it true with no evidence, then referred to people who don't like curse as a "vocal minority" who should "get over it." That's not discourse; it's dismissive and unneeded. Furthermore, literally 2 posts before mine is the very evidence you requested vis-a-vis mod authors: Before you go about being nasty perhaps you should read the thread, or at least the prior 3 posts. EDITED: Lol, ninja'd by the most appropriate person to do so... thanks AS

That's an interesting point, Beo. I hadn't thought of that, the airbrakes although producing more drag when deployed, would only deploy at the moments they are needed rather than the constant but less drag provided by fins which would provide drag even when not required... interesting. My point was more directed at your last sentence, modern rockets are obviously much more thoroughly tested than our kerbal creations, and for safety that the lack of fins/brakes on most modern rockets is due to larger gimbals on the engines than we see in stock KSP. As others have pointed out, the fins on the Saturn V were probably unnecessary as well, but were there for safety margins. I don't know about the rest of you, but I have been known on occasion1 to place my kerbal's on vehicles with, shall we say, "sub-standard" safety protocols? 1Occasion shall be defined in this context as most of the time.

Simple question. Simple answer. The majority of people registered and somewhat active on this forum don't like Curse... a majority of mod authors in the past have not linked to Curse. A minority of the people in the US elect the President every four years. When people say things like "vocal minority" its a way of diminishing our view point with a round about ad hominem attack instead of pointing out the flaws in our dislike of Curse, which of course is a losing argument because its an opinion in the first place. I frankly don't care if I'm in your so-called-majority or not. Your logic is also flawed because it inherently implies that the people who dislike Curse are not representative of KSP's userbase as a whole. You *could* be right, I admit that. But you present precisely ZERO proof to back your claim. Another person could point out that the Curse supporting crowd are just a "vocal minority" using the same flawed logic. I choose not to do that. I will, on occasion, disagree with a person either on this forum or in real life and when I do so I will *disagree with the argument they are making* not attack them personally or as a group. Ahh, and know we get to the heart of it. Your view is right, our view is wrong, and therefore we should "get over it." This forum needs to hold itself to a higher standard than that type of behavior.

Before finding a mod that modded RemoteTech, I would edit my save file to extend the antenna on a probe that left KSP's range before I remembered to extend the antenna/dish in game.

Lot of anger in this thread... If I can help a bit, I think one of the major reasons we see smaller (or no) fins on real world rockets is because they have significantly higher gimbal than stock KSP. The shuttle's main engines had 10.5 degrees of gimbal range. I mean some engines in stock KSP have like 8 degrees, but its only the little ones. Primary launch engines, i think the largest gimbal is on the Rhino at 4 degrees. Even the massive F1 engines on the Saturn V had about 6 degrees of range (i think the center one was fixed and it was only the outer 4 that had that range, but don't quote me on that). I couldn't find for certain if the modified rs-25s from the shuttle that they plan to use on the SLS will have the same range as they did on the shuttle, but i think its safe to assume so, or at least that they'll have substantial gimbal range. Its just generally more efficient than the drag created by fins, or any other aerodynamic system. In any case, real world gimbal creates a substantial amount of force that doesn't exist in stock KSP. @OP if you wanted something more realistic i think the earlier advice about procedural tanks is a good idea + modding the engines to something similar to real world engines would let you go finless without airbrakes. I mean if the goal is realism then real space agencies found ways to reduce/remove fins to reduce drag, obviously airbrakes would add a bit of drag That said, it would make the game a bit easier... not sure if you really want that or not. PS. I love fins. Reminds me of building rockets as a kid.

Amen. Totally respect what you are saying, but with a caveat... I've modded many games and KSP is unique. Its not your typical Call of Madden Warcraft Duty moronic racist asshat players that need sites like Curse. (My wife always joked while I played BF3 that I must be playing exceptionally well if other users were referring to me as a homosexual African American... hope that doesn't offend, my gay and black friends think its funny as hell.) Well, thank god, that's just not the KSP community! We have passionate arguments about the appropriate amount of heat generated by a 25km peri aerobrake on Duna... and I love that. We don't need to cater to the lowest common gamer denominator. Squad should trust its community to build its own modding website and simply provide its blessing and a modicum of support. Did everyone read SirCmpwn's note on KerbalStuff? The site was costing him $100/month and the upgrades needed would be $180/month. I provided zippo to support him. Shame on me; shame on all of us. 2 grand a year is a lot for an individual. Its not for Squad. Especially when it is a game *driven* by its mod community... Am I the only one who feels this way? I don't get the sense that I am unusual in this regard... but I suppose I could be wrong. I want this game to succeed even further. I want everyone who had a hand in making it to get rich. I just think a community based mod website furthers that goal. PS. It's not unfair to point out that my beliefs on this matter are somewhat self-serving. Guilty as charged. But that doesn't necessarily make me wrong...

Amen. Let me respond to this and explain why Curse is not the best option for KSP. First off, I understand why Squad chose Curse at the time. Again, love you Squad in advance. But we all know that Spaceport was a bit of a mess... to quote the pertinent aspect from Kasper "we can happily recommend Curse for this purpose, at the very least as a stopgap measure." And at the time I could accept that as a "stopgap". Squad needed to focus on what they are best at... developing a video game, not managing a mod website. So even though we all know that Curse is run by, pardon me, but total asshats, they had the infrastructure already in place. With all due respect to HaryR, the time to change is now. Why? I played WoW, the average player on a WoW server is at best mildly mentally deficient... is that the nicest way I can say it? The average KSP player is, if the general discourse on this forum is a valid measure, considerably of above average intelligence... let's face it being good at at KSP literally requires a basic understanding of (the almost cliche joke) rocket science. lol. In short, we don't need the same moron proof modding that Curse and their ilk provide. If you're to dumb to install a KSP mod, then you're too dumb to play the game. I'm really not being an amazing1 person... at least I don't think I am... seriously how can you possibly understand delta-v and ejection angles and not understand typical OS folder structures? @KasperVid and Squad, I understand why Curse was used as a stopgap for Spaceport, but that was a long time ago. Please, please, please trust your community. I promise you that your paying userbase is more dedicated and far more intelligent than those money grubbing, amoral, "developers" at Curse. Give the people who love this game your blessing and a tiny bit of support and watch your community continue to flourish and, appealing to your pecuniary interest , provide you with additional game sales. 1PS. I love that the forum changed the word that I wrote to "amazing" when what I actually wrote was the final sphincter in a donkey's digestive tract.

With all due respect, I have no issue with any company making a profit. That said Curse's behavior has been, in the eyes of many, egregious. Adware/malware/spyware? No thanks. There are many people, myself included, that think astroturfing should be outlawed. In any case, its morally bankrupt. And as an ex-WoW player don't even get me started on the crap they pulled with the wiki. I still don't understand Squad's decision, I'm sorry Squad, love your game, but I don't understand your business partner decision. They are the antithesis of everything that makes this game great. As to the closure of KerbalStuff, and @SirCmpwn specifically, I never complained about downtime or "missing" features. But, I like many of us, I also never gave any thanks or appreciation. The following statement is belated and unfortunately diminished by its timing, and for that I am ashamed. Thank you for all your time and effort. @Squad, Without the support of the many under-appreciated modders and community members I probably would never have bought KSP. I wouldn't have recommended it to a number of friends. It is time for the association with Curse to come to an end, and support and assist a modding site that does it for the love of the game instead of a site that abuses, imo, its visitors.

Nah, you didn't misrepresent. Just some people jumped in with their 2 cents and frankly their 2 cents was bad advice. I just wanted to correct the bad advice, cause well, I'm sure other people have read this thread who are thinking about building their own new system. I agree with you on the liquid cooling. My advice is that if you can cool it enough with a reasonable well priced air system, something like the sub $40 CM Hyper 212 series, then great... but once people start talking about buying scythe fans at $25-30 a pop, you'd be doing yourself a disservice to not look at liquid cooling at that point, especially nowadays with a good selection of sealed-almost-idiot-proof prebuilt liquid coolers. Nice custom loop? hell yeah, scrib. But I do have one caveat, people who aren't real comfortable and don't have a good grasp of how it works shouldn't touch custom setups... And DDR4 I think is a real must if any of your are buying a new system. DDR3 is going to become more rare as everyone switches over to manufacturing primarily DDR4. Also, like I said in my prior post, DDR4 already demonstrates frame rate increases in current titles. DDR4 at speeds of 2400/3200/3600 are readily available at decent prices. Hell, they already have some sticks of DDR4-4266 available... yeah its $25/GB right now, but that will come down. PS. Just to curtail anyone who tries to be smart and points out that DDR3 can reach speeds of 3200... yeah, technically that's true. Feel free to pat yourself on the back. Its also about $60 per GB and DDR4-3600 is like $8/GB and dropping. PPS. My advice is for general gaming. Kerbal is a bit unusual in that it is generally cpu bound unless your graphics card is really poopy or you only fly ships with few parts. Most of the typical games out there, like the Witcher 3 or whatever the newest Call of Ghost Battlefield Black Ops Failed Launch Servers Part 17, are going to be gpu bound (unless you have an super crap cpu ).

I just wanted to give my opinion on some the responses in red... First off, I had an i5-2500K and now have an i5-6600K, I recorded a number of benchmarks in the Kopernicus thread in an effort to help that team narrow down a bug in the mod that was causing a fairly serious fps drop. I've also been building systems for years and years... The 6600 vs the 2500 on a clock for clock basis is an increase of 20-25% on cpu limited scenes, that's not "barely" and that's with both set to 4.5Ghz. I wouldn't generally recommend an i7 over an i5 for anything between ivy and skylake for gaming... games just don't benefit from the hyperthreading, hell most games don't even benefit from an i3 to an i5 on clock for clock because very few use more than two cores. Its also why 8 core AMDs aren't great for gaming, the games just don't take advantage of those extra cores and the intel chips are substantially faster on a per clock/per core basis. SSD's are a "HUGE waste"? LOL. SSD's are one of the greatest improvements to computing in the last 6-7 years (yes I'm aware they were available before that, but they really didn't drop into a reasonable price range for consumers until about late 2009 iirc) Having said that, to the OP there is no need for 2 SSDs they don't have the same limitations as HDDs in terms of seek times and fragmentation, so having 2 separate drives will have almost no noticeable performance increase. Also, as for the load time of KSP it is not limited by the speed of the drive, it barely has any effect, but it has advantages in nearly any other game out there. And no, an SSHD won't cut it for those purposes. PS. My next upgrade will be an M.2 drive. Typical 7200 rpm drive? ~130MB/sec read rate. Samsung 850 series SSD? 500+MB/sec. The new M.2 drives? 2,500 MB/sec read rate... I think i just peed a little. DDR4 is overpriced? Uhh what? Yeah the news from 2 months ago called and left a message... DDR3-1866 and DDR4-2400 are essentially the same price. Overrated? Again, I have to laugh. Yes, at stock speed DDR4-2133 (which no one buys), then DDR4 vs DDR3-1866 is negligible. But here's the thing, DDR4 can already easily overclock to DDR4-3600 and that will grow in the future. And yeah that makes an enormous difference in some games/apps - i haven't tested KSP, but I bet the difference in KSP is negligible if you have a decent video card with enough VRAM, but to say its overrated is just wrong. Give or take a 5-15% fps increase from DDR3-1866 to DDR4-3600 (http://www.hardocp.com/article/2015/08/05/intel_skylake_core_i76700k_ipc_overclocking_review/6) and a price difference of $8/GB for 3600 instead of $5/GB for 2400 and its worth it to me. DDR3 is *already* a bottleneck in most modern games, try anything that has to load assets on the fly and tell me DDR4-3600 isn't worth it... Liquid cooling is up to you, but if you plan on overclocking to 4.8Ghz I think its a good plan, yeah the price is higher than high end air, but I'm sure you already know that. An OC'd 760 is plenty for Kerbal, but with the rest of your system I'd up it something more powerful for other games...

Is anyone else having an issue with jagged seams in the planets/moons? Some pictures to show what I mean: This is with just Kop, OPM and MM installed. Nothing in the logs to give me a clue other than the following sections: From KSP.log [WRN 22:31:44.098] Cannot find preset 'High' for pqs 'Plock' [WRN 22:31:44.103] Cannot find preset 'High' for pqs 'Nissee' [WRN 22:31:44.108] Cannot find preset 'High' for pqs 'Thatmo' [WRN 22:31:44.113] Cannot find preset 'High' for pqs 'Tal' [WRN 22:31:44.117] Cannot find preset 'High' for pqs 'Wal' [WRN 22:31:44.122] Cannot find preset 'High' for pqs 'Priax' [WRN 22:31:44.127] Cannot find preset 'High' for pqs 'Polta' [WRN 22:31:44.132] Cannot find preset 'High' for pqs 'Tekto' [WRN 22:31:44.137] Cannot find preset 'High' for pqs 'Slate' [WRN 22:31:44.146] Cannot find preset 'High' for pqs 'Ovok' [WRN 22:31:44.150] Cannot find preset 'High' for pqs 'Hale' And a bunch of these in the output.log Serialization depth limit exceeded at 'ThermalLink'. There may be an object composition cycle in one or more of your serialized classes. (Filename: Line: 67) Serialization depth limit exceeded at 'OcclusionData'. There may be an object composition cycle in one or more of your serialized classes. (Filename: Line: 67) ... Serialization depth limit exceeded at 'Contracts.Agents::AgentStanding'. There may be an object composition cycle in one or more of your serialized classes. (Filename: Line: 67) Other than that no errors or exceptions in the logs (except for the standard stuff like WheelCollider). System stats: i5-2500k OC'd @ 4.2GHz HD7950 OC 12GB ram Win7 64bit, running 32 bit KSP The stock planets don't exhibit this behavior... including the ones that are changed into moons by OPM. Let me know if you need anything else. Thx.

*** Kopernicus Beta 0.4 fixes this issue, fps is back to 0.3.1 levels *** Yeah, I wasn't sure you got enough love in the thread. So, I thought I'd add some numbers to the mix so hopefully someone realizes this a near game breaking killer for a lot of people - when overclocked intel core cpus can't keep up on a single threaded game you have an issue, lol. @The White Guardian - That's a common misconception that occurs because of the way KSP handles its memory "management" (if one can call it that - no offense squad, love your game ) In a lot of other games we see performance increases with texture reducers/managers because those games are constantly loading textures in and out of the memory, and many of those games are GPU-bound. KSP doesn't do that; it loads *everything* at the start of the game. For example, if World of Warcraft did that, you'd need 40GB of ram to play it and it would take about 7-10+ minutes to load from a typical hard drive... So, ATM for KSP is about one thing and one thing only. Not performance, but rather keeping your game within the 32 bit address space (4GB). Once loaded, the relative size of the textures has almost zero impact on performance on a cpu-bound game. As a note, I tested my game with just Kopernicus installed (which causes the fps drop), and then with Kopernicus and OPM installed. The difference in fps on the launchpad between Kopernicus (~600KB) and Kopernicus + OPM (~140MB)? Zippo, exactly what we should expect.

Just wanted to make everyone aware that I think there is a cpu devouring issue that started with Kopernicus 0.3.2. Link is here if anyone wants more details: The TLDR version is Kop 0.3.1 -> 0.3.2/3 cuts my fps by over 50%... unfortunately I think 1.8 requires 0.3.3, so if you roll back to 0.3.1 for Kopernicus then only 1.7.2 will work for OPM. If anyone else is having a similar issue, feel free to add your voice to the Kopernicus thread, I see absolutely *zero* errors in the logs. Btw, to CaptRobau, thank you for the mod. And to be clear, this fps drop happens with just Kop installed, it has nothing to do with anything in OPM.

Hey all. sarbian thank you very much for this mod. Having an issue with how to properly use AFTER[]. Essentially, what I am trying to accomplish is a double after if that makes any sense. I tried searching for the answer and have read the handbook and still can't figure this out. I have 2 mods, we'll call them Mod_Z and Mod_Y. Here is what happens in the logs: Mod_Y loads up. Mod_Z loads up. After Mod_Z loads up Mod_Y uses MM to change a part we will call Part_X, it does this by using "@PART[Part_X]:NEEDS[Mod_Z]:AFTER[Mod_Z]". Now I also want to modify Part_X but one of the values I am editing is also edited by Mod_Y. I've tried all of the following (by the way each one loads in the log file in the config section - my comments are limited to the [ModuleManger] part of the log): @PART[Part_X]:NEEDS[Mod_Z]:AFTER[Mod_Z&Mod_Y] and @PART[Part_X]:NEEDS[Mod_Z]:AFTER[Mod_Z,Mod_Y] --Nothing appears in the MM log section @PART[Part_X]:NEEDS[Mod_Z]:AFTER[Mod_Z]:After[Mod_Y] --After Mod_Y loads MM executes my changes, which do nothing because the module i am editing doesn't exist... it is created by Mod_Z which hasn't loaded yet. @PART[Part_X]:NEEDS[Mod_Z]:After[Mod_Z] --After Mod_Z loads MM executes my mod, but then executes the changes from Mod_Y, which overwrite my changes. I don't have any issue with using & with NEEDS[] just with AFTER[]. I found a solution to my problem, which was simply to name my folder something later in the alphabet than Mod_Z (originally my folder was earlier in the alphabet). That said this may eventually be something I release at some point and I'm hoping for a more elegant solution. thx much.

Just did a quick test lowering the mass of the KER chip from .005 to .0001. Basically no effect, slightly higher dv at the end, but only due to the mass reduction (about 20 additional dv at launch and at orbit). @RIC, yeah that's a good point, I put KER on all my ships as well, and I thought about doing that. Perhaps my bigger concern is with how this will play out with all parts, e.g. does putting a thermometer on the side lower my dv by 150? idk yet.

Ahh, thanks much, I'll look into that further. Well in the meantime I setup a test to see exactly what kind of loss we're talking about, it's fairly significant... Craft 1: 2445 kg 3810 dv (atmospheric at alt 0.0) Surface TWR at launch 1.34 (rises to 1.4 within 5-6 seconds due to the light craft weight) MJ and KER chips inside of a Service Bay Craft 2: 2433 kg 3853 dv (atmospheric at alt 0.0) Surface TWR at launch 1.34 (rises to 1.4 within 5-6 seconds due to the light craft weight) MJ and KER chips attached to the body of the ship Here is an album for anyone interested: Both flown with MJ's autopilot for consistency (i normally like to fly my own craft ), limited to 19 m/s acceleration, at 35km acceleration limiter turned off. Gravity turn started at 110 m/s, ascent path 50 degrees. Craft 1 w/service bay: At 90 seconds after launch, Pure drag loss is 3.4 m/s^2. At orbit gravity loss is 1291 drag loss is 359 Remaining dv at orbit is 269 m/s Craft 2 w/chips attached to body: At 90 seconds after launch, Pure drag loss is 6.6 m/s^2. At orbit gravity loss is 1369 drag loss is 553 Remaining dv at orbit is 43 m/s TLDR: Putting a KER chip on the outside of a ship reduced dv at orbit by ~270 dv. (The difference between the 2 ending orbit dv and the starting dv). That seems like an enormous loss for a thin 5kg chip on the side of a craft imho... should that be happening? Am I just completely ignorant on aerodynamics? Totally willing to admit if I'm wrong, just seemed like a lot to me. ---- PS. Obsessed, you're completely correct a different ascent profile can have a profound effect, that said I tried to find numbers that were efficient enough and worked with MJ. For example with a shallower ascent profile at 45 degrees (reduced 5 degrees), lowering the acceleration to 14 m/s, gravity turn at 75m/s, the crafts don't even make orbit. Other tests (16m/s, 48 ascent, 90m/s turn) just led to lower numbers remaining dv in orbit. I know MJ isn't perfect, but like I said... more about the consistency for testing purposes rather than ideal flight paths. PSS. The same effect happens with a MJ chip on the side of the ship, but to a much lesser extent, and it becomes almost negligible if the MJ chip is tweakscaled down a step. Not sure if it is because of the mass being 1/50th of the KER chip or because of the "drag cube" I'll try to test that next time. PSSS. To anyone wondering why I put the chips on Craft 2 on the rear end of the craft by the engine... i was testing whether putting them on the side versus underneath the tank would make a difference. My thought process was that the tank might shield the chips from creating drag. Short answer: Nope.

Anyone else having an issue with excessive drag on the chip itself? I ran a couple of tests with both a MechJeb and KER chip on the ship, I used the MJ for both the autopilot for consistent results and because it displays the total losses on the ship split into gravity & drag losses. On a small single stage LKO probe, the losses from drag on the chip were in excess of 150m/s dv, which seems like a lot. Now if I put it in a container, that loss was prevented, (small dv loss due to the extra weight of course). MJ modules exhibit the exact same behavior, but it is much less of a loss, perhaps because the MJ module has less mass? This seems strange to me, since both KER and MJ define their parts with maximum_drag = 0.0 and minimum_drag = 0.0. I don't believe any of my mods would be changing aerodynamics or those parts (not running near, far, etc). Anyone else seeing this behavior? Or maybe I'm just misunderstanding what maximum_drag really does, I assumed it would make the part essentially invisible to the drag system by setting those to zero...

Thanks for the fast response and for the balanced mod, I was looking for a non-game breaking station lab and it sounds like this fits that perfectly. If I'm reading the bitmasks correctly can these also be used on the ground? (51 is for space high\low & landed & splashed if i understand correctly) Also if that's right, then the zoology test can be done while flying... incoming bioproducts at mach 2. Ahh, okay so while the other items are new science entries, the Specto is just a massive transmit increase over stock, but still only applies to the stock "surface sample"?

Hi Ethernet and all... This mod looks really interesting to me, especially with the now completely broken stock MPL. But I had a couple questions about how the mod is supposed to work/flow of the inputs. Required: 1) Lots of power 2) Science Lab --> Eurekas 2 other basic components: 1) Zoology Bay (w/kibbal container) --> Bioproducts 2) Cyclotron --> kuarqs These 3 base "materials", kuarqs, bioproducts, and eurekas are used by the other modules... (e.g. kuarqs + eurekas + prograde\retorgrade kuarqs experiments --> science) If I'm misunderstanding any of the above please let me know... Now my questions: 1) I can run the experiment from each module once and get science from it? 2) I can also get more science from a module even if it has been already run once if requested through a contract? 3) This is the part I'm not sure about, are the experiment modules essentially meant to be returned to kerbal? 4) Is the science limited to once per module or once per experiment? If I bring down one prograde kuarq experiment back to kerbal, and bring up a new prograde kuarq module and dock it, then can I get science again from the new module? 5) Is the Spectrometron limited to one use per different type of soil sample or can I run it more than once per sample type? Like, can I bring it 4 samples in a row from the shores of kerbal and get repeated science from them? 5a) If it is limited to once per soil type, does that apply globally or only as to that Spectrometron? Thanks

I think I have found a bug, but frankly its been a reeeallly long time since I've written any code - also this may be a working-as-intended issue. I noticed this because my missions were not paying out correctly - or perhaps, the math just wasn't working as I thought it should. When the a vehicle is launched MCE is multiplying the cost of the vehicle by the payoutmode and subtracting that product from your available funds. For example, if you are in payoutmode1, a 20% increase to rewards, the cost to launch a vessel is Total Vessel Cost as seen on the Ship Breakdown window increased by 20%. I assume that is not intended? onLaunch calls manager.costs which in turn calls reward with the value of the ship as a negative. I think reward is multiplying any value, positive or negative, it receives by the payoutmode. Thanks much for the mod.