Lisias

Whoops. It was not NASA, it was the University of Alabama. The paragraph immediately followed one talking about NASA and I ended up mixing the information. Sorry for the memory failure. https://www.wired.com/story/test-out-next-gen-space-tech-kerbal-space-program/ The information I have is that they were supporting each other on development (ksp2 devs giving a hand on ksp1, and vice versa. It was published here on forum sometime ago. But using the same engine does.

Bell X14 VTOL Interesting Kerbal. Wondering if the Junos would be powerful enough for a replica.

The smallest company I worked was contracted by Nokia, at that time the biggest Mobile maker in the World. We also made games to Samsung (C3300 was one of the phones I targeted, if memory serves me well), and this game used licensed material from a really big Entertaining Company) to be bundled on a promotional models sold on the whole country. At 35USD, these cheap phones sold as water - but, obviously, I don't have a clue of how many were that promotional models I coded the game. At that time, Android phones were still fighting for the limelight and were expensive as hell, so Nokia and Samsung were still a thing on the market. I can tell you in details how was to work for these two different companies. The shop was localized over a bakery - hell, that (wonderful) smell on the morning, I must had earn 20 pounds at that time. Even by walking home at the end of the day trying to lose some. You see, you guys are not the only ones in town. What I fail to understand, however, is where this liquiding context matters to the subject at hand. Unless you have privileged access to the binaries (and so, please be cautions about the NDA you signed), what you have seen is the game running on developer's workstations. As long they are aware of some some less than ideal decisions on Unity and had a workaround for them. Some decisions on how to handle multithreading are way less than ideal, and even beefier machines are being harmed somehow by them. And since the workarounds are terribly counter-intuitive, it's not impossible that they could be caught with their pants down on the subject. Since I have notice that they are helping on KSP1 development, and since KSP1 is somewhat messed up on performance on some still popular architectures, I think the OP concerns are pretty valid. On that, I agree with you (except by the leak). However, it was exactly that extremely unorthodox loading scheme one of the reasons for KSP's huge success. This is extremely modding friendly, and mods are (was?) one of the cornerstone of the game. But there are some vast opportunities for improvement, no doubt. However, I disagree about the memory leaks. Memory overhead are tied to less than ideal coding (been that, screwed that) but also due that very multithreading bad decisions I mentioned, that ended up screwing the garbage collector itself. Some leaks appears to be related to this too - with less cycles available to the GC, it does a less than ideal job with the time it have. But usually leaks are related to coding problems, what I agree with you are not expected to happen on KSP2 (at least, until mods start to be made for it).

It's exactly the other way around. And yet, KSP1 has inspired some of the most specialized professionals on the aerospace industry. NASA uses KSP1 for fast prototyping some ideas, just for starters.[Nope, it's the University of Alabama, see my post below...] It's not about how much money you put on it. It's about how you use the money you put on it. People love results, not the money you spent. As Boeing/Starline versus SpaceX/Dragon 2 ? Big Corps also screws up. Badly. See CDPR Red. There's no such a thing as "Too Big to Fail" anymore, you can lose your job by buying IBM if the thing doesn't work nowadays. I don't know if KSP2 will be a huge success, a flop or will have just a moderate response from the market. But I know that whatever it happens, it will be a direct consequence from how money is spend there, and not how much.

As a matter of fact…. And I on my counter proposal! They are molluscs that evolved into a higher form of life using hemocyanin on the blood - they virtually have blue blood, what on a yellow flesh give them the green colour.

Hi! This file sounds like something made by third-parties, the stock installation don't have it, neither the Deutsch localisation depot (I use Steam, I downloaded it using the Steam Console). Probably a left-over. Out of curiosity, what's on that file? You can probably ignore it, but since it's an "alien" artifact contaminating stock assets (GameData/Squad and GameData/SquadExpansion ideally should be considered sacred land), the ideal solution IMHO would be to remove it - assuming this is not needed by some sacrilegious 3rd party add'on - since the curiosity on checking what's inside of it.

Hyperspace. Clever trick, it replaces the default BinaryReader constructor with one that creates a bigger read buffer, and this speeds up reading things, as you less IO commands for the same file. At that time, there was a gotcha, however. Apparently this thing was affecting BinaryWriters too and this was kinda annoying when you are debugging things and monitoring the KSP.log, as the file buffer gets bigger too and so the flushing happens with really large amounts of text at once. ideally, the developer should trim the buffer size to the kind of file he/she is dealing with. Large blobs read at once will benefit from large buffers, but big files made of many, many small chunks of data (as databases) are better served by smaller buffers.

[snip] Some of the biggest companies on the World were born from garages, dude. And they shadowed most of the "reputable" manufacturer out there.

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!