Lisias

Well, you are getting a division by zero or some other math accident on the code! rPos: [NaN, NaN, NaN] rVel: [NaN, NaN, NaN] |NaN| Delta: [NaN, NaN, NaN] / [NaN, NaN, NaN] The problem happened at 1.000 meters apparently. And I think it can be related to the 3D World rendering instead of the physics engine - something happens at 1.000 meters. But without the code, it's a blind guess - with the code we will be guessing too, but at least we would be seeing what we are guessing. — — — POST EDIT — — — I run a small test: got a rocket, activated the infinite fuel cheat and launch it with the smallest vertical velocity I managed to set - of course, with SAS activated and keeping the nose straight up (at 90° marker on the Navball). You will notice that the ship will "drift" to west slowly. This is Kerbin rotating under you - winds are not simulated on KSP. Division by zero happens when the dividend gets smaller and smaller until you have a underflow and the float is "rounded" to zero. Assuming this is what happened on the code, something that never goes to zero is... going to zero, and then things go through the tubes. One thing that is never zero once you are flying are the angular speed of Kerbin. Since KSP "centers" the universe around your ship (i.e., everything moves around you for simulating you moving around - this is a trick needed due Unity using floats and not doubles on the physics - something needed as GPUs are tremendously faster handling floats than handling doubles), Kerbin is not moving under you when you are landed - but once you are flying, this is something that cannot be zero. Ok, this is a wild, blind guess. But it's something to start looking into the problem.

Ah! I finally got it! KSP 0.7.3 was the first public release, published in June 24th, 2011. KSP 1.7.3 was published in 11th July, 2019. 8 years and 16 days later. Or exacts 8 * 365 + 2 (leap years) + 16 == 2938 days. From KSP 0.7.3 to 1.0.0 (27th April, 2015), they took 3 years, 4 months and 3 days. Or 3 * 365 + 1 (leap year) + 117 (days from 1st Jan to 27th April on a non leap year) == 1213 days. Or ~41.28659% of the whole development time for public releases. So I conclude, using data pulled out of my hat and using uncorrelated figures I found by inferring numbers without any meaningful reason, that KSP 2.0.0 will be published on 19th, November 2022 ! (yep. pre-deploy anxiety. )

As LGG commented above, we need more information. What's your machine? MacOS version? You can try the "-force-glcore" stunt. Open your terminal and try this line: open -a "/Users/lisias/Applications/Games/KSP/Challenge.Walker/KSP.app" --args -force-glcore Change the full pathname above to whatever you had used to save your game. That failing, we will need the KSP.log and also the ~/Library/Logs/Unity/Player.log . MacOS has a very handy utility called "Console" where all the logs are consolidated, I recommend it. The OpenGL was deprecated in MacOS 10.14 (Mojave). This means that the artifact is not being updated, and it may or may not work as Apple updates the system device drivers to support new hardware (of fix bugs). It's a matter of time until new drivers break the abandoned OpenGL and then it will be it.

The Database AutoReload doesn't reapply MM patches. It's something I was working on my personal fork when some third-party code changed, breaking some internal code. Currently I'm waiting for that changes to stabilize so I can attack the problem again without risking throwing the work through the Window (time is scarce these days, and I still have some debits on TweakScale).

I'm laughing my SAS out. It's absolutely amazing how my own mishaps on launching things usually ends exactly this way!

CLOSED/WORKS_FOR_ME KSP has a lot of annoying bugs, and I don't have the slightest problem on pinpoint the ones I find. But this is not one of them. Apple, from the top of their arrogance, is deprecating OpenGL. They plain refuse to realize that people just don't throw away software just because. Even Microsoft tries hard to keep things working as the time pass. The fine irony is that Unity has born as a Engine for Macs. Life is made of choices. I choose to stick to Sierra (I used High Sierra for a couple of days and gave up on Apple). Perhaps you should complain to Apple in the same way you complain to Squad? (please note that I'm not criticizing your complain to Squad, besides believing there're better ways to do so - I'm telling you to use the right complain to the right responsible. Or culprit).

Hi. These are parts from Munar Industries. Totally unrelated to IFS. I gone a bit proactive and checked MI's patches for TweakScale for any evident mishap - not a single one, the patches are being applied to MI's parts only. So there's nothing @FreeThinker can do about. Post the whole KSP.log on the TwealScale's thread. From the log I can trackdown who's applying patches to the parts and in which order, so I can detect the problem and provide a fix. — — POST EDIT — — @Mordrehl, the problem was detected and fixed. See TweakScale Thread for details:

Not exactly a surprise but KAX is working fine on KSP 1.7.3 (with Making History and Breaking Ground).

ANNOUNCE: Impossible Innovations V0.8.8.5 is on the wild! Nothing really important, just a small fix on the filesystem to prevent problems with another Add'Ons (as TweakScale). And the thing is (still) working fine on KSP 1.7.3 Download on the OP. Cheers!

Perhaps this is the problem? Being able to built a rock with 3 or so parts? This is not Simple Rockets. KSP is a "brick game" blended with a "puzzle game" with some Aerospace background as theme. LEGO Style. LEGO is famous for their building bricks. And yet, they also add some function specific "bricks" to the set. It's not different, on my opinion. They saw a need to extra, fueled wings and a high pass turbo-fan engine. These things could not be implemented using the standard set of "bricks", so they added it to the game so gamers would not need to rely on Add'Ons for that feature. From a guy that spend some time building some really huge planes, having wings with fuel is a life part save. With this puny machine I still using for some playing, the part count matters - not to mention the piling drag issues. I think it is. The only real alternative to a propelled aircraft is Fire Spitter. All the rest are just jet engines in disguise - no more than that. I would be somewhat disappointed if Squad would had wasted valuable development time on vanity parts only. That said, I'm unsure if "Robotics" is the right place for the Turbo Shaft Engines. There's already a Category for Engines, they should be there.

I'm late to this party, and just had time to fire up KSP yesterday night. Gone straight to the Props and Turbo Shafts, by the way - didn't had time yet to see anything else. The whole concept shines on my eyes. What some people calls "unneeded complications" are exactly what make props interesting at first place: you need to choose the right prop, and you need to trim the blade's angle of attack together the engine torque! Beautiful! The propellers are simulated individually , by the way. The only flaw is not being able to "group" them on the same engine so they would receive the commands as one - symmetry doesn't cut it out for them. I can't talk about anything else yet (but that ejection seats gave some kerbal ideas…), but I'm on it!

Thanks, @Annastasya! I will give a look on your fixes on the WeekEnd! (And to think they told me this week would be easy… hehe… I was trying to read your posts for the last 18 hours! ) — post edit -- In some other weekend, as it appears. But I will look on it.

Indexing mismatches and vanished mass on a few parts. I think that it's a third-party something stomping our toes. There's a partial report here. I need a couple days more for a proper research, all I got until the moment are collateral effects. My guess is that by deleting IFS, he got rid of the Screaming Victim - the perpetrator is still hidden somewhere.

I came to realize that using GameDatabase.Instance.GetConfigNode(Part.partInfo.partUrl) is a very handy way to get exactly what the ConfigNode of a part is in memory. But it happens that spaces on the partUrl make it borks. I can inspect any part on the GameDatabase using the partUrl, except by the ones using spaces somewhere on the URL. There's a workaround for this, as replacing "_" by "." on the partNames?

From that time to nowadays I further improved the concept. I documented my current thoughts on this issue: https://github.com/net-lisias-ksp/TweakScale/issues/46 The good news on this is that Robotics doesn't uses mass on the MODULEPARTVARIANT, so this is not a blocker to implement TweakScale patches to the Robotics parts. Keep in mind that all of this is pure Research at the moment. So things can plain go through the tubes without previous warning. There're a lot to be learnt about it yet.

Yet a one more small enhancements to the Logs. Add the part's Title. The U.I. name for the mentioned parts are: Size1p5.Tank.01 : FL-TX220 Fuel Tank (Making History) fuelTank.long : FL-T800 Fuel Tank (Stock) adapterSize2-Size1 : C7 Brand Adapter - 2.5m to 1.25m (Stock)

Interesting. The output_log is clean. It shows you pausing the game and other unrelated actions, absolutely nothing abnormal. Well, the good news is that we are not injecting garbage into the Physics Engine as I was fearing. I found this, however: [WRN 18:06:04.403] [Part]: PartModule indexing mismatch at Size1p5.Tank.01, index 1. Node 'TweakScale' found in loaded data, but 'InterstellarFuelSwitch' is defined in prefab. Looking for TweakScale in other indices... [WRN 18:06:04.403] ...TweakScale module found at index 10. [WRN 18:06:04.405] [Part]: PartModule indexing mismatch at Size1p5.Tank.01, index 2. Node 'InterstellarFuelSwitch' found in loaded data, but 'IFSCryostat' is defined in prefab. Looking for InterstellarFuelSwitch in other indices... [WRN 18:06:04.405] ...InterstellarFuelSwitch module found at index 1. [WRN 18:06:04.405] [Part]: PartModule indexing mismatch at Size1p5.Tank.01, index 9. Node 'IFSCryostat' found in loaded data, but 'ModuleFuelJettison' is defined in prefab. Looking for IFSCryostat in other indices... [WRN 18:06:04.405] ...IFSCryostat module found at index 2. [WRN 18:06:04.405] [Part]: PartModule indexing mismatch at Size1p5.Tank.01, index 10. Node 'ModuleFuelJettison' found in loaded data, but 'TweakScale' is defined in prefab. Looking for ModuleFuelJettison in other indices... [WRN 18:06:04.405] ...ModuleFuelJettison module found at index 9. It appears to be the aftermath of a Toe Stomping Fest. This is happening for fuelTank.long and adapterSize2-Size1 too. I also found: [WRN 18:06:03.612] [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 hints me that something is, indeed, wrong while initializing things. This message doesn't tells me the part, however. I need to fix that log. I need the part's name in order to know where to look for problems. Mass is a very important thing on Physics Engine. I think something would be logged on the output_log if anything gone wrong on that level, but things change between KSP versions, logging included, so I will not rule this out for now. There're no conclusions on the problem yet. I need to spend some more time doing tests, but at least I have a start point. Did you used Size1p5.Tank.01, fuelTank.long and adapterSize2-Size1 on any of the vessels on that flight? — — — POST EDIT — — — [Forget everything below. I detected the problem, and it's a very stupid one! It's a problem to me, however, as I still need to check the integrity of every part]

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.