AccidentalDisassembly

Sorry, thought ksp.log was the one! Now I know, though, thanks!

This doesn't prevent the inevitable crash about 2 minutes after I place the normal MK2 cockpit in the SPH - was there something else I was supposed to do to fix this? Using either RPM 16 or 17 it crashes after "hiccups" closer and closer together. Here's a log: https://dl.dropboxusercontent.com/u/59567837/KSP.log EDIT: Removing the lines about the RPM cameras in the cockpit's CFG file seems to have fixed it.. maybe.

Quick question - under what circumstances will two workshops produce things faster than one? I have two workshops with 10 kerbals each in a station (attached at opposite ends of it), and only one of the workshops lists any productivity (and it's equal to vessel productivity). Builds take an absolutely insanely long time, and my Kerbals aren't THAT dumb. How do I use multiple workshops at once?

So I've noticed in 1.21b (which is the version I think I have) that massFactors has no effect on anything anymore - masses all scale as a cube function. Can you show an example of how to properly get a different mass-scaling exponent to work on a part-by-part basis or inside a SCALETYPE{} please (as opposed to changing it globally in the exponents cfg)?

This... I desire this muchwise.

You're right, it does happen with all parts... just noticed this. I guess it was only blatantly obvious enough for me to see it when the parts were huge, but it does indeed happen with everything for me too.

Another random note: in the SPH, a very large-scale LLL part (8x normal scale) I was playing around with has an odd behavior with nodes. Node size does scale up as the part scales up - but if you alt-click the embiggened part to copy it, it is copied with a smaller node size than the original it's taken from.

No idea, I only really noticed it with parts that were placed in symmetry, and when IR was installed it was far worse, but couldn't really figure out what was going on. All I came up with was the half-baked theory that two copies of scale.dll was making some error in the code go crazy - masses became absolutely huge, bigger every time a ship was loaded or a part was picked up & re-placed... millions of tons range, if you picked up and put them back enough

If you're willing to use TweakScale and write a custom cfg for the truss parts, you could probably get them to scale somewhere near FUSTEK sizes...

Sorry if someone has already suggested this - I really like the parts in this pack, but here's my problem - question of convenience, really: keeping texture duplication minimal is great, but you can't delete parts from B9 without wrecking the ones in this pack. Of course I know it's an expansion to B9 and all, but what if you like the D12 parts but not the specific B9 ones that supply textures? It's obviously possible to just leave the textures needed in the B9 folders where they were, but this is somewhat of a pain since you have to look through the de-textured/black parts' CFGs to figure out which B9 textures not to delete from what folders. Would it make any sense to take the small number of specific textures you need from B9 and replicate them as common resources in a folder in this pack? That way it's still possible to easily follow the convention of deleting a part's folder to remove it from B9 if we are both lazy (not wanting to ensure we don't delete the wrong textures) and don't want that specific one anymore. Or would even that limited duplication mean that the RAM usage reduction wouldn't be appreciable compared to what the pack accomplishes as it is right now...? Along those same lines, again just for convenience, it would be handy to have the D12 parts folder organized into part-specific sub-folders so we can do the same thing: could separate all those small texture files in there into their own folder if they are common to every part - but if many of them are specific to one part only, they could be organized into part subfolders with the CFG and .mu so that you can easily remove the parts from the pack that you don't personally use. Just my two cents. Really like the parts you've made though!

Cool, that solution (mass = 2) inside the TweakScale module sounds really easy. More intuitive too, and especially cool if it works without a hitch with exponents like 1.8 or 2.7 or whatever. The reason I was thinking of somehow fitting the definition of that mass=X thing into a scaletype is just that it's very handy to do something like this: SCALETYPE { name = CustomStackBasedOnSurfaceArea scaleFactors = blah blah blah... massExponent = 2 } } ... and then just throw that in the cfg for a particular part, as opposed to having to individually add the mass=2 to every part that also has this scaletype... either way would work, of course. It would let me really easily create scaletypes like "Stack_Engines" and adjust the mass exponents for a whole bunch of parts at once, with an exponent of 2.5 (or something) to make it fall somewhere in the middle of square/cube scaling.

Maybe you're having the same problem as me: does this happen only with parts placed in symmetry? Because the scaling of mass is incorrect for SOME parts in symmetry (I think for parts using anything other than 0.0, 0.0, 1.0 massfactors) when you either pick them up and place them again in the VAB or you save/load a craft, and for all parts if you have IR installed - as far as I can tell.

I do use massfactors for custom configs for things like cargo bays - I feel like they shouldn't actually weigh 8 times as much (0 0 1) when scaled to 2x dimensions since they're hollow (even if that's not what would happen in reality), so I use surface area (0 1 0) for them instead. I'll see if I can replicate any of the weirdness I've been having and/or figure out the output_log... Maybe instead of the whole polynomial thing you could do a per-part or per-scaletype exponent like you have in your example? As opposed to only having one variable that controls EVERYTHING. Like engines, for example: if the mass of the engine scales with volume (cubed) and the thrust scales with area (squared), the TWR of an engine goes down drastically the more you scale it. But in the real world, would you really have to have 8 times the engine mass when scaling to double the nozzle area/thrust? Not a rhetorical question, I really don't know..

Thanks! I don't know if it's helpful, but I noticed that it *seems* like, after removing only scale.dll from the MSI folder (nothing else changed/moved), that it only fixes the strange mass scaling for certain parts - notably it does seem to fix the Rockomax mark 55 radial engine, but it does not seem to fix the (non-robotic) MSI/Parts/Rework/Structural_Probe trusses and whatnot. Tried a few random parts from different mods (VAB scale/mass check only, no save/load or launchpad): Not working: - LLL 1x1 hull - IR Rework structural parts - LLL 1x1 to 1.25m adaptor Seem to work: - KW ST-25 2.5m version of the side tank thing - KW Globe X-5 Thor - Extraplanetary Launchpads MSV-1000 rocketparts container - FASA Saturn H-1 Engine - LLL Radial Thrusters - LLL 1x1 Kethane tank Sorry for wrecking your evening with this! EDIT: I have a crazy theory. Even with MSI folder removed from GameData the shifty mass problem (more mass on re-placement or on load/launch) occurs, but seems maybe less severe. I think it MIGHT have something to do with parts not scaled using massFactors = 0.0, 0.0, 1.0. I had set custom scales for certain parts to scale based on surface area or whatever - this also is the case with the trusses etc. from the IR rework structural pack (I think). Perhaps therefore a general problem in all scale.dll files, somehow made worse when there are 2 of them in gamedata? No clue. Wish I could be more helpful. I am going to hazard a guess that having 2 scale.dll files somehow applies the polynomial massFactors twice. Not sure how to confirm math on that.

Welp... looks like there's funny business with the mass still, when scaled. Both when going to launchpad and in VAB. EDIT: And apparently you spawn in orbit and/or coming back to the VAB makes symmetrical robotic parts disappear and other strange things.

OK! No worries. Not exactly a serious life problem, obviously - I appreciate it though! Testing that now.

Yeah, but for the moment, since the scale.dll copies seem to conflict somehow (I guess?), was just fishing for an easy fix that didn't remove functionality =(

Well poop. Is there any way to just have one? Or does the IR scale.dll do things the TweakScale doesn't?

Huh... I'll go look at this again too. I was using MechJeb to judge mass. I deleted the scale.dll from MSI (16.2) and not TweakScale (1.20). Here's how I'm testing this: - VAB: place whatever part, put mechjeb box on it - Stick Squad rockomax 55 radial engine in symmetry - Scale up radial engine, check mass readout (should be normal/proportional until you pick up the part and re-place it) - Pick up radial engine, put back on whatever part it was on - new mass higher than previous Seems to work OK (no magic mass) when the MSI scale.dll is removed... both when picking up / re-placing and when saving/loading.

Hmmm... Problem is the following. You should be able to replicate it (well, maybe): - On loading in the vab, previously tweakscaled parts placed in symmetry (doesn't seem to happen with non-symmetrical parts) have a huge amount more mass than they ought to. - Can make something similar happen too by placing a part in symmetry in the VAB, then scaling it, then simply removing it from the ship and re-placing it right back where it was. Only happens on parts that have been scaled. Upon re-placing the part, it gains mass. Sometimes it gained mass every time I picked up the part off the ship and put it back on, and seemed exponential - ultimately up to millions of tons for something like a landing leg. - Not just a problem with mass readout from MechJeb: crafts that got saved/reloaded, or where parts were picked up and re-placed in symmetry, really did weigh hundreds of thousands of tons and couldn't take off. I deleted the scale.dll from the MSI folder just to see if that was the problem, and parts now can scale in the VAB and do have the correct masses when picked up / re-attached... will having only the scale.dll from TweakScale cause problems because of referring to MSI's copy, then? I mean to say that I don't know how references in DLLs work - is it just necessary for there to be one scale.dll somewhere in gamedata, or does it have to be a copy at a specific location or something like that?

Quick question - there's a scale.dll in the MSI folder, and scale.dll in TweakScale. Which one am I meant to keep / which is the newest or whatever? Having both causes unfortunate sadness with tweakscaled parts placed in symmetry.

Third bizarre thing happening that I can't figure out how to duplicate: sometimes on loading in the vab, tweakscaled parts placed in symmetry (doesn't seem to happen with non-symmetrical parts) have a huge amount more mass than they ought. I can (sometimes) get this to happen too by placing a part in symmetry in the VAB, then scaling it, then simply removing it from the ship and re-placing it right back where it was. Only happens on parts that have been scaled. Upon re-placing the part, it gains a lot of mass. Sometimes it gained mass every time I picked up the part off the ship and put it back on - ultimately up to millions of tons for something like a landing leg. Can't figure out the circumstances it happens under though... EDIT: After a godawful process of elimination, I think (probably?) the problem stems from Infernal Robotics + TweakScale combination. Infernal robotics installed: problem. Removing MSI's scale.dll seems to resolve some of it for some parts, not others... EDIT 2: Crazy theory posted in MSI thread too: Even with MSI folder removed from GameData the shifty mass problem (more mass on re-placement or on load/launch) occurs, but seems maybe less severe. I think it MIGHT have something to do with parts not scaled using massFactors = 0.0, 0.0, 1.0. I had set custom scales for certain parts to scale based on surface area or whatever - this also is the case with the trusses etc. from the IR rework structural pack (I think). Perhaps therefore a general problem in all scale.dll files, somehow made worse when there are 2 of them in gamedata? No clue. Wish I could be more helpful. I am to take a wild flailing guess that having 2 scale.dll files somehow applies the polynomial massFactors function you mentioned before, but twice; though errors occur with only one copy too. Not sure how to confirm math on that.

Perhaps a silly suggestion for anyone but me, but hey, maybe an easy part to create - with TweakScale making it easy to make 2x size MK2 parts for greater spacecraft hugeness, would it be easy to make a MK2 to larger MK2 adapter? something like 1x to 1.5x and 1x to 2x sizes?

Second weird thing - it seems that the exponents in ScaleExponents.cfg only apply to Squad parts - I modified it (separately from last post) so that the ModuleEngines bit was 2.5 instead of 2. This ended up making Squad parts more than 4x as powerful when they doubled in radius, but other parts (like the one Klockheed engine that would scale) remained at 4x...

Noticing something strange - maybe - wondering if anyone else has this issue: some engines just won't scale (meaning the option to TweakScale at all doesn't appear when right clicking), where others from the same pack will. I cannot for the life of me figure out why. TweakScale 1.20. Here is the code I'm using for the Klockheed OMS engine - this first one will not scale in the VAB: In the exact same cfg file, here's the code I'm using for the klockheed linear aerospike: This is on a clean install of KSP, clean TweakScale, clean Klockheed. WTF am I doing wrong? Config file for the non-scaling OMS: PART { // Kerbal Space Program - Part Config // Shuttle Engine // // --- general parameters --- name = km_se0-oms module = Part author = dtobi // --- asset parameters --- mesh = x0-oms.mu scale = 1.0 rescaleFactor = 0.75 // --- FX definitions --- //fx_exhaustFlame_blue_small = 0.0, -3.0, 0.0, 0.0, 1.0, 0.0, running //fx_exhaustLight_blue = 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, running //fx_smokeTrail_light = 0.0, 4.0, 0.0, 0.0, 1.0, 0.0, running //fx_exhaustSparks_flameout = 0.0, 4.0, 0.0, 0.0, 1.0, 0.0, flameout // --- Sound FX definition --- sound_vent_medium = engage sound_rocket_hard = running sound_vent_soft = disengage sound_explosion_low = flameout // --- editor parameters --- TechRequired = precisionEngineering entryCost = 4200 cost = 620 category = Propulsion subcategory = 0 title = FSX0-OMS Micro Shuttle Engine manufacturer = Klockheed Martian description = Initially a shuttle engine. Now an OMS. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,0,1 node_stack_top = 0.0, 0.31, 0.0, 0.0, -1.0, 0.0, 0 node_stack_bottom = 0.0, -0.47, 0.0, 0.0, -1.0, 0.0, 0 // --- standard part parameters --- mass = 0.40 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 7 maxTemp = 2400 stagingIcon = LIQUID_ENGINE EFFECTS { powerflame { MODEL_MULTI_PARTICLE { name = flamethrust modelName = Klockheed_Martian/FX/engine/x0OMSflame transformName = exhaust emission = 0.0 0.1 emission = 0.5 0.25 emission = 0.75 0.75 emission = 1.0 1.0 speed = 0.0 0.40 speed = 1.0 1.0 size = 0.0 0.3 size = 1.0 0.7 localOffset = 0, 0, -3 } AUDIO { channel = Ship clip = sound_rocket_hard volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } } powersmoke { PREFAB_PARTICLE { name = flamethrust2 prefabName = fx_smokeTrail_light transformName = smokePoint emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.25 speed = 1.0 1.0 localOffset = 0, 0, 0 } } engage { AUDIO { channel = Ship clip = sound_vent_medium volume = 1.0 pitch = 2.0 loop = false } } disengage { AUDIO { channel = Ship clip = sound_vent_soft volume = 1.0 pitch = 2.0 loop = false } } flameout { AUDIO { channel = Ship clip = sound_explosion_low volume = 1.0 pitch = 2.0 loop = false } } } MODULE { name = ModuleEnginesFX //engineID = rocketengine runningEffectName = powersmoke directThrottleEffectName = powerflame thrustVectorTransformName = exhaust exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 85 heatProduction = 360 fxOffset = 0, 0, 0 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 380 key = 1 330 } } MODULE { name = KM_PreLaunchEffect effectName = PreLaunchEffectEngine0 isActive = false } MODULE { name = KM_Gimbal gimbalTransformName = gimbal debug = true yawGimbalRange = 5 pitchGimbalRange = 5 } MODULE { name = ModuleAlternator RESOURCE { name = ElectricCharge rate = 4.0 } } MODULE { name = ModuleAnimateHeat ThermalAnim = x0-heat } RESOURCE { name = ElectricCharge amount = 0 maxAmount = 0 isTweakable = false hideFlow = true } MODULE { name = ModuleJettison jettisonName = fairing bottomNodeName = bottom isFairing = True jettisonedObjectMass = 0.1 jettisonForce = 5 jettisonDirection = 0 0 1 } } Config for the yes-scaling spike: PART { // Kerbal Space Program - Part Config // Shuttle Engine // // --- general parameters --- name = km_se4L module = Part author = dtobi // --- asset parameters --- mesh = x4l.mu scale = 1.0 rescaleFactor = 1.25 // --- FX definitions --- //fx_exhaustFlame_yellow_small = 0.0, -10.0, 0.0, 0.0, 1.0, 0.0, running //fx_exhaustFlame_blue_small = 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, running //fx_exhaustLight_yellow = 0.0, 4.0, 0.0, 0.0, 0.0, 1.0, running //fx_smokeTrail_light = 0.0, 4.0, 0.0, 0.0, 1.0, 0.0, running //fx_exhaustSparks_flameout = 0.0, 4.0, 0.0, 0.0, 1.0, 0.0, flameout // --- Sound FX definition --- sound_vent_medium = engage sound_rocket_hard = running sound_vent_soft = disengage sound_explosion_low = flameout // --- editor parameters --- TechRequired = veryHeavyRocketry entryCost = 24000 cost = 2320 category = Propulsion subcategory = 0 title = FSX4L Linear Aerospike manufacturer = Klockheed Martian description = The epitome of kerbal rocket engineering. This wonder of technology can power shuttles of any color. Has an extreme gimbal range and is very efficient. // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,0,1,0,1 //node_stack_top = 0.0, 0.47, 0.0, 0.0, -1.0, 0.0, 0 // --- standard part parameters --- mass = 6 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.2 angularDrag = 2 crashTolerance = 12 maxTemp = 3600 breakingForce = 200 breakingTorque = 200 stagingIcon = LIQUID_ENGINE NODE { name = top transform = node_top } //MODULE //{ // name = ModuleEngines // thrustVectorTransformName = exhaust EFFECTS { powerflamel { MODEL_MULTI_PARTICLE { name = flamethrustl modelName = Klockheed_Martian/FX/engine/airflamel transformName = exhaustl emission = 0.0 0.1 emission = 0.5 0.25 emission = 0.75 0.75 emission = 1.0 1.0 speed = 0.0 0.40 speed = 1.0 1.0 size = 0.0 0.1 size = 1.0 0.25 localOffset = 0, 0, 0 } AUDIO { channel = Ship clip = sound_rocket_hard volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } } powersmokel { PREFAB_PARTICLE { name = flamethrust2 prefabName = fx_smokeTrail_light transformName = smokePoint emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.25 speed = 1.0 1.0 localOffset = 0, 0, 1 } } engage { AUDIO { channel = Ship clip = sound_vent_medium volume = 1.0 pitch = 2.0 loop = false } } disengage { AUDIO { channel = Ship clip = sound_vent_soft volume = 1.0 pitch = 2.0 loop = false } } flameout { AUDIO { channel = Ship clip = sound_explosion_low volume = 1.0 pitch = 2.0 loop = false } } } MODULE { name = ModuleEnginesFX //engineID = rocketengine runningEffectName = powersmokel directThrottleEffectName = powerflamel thrustVectorTransformName = exhaustl exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 775 heatProduction = 275 fxOffset = 0, 0, 0.0 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 390 key = 1 385 } } EFFECTS { powerflamer { MODEL_MULTI_PARTICLE { name = flamethrustr modelName = Klockheed_Martian/FX/engine/airflamer transformName = exhaustr emission = 0.0 0.1 emission = 0.5 0.25 emission = 0.75 0.75 emission = 1.0 1.0 speed = 0.0 0.40 speed = 1.0 1.0 size = 0.0 0.1 size = 1.0 0.25 localOffset = 0, 0, 0 } AUDIO { channel = Ship clip = sound_rocket_hard volume = 0.0 0.0 volume = 1.0 1.0 pitch = 0.0 0.2 pitch = 1.0 1.0 loop = true } } powersmoke { PREFAB_PARTICLE { name = flamethrust2 prefabName = fx_smokeTrail_light transformName = smokePoint emission = 0.0 0.0 emission = 0.05 0.0 emission = 0.075 0.25 emission = 1.0 1.25 speed = 0.0 0.25 speed = 1.0 1.0 localOffset = 0, 0, 1 } } engage { AUDIO { channel = Ship clip = sound_vent_medium volume = 1.0 pitch = 2.0 loop = false } } disengage { AUDIO { channel = Ship clip = sound_vent_soft volume = 1.0 pitch = 2.0 loop = false } } flameout { AUDIO { channel = Ship clip = sound_explosion_low volume = 1.0 pitch = 2.0 loop = false } } } MODULE { name = ModuleEnginesFX //engineID = rocketengine runningEffectName = powersmoker directThrottleEffectName = powerflamer thrustVectorTransformName = exhaustr exhaustDamage = True ignitionThreshold = 0.1 minThrust = 0 maxThrust = 775 heatProduction = 275 fxOffset = 0, 0, 0.0 PROPELLANT { name = LiquidFuel ratio = 0.9 DrawGauge = True } PROPELLANT { name = Oxidizer ratio = 1.1 } atmosphereCurve { key = 0 390 key = 1 385 } } MODULE { name = KM_Gimbal gimbalTransformName = gimbal yawGimbalRange = 1 pitchGimbalRange = 30 responseSpeed = 50 } MODULE { name = KM_PreLaunchEffect effectName = PreLaunchEffectEngine } MODULE { name = ModuleAlternator RESOURCE { name = ElectricCharge rate = 14.0 } } MODULE { name = ModuleAnimateHeat ThermalAnim = x0-heat } RESOURCE { name = ElectricCharge amount = 0 maxAmount = 0 isTweakable = false hideFlow = true } }