speedwaystar

Just for information, since I'm not using asset bundles, I downloaded it anyway and was able to successfully export models to KSP using Part Tools 1.1.2 -- so if you're not doing anything too fancy, it seems to work fine.

Quick question: am I likely to run into any problems if I upgrade Unity to the latest version? I'm currently running Unity 5.2.4f1, but one of the plugins I've been using to import models into Unity now annoyingly requires 5.3.4.

masses are looking good. fuel sliders don't update until you dismiss the properties window and recreate it. if you drag the sliders around before dismissing and recreating the properties window you get:

in PP 1.2.3, a 2m long tank masses half as much (dry and wet) as a 1m long tank, and contains the same amount of fuel. *scratches head* perhaps it is made of Unobtainium? ;-) ,

CoolRockets/Smokescreen effects are working fine on the launchpad, but in the VAB the "show in editor" buttons do nothing, and if debug=true, the editable values appear in the properties menu but the sliders don't work.

looks like it's gone in 1.1.2 parttools, so i suppose that answers my question!

standard_bumped looks pretty nice in Unity (but doesn't make it through PartTools yet). any update on when it might be enabled?

about a billion of these errors in ksp.log: [EXC 17:24:33.477] NullReferenceException: Object reference not set to an instance of an object KRASH.Hyperedit.OrbitEditor.Simple (.OrbitDriver currentlyEditing, Double altitude, .CelestialBody body) KRASH.SimulationPauseMenu.DrawGUI () KRASH.SimulationPauseMenu.OnGUI () [EXC 17:24:33.526] NullReferenceException: Object reference not set to an instance of an object KSP.UI.Screens.AltimeterSliderButtons.LateUpdate ()

it's up to ShotgunNinja to tell RemoteTech to disable communication for the duration of his blackout. it's not RemoteTech's job, nor is it possible since RT has no way of telling when another mod has decided that a coronal ejection is occurring unless that mod tells it. Luckily, RemoteTech provides a software API for other mods to easily do this. for instance, Kerbalism (or any other mod) could set RemoteTech.API.HasAnyConnection for the vessel to false, and RemoteTech would dutifully disable the vessel's communication channel; then set it to true again after the blackout has run its course.

well that was quick! ( ^_^)b EDIT: oh, MERCURY-redstone... bah.

after watching Bob Fitch's History of Spaceflight in RSS, which dovetails with your pack rather nicely (for obvious reasons), I feel the lack of a vanilla Redstone sounding rocket mission in your pack, to sit between the Blossom and the Juno I (which was an uprated Redstone). just a thought!

it was working normally before the update which added the choice of two dependencies. until the problem gets fixed, you can simply tell CKAN to uninstall scatterer, then reinstall it. a clean install doesn't throw the error, only an upgrade to an existing install. EDIT: just noticed @Steveo has already posted this workaround.

i thought that line looked suspicious. i've sent you a PM with the dropbox link.

many thanks. since i accepted the R-1V and V-2N20 at the same time, would this have anything to do with it? CONTRACT_FINISHED { guid = 56bbe9a4-8bd1-4ad6-976c-e5106022de69 <snip> subtype = R-1V title = R-1V <snip> REQUIREMENT <snip> PARAM { <snip> PARAM { name = IsNotVessel id = IsNotVessel state = Complete disableOnStateChange = False values = ,,,, ContractIdentifier = HistoricMissions.R-1V title = Must be a new vessel upon accepting this contract. notes = completedMessage = fakeFailures = True allowStateReset = True failWhenUnmet = True vesselKey = V-2N20 // <---- was active at the same time, or possibly before, because i also accepted the blossom-1 mission <snip> persistent.sls is here.

@Whitecat106: sorry to pester but further to my sequential missions question above, i'm now all the way up to the early Pioneer Program and have been offered only US missions in a steady stream, one after another. the Soviet mission tree is stalled at R-1V (which I completed), never offering me R-2A or later. is this expected behaviour?

further to my earlier post, a probe which "can generate power" must have one or more of the following modules by definition: Power = ModuleGenerator // Part module considered to be a power generator by career Power = ModuleDeployableSolarPanel // Part module considered to be a power generator by career Power = FNGenerator // Part module considered to be a power generator by career Power = FNAntimatterReactor // Part module considered to be a power generator by career Power = FNNuclearReactor // Part module considered to be a power generator by career Power = FNFusionReactor // Part module considered to be a power generator by career Power = KolonyConverter // Part module considered to be a power generator by career Power = FissionGenerator // Part module considered to be a power generator by career Power = ModuleCurvedSolarPanel // Part module considered to be a power generator by career afaiks Kerbalism doesn't modify these modules nor does it add its own so, provided you have an RTG or a solar panel of some kind, you should be good to go. or a Fusion Reactor!

KSP's definition of an antenna for career contract purposes is "thing with ModuleDataTransmitter". unfortunately, Kerbalism renames ModuleDataTransmitter to Antenna, so the contract system no longer considers the part to be an antenna. Luckily, there is a way to extend the game's definition: Squad already supports a few common alternative Antenna nodes (for instance, RemoteTech) in its Contracts.cfg: Contracts // Below you will find many career mode options, and most are commented { ... MODULE_DEFINITIONS // Modules that contracts consider for certain things { Antenna = ModuleDataTransmitter // Part module considered to be an antenna by career Antenna = ModuleLimitedDataTransmitter // Part module considered to be an antenna by career Antenna = ModuleRTDataTransmitter // Part module considered to be an antenna by career Antenna = ModuleRTAntenna // Part module considered to be an antenna by career ... } } Kerbalism can add its own Antenna module to the list in Squad\Contracts\Contracts.cfg using ModuleManager. @Contracts { @MODULE_DEFINITIONS { Antenna = Antenna // sic } }

this quick and dirty ModuleManager config will convert all standard antennas to Kerbalism antennas with range "extreme" and vaguely reasonable transmission values. @PART[*]:HAS[@MODULE[ModuleDataTransmitter]]:FINAL { MODULE { name = Antenna // assuming vanilla for now scope = extreme min_transmission_cost = #$../MODULE[ModuleDataTransmitter]/packetSize$ max_transmission_cost = #$../MODULE[ModuleDataTransmitter]/packetResourceCost$ relay_cost = 1 @relay_cost -= #$../MODULE[ModuleDataTransmitter]/packetInterval$ // pick a number, any number @relay_cost /= 10 } !MODULE[ModuleDataTransmitter] {} }

indeed! i was going to do the commenting out tomorrow... it's way past bed time for me. i'll add support for a config file setting to enable/disable signal processing. *sleeps*

https://github.com/speedwaystar/Kerbalism/tree/play_nice

is there an easy way to ensure that every contract is offered sequentially? looking in HistoricMissions/Missions/EarlyMissions i see that the sequence is: A3 -> V2 -> R1V -> R2A -> sputnik1 -> sputnik2 -. sputnik3 | V2N20 -> vanguard1 -> vanguard2 -> vanguard3 | explorer1 -> probe missions on competing V2 the tree splits and i'm offered R1V and V2N20. i took both, and on completion i was offered vanguard1 and explorer1 but *not* R2A. currently i'm seeing: if i wait around, will the R2A contract eventually be offered (RNGeezus willing), thus leading to sputnik1? or am i out of luck?

rather than waiting until @ShotgunNinja gets round to supporting all the myriad of community antennae, or until he implements all the functionality of the already existing RemoteTech into his own mod, wouldn't you prefer if Kerbalism's signal processing module could be disabled by config, and you could continue using your preferred antenna mod while enjoying the life support and magnetosphere features of Kerbalism? i know i would. choice. it's good.

ahhh... okay. i didn't drag Community Resource Pack into my 1.1 test folder along with IFS. >_< my bad.

can confirm FStextureSwitch2 is now working with @raidernick's R7 under 1.1 Prerelease. ( ^_^)b

v1.19 doesn't seem to be working with 1.1 Prerelease, i'm afraid to say.