AlonzoTG

TWEAKSCALE 2.4.6.22 IS BROKEN, DO NOT USE!!!!! It throws fatal errors and mentions a problem (duplicate config parameters) which do not exist in the files, each config line is unique in the actual files. I tried to play the game and the game refuses to save past a certain point in my flight and barfs tweakscale NREs to the log... [snip] It used to be a very reliable mod... =( [LOG 23:13:11.446] ScaleModList: listSize 697 maxListSize 589 [EXC 23:13:17.218] NullReferenceException: Object reference not set to an instance of an object TweakScale.TweakScale.OnSave (ConfigNode node) (at <cf1abb1b50de40fe83042990f01ebf6f>:0) PartModule.Save (ConfigNode node) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoPartModuleSnapshot..ctor (PartModule module) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoPartSnapshot..ctor (Part PartRef, ProtoVessel protoVessel, System.Boolean preCreate) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoPartSnapshot..ctor (Part PartRef, ProtoVessel protoVessel) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoVessel..ctor (Vessel VesselRef, System.Boolean preCreate) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoVessel..ctor (Vessel VesselRef) (at <be370b73275e49439ea5e41ceef6700f>:0) Vessel.BackupVessel () (at <be370b73275e49439ea5e41ceef6700f>:0) FlightState..ctor () (at <be370b73275e49439ea5e41ceef6700f>:0) Game.Updated (GameScenes startSceneOverride) (at <be370b73275e49439ea5e41ceef6700f>:0) Game.Updated () (at <be370b73275e49439ea5e41ceef6700f>:0) QuickSaveLoad.doSave (System.String filename, System.String screenMsg) (at <be370b73275e49439ea5e41ceef6700f>:0) QuickSaveLoad.quickSave (System.Boolean saveAs) (at <be370b73275e49439ea5e41ceef6700f>:0) QuickSaveLoad.Update () (at <be370b73275e49439ea5e41ceef6700f>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 23:13:23.259] NullReferenceException: Object reference not set to an instance of an object TweakScale.TweakScale.OnSave (ConfigNode node) (at <cf1abb1b50de40fe83042990f01ebf6f>:0) PartModule.Save (ConfigNode node) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoPartModuleSnapshot..ctor (PartModule module) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoPartSnapshot..ctor (Part PartRef, ProtoVessel protoVessel, System.Boolean preCreate) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoPartSnapshot..ctor (Part PartRef, ProtoVessel protoVessel) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoVessel..ctor (Vessel VesselRef, System.Boolean preCreate) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoVessel..ctor (Vessel VesselRef) (at <be370b73275e49439ea5e41ceef6700f>:0) Vessel.BackupVessel () (at <be370b73275e49439ea5e41ceef6700f>:0) FlightState..ctor () (at <be370b73275e49439ea5e41ceef6700f>:0) Game.Updated (GameScenes startSceneOverride) (at <be370b73275e49439ea5e41ceef6700f>:0) Game.Updated () (at <be370b73275e49439ea5e41ceef6700f>:0) QuickSaveLoad.doSave (System.String filename, System.String screenMsg) (at <be370b73275e49439ea5e41ceef6700f>:0) QuickSaveLoad.quickSave (System.Boolean saveAs) (at <be370b73275e49439ea5e41ceef6700f>:0) QuickSaveLoad.Update () (at <be370b73275e49439ea5e41ceef6700f>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [EXC 23:13:23.558] NullReferenceException: Object reference not set to an instance of an object TweakScale.TweakScale.OnSave (ConfigNode node) (at <cf1abb1b50de40fe83042990f01ebf6f>:0) PartModule.Save (ConfigNode node) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoPartModuleSnapshot..ctor (PartModule module) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoPartSnapshot..ctor (Part PartRef, ProtoVessel protoVessel, System.Boolean preCreate) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoPartSnapshot..ctor (Part PartRef, ProtoVessel protoVessel) (at <be370b73275e49439ea5e41ceef6700f>:0) ProtoVessel..ctor (Vessel VesselRef, System.Boolea

does not load, barfs when configuring Kerbin (!!!) error: [LOG 20:34:48]: [Kopernicus]: Configuration.Loader: Failed to load Body: Squad/Kerbin: Default constructor not found for type UnityEngine.Material [LOG 20:35:06]: [Kopernicus] RuntimeUtility Started AND [LOG 20:34:48]: Parsing Target Material in (Kopernicus.Configuration.PQSLoader) as (UnityEngine.Material) [LOG 20:34:48]: Exception Was Recorded: Default constructor not found for type UnityEngine.Material at System.RuntimeType.CreateInstanceMono (System.Boolean nonPublic) [0x0007b] in <9577ac7a62ef43179789031239ba8798>:0 at System.RuntimeType.CreateInstanceSlow (System.Boolean publicOnly, System.Boolean skipCheckThis, System.Boolean fillCache, System.Threading.StackCrawlMark& stackMark) [0x00009] in <9577ac7a62ef43179789031239ba8798>:0 at System.RuntimeType.CreateInstanceDefaultCtor (System.Boolean publicOnly, System.Boolean skipCheckThis, System.Boolean fillCache, System.Threading.StackCrawlMark& stackMark) [0x00027] in <9577ac7a62ef43179789031239ba8798>:0 at System.Activator.CreateInstance (System.Type type, System.Boolean nonPublic) [0x00020] in <9577ac7a62ef43179789031239ba8798>:0 at System.Activator.CreateInstance (System.Type type) [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at Kopernicus.ConfigParser.Parser.LoadObjectMemberFromConfigurationNode (Kopernicus.ConfigParser.Parser+ParsedMemberInfo parsedMember, System.Object o, ConfigNode node, System.String configName, System.Boolean getChildren) [0x002f1] in <b81c7e09ce34479e9d3831f2ed50b754>:0 at Kopernicus.ConfigParser.Parser.LoadObjectFromConfigurationNode (System.Object o, ConfigNode node, System.String configName, System.Boolean getChildren) [0x000bd] in <b81c7e09ce34479e9d3831f2ed50b754>:0 at Kopernicus.ConfigParser.Parser.LoadObjectMemberFromConfigurationNode (Kopernicus.ConfigParser.Parser+ParsedMemberInfo parsedMember, System.Object o, ConfigNode node, System.String configName, System.Boolean getChildren) [0x00328] in <b81c7e09ce34479e9d3831f2ed50b754>:0 at Kopernicus.ConfigParser.Parser.LoadObjectFromConfigurationNode (System.Object o, ConfigNode node, System.String configName, System.Boolean getChildren) [0x000bd] in <b81c7e09ce34479e9d3831f2ed50b754>:0 at Kopernicus.Configuration.Loader.Kopernicus.ConfigParser.Interfaces.IParserEventSubscriber.PostApply (ConfigNode node) [0x000d7] in <addff56048ca4755ba9b6dedf7ae3dd8>:0

Heh, woomerang is 3.5km underwater. =P

damn mod has broken most of my entire collection dating back to 2014.... It seems to breaking specific parts, all of which are stock: -> stock decouplers. -> stock probe cores. -> stock trusses -> stock antennas. No other parts are affected. =| All spawn at 20M scale. (SRSLY??????) Workaround is to manually edit the craft file and remove tweakscale module.

Whatever happened to the large truss segments that a good portion of my fleet depended on? =\

Hey, I've liked this mod for a long time. Unfortunately it now seems to interfere with and break a number of other mods these days including the WildBlue collection and even the stock ground deployable experiments. =\

Dear TTI: Good Grief, sir! Doest thou even TEST??? Could this be being caused by VRAM exhaustion? Does anyone with a 6+ gb GPU have this problem? (GTX 980/4gb here)

It was fixed in 1.4.5 but the fixes from that release have never been ported to any later release, they forked 1.5.x off of 1.4.2 or something and never looked back. =((( So there are many regressions and Squad/TT are out to lunch on this issue. =( The current PM brags that he's been playing since 1.0, I've played since 0.23 so I out rank him and I want to take over this project.

My install is not even slightly sane right now, north of 20GB running 15+ minute load time, I think the planet packs I have right now are what's really killing it. I'm happy with the 3 launch sites provided by the DLC so I'm not using KK.

It is clear that more than a few bugfixes in the 1.4.x line have NOT been ported to the 1.5 branch. some examples: -> inventory icon alignment in the editor. -> crashes related to crew assignment validations, triggered on larger ships/more complex missions. Both had been broken in early 1.4.x and had been fixed in 1.4.5.

Squad had reported that they had fixed this problem later in the 1.4 series, but in 1.5 I'm noticing more than a few regressions, someone really messed up over there. =| Notice the inventory list isn't lined up anymore, it had been fixed in 1.4.5... So apparently 1.5 had been forked early in 1.4 and more than a few fixes were not back-ported. =0 Damnit, why doesn't the best game ever made have more careful developers?

Yeah, I have like 5,000 hrs+ in this game. =P I have over 250 craft in my active fleet. With this one, the total mass comes out to about 700 tons even on the pad... You have a VERY tall 5M stack and a total of three decouplers, additionally the bottom of the rocket is ringed with an absurd number of tailfins... Solution? Attach the boosters near the top so there is less total stress on the stack and less possibility for the joints to buckle... I kick the thing up to hypersonic ASAP and then kick off the boosters. This is shockingly non-problematic... At 40-50km there are two kinds of rockets, fast rockets and slow rockets... A fast rocket would be getting significant atmospheric heating, even though the density is about 0.02 at that altitude and needs the fairing up until about 51km. A slow rocket, such as this one, is just lumbering along wondering why it needs a fairing when the atmo is so thin at this altitude, so just go ahead and dump it, it's just weight... In the most extreme case I ever launched, a surface sailing ship for Laythe on a 10M stack, I actually had to shut down the engines at 50km, dump the fairings, and then light everything up again. The solution for this rocket is to spin the hell out of it and hope the fairings clear... Mechjeb can then recover and the launch continues as normal. On orbit, I think I'm going to have to retract that telescope thingy before dumping my upper stage otherwise I get killed by that hexagonal cover every time. =\

Okay, I deleted the incompatibility patch directory and the mod is essentially working again. Procedural Parts is not working 100% at this time but I had to use what it claimed to be a 50cm tube to extend the location of the attach node up to where the stock #1 docking port needed to be. I had to use monstrously huge tail fins on the rocket to get it to do anything but cartwheel. =\ (no FAR). I also moved the boosters to near the top of the rocket to compensate for the CoM issue. I get it to about 40km when I want to dump the nose fairings, I found that I have to roll the thing violently to get the fairings to separate without destroying the telescope thingy... Mechjeb deploys it on orbit anyway... When I dump the engine on orbit, it kicks off a hexagonal piece of debris which never fails to score a direct hit on that telesope thingy. I tried to send Bill out to fix it but he can't.

I found a shroud in KW rocketry that should work, but when I loaded the part up in 1.5.1, it loaded as a 3.75m part, with nodes in the wrong position. Also, the docking ports do not seem to follow Kerbal node placement conventions so I can't swap the realistic ports with ordinary kerbal-style ports. =\ The "top" node should be level with the mating surface, and the back port should be flush with the apparent back-plate of the part. For a cone style docking thing, it should be the outer ring that would be brought into contact as the probe is retracted. There seemed to be a shroud like mesh clipped inside the station, not sure what that was for...

Running the game out of tree hasn't worked since 1.4 because of all the "phone home" functions Take Two added. =(

I'm mostly mad at Squad right now for just dumping this on us without really advertising a release date and breaking my career game BAD while changing far more than they should have at this point in the game's life. Also the major change in the game's underlying aesthetic.... -- beat up junky parts -> sleek modern parts. Give the mod authors 2-3 weeks on this one, Squad really did a number on the game this time. =\

Performance is too suck still. =( I installed a beyond kerbin planets mod and I have like 20 experiments at each site to make sure I'm not grinding all month to get a FTL capable ship... Well, it takes literally 9 seconds to do basically anything.... Switch SOI? -> 9 seconds; run an experiment -> 9 seconds; transmit an experiment -> 9 seconds, Get out of the pod -> 9 seconds; let go of a ladder -> 9 seconds, FOR EACH EXPERIMENT!!! It's basically unplayable. Plz get yourself an algorithms textbook and a pot of coffee. =\ I can try to help, plz do e-mail me with stuff you want me to fix or look at...

Hey, I was working the orbital telescope contract and it was very unclear about the requirements. Why aren't you using the stock requirements checklist so I can check whether my vessel matches by just rolling it out? Also, I thought you meant a stock like science lab so I had station parts extended 3.75 M lab on the thing, when I actually needed a ** station science ** lab, apparently... Also still, my instinct for launching this was to send it directly to a graveyard orbit of 4,000km at 10% inclination so it wouldn't pose a risk to anything... Really, the contract needs to spell this out. =|

urk, that just killed loading the parts, going to go through them in groups of ~4 and see if I can nail down the fail tighter than just the R7 directory...

Seems to be an overly nested directory issue in the R7 set, taking out that extra nesting layer seems to prevent it from crashing the game on load... (game ver 1.4.2 )

Yeah, unless you can find a coupler that actually is hollow on the inside (actual collider is hollow, not just appearance, I installed SpaceY to launch this and it's decoupler is NOT compatible...), or re-purpose an engine interstage, there will be a collision when the decoupler fires and it will not separate cleanly because it will be processing collisions between the station's superstructure. On my most recent flight, the launcher was kinda caught on the thing and wouldn't actually separate.

The single biggest issue in making a working spaceship is joint stability. There are two factors that directly impact the stability of a joint: The inherent strength of the joint, and the diameter of the joint. Joint strength is always negatively impacted by having miss-matched node sizes too. (assuming the colliders are well aligned with the node positions..) As coupling solutions are available for everything up to #8 (10M) nodes, as well as several alternate form factors such as Mk2, Mk3, and several mod truss profiles... My latest generation tug, for example, supports #2, #3 and #4 payloads on the bow end, and #3 and #4 payloads on the stern end. Having a #3 node allows me to jettison the #2 adaptor, saving both weight and improving the matching.

I much like the new parts except the orbital assembly line. The transfer pods seem to be very nearly compatible with Near Future construction (iirc.), ie the truss adaptor seems to be correct for mounting it to a 2.5m stack (assuming it's size is not variable, just doing initial VAB testing right now..) My issue with the orbital assembly line and the orbital assembly space is that these are basically #3 parts, or parts that rightfully should have #3 nodes... Take a close look at how the Orca command pod in Rover Dude's Umbra Space Industries FTT pack works. It uses the engine shroud code to create a variable mounting mesh. Indeed, the assembly line requires an expanded 5M (#4 oversized) fairing, so anything less than a #3 mating surface is just not right...

I loaded it up recently and had trouble mounting it to the launch vehicle because the bottom node is "hidden". It causes issues with any part used as a coupler. If i move the node down below the plate it should be fairly easy to add a standard fairing down there and party, or provide a highly detailed launch support structure, otherwise extremely awesome.

Steam is only providing 1.4.4 to Linux users. =|