gleedadswell

I got this exception: [ERR 00:30:16.006] ContractConfigurator.ConfiguredContract: Error initializing contract CONTRACT_TYPE [mMunOrbit] [EXC 00:30:17.407] NullReferenceException: Object reference not set to an instance of an object ContractConfigurator.Extensions.CleanDisplayName (.CelestialBody body, Boolean lower) ContractConfigurator.Parameters.ReachState.BodyList () ContractConfigurator.Parameters.ReachState.CreateDelegates () ContractConfigurator.Parameters.ReachState..ctor (System.Collections.Generic.List`1 targetBodies, System.String biome, System.Collections.Generic.List`1 situation, Single minAltitude, Single maxAltitude, Single minTerrainAltitude, Single maxTerrainAltitude, Double minSpeed, Double maxSpeed, Double minRateOfClimb, Double maxRateOfClimb, Single minAcceleration, Single maxAcceleration, Double minDeltaVeeActual, Double maxDeltaVeeActual, Double minDeltaVeeVacuum, Double maxDeltaVeeVacuum, System.String title) ContractConfigurator.ReachStateFactory.Generate (Contracts.Contract contract) ContractConfigurator.ParameterFactory.Generate (ContractConfigurator.ConfiguredContract contract, IContractParameterHost contractParamHost) ContractConfigurator.ParameterFactory.GenerateParameters (ContractConfigurator.ConfiguredContract contract, IContractParameterHost contractParamHost, System.Collections.Generic.List`1 paramFactories) ContractConfigurator.ContractType.GenerateParameters (ContractConfigurator.ConfiguredContract contract) ContractConfigurator.ConfiguredContract.Initialize (ContractConfigurator.ContractType contractType) UnityEngine.Debug:LogException(Exception) ContractConfigurator.LoggingUtil:LogException(Exception) ContractConfigurator.ConfiguredContract:Initialize(ContractType) ContractConfigurator.<GenerateContract>d__33:MoveNext() ContractConfigurator.<ContractEnumerator>d__32:MoveNext() ContractConfigurator.ContractPreLoader:Update() The exception occurred just after completing the manned orbit for 72 hours contract. Now in Mission Control it shows that all of the requirements are met for Manned Mun Orbit, but it isn't offering the contract. I am running with the Galileo planet pack. Could that be the problem? Is there any way (an edit of the .cfg?) that I can make it offer the contract? Cheers! Later edit: hmmm... also the "Minmus and Kerbol" mission isn't even showing up in the list.

Ahhhh.... Thanks! That is very helpful. So, in CKAN you "just" have to go into Settings -> Compatible KSP versions. Then add 1.4.5 to the list (it wasn't in the list originally). Then check the box for 1.4.5 and hit accept. Now CKAN will offer MKS/OKS as a compatible mod for 1.6.0.

Is this currently working under 1.6.0? It looks like people are using it in 1.6.1 so I'm guessing yes. But it doesn't show up in the compatible list for 1.6.0 in CKAN. Do I just need to install it manually?

I reverted to version 1.1.4 of CustomBarnKit and the problem went away. So it looks like something in version 1.1.5 is not getting along with RP-0.

I can confirm that reverting to CustomBarnKit 1.1.4 (today's update was 1.1.5) fixes the problem.

I'm playing a RP-0 game and it looks like the last update of CustomBarnKit may have broken things. All of a sudden rockets which I've launched before are exceeding mass/size limits of the launch pad. The launch pad is at upgrade level 2 and the mass limit is showing up as 140 t (in RP-0 it should be 800 t.).

I haven't noticed anything with other buildings, but I agree that this sure looks like the update of CustomBarnKit broke things.

Did something just break, with craft mass and size limits? All of a sudden rockets that I've launched before in the current game that I'm playing are exceeding size and mass limits of my launchpad. The Launchpad size limit (level 2 upgrade) is set to 140 t. I see a config file, CustomBarnKit.cfg, in the RP-0 directory which seems to be showing that the mass limit should be 800 t and that matches my memory of what it should be. But clearly that isn't being implemented. I went into the CustomBarnKit directory and edited the default.cfg to try to set the mass and size limits that way. But that didn't change anything. So I presume there must be some other mod which is changing these values somehow. Help?

I've been using Dangit! for a while (and "enjoying" it much like I enjoy bashing my head against a wall...why do we do things like this to ourselves??). I've noticed a new behaviour in the last day or two which seems like a bug. At the moment practically every time a kerbal boards after an EVA a part will break. This makes it basically impossible to keep the craft in any state of repair because it is an endless loop of EVA-repair-board-something breaks. I see there are issues with USI and I am using USI. But the things that are breaking are generally batteries and fuel/monopropelant tanks, so this doesn't seem like a USI issue.

I've been playing with Entropy and it *was* working as far as I could tell. But just recently it seems to have gone nuts. For the last day or two every time a kerbal boards a craft from EVA something (usually a battery or tank) breaks. Time to uninstal it.

Awesome! How did I not notice that directory? The script looks useful, but I'm in Linux so I don't think there's a straightforward way to use Power Script. If I was feeling ambitious I'd rewrite your script in bash, but I'm swamped with other things. I think for now I'll call the declining reputation a "difficulty setting". Thanks!

Hi everyone, I'm playing around with this because it looks potentially like one of the most awesome things ever... I can get a server up and running for local play, which is all I'm trying to do. But I'm having trouble setting any options using the DMPServerSettings.txt file. I make the file but when I run the server it seems to just delete the server settings file. I *assume* I've just got the syntax wrong, but there are no examples of correct syntax that I've been able to find. For example, trying to set it up for a career mode game I've tried each of the following: gamemode=CAREER gamemode CAREER gamemode=2 gamemode 2 but none of those work. Can anyone post a few code snippets of correctly written DMPServerSettings.txt files? Obviously, the thing I'm most interested in is setting it for career mode, but other things would be handy for me and for other noobs as well.

Tried again today without changing anything. Now instead of listing B9 aerospace pack twice it lists it once and then lists B9 aerospace props and the install works just fine. So either someone fixed it (thanks!) or the gremlins went to cause mischief elsewhere.

Is there a problem with the ckan metadata for this mod? Trying to install it using CKAN it shows that it is trying to install *two* instances of B9 Aerospace Pack R5.4.0 It then crashes every time without successfully installing B9. I've tried installing all dependencies first (Firespitter Core, B9 emissives, etc.) so that all CKAN is trying to install is the B9 Aerospace pack. But it now won't install B9. The fact that it lists the mod twice in what it is trying to install might indicate what the problem is.

Hooray! Now I can spend my evening launching rockets instead of figuring out syntax!

I've been looking at how ckan metadata works and I've found where the old, now out-of-date, netkan file is for tacLS. The process looks like something I can figure out. I'm wondering whether it would be kosher for me to attempt to update the ckan metadata as a service to others. Realizing: 1. I have no ownership over tacLS and am only trying to help, but if people will be mad at me for poking my nose in this then obviously I won't do it. If someone is already on this and I'll just get in the way then let me know. 2. I'm not a modder. But I have rudimentary coding skills and this looks simple. In other words, I might break it. But I'll try to fix it if I do. 3. I might need some guidance from someone who knows what they are doing in the final steps of submitting the new netkan file to the appropriate place so it becomes available to everyone, though it looks like the wiki on adding mods to ckan gives instructions on this. 4. If TAC has new dependencies, or new recommendations for other mods then I'm unlikely to know this without being pointed at them. Thoughts before I try to do this? If I get no replies within the next few hours I'll try my hand at this.

Yayyyyyyy!!! Two follow-up questions: 1. Is the ckan config going to be updated so it can be installed that way? While I certainly can install it manually I'd rather let ckan do it so that it will handle dependencies correctly for other things (such as question 2). 2. Does this mean the next version of RP-0 will be out soon?

Love this mod (but still relearning how to use it and KAS since it has changed so much from how KAS used to work). I have a quick question which might more correctly belong on the KAS thread. Why are the KAS struts (CS-R2 struts) not stackable in the inventory system? I'm not sure I'm using the right terminology - by "stackable" I mean the parts which give a little Xn icon in the inventory and you can add more by right clicking and increasing the quantity in the dialogue box. I would have thought they are the sort of small part, used in large quantities, which you would want stackable. The same goes for the connector port. It seems odd that the ground pylons are stackable but the connector ports and struts are not.

Hi folks, I had commented some time ago that in Realism Overhaul I was having trouble with probe cores indicating "not enough charge" and rockets becoming uncontrollable even though there was still charge in batteries. This is in 1.0.4 (because RP-0 isn't available for 1.0.5 yet, so I'm still in 1.0.4). I was told to remove the ElectricityFlow.cfg from the RP-0 directory but that doesn't seem to have fixed it (I also tried removing it from the RealismOverhaul directory). Since probe cores seem to draw from their own internal charge before draining batteries this was causing me a lot of trouble. I've figured out more of the symptoms, to the point that I can deal with them. If the charge in the probe core itself runs out then the probe core will report "insufficient charge" and stop working even if there is a full battery connected directly to the probe core. However, if the core has charge in it and you lock it then it will still function if there is a battery connected to it. So now I'm just connecting small batteries to all my probe cores and locking the charge in the probe core during construction. This seems to have solved the problem. Of course, I doubt this is the intended behaviour, but if any of you are having the same problem this gives you a workaround.

I'm running 1.0.4 in an RP-0 game. ckan just updated some mods. Now during game boot up it stalls on proceduralSRBRealFuels. I'm not sure whether it was the procedural parts upgrade that broke things or real fuels. I'm going to try the following and report back: 1. See if I can migrate everything over to 1.0.5 (I'm going to guess that at least some mods will break if I try this). 2. Manually revert back to an earlier real fuels and/or procedural parts version. Later edit: 1. yes migrating everything to 1.0.5 doesn't look like it will work yet. There are lots of mods that don't appear to be updated for 1.0.5. It might be possible but ckan won't do it. 2. The problem is RealFuels, not Procedural Parts. Procedural Parts shows version 1.1.7, which as far as I can tell should be fine in 1.0.4. But Real Fuels has updated to 10.8. Unfortunately, I could't *find* a link to 10.7 online, but luckily it was in my ckan/downloads. Deleting RealFuels from GameData and unzipping the older version to replace it has fixed the problem. So, if you are running 1.0.4 don't let ckan update RealFuels to the latest version.

[quote name='chrisl'] I'm playing RO/RSS/RP-0 with RemoteTech ... The problems start when I activate the Communotron 32 antennas. Everything appears to be fine until I reload a save game at which point the satellite starts dancing around until it eventually explodes from excessive g-forces. This happened on some of the older DSN satellites I launched which used Communotron 16 antenna but I thought that was because I had mounted them to a small strut. But with these new DSN satellites, I've mounted the Communotron 32s to the Octo probe core so they should be far enough apart to not be interfering with each other. But for some reason, if I activate the antenna and then save the game, I can never refocus on these satellites without this issue occurring again. Has anyone ever encountered this and does anyone have any ideas how I could maybe correct it?[/QUOTE] The symptoms sound a bit similar to that old bug in remote tech that caused there to be duplicates of your vessels. The duplicates would spawn "on top of" the original causing behaviour similar to what you are reporting. But I thought that bug was long dead... Check a quicksave file to see whether vessels are duplicated. They may also show up in the tracking centre, in which case you could delete the duplicates.

Hmm...the problem with electric charge seems to be making a repeat appearance. The craft has lots of charge, including in one of the probe cores. But the probe cores report "Not Enough Electric Charge". Oddly, if I time accelerate then the probe cores report "Operational", but as soon as I end time acceleration they go back to reporting insufficient charge. I have deleted the charge flow cfg in RP-0 (and checked to make sure that it remained deleted after a recent update). In case it matters, the craft has two probe cores. One is a an early small probe core and the other is a Delta avionics unit. This is the same design of craft that I had the trouble with before and I've never noticed the problem with any other craft. Could there be something wrong with the .craft file that is causing this?? Later edit: two additional oddities I've noticed. 1. Looking in the quicksave file, the charge in batteries etc. is reported as completely full. But in game they aren't full. i.e. the quicksave file disagrees with what is reported in game for charge on the ship. 2. Even when the probe cores report not enough charge (and RT says no connection as a result) I can still throttle up and down using z and x. The behaviour is inconsistent. Some times the vessel will just "wake up" for no apparent reason. It does not seem to have anything to do with how much charge is on the vessel (that is steadily decreasing due to insufficient solar panels) and the map view always shows possible communications connections back to ground stations.

OK, that seems to have fixed it. A few questions, some of which I realize might not be answerable without me giving more info: 1. Is this a stopgap until something in the electricity flow gets fixed? 2. Is there some "realism" that is suspended by deleting this file? 3. I installed via CKAN. If this is fixed will CKAN eventually grab me a new electricityflow.cfg without me paying attention to it? 4. Why wasn't this a problem on (the many) previous ships I'd launched in this campaign? Did it crop up in a recent update or would have been something on the current ship that might not have been an issue with previous ones? Cheers!

Having a funny problem with one craft. It seems like it is losing connection. But the RT display in the upper left shows a green signal delay and in map view it shows a nice green line back to the launch site. But right clicking a part and issuing a command gives the "no connection to send command on" message. The probe core shows insufficient charge, but the vessel has lots of charge, including in that probe core. Can't stage either. What else could be wrong?

Hi, Testflight shows up as incompatible with 1.0.4 in ckan. But it seems to be compatible (I've been using it).