Lisias

Just for the sake of completude, this is the video where the problem happens: This is remarkably similar to the very first really nasty bug that had bitten me. Some time after the craft exploding, nearby statics exploded too! You are using S.A.V.E. - GOOD! What I found on your KSP.log was a Toe Stomping Fest between TweakScale and IFS. I can't say who is the stomper, as it's usual that an additional Add'On is the one getting in the way - in a way or another, is not a fail on an Add'On, there's no culprit on this. It's a failing on collaborating to each other, a collective bork. The easiest way to check this is uninstalling IFS or TweakScaling so we could confirm at least two of the Screaming Victims - but tha would probably render your test bed useless. There's another way, and it is to check for the collateral effects on the logs. Please fire up your KSP and reproduce the problem on a backup savegame, finish KSP and then publish KSP.log and output_log.txt from Unity's. This time I need both. You will find the instructions on this thread, but I will reproduce the interesting bits below:

With TweakScale available, I didn't care too much about the current part's size. I just scale them and call it a day. This will not work very nice with parts with crew due a glitch on the KSP User Interface (yeah, things works fine on the game engine, it's the User Interface that blows up!) What I would like to avoid is to colide with existing Add'Ons "just because". If there's a better place for a part (as a new MK2 part into the MK2 Extensions), and the maintainers accept it, I think this would be logical - new MK2 parts came from MK2 Ext, new Early Cold War and Pre WW1 eras parts go into KAX. (Electras. I love Electras, by the way. Had flown on one as a kid!). So people don't have to install a whole basket of undesired parts just because they want that extra one. People wiling to use Mk2 spaceplanes usually are not interested on Electras and PeaceMakers.

You are taking it wrongly. It works for KSP as long rogue patches doesn't screws it up - what's being happening for a long time, but I just detected on the problem on the 1.7 era. TweakScale is working for KSP 1.4 and beyond, so you can check for yourself about this. These are the nasty ones that could ruin your day - so TweakScale 2.4.3.0, besides being the most annoying release ever, it's also the safest. Other than that I have 1 visual glitch and two recently discovered annoyances, currently Work In Progress. Yep,. I was wondering if I should ping you back there Yes, this is exactly what I need, thanks. I will post a follow up in the next few hours. I lost you in the stream sorry. I'm delaying CKAN due a mishap on handling U.I. Plain idiocy. Since Real Life took me away for some weeks, I'm going to fix that idiocy and some small things more on 2.4.3.1 . This one will be released for CKAN (unless someone kicks me in the SAS due some more mistake, of course).

News from the front. I finally got some sparing time for coding KSP, and TweakScale was the top of the list. While I managed to close some minor issues (opportunistically, as I was checking different things and it happened to be easy to do the task at that moment), I failed to really solve (today) some more pressuring issues - but at least I managed to figure out where the problems are not in. The Exhaust and Plume Scaling Problem (issue #27) is completely unrelated to the Drag Scaling Problem on the Root Part, as well to the Attached Parts being Moved Incorrectly at Scaling. I will need to dig more on KSP and Unity to fix this, as it appears. On the other hand, the last two can be related. The Incorrect move of attached parts happened only once to me (but I'm almost not playing KSP on the last few weeks), and it plain vanished once I reload the craft - so this hints me it's a problem on the Craft's Life Cycle - something is not being done (or are being done too late), and some data are not initialized correctly and the function that decides to move or not the attached parts borks. I'm guessing that the Drag problem can be related to the Part's Life Cycle too, as a eye inspection revealed that the Drag Function is called differently depending in the state of the cycle the part is. I detected similar issues on another Add'On, by the way. It's a pain in the SAS to find exactly what's happening, and I'm unsure I could do this in just one Sunday. But it's a solid theory, and it's what I'm going to pursue on the Sunday.

Heard this today, and I found it pretty good! Nice to have music like this back on games!

I think that Mk2 Extensions would be a better place for them. It's a very good Add'On, I use it in combination to KAX and get good results. Check the Mk2 Extensions licensing terms and if you do agree with them, check with the Maintainer about your ideas for new parts. But if you are talking about militarized parts, then Mk2ext probably would not be the best place. But neither KAX to tell the true. Then we can talk on that idea you gave earlier! (I plan to use KAX for "not or demilitarized parts", even if that parts can be used on military vehicles. The militarization is to be accomplished by a sister Add'On).

Yep. But we are seeing what's happening, not why it's happening. And without the 'why', it's hard to propose a solution. Or even know for sure that it's not a problem, just a glitch that you can ignore. Doesn't hurt to ask the guys about ROCManager to be sure. A lot of things I used to think it was just a glitch ended up biting me on TweakScale. There're a situation (and this situation is very similar to yours!) in which by merely using the part, you can get into trouble. What happens is that there're conflicting instructions about how the part should be scaled, and this conflict is "handled" in a non logical way. Worse, if something changes (by adding or deleting a Add'On, triggering a new set of patches that can change the present instructions set), the thing that defines how the part should be scaled changes, but not the data used by it! This is one possible aftermath for this problem: This is nasty because the this can happens at any time (by adding or deleting a single patch on the whole system!), and then every craft file and, worse, every flying craft on your KSP installment (as long it has that **FATAL** issue) can end like this. You close KSP, you change a single patch (that by bad luck. borks a part used by a flying craft) and then suddenly, by loading the savegame, your crafts have that part mangled. Sometimes, the part gets bigger, not smaller. You can imagine the results. Yes. But you need to keep remembering it, what's cumbersome. (I thought on patching the part name to keep it flagged - but then I considered I would be patching by brute force an already badly patched part, and considered not being the best of the ideas, as it could be harder to convince people TweakScale is not exactly the one borking on it.) The only really safe option is to fix the problem in a way or another. Since you got lucky and there're only one part on your current installment, you can walk away with this. But avoid adding or deleting Add'Ons to prevent creating new problems (that pesky DialogBox shows a counter), as things can escalate fast. One of my installments got 182 "fatalities" first time I tried 2.4.3! In the mean time, I'm working with Add'On maintainers to hunt down and fix every issue I hear of. A patch at time.

Thanks! The only bad news I detected is about batteryBankMini . Something is patching it twice, and it's the reason that **FATAL** thingy was shown to you. The Module Manager cache shows me that this part has the following TweakScale data: MODULE { name = TweakScale type = stack defaultScale = 0.625 type = RealismOverhaulStackSolid } You see that double "type" thing? That's the nasty stuff. Realism Overhaul is involved for sure, but we can't say if it is the one borking because we are seeing just the ending results, not the order in which things are happening. So I digged again into the KSP.log and found this: [LOG 10:38:01.023] Config(@PART[batteryBankMini]:FOR[RealismOverhaul]) RealismOverhaul/RO_SuggestedMods/Squad/RO_Squad_Electrical/@PART[batteryBankMini]:FOR[RealismOverhaul] [a lot of lines later] [LOG 10:38:01.182] Config(@PART[batteryBankMini]) TweakScale/patches/Squad/Squad_Util/@PART[batteryBankMini] What hints me that Realism Overhaul apparently :NEEDs to add the :NEEDS[TweakScale] clausule on one of their parts, as they are being applied before the default TweakScale ones. Interesting, none of that Exceptions and Warnings that caught my attention on your previous log are being logged this time. So yeah, that hunch paid - the previous TweakScale version was being ran over by other Add'On (or vice-versa!) on the Main Menu (when a lot of Add'Ons needs to finish some business before you can play). The 2.5 beta has some measures that tries to avoid the Toe Stomping Fest, and it appear to have worked for you! The only remaining significative thing worth of being mentioned is this Exception: [WRN 10:40:11.391] [ROCManager]: Invalid CelestialBody Name Eeloo on ROC Definition EelooBerg. Removed entry. [ERR 10:40:11.392] Exception handling event OnPSystemReady in class ROCManager:System.ArgumentOutOfRangeException: Argument is out of range. Parameter name: index at System.Collections.Generic.List`1[RocCBDefinition].get_Item (Int32 index) [0x00000] in <filename unknown>:0 at ROCManager.ValidateCBBiomeCombos () [0x00000] in <filename unknown>:0 at ROCManager.GetROCControlFromCB () [0x00000] in <filename unknown>:0 at EventVoid.Fire () [0x00000] in <filename unknown>:0 This one probably was already there last time, but I missed due being worried about the other ones. My advise to you are, so: The most important of any advise I could give, install and use S.A.V.E. . This will help us to keep your savegames alive Apparently,. TweakSkale 2.5 solved some problems for you . Consider using it for while, I will back port some features for 2.4.3.1 as your installment clearly demonstrated they are needed and effective. TweakScale 2.4.3.0 should be enough, but it will pesky on that **FATAL** message every time you boot KSP until all the **FATAL** messages are gone, and I failed to add a "Cancel" button on that damned thing. In a way or another, S.A.V.E. will prevent any savegame corruption, and I will help in any manual intervention if necessary. Ask Reality Overhaul guys to check their patch on "batteryBankMini" and see if by adding a :NEEDS[TweakScale] that **FATAL** goes away. And thanks for using TweakScale. I can be grumpy sometimes, but I'm also thankful to see TweakScale being useful. humm… The Thankful Grumpy - nice name for a Rock Band…. — HOT FIX — Download the file below (it will be featured on the next minor release - sooner or later :P) Extras/TweakScale/HotFixes/RO-Stock_Electrical.cfg (click the Raw button) and save it into your GameData. I strongly advise to use the following directory (create it if needed): So the patches will survive updates and will be easily found when the time to delete them come. Do you know that feeling in which it looks like we are walking on hot charcoal? Well, I'm currently seating on some. Believe me, this happens. And it happens a lot. All the time. It's the reason we implement some safety-guards and reviews on the development process. As soon as my SAS cold down I have a lot of histories that will make you feel better. Really. We will laugh of this soon.

I'm a bit jumpy due some Real Life Job issues. Sorry if I sounded harsh, sometimes I let RL leak into the Forum. In a way or another, as soon as RL allows, 2.4.3.1 will be released for everybody. Gradually, just in case.

I need the KSP.log. output_log.txt helps when KSP crashes or does something unexpected. To diagnose Add'Ons (and TweakScale), we need KSP.log too. The KSP.log lists every troublemaker part, and you want to detect and fix the parts mentioned with "**FATA**" on the log. Not this one. 2.4.3.1 will be released on the CKAN, the problem that triggers the **FATAL** Pop Dialog are far more spread than I though, and the absence of the "Cancel" button would make havoc around here. A better cooked version is on the way. In the mean time, use "S.A.V.E.". Keep using it], by the way. Yes, let make this perfectly clear. There's no fix on TweakScale for #34 because it's not a TweakScale problem. It's a patch problem. People borks. And since people that writes patches are people, they bork too. Fell free to join the rogue patches hunt. It will be fixed when people start to help detecting problems on the patches, TweakScale's job is to warn about the problematic patches, and this is what it's being done. Issue #34 is closed, by the way. The current TweakScale version is the one you have access to.

It's me, Mari…uh.. Wrong game. Right. LGG had already mentioned it, but I will do it again for the sake of completude: [EXC 18:32:08.050] NullReferenceException: Object reference not set to an instance of an object PartJoint.SetupJoint (Vector3 jointPos, Vector3 jointOrt, Vector3 jointOrt2, Int32 size, .AttachNode nodeToParent, .AttachNode no PartJoint.create (.Part child, .Part parent, UnityEngine.Transform nodeSpace, Vector3 nodePos, Vector3 nodeOrt, Vector3 nodeOrt2, PartJoint.Create (.Part owner, .Part parent, .AttachNode nodeToParent, .AttachNode nodeFromParent, AttachModes mode) Part.SecureAutoStrut (.Part anchor, .AttachNode attachment, Boolean srfAttached) Part+<SecureAutoStruts>c__Iterator3.MoveNext () UnityEngine.SetupCoroutine.InvokeMoveNext (IEnumerator enumerator, IntPtr returnValueAddress) There's a lot, an awful amount of occurrences of this issue. KJR cannot be the culprit, as it's not on your mod-list:[man, I need more coffee! I was looking for my old, deprecated fork, didn't realized the current fork! ] Mod DLLs found: Stock assembly: Assembly-CSharp v0.0.0.0 ModuleManager v4.0.2.0 unBlur v0.5.0.0 MiniAVC v1.2.0.6 ClickThroughBlocker v0.1.7.2 / v1.0.0.0 MiniAVC v1.2.0.6 aaa_Toolbar v1.7.19.1 MiniAVC v1.2.0.6 ToolbarControl v0.1.7.0 / v1.0.0.0 MiniAVC v1.2.0.6 DockingCamera v1.3.5.0 / v1.0.0.0 EasyVesselSwitch v1.11.7052.36539 / v1.11 for KSP v1.7+ KSPDev_Utils.1.2 v1.2.7031.33522 / v1.2 for KSP v1.6+ MiniAVC v1.3.0.3 MiniAVC v1.2.0.6 EditorExtensionsRedux v3.3.21.0 MiniAVC v1.2.0.6 FShangarExtender v3.5.4.0 / v3.5.0.0 HideEmptyTechTreeNodes v1.0.0.0 InterstellarFuelSwitch v3.8.6.4 MiniAVC v1.0.3.2 Scale_Redist v1.0.0.0 KAS-API-v2 v2.0.7037.1430 / vKAS API v2 KAS v1.4.7097.36908 / v1.4 for KSP 1.7.1+ KSPDev_Utils.1.2 v1.2.7031.33522 / v1.2 for KSP v1.6+ MiniAVC v1.3.0.3 KerbalEngineer v1.1.6.0 KerbalEngineer.Unity v1.0.0.0 MiniAVC v1.0.3.2 KerbalJointReinforcementNext v4.0.13.0 HyperEdit v1.5.8.0 / v1.5.8 KIS v1.22.7090.200 / v1.22 for KSP 1.7+ KSPDev_Utils.1.2 v1.2.7031.33522 / v1.2 for KSP v1.6+ MiniAVC v1.2.0.7 KSP-AVC v1.3.0.3 MechJeb2 v2.5.1.0 / v / v2.8.4.0 ParkingBrake v0.1.2.0 MiniAVC v1.2.0.6 PreciseNode v1.2.10.3 / v1.2.4.0 Stock assembly: KSPSteamCtrlr v0.0.1.35 MiniAVC v1.0.3.0 TacFuelBalancer v2.20.6792.18106 KerbalAlarmClock v3.10.0.0 Scale v2.4.2.0 Scale_Redist v1.0.0.0 MiniAVC v1.0.3.0 [x] Science! v5.22.7074.4176 (Your TweakScale is the one current available on CurseForge,. SpaceDock and CKAN by the way). TweakScale does not messes with PartJoints. There's no way TweakScale is directly involved on this. I think that whatever is borking on the PartJoints, is also borking on TweakScale, as I found also a awful amount of what follows: [WRN 18:32:06.246] [TweakScale Warning] No valid member found for mass in TweakScale TweakScale.Tools:LogWf(String, Object[]) TweakScale.MemberUpdater:Create(Object, String) TweakScale.ScaleExponents:UpdateFields(Object, Object, ScalingFactor, Part) TweakScale.ScaleExponents:UpdateObject(Part, Part, Dictionary`2, ScalingFactor) TweakScale.TSGenericUpdater:OnRescale(ScalingFactor) TweakScale.TweakScale:CallUpdaters() TweakScale.TweakScale:Setup() TweakScale.TweakScale:OnLoad(ConfigNode) PartModule:Load(ConfigNode) Part:LoadModule(ConfigNode, Int32&) ProtoPartModuleSnapshot:Load(Part, Int32&) ProtoPartSnapshot:Load(Vessel, Boolean) ProtoVessel:LoadObjects() Vessel:Load() Vessel:Update() What happens by TweakScale not finding the mass data of a part, what is… interesting… to say the least. My best advise to you, right now, is: Install S.A.V.E. and make good use of it. Right now. (This should be the Add'On of the Year, IMHO. ) Install a interim, full debug, work in progress, beta test release of TweakScale that will full diagnose the parts being TweakScale as well any problem it founds while doing its job. It's available on this post. (at the end) The User Interface as messed up, but the code is good for the purpose Install this thing manually, fire up KSP and wait for the Main Menu. Once any Pop Window appears (and expect some), close KSP and publish on TweakScale thread the new KSP.log as well all the Module Manager's data files. Then go back to the 2.4.2 Version of TweakScale until I release the 2.4.3.1 (2.4.3 with a proper U.I, currently a bit more annoying than needed). — — — — POST EDIT — — — — I did a fast look into the MM Cache. Weirdly, I didn't found any of the issues I was expecting, your ConfigCache appears to be clean of TweakScale glitches!

Nice suggestion, I will do it on my next "part development" time window!

After some weeks of intense Real Life work, I finally have some sparing time again. Not much, but enough to retake some researches for some autonomous "weapons" and war birds. (SXT and TweakScale were used on this craft) More pictures clicking on the image. I'm trying to get a nice "historical revisiting" on the airplane that launches this thing, but this is something for the next weekend.

Every engine has this thrust issues, but on propellers they bite stronger due the propellers.: they are just rotary wings, with all the consequences including stall, sound battier issues and drag. I think this happened while transitioning out from FireSpitter (what was a bad move in my humble opinion - even if necessary, I can tell). FireSpitter models the haw stationary engine power (usually measured in horse-power) and this torque being applied to the propellers, considering all the factors above (even on a simplified way) and the net result is thrust (measured in Newtons). Stock engines just handles thrust and call it a day. It appears to me that AirplanePlus plain used the haw power directly into Newtons. I don't exactly think the KSP engines are overpowered. The KSP atmosphere are somewhat more viscous than real life, what probably was done this way to compensate for the smaller size of the planet. Stock KSP engines appears to match exactly their real life counterparts, by the way. It worths to mention that KSP airplanes are usually heavier than the real-life equivalents. Fuel is way heavier than the same amount of Real Life Jet Fuel. In the end of the day, I do decisions by comparisons. I take the stats of a real life equivalent of a stock engine, then compare with the stats of the thing I'm modelling. Whatever is the result (weight, size, power, consumption, etc), is mimicked on the part being develoiped while compared with that stock engine. A lot of learning and research are involved on this. Not a easy and dirty task.

Answering my own question - the Z position of the attached part. I think the scaling code is "leaking" into some other datum. This time, on an attachment point. Interesting enough, by reloading the craft the problem plain vanished, now it works fine again. I'm trying to remember the sequence of changes that leaded to the problem. I think that re-rooting the vessel can be involved, as I remember doing that, but for the moment, no dice. If someone manages to reproduce something as this, please advise. — POST EDIT -- The good news is that the the bad scaling of the attached parts is unrelated to the exhaust/plumes scaling. On the other hand, it appears to be related to the fail on scaling the Root part. It's apparently a change on the Part's life cycle - the order in which some callbacks had changed, or perhaps some things that were used to be called serially are now being called concurrently.

You can say that twice. Two times in a row! I spent the last 12 hours hunting down a "terrible" logic bug that fooled the QAS and got through. It ended up not being a logic bug, that code was the Screaming Victim. And I didn't exactly found it, I stumbled on it due another silly mistake that I was reporting to a colleague. Silly mistake that I caught while trying to figure out the problem. What's irrelevant anyway, as that silly mistake when fixed ended up minimizing the need of my feature at first place, the product could go live without it now. So I leaved for lunch. And eat the most greasy, brain satisfaction inducing food available on the eatery. — — — POST EDIT — — — (after nap) — — — — — — — — — — — No need to hurry, I called it a day and i'm going to get some sleep. The (very) good news is that I finally have time for KSP again.

It took me some serious time until I realized what's happening… There's no Scale.dll on your installment!!! Somehow, someone of something deleted Scale.dll from the GameData/TweakScale/Plugins folder. This folder is still there, I think, as Scale_Redist.dll is on the DLL listing. I suggest you to reinstall TweakScale.

Adress bus is not the same as Memory Controller. You usually build the Memory Controller around the address bus. That said, X64 only uses 48 bits internally, the remaining 8 bits of the address registers are plain floating. So even by have a 40 bit address bus on the "outside", internally the CPU still supports up to 48 in the core. 48 bits allows you to address 256 PETABYTES of memory. Unfeasible to get any computer with that much RAM in the foreseeable future. 40 bits allows you to address "only" one PETABYTE of RAM. I'm pretty sure this is enough for nowadays uses.

We unintentionally derailed the thread with side talk, then we moved the posts to a better place when we realized the problem.

(sigh). When everything else fails, read the Manu… I mean.. the Source. You can omit the "name = Part", it's automatically added at runtime. About the nonworking thing , I need your full KSP.log and MM's ConfigCache to see if there's something interesting there before firing up a dedicated test bed for this issue and start comparing results.

Forget what I said below! =D This is what you need to do: @PART[SCAN*]:NEEDS[SCANsat]:FINAL { MODULE { name = TweakScale type = surface //SGExPercentScale TWEAKSCALEEXPONENTS { name = Part DryCost = -1.5 mass = 1.25 } } } // zer0Kerbal // CC BY-NC-SA 4.0 I'm so focused on fixing bugs that I seeing bugs on everything I touch!

Who likes Hammond's sound?

Until they screwed up HMI devices support. Yeah. Joysticks.

The funny thing: if you are not using TweakScale, installing it is safe - as you for sure are not using any scaled parts on your savegames! Things goes through the tubes only when you load the savegames, so firing up KSP with TweakScale to see what happens is also safe. Additionally, there's S.A.V.E., linked above. Frankly, I just don't know why I (or someone else!) didn't came with this before. Wth this working, you have for "free' the backups I'm advising to be done, You should use the latest TweakScale. This is the one that would pop up a Alert Box is any showstoppers are found. If you are creating patches for TweakScale, it's essentially the mandatory one - any mishap that lead to a known problem, and an entry on the KSP.log happens - that scary message only happens for the real, real terrible ones. It's worth to mention that the problem is not a bug on TweakScale code os something - it's a problem on patches. The real nasty problem is when you apply a bad patch to a part, and this part is being used on a flying craft - this corrupts the memory copy of the part, and from this point on, your craft is ruined (assuming it's not exploded). As a side note - a Quick & Dirty way to "fix" a installations with rogue patches for a new, fresh install is to open the KSP.log file, check the offending parts (that one with "**FATAL**" and then locate and delete that kraken damned patches. The current public release of TweakScale leaked two bad files: for MarkIV SpaceSplanes and for B9 HX: For B9 HX: B9_Structure_HX1_S_HS ( HX1-S-HS Structural Hub Support) Mark iV System: mk4cockpit-shoulder-1 (Mk4 Aerodynamic Shoulder) mk4cockpit-shoulder-2 (Mk4 Orbital Maneuvering Shoulder) mk4cockpit-shoulder-3(Mk4 Intake Shoulder) Delete that patches (or the whole file) if you have these Add'Ons installed and move on. Next TweakScale will have them fixed.

I can only imagine the harsh work and trial and error and work again. Looking on TweakScale commit history is to look into a Window through KSP development history - it's almost archeological. . You hinted me that I need to expand my researches to Unity itself. KSP is "just" a layer over Unity, not the whole thing. Something that you couldn't, by the way. Unity 4 and 5 source code are not available (not even now, the oldest published is 2017.1.0a3) - it's less hard nowadays. By the way, that exhaust scaling bug can be related - or not, just with the same root cause. What raises a yellow flag - if the flame is not being scaled on an axis (the length) what's being scaled in its place? That bug can be more than just aesthetics! About reputation… It's a highly volatile asset. You can loose it or earn it for the most silly reasons. Thrust , on the other hand, is a invaluable resource, and once you lose it, it's done. You made a hell of a work, dude. No one can take it from you. And as Asimov said: "Never let your sense of morals get in the way of doing what's right."