Chonner

Aha makes total sense, I had Spacetux Shared assets through CKAN, but when I did a search for the the CONTRACT_GROUP Node with Sublime I limited it to the Unmanned Contracts folder so it didn't come up! I've just changed the simultaneous limit to 2 in that. Thanks for that. My point still stands about 99 weights on the initial flyby missions, so hopefully linuxgurugamer will consider changing them, or making so you only get Mun and Minmus ones to begin with.

You've defined group = SpaceTuxGroup on each of the available contracts, but nowhere have you actually placed a Contract Group Node defining this group. This is meaning that the initial flyby missions with their weight of 99 are out weighing contracts from pretty much every other mod (particularly Advanced Progression) in the Significant Category, meaning I can't get any of the early career missions from them, making it really difficult. Personally I would so you could have a maximum of two initial missions offered at any time, and maybe reduce the weighting and maybe make them declinable. I think the ideal scenario would be all the initial flyby contracts in one group with a maximum of say 2 active at any time (and maybe mix up the Significant vs Exceptional parameters a bit, so they don't crowd out Significant all the time), then once you achieved flyby for a particular body it opens up the other missions for that body. Then either through progressive requirements or a grouping for each body, make sure the missions for a body don't crowd out the offers as well. Also maybe make it so that you have to explore Mun, Minimus first, as I'm getting Bop, Tylo and Pol missions before I've even gotten out of Kerbin Orbit!

Congrats on the new version! Thanks for all your work! Just incase anyone was wondering why they aren't getting it, it hasn't pushed to CKAN yet for some reason (usually it is pretty quick, a few hours after KerbalStuff), but they mentioned over in the CKAN thread that the Netkan Bot might be AWOL/a bit slow at the moment at indexing Kerbalstuff as they are changing the backend, but hopefully it will appear through it soon though. Are these incorporated into SETI with the update, or just compatible and need "installing" themselves?

Kerbal Construction Time simulations work on the principal of quick saving when you enter the Simulation, then reverting to that quick save when you exit it, so as long the relevant parameters are stored and loaded with quick saving/loading it should function correctly and revert everything at the end of the simulation even if the billing has fired I believe. I also use Kerbanomics with KCT and don't think I've been having this problem, but I will do some testing later and check.

Two ways of fixing it. 1. Simply delete GameData/ProceduralParts/ModuleManager/RealsimOverhaul_TechLimits.cgf as if your using SETI you are not using RO so it won't break anything. 2. Copy this file over your GameData, which will overwrite the above mentioned file with a corrected one. I'll maybe write a small config patch later that will apply the SETI Tech Limits to the Real Fuels SRB, but need to check it doesn't create the same bug that happened before. Tested and that works perfect!

Found the cause! It was actually within Procedural Parts itself, ProceduralParts/ModuleManager/RealismOverhaul_TechLimits.cfg there was a couple of missing NEEDS[RealismOverhaul] statements which meant it was applying their tech limitations. So the cause of the problem was like this - place Procedural Real Fuels SRB, adjust something but not diameter keeping that at the default 1.25m (>> 0.2m limit), when you launch it sometimes (seemly randomly) checks that you fall with in the tech limits on volumeMax, therefore reduces the amount of solid fuel, but doesn't alter the actual model, reducing the fuel in turn increases the Burn time greatly and reduces the thrust (not sure why it does that, seems like a separate issue that BurnTime, Thrust and Solid Fuel arn't properly proportionally linked). Faster, the simple solution is just go and delete ProceduralParts/ModuleManager/RealismOverhaul_TechLimits.cfg, I've created a merge pull request to get it fixed if/when another version of Procedual Parts is released. This should revert it to the default maxDiameter from Procedural Parts of 1.75m, and mean you never have a Part greater than the limits actually allow. As it wasn't really a reproducible bug, I'm not sure if this completely fixes it, but I think it should!

So I actually just had this for the first time! Wondered why my vehicle wasn't getting off the pad! Going back to the VAB and launching again seemed to fix it, but this would cause problems when that is not possible (i.e. with Kerbal Construction Time). So I've done some digging, and something (not sure what) is causing proceduralSRBRealFuels PART to have a diameterMax = 0.2 at TECHLIMIT start, which is different to the Procedural Parts Mod Pack default of 1.75. which might have something to do with it, but I haven't been able to reliably reproduce it the glitch. It also seems that this limit is only applied if you change the diameter from the default of 1.25 when you place it in the editor, but it might somehow be applied on the way to launch pad, sometime making the engine bell only 0.2 wide, and therefore massively increasing the burn to compensate. Has it ever happened to you in Sandbox mode? Either way I have no idea if it is a problem with SETI or Procedural Parts or Real Fuels or a interaction between them. I've tried placing the following in a config file to see if it fixes it, but looking at the ModuleManger cache it hasn't done anything to it, so it is either wrong in someway, or the order of operations is causing it to be changed after this does (I know RealFuels seems to quite liberally use the :Final instruction). @PART[proceduralSRBRealFuels]:Final { @MODULE[ProceduralPart] { @TECHLIMIT[start] { @diameterMax = 1.75 } @TECHLIMIT[basicRocketry] { @diameterMax = 1.75 } } } I'm just taking a stab at it here, I'm not a modder by any shouts, only been using mods for a few weeks! For now on I'll have to defer to someone who knows what they are doing! Are you using Kerbal Construction Time? This is a known bug with RealFuels and KCT with it boiling off before launch. The most recent dev version of KCT fixes this, which I think might be going to be released relatively soon based on what magico13 has been saying.

The 4.1.4 updates are not pushing to CKAN as the 4.1.3.1 update was missing the extra .0 after the 90 in the naming convention and it is not recognizing the newer version after them when ordering them- see here in the CKAN Meta https://github.com/KSP-CKAN/CKAN-meta/tree/master/ShipManifest Guess the the misnamed version just needs deleting, not sure how/who would go about fixing that, a bit inexperienced when it comes to github!

As noted over in the SETI thread, either RF or this Mod also breaks Yemo's Hybrid Rocket Booster, this is relatively easy to fix, the following MM code that just swaps out the Oxidizer for RF LqdOxygen and all works fine after that, although I don't know if there are any balance issues associated with doing that. Another option would be to use NitrousOxide instead which is more common with real hybrid motors, but wasn't sure on whether it would need changing of ratios and tank volumes to ensure it makes sense so LqdOxygen is just the simple solution. Also note this is only my second ever MM cfg code written, so it is probably really poor syntax but it works! @PART[proceduralTankHRB]:AFTER[SETI] { @MODULE[ModuleEngines] { @PROPELLANT[Oxidizer] { @name = LqdOxygen } } @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[SolidFuel] { @RESOURCE[Oxidizer] { @name = LqdOxygen } } } }

How is the Procedural Real Fuels SRB broken? I've got SETI + Procedural Parts + Real Fuels + RF Stockalike Engine Configs + Karamazovnew's Real Fuel Stock Tank Prices all installed and the SRBs work fine. The HRB unfortunately doesn't due to the Oxidizer vs LiquidOxygen compatibility issue, but I've been thinking of taking a look into the configs to see if it is an easy fix, but I also don't miss them too much as everything can be done with a combination of Solid and Liquid. (Also helps that I have RoverDude's Sounding Rockets installed that gets you the science for the first couple of tech nodes). Edit: The HRB is easy to fix, the following MM code just swaps out the Oxidizer for RF LqdOxygen and all works fine after that. Another option would be to use NitrousOxide instead which is more common with real hybrid motors, but wasn't sure on whether it would need changing of ratios and tank volumes so LqdOxygen is just the simple solution. Also note this is only my second ever MM cfg code written, so it is probably really poor syntax but it works! @PART[proceduralTankHRB]:AFTER[SETI] { @MODULE[ModuleEngines] { @PROPELLANT[Oxidizer] { @name = LqdOxygen } } @MODULE[TankContentSwitcher] { @TANK_TYPE_OPTION[SolidFuel] { @RESOURCE[Oxidizer] { @name = LqdOxygen } } } } I'll post this over in Karamazovnew's thread aswell so people are aware of it there.

I had a similar problem since upgrading to 0.7, none of the contracts in my career mode save would complete (the 18km Manned from SETI and the Artificial Satelite in Orbit one from Advance Progression, not recognizing Alitude and Orbit Situation respectively). Tried uninstalling a few suspected culprit mods and nothing seemed to fix it. My solution was to regenerate the current contracts from the Debug Toolbar, Contracts, Tools Menu and then reaccept them all (although one from Advanced Progression didn't reappear and was sustituted by another one, but I guess it will come back eventually. I had First Orbital Satellite, but First Kerbal in Orbit was regenerated.). I then corrected my funds using the GovFunding Mod which I have installed anyway (make a note before you regenerate, you can end up with less or more funds depending on advances on contracts). Note: I am not sure this is necessarily a bug with CC, as I had a Mission Controller 2 contract that was not completing too, something just went awry with contract system in general. I also updated Contracts Window Plus at the same time as CC which could of had an effect maybe. Also, I noticed that in the Debug Toolbar, Contracts, Add menu all CC contracts are just displayed as "ConfiguredContract", where as those from Mission Controller 2 and Dmagic actually have the contract name, would be useful to have the name displayed there to enable manually regenerating a contract in these kinds of situations. Finally, thanks for the awesome mod Nightingale, loving the customisability of these contract pacts, and after editing Advance Progression to suit my tastes a little bit, and realising how easy it is I have an idea for a small very simple contract that I might implement for my first foray into mod creation.