Lisias

That may or may not be enforceable, depending of the country the guy is (exactly as the software licenses, by the way). Did you ever checked what would happen if you try to get permissions to track data from kids under 13? Unfortunately, it's not that simple. There's the P/R factor. Being involved on a lawsuit even when you are right and can prove you didn't did anything wrong still hurts your reputation, and reputation is something expensive to fix. I agree. Unfortunately, things takes a lot of time to get fixed - and we still need to keep our lives going on in the mean time. So some compromise is needed. Me too. And exactly by that I understand his motivations, besides not agreeing with them. You can be "wrong" and still have good reasons to be "wrong" - sometimes, all we can do is to try hard to be the less wrong possible given circumstances we have no choice but to cope with. Not exactly. KSP is great because, besides some disagreements that could theoretically ended up in a Court of Law, the absolute majority of people here puts the game above their personal feelings, and almost every time we settled up on doing what's right in a way or another. What makes everything here be so great is not the absence of problems, but the willing to fix them how we can and do better next time.

It's in Beta yet. It's perfectly safe for use (the Alpha ones are potentially harmful), but it have an issue that prevents it to be published widely at this moment: by some reason that I still don't understand, the Revert to Launch resets the plume to the original scale… You can save the game, load the game, switch between vessels, revert to editor and launch again, no problem. But if you Revert to Launch the plumes are descaled, and I just didn't found the reason yet…. (working on it as RL allows)

Hi, Guilty as Charged, Your Honor. Sorry. What happens is that, on KSPIE, TweakScale is made unavailable* for new crafts when full third-party modules support is not available (existing crafts and savegames are preserved, but as is - use them at your own risk). Currently, this happens when you have Waterfall installed, but not the TweakScale Companion for Visuals, that would provide support for scaling the plumes - and scaling engines without scaling the plumes was considered undesired by KSPIE. Your current choices are to deinstall Waterfall or to install TSC for Visuals. One of that will make TweakScale available gain for new crafts. *obs. Since 2.4.5, TweakScale provides ways to "soft ban" scaling on some parts at System's Integrator discretion (i.e., TweakScale never soft-ban anything, it's up to third-party authors such decision). It's called soft ban because it does not screws up any already existing crafts and savegames, but prevents TweakScale from being used on new ones. This was originally intended to be used on Challenges where some (or all) parts should not be TweakScaled (preventing the need to uninstall TweakScale for playing such Challenges), but this stunt found its way into situations where systems' integrators found undesirable to allow TweakScale to be used punctually by other reasons.

Now and then this music sparkles on my head for days. Here. Now I'm not listening to it alone anymore!

I need the full KSP.log published on dropbox or something, otherwise I can't help. Please also add ModuleManager's Patch Log and the ConfigCache, as this can be helpful once we have a lot of add'ons installed, potentially stomping each other's feet. — — — POST EDIT — — — @Cookie0815, I just did a code review on Refunding looking for a division by zero or something that could be inducing the current thread to die and provoking some spurious processing (like stack dumps) that could affect your FPS, but I found nothing obvious. So, even by being something on Refunding, I really need your logs to purse this question - I have little to no time for leisure, what to say for modding, and exploratory tests are out of the question - I can't dispose the little time I have these days pursuing problems that I don't know for sure where they are! I have a new release of Recall on the works, I will delay it a day in the hope I get your log in the mean time. Cheers!

It's an usual source of misunderstanding to assume things. The best way to detect and confirm problems is, well, testing for them. No. Mechanical strength does not scales at the same pace of the weight of the material. This is another assumption that is driving you into the wrong path. You can almost double the mechanical resistance of a structure by changing the shape of the structural tubes but using the same mass. Off course you will be strengthening one axis and weakening another, but by then you can reinforce the weakened axis (if needed) with lighter materials, as steel wire ropes, with the net weight growth way less than the twice TweakScale uses. Corrugating the material is also a well known way to strengthen mechanical resistance with way less material than otherwise. They did it on Saturn, by the way. One size does not fits all. On your assumptions, you are not considering the function of the scaled part neither. A scaled up NoseCone will not carry more payload once scaled, as they don't carry payloads at all. So no reinforcements on the floor (or whatever a payload would be attached) is needed - and, frankly, NoseCones don't even have a "floor", as it would be a wast of material and unnecessary weight. Scaled up nosecones do not need to withhold more load per squared inch than unscaled ones. Since they are bigger, they have more squared inches to account for, but the load that each squared inch will withhold is the same. So I don't need to scale the skin thickness of the NoseCone, and so no extra material will be used on it other that the needed for the extra area. In a nutshell, scaling up the size of things does not implies automatically on the same scaling up of the materials used. The forces to be withhold are recalculated and the needed amount of materials is used instead. As an example: The Saturn V's S-IC (first stage) weights (when empty) 130 tons (and measures 42 x 10 meters). The S-II (second stage) weights 36 tons (and measures 24.9 x 10 meters). S-IC is where the engines are attached, and those struts weights about 21 tons. Each F1 engine weights 8.4 tons, so we have now 21 + 5x8.4 = 63 tons of mass. So the S-IC once extracted the engines and respective struts weights about 67 tons. The amount of fuel the S-IC carries weights about 2.000 tons (the gross mass is 2.280 tons). So it uses 1 ton of materials to carry about 29.8 tons of fuel. Or, in another terms, a ton of fuel needs 0,033557047 tons (or 33.5 Kg!) of materials to be carried on. The amount of fuel the S-II carries weights about 443 tons. So it uses 1 ton of materials to carry about 12.3 tons of fuel. Or, in another terms, a ton of fuel needs 0,081300813 tons (or 81.3 Kg!) of materials to be carried on. Do you see a trend here? The bigger the tank is, the most efficient per ton it became - the "savings" are not linear. And the S-II is not corrugated. The same happens with Nose Cones, the difference is the "load" happening on the skin from outside.

They do the same thing in different ways. KJR/Next is not updated for 2 years (and it's a year since the last time I tested it), so yeah, everything I said is still valid - at least, for the KSP versions it is still working (I don't remember the last time I tested it, so I can't say if it's working for contemporaneous KSPs). KJR/c was updated 6 months ago, and it merely disabled one of the features introduced on the immediately previous version, so yeah, everything I said is still valid. Again, for the KSP versions it is working on (you will need to test it yourself, I think).

BetterBurnTime appeaes to be trying to read a file that doesn't exists. Remove BetterBurnTime from gamedata and see if the game loads. I think it will. If successfull, reinstall BBT from scratch. If it fails again, you will need to ask for help on the BBT thread. If by removing BBT the problem persists, the we will need the whole KSP.log on Dropbox or something, as it's something else borking and letting BBT taking the blame.

Found this, it appears to be related to the problem when it happens on MacOS: https://developer.apple.com/forums/thread/124155 Apparently, it describes the situation I think we are having on KSP: a main, high prioritized thread being screwed up by waiting for lower prioritized threads. What should be nonsense on a sane World, as high priority threads "don't call", they are "called". The "Busy Wait" (or SpinLock) I detected may be an undesired and unexpected side effect of the priority inversion of a main thread, being so this the problem. What suggests a less then ideal overall design of the process. On an educated (but somewhat blind) guess, a inversion of control should be applied here instead, where the low priority thread would "call" the high priority thread when the job is done, instead of having the high priority thread asking the lower priority one "are we there yet?" all the time...

Bye Bye Beautiful. Onlson had her good moments on Nightwish, no doubt!

EXCELENT! One of the best Kerbal videos I ever watched!

Geez…. Things are worse than I thought. Use of spinlocks on user-space was already chewed down by Linus Torvalds! It's a trend, a nasty and naught trend. To the point that sooner or later this need to be addressed by the anti programmed obsolescence guys. These developers are deprecating hardware by no reason. https://linux.slashdot.org/story/20/01/06/012251/linus-torvalds-calls-bloggers-linux-scheduler-tests-pure-garbage I didn't had too much improvements, other on the loading time - and even that, as long as I don't reload the game more than 2 or 3 times in a row. Obviously, I'm already bottlenecking something else on the MacCrap 5.1. However, by using mono threads as 2, I feel the thing is slightly less sluggish, and the whole machine is now performing better. And 8oC (to 10!!) cooler that using default. I'm serious, my machine is running cooler this way. What, again, pinpoints a bottleneck somewhere else on the rig - almost surely on the GPU (that, frankly, is terrible - Intel HD 3000). Another noticeable enhancement is the Main Menu animation - way smoother. What again suggests I'm bottlenecking the GPU - the Main Menu animation is somewhat spartan compared to the Flight Scene. —— POST EDIT ---- I removed some GPU intensive add'ons (as Waterfall, that I was testing successfully on 1.8.1) and it improved the framerate a lot (almost to the level of 1.7.3 on the same machine!!!). The CPU temperature raised a degree too, so I was right about bottlenecking the GPU.

I did some timings on a Mac Mini 5.1 (i5-2415M 2.3 / 16GB RAM) and KSP 1.8.1. I just fired it up and stop the chronometer on the first chord of the intro music: default 5:48 MONO_THREADS_PER_CPU=1 5:10 MONO_THREADS_PER_CPU=2 4:48 (!!!) MONO_THREADS_PER_CPU=3 5:02 MONO_THREADS_PER_CPU=4 5:03 MONO_THREADS_PER_CPU=5 5:00 MONO_THREADS_PER_CPU=6 5:04 MONO_THREADS_PER_CPU=2 5:00 default 5:33 MONO_THREADS_PER_CPU=2 5:22 (???) The values are inconclusive. Apparently, the best loading times are get with 2 threads per CPU on my rig, but the schizophrenic cache mechanism used by MacOS may be screwing up these values greatly. (The use of a spinning disk is also a factor, for sure) (the tests were made one after the another in a row, with the first test not counted). I will redo this test by night, with the machine rebooted (something on Unity appears to need it sometimes) and without anything else running to see what I get.

Don't have a clue, it can shoot backwards easily. As a rule of thumb, you should not have more threads on spinlocks than the available CPUs (or hyper threads). But by doing so, you sabotage paralelism on your rig. So there's a sweat spot where you don't screw up too much your cores to the point of saturation and still have decent parallelism. Apparently this sweat spot is 2 for i5 mobile - more than this and the whole machine start to stutter without any benefit for the game. Xeon cores will probably withhold more abuse. But you will need to try and err your way on your rig. Geez!!! That much?

You are running on Windows, right? Well, on Windows I only remember how to set system wide Environment Variables. Whats not exactly optimal, because we want a way to set it up only for KSP 1.8.0 and newer. Anyway, this link explains how to do it: https://www.twilio.com/blog/2017/01/how-to-set-environment-variables.html You want to create a new ENVVAR called MONO_THREADS_PER_CPU and set it to 1, and see what happens. If your problem persists, it will not help you - so redo the steps above and remove this variable, as it will hinder your Unity games for sure. On the other hand, if the stunt sticks, you will want to change 1 to a bigger value, the bigger you can set it up without screwing up your computer (neither triggering the TLA again). It's a trial and error process. Let me know if it works for you! This appears to be important.

@steve_v, if you are still around, I think you will like this one.

@Commodore_32, I just found something that may be related to this problem! Do you still have this happening to you? On the thread below, I discovered that by using a thingy called MONO_THREADS_PER_CPU I could run KSP on older machines where this was impossible due stuttering. Thinking a bit about, the same thingy that it's delaying the GC could be affecting you too, so perhaps setting the MONO_THREADS_PER_CPU to 1 (for starters) may help on this issue!

That's the History. When KSP 1.8. came, using Unity 2019, my old Mac Mini 5.1 (i5, 2 cores, 4 HyperThreads) didn't handled it. I just could not fire up KSP and keep the machine useable - the whole thing started to stutter. Facebook, Youtube, command line terminals, you name it. Everything were stuttering, it was impossible to watch a video! Since I was going to buy a new old rig anyway (that by pure chance ended up being an Mac mini 6.2 - 4 Cores, 8 HTs), I didn't gave it to much attention. The new old Potato ended up handling KSP >= 1.8.0 and that allowed me to keep using it for development (besides KSP 1.7.3 still being way more performatic, being the reason my main playing is still 1.7). And so KSP 1.12 came, and screwed everything again: KSP 1.12 did to my Mac Mini 6.2 what KSP 1.8 did on the 5.1 . Krap. Oh, well. Life goes on. I still can run KSP 1.12 for some "quick" and small tests and use 1.11 for the main workload until I figure out a way to buy yet another new old potato. But then I realized I made a less than ideal decision making on a thingy called Refunding from KSP-Recall. At that time, I had pretty little time to fool around and made things the fast as I could in order to work around the problem under my nose, rushed the thingy into the Mainstream and gone back to day job, and by doing this I ended up bullying the GC. I then optimised a bit the memory usage, but the bulling just would not stop. It ended up being (another) bug on KSP that was causing a memory leak, that was triggering the GC a lot, that was being sabotaged by spinlocks on the waiting threads! Checking the worst processor hogs on the KSP's process, it came to my attention that almost 100% of the CPU time was being used on a system call related to Semaphores inside an Unity thread, the dispatch_semaphore_wait_slow that by itself was spinning around os_semaphore_wait that by its turn was calling semaphore_wait_trap. Interesting. Checking the other threads of the KSP's process, I got horrified! LOTS AND LOTS OF THREADS hogging up 100% of the CPU, a clear indication of busy waits! It's not a surprise Refunding was provoking a memory leak - there're so many threads busy waiting for the GC that there's no CPU left for the GC itself, and so we have a dead lock!!! Every single thread, including OSX HID Input (Human Interface Devices) are boggling the CPU at 100%! It's evident now why the input is so sluggish when your crafts gets to big for your rig!!!! Digging a bit more on the subject around the Internet, I came to a Swift code like this one: if (mutex_sem != 0) kr = semaphore_wait_signal_trap(cond_sem, mutex_sem); else kr = semaphore_wait_trap(cond_sem); What explains a lot - semaphore_wait_trap is used without a mutex, and so somebody somewhere is using a spinlock to do the job - you know, we need to synchronize things between threads, right? Remembering a very productive exchange with @darthgently, I decided to use one of the tricks he taught me, the MONO_THREADS_PER_CPU environment variable. It tells mono to, well, limit the number of threads per CPU. By limiting this number, we would have less spinlocks on the process, and so the poor CPU would have a better chance to do its job instead of spinning around the same code waiting for something that will never happens because the CPU is being completely screwed up by the waiting threads. Since I'm on a UNIX machine, this is what I did: The command MONO_THREADS_PER_CPU=1 ./KSP.app/Contents/MacOS/KSP will set the environment variable and then call the executable `KSP`. On exit, the environment variable will be lost, so no chance for it to linger and end up screwing up some other process you call later. And that, my friends, solved the problem for me. My old Mac Potato 5.1 is now able to run KSP 1.8.1 . Barely, the game is still slugish but the rest of the machine is useable! I can even watch Youtube videos while running KSP 1.8.1, something that was impossible for this machine 17 months ago! My less old Mac Potato 6.2 managed to withhold some more abuse from KSP 1.8.0 to KSP 1.11.2 because it have twice the cores of my previous rig, but now on KSP 1.12.0 someone increased the default number of threads per CPU again (or something similar) [edit: see note below], and it screwed up my i7: there's no point on increasing the working threads with spinlocks, all you will get is more threads waiting for something that will never happens because your threads are preventing everything else to run! Note: Since the last time I revisited this article, I managed to diagnose the reason KSP 1.12.x screwed up so badly my punny Mac Potato 6.2: THE TEXTURES. Squad essentially quadrupled the VRAM footprint and this completely wrecked my GPU, as it has a maximum of 1536MB of VRAM. By manually shrinking the textures sizes to a quarter of the original size (more or less the sizes on the KSP 1.5 era) KSP 1.12.x behave nicely on my rig! More info on this thread. Aftermath Right now, I'm being able to run KSP >= 1.8 on my oldest rig by using this trick. I'm trying now to figure out the best compromise of threads for my rig (2 appears to be acceptable, I will try 4 on my next time window for this). I'm pretty confident that a similar trick will "solve" the issue for my less older Mac Potato, so soon I'm be able to test drive things (and diagnose problems) on KSP 1.12.x, something that until now I was not able to do properly. These hacks are not solving the bad performance of KSP itself, besides it is getting slightly better (or less worse) too. What will solve the problem for good is using MUTEXES instead of spinlocks, and this is something I do not currently know if it's doable by options or environment variables. I will update this article with my findings as they happen. Addenda On KSP 1.7.3 Out of curiosity, I fired up KSP 1.7.3 (Unity 2017) and inspected the process the same way I did on KSP 1.8.1: We still have lots of threads screwing up the cores with semaphore_wait_trap, but we also have some others that don't! Some unnamed threads are using nanosleep, and the OSX HID Input one is using mach_msg_trap. We have now good evidences that my thesis have teeth. On KSP 1.3.1 On KSP 1.3.1 (Unity 5) I got similar results! It worths to mention that KSP 1.3.1 and older are simply the best performatic KSP versions on my i5. Point. I think we have a pattern here. Unity is (ab)using dispatch_semaphore_wait_slow on Version 2019, and this is royally screwing KSP on anything not top notch (and probably hindering top notch machines as they would probably perform better without this mess). Conclusions Besides being a Bad Move™ (and Unity would have better results on the field without using that kind of stunt), what's really screwing up things is not necessarily the spinlocks, but using them where a proper MUTEX is really mandatory. The HID Input thread appears to be one of them, at least. I think it's more than due time for Unity to start getting their excrements together and do things right. For a change. This article is also published on my site.

There're a lot of new words to be learnt about this incredibly stupid misfeature from Apple. Unfortunately, none of them is forum rules compliant. Nosecones are not solid. Their mechanical resistance is achieved by an internal frame. It's like the steel frames used on construction, they are incredibly light and still resistant when done right: https://www.indiamart.com/proddetail/hollow-structural-steel-section-7080402462.html The mass for these structures don't scale cubicly, they are not solid. Additional material on building bigger structures are not always needed, sometimes you only change the shape of the hollow tubes in order to maximize the resistance on an axis (at expenses of the other one, of course - there's no free lunch!): https://www.shrilakshmisteel.in/rectangular-hollow-sections-square-hollow-sections.html So, besides not exactly exact, quadratic sounds fine to me. Perhaps 2.1 or 2.2, but definitively not 3. Yep. https://github.com/net-lisias-ksp/TweakScale/issues/135 This is planned to be pursued after I manage to investigate Serenity. https://github.com/net-lisias-ksp/TweakScale/milestones — — POST EDIT — — It's something wrong on KER, probably. The Chutes are being scaled fine. Had the Chutes some problem on scaling, the test craft would not be tilted on the descend. Test Craft on the Issue https://github.com/net-lisias-ksp/TweakScale/issues/135#issuecomment-874419164 Since I'm currently without a KSP 1.12 capable machine (the oldest rig barely handles 1.8.1, damn it!), I will postpone a test on it by some days - anyone willing to try it, just launch the thing, cheat it into 3K meters high and stage the chutes.

Some crazy dude called Bob Lazar strapped a J20 Jet Engine on a bike once. https://www.otherhand.org/home-page/area-51-and-other-strange-places/looking-at-the-bob-lazar-story-from-the-perspective-of-2018/ Please remember Forum Rules on commenting this stunt - Kraken knows I have some about the strapping failing with that thing lit.

Announce! TweakScale Companion for Visuals 0.0.2.0 BETA is on the wild. Adds support for Waterfall and works with TweakScale 2.4.5.x series and newer. Rework the DLL loading procedures to bet cope with missing dependencies. Slightly faster patching when dependencies are not met Promotes the thingy to BETA, as this is not blowing up on the wild anymore. Hopefully. Known Issues: The plume's scaling is reset to the original size when Reverting to Launch. There's something I still didn't understand on the ModuleWaterfallFX's life cycle, as it appears Launching from Editor and loading Savegames works fine (at least, until now... ). Download here or in the OP. have fun!

Dude, do you have an USB crystal ball shoved on your computer or something?

Yep, I know! Thanks for the heads up! Done! — — — METAR — — — Well, things are not so good on the rescue of the less old rig for KSP development (a MacMini 6.2). After salvaging about 900GiB of data and testbeds without any problem (I didn't lose even the mp3 neither the downloads), I opened the damned thing (MacMinis are pretty nice machines - until the need to open the damned thing to service something), replaced the hard disks and fired it up, intending to call it a day. Guess what? BOTH HDDs are now with the data inaccessible. BOTH. After ruling out a mechanical or human mishap (I found some known strings by grepping things in low level, so both devices are still working), I come to this after hours and hours of research: APPLE SCREWED UP AGAIN. Obviously, I'm using that marvelous new APFS filesystems, the CopyOnWrite thingy is a lifesaver. But it have a catch - by some absurd reason, you should not use MBR on disks with APFS Physical Storages (besides the damned Disk Util gladly doing this without the slightest warning). Apple royally screwed up something, because when you are using an MBR, the metadata needed to access the Volumes apparently is written in some non usual place and another machine cann't find it (or, at least, Modern MacOS - I was told that this worked on the first MacOS versions to support the damned thing). It's something absolutely weird - both HDDs were working fine during the rescue, that took me half the week. The new HDD was being used on an USB caddle, and the machine was rebooted sometimes (Darwin don't like too much when spinning disks start to tlec-tlec beetween disk accesss too much), so there was no signal that MBRs were going to be a problem. Things gone south only after replacing the internal HHD with the new one. (sigh) Well, I still have some options to try: firing up the less old rig on Target Disk Mode on an older MacOS rig (good thing I didn't updated my Sierra rig) to see if it can understand the mess Apple did on the thing. mount the damned thing on Linux and use fuse-apfs to salvage (again) the data on a third 2TB HDD (as I will use the good and old HFS+ this time, so no CoWs…) try to build by hand a GPT partition on the freaking disk, as I read someone on some Forum saying he manage to did it. Worst case scenario, I will buy some partition recovery tool and apply it to see what happens. It's plain impossible I'm the only idiot on this Planet that was caught (again) with his pants down by Apple's Atavistic Idiocy. Forum Rules prevent me to further commenting on this thing (boy, I'm mad). In the mean time, development will happen (somehow) using the older old rig, as it still have most of the development tools needed - besides being able to run only up to 1.8.1 or perhaps 1.9.1, as the thing is too old to handle KSP 1.12 or 1.11 - hell, I was getting problems on KSP 1.12 on the less old MacCrap, what to say on a MacMini 5.1?

FMA is already an old friend on this thread, and now I found something else worthing being mentioned! FMA IAe 37. Argentinians, I'm proud of you! https://en.wikipedia.org/wiki/FMA_I.Ae._37 https://www.pinterest.com/pin/fma-iae-37--139752394667339740/

Worst metaphor possible. You don't use a Toledo Salamanca to do the job of a Katakana. — post edit -- Worst counter-metaphor ever! A false cognate was triggered on my mind, "espada" (sword) sounds pretty much as spade, and… Well. Anyway… The counter-argument stands. There're different kinds of spades - for gardening, for construction, you name it.