Lisias

No. It runs on KSP, not on CKAN. But if you want to know if it's added to CKAN, yes: https://github.com/KSP-CKAN/NetKAN/blob/master/NetKAN/AtmosphereAutopilot.netkan

No joke, I still play this thing on my retro-computers now and then. It's incredible how the guy managed to add volumetric clouds on an Amiga 500 machine without screwing the frame rate... If we at least could do the same nowadays... Jokes aside, I really found these clouds pretty beautiful. It only happens that I can't run it on my puny hardware - but I don't mind the game having them because I don't mind people having computers better than mine. As long as I can deactivate the thing in order to make it to run on the hardware I have now, I'm fine. That said, Elite Frontier is a hell of a good game, this thing is legendary and Frontier Development managed to fund Elite Dangerous exactly due the game being legendary, with dated graphics and all. You see, the key selling point is: good game, not nice volumetric clouds. If you don't have a good game yet, wasting resources on adding volumetric clouds is just... waste. They had way more important things to do (as freaking colliders for the whole KSC, damnit, they left the main landmark of the whole game lagging behind to add volumetric clouds?).

Something apparently removed from the elevons the ModuleControlSurfaces, the thingy that makes control surfaces to behave like control surfaces. Or perhaps something is "killing" the mentioned code? Send me your KSP.log and ModuleManager.ConfigCache and I should be able to pinpoint exactly what's happening.

They told me the same about Terminator and Planet of the Apes. And I really starting to worry about Omega Man and Zero Population Growth - but I think we still have some decades before Soylent Green.

Steam is powerful exactly because they succeeded in being a middleman. Don't ever forget that, they ARE a middleman and this is the source of their power. That said, this doesn't mean necessarily they are a evil middleman. Please note that on the statement that yourself quoted I said "added value", being a extended store guarantee one of them. That it's very important to me because, as I had said, my GoG's Inventory is four times the size of my Steam's one. But, still, I still have some games on Steam - and not always because GoG doesn't have them (most of the time don't, but...), but because for some games, Workshop and Steam Deck seamless integration talk louder than an extended guarantee - as a matter of fact, it's not usual I ended up buying the game again on Steam (on a discount, of course) due the Workshop and easily Steam Deck integration. Again, added value.

Of course, they are a Store, right? This is exactly the reason we buy things from stores! Store Guarantee someone? Stores with better guarantees usually sell better, my GoG's Inventory is FOUR TIMES the size of my Steam one for a reason. Why bother buying from a Store if not by added value? Otherwise it's better to buy directly from the developer and save 30% of the fee...

Multiple channels pushing the same narrative concurrently rarely, really really rarely, aims to promote exactly what described in the narrative. The wave of layoffs will flood the market with seasoned (or, at very least, minimally skilled) professionals on gaming. These guys are not going to sit in their armchairs eating junkfood and drinking beer until the money ends - they will pursue ways of making money at any costs the way they can. Whatever can be done to make EA games less viable to any indie developer will be less competition for these AAA stand-up guys - as you said yourself, these very stand-up guys are failing upwards, what means that this is way the cookie will crumble from now on. I suggest a quick research on the commercial practices engaged by Microsoft on the 90s and early 2000. I don't expect less from this point. Abandonment means that no one is looking for the asset, what means that no one is making money from the asset. If no one is making money from the asset, it's not a problem because there will be no one filing complains about copyrights - it's a grey area of the Law, but it works exactly this way. If the author/owner is making money from the asset, and if you risk getting sued by redistributing the game without authorization, then the asset is not abandoned and I highly recommend people to avoid using this term. This narrative will only play havoc on the really abandoned games (as we have them on homeoftheunderdogs), whats - how interesting - it's also something that would help the new status quo by associating really abandoned games to games "falsely" tagged abandoned and that people can get sued by redistributing without authorization. ---- POST EDIT ---- It's about money. IT'S ALWAYS ABOUT MONEY. The incompetent sociopaths also have to eat. It's up to us to decide if we are going to feed them or not. Apparently, most people is willing to do such.

Uh... me? Late?? Just a little bit... In time, pinging... @Royale37

Nope. As a matter of fact, only 2 casualties (pilot and co-pilot/owner). AFAIK 6 people got hurt (one more or less seriously, but not fatal - everybody walked into the ambulance) on the ground, but - being absolutely frank about, this is a God Damned miracle, the plane tried a crash landing near one of the most crowded metro stations in the country! That pilot demonstrated an almost paranormal pilotship, he could had saved thousands of lives in this final moments: the plane didn't crashed, it landed on the very single spot in his reach where the least possible amount of damage would happen.

Being the reason sometimes I flirt with the idea that this movement have a hidden agenda. Do you follow the Steam Discussions?

Announce! New release 2025.2.7.0 2025.2.7.1 for the TweakScale Companion ÜberPaket with everything (and the kitchen's sink) included for the lazy installers !! Updates the Companions: Living Style to 0.0.3.1 PKMC to 2.2.1.2 And fix a mishap on a left over patch that passed trough the cracks. See the project's main page to details. Your attention please Completely remove all the previous contents in the GameData/TweakScaleCompanion directory, or you will trigger some FATALities on TweakScale's Sanity Checks! This thingy needs TweakScale v2.4.7 or superior to work Download here or in the OP. Also available on CurseForge and SpaceDock.

It's two weeks that all I do in KSP is to diagnose and fix problems. I usually enjoy doing it, but this time (reasons that I don't want to disclose), it affected me and got on my bad side. I will be away from KSP and Forum this WeekEnd. I'm planning to spend it maratoning Love Death +Robots, revisiting Cowbow Beebop and perhaps even Ghost in the Shell. And perhaps touch some grass? Anyway. See ya.

Send me this KSP.log . I will give it a peek now on my lunch. Don't bother. Found the problem. [ModuleManager] Log is set to level TRACE. My fault, an update will be issued today. Done.

I just generated my ckan file that will reproduce your rig using my lunch time, but will be able to dive into it only by night. However, I found some oddities that may be the cause, on a somewhat educated guess based on my previous post. I didn't managed to identify on CKAN's metadata the following directories: 77Industries Appears to have only flags, and none of the assets mentioned on any netkan. oxbow_Robin Don't have the slightest idea what it is Sigma Appears to be empty RESCALE Contains a directory called 2.5x, and after some efforts I remembered this: https://github.com/Profiremu23/RescaleContinued/ ASTRO Don't have the slightest idea what it is OPX-SSM Don't have the slightest idea what it is Since apparently the problem is related to SkyBoxes, the problem could be related to something using Kopernicus like a Solar System Replacement, or something somewhat old triggering collateral effects on newer versions of this (or similar, like SigmaDimensions) mod. So, I want to suggest you to make a FULL COPY of your KSP into somewhere easy to find (like the Desktop), then remove: oxbow_Robin ASTRO RESCALE OPX-SSM on that copy and fire it to see what happens, and then publish here the results. DON'T TOUCH your original KSP, the tests we are going to do on it are destructive beyound salvage. Use only a copy for exploratory tests! If you could do it before 20:00 GMT-3, it would save me a good amount if time!

That's interesting... It was my hope that whatever was causing this: [EXC 12:50:03.542] ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <9577ac7a62ef4317 System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <9577ac7a62ef43179789031239ba8798>:0) FlightGlobals.getMainBody (Vector3d refPos) (at <4b449f2841f84227adfaad3149c8fdba>:0) GalaxyCubeControl.Update () (at <4b449f2841f84227adfaad3149c8fdba>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) and this: [EXC 12:50:03.576] NullReferenceException: Object reference not set to an instance of an object (wrapper dynamic-method) OrbitRendererBase.OrbitRendererBase.LateUpdate_Patch1(OrbitRendererBase) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) Would be being induced to bork as splash damage from something else, and MiniAVC was the only known thingy that could be causing it. Well, it wasn't. And since there's no ReflectionException on your log, this ruled out a whole class of known problems. You have a good amount of RAM, a reasonably decent CPU and a decent GPU. I think we can rule out lack of memory or VRAM. It's almost surely a conflict on patching or something, and it appears to be related to the SkyBox. But I didn't found anything (that I know at least) that would be mangling the SkyBox (perhaps something trying to use Kopernicus and failing?). We are going to get our hands dirty on this one. I will need to reproduce your rig and see what happens on my rig. I will get back to you Soon™.

Absolutely GORGEOUS. I want one of these for me! 1938 REO Tractor and 1937 Curtiss Aerocar Trailer

MM have an interesting feature: when it loads the last successful patching from the ConfigCache, it copies the logs generated on that session to the KSP.log simulating what would happen (approximately) if the patching would had been done instead of loading from ConfigCache. Since your last successful ConfigCache was created using TRACE, this is what will be copied into KSP.log until you regenerate the ConfigCache. Delete the ConfigCache (on PluginData/ModuleManager) and the new MMPatch.log will be smaller, and then future KSP boots will have it instead

My fault. You don't have the KSPe.cfg in your PluginData, and so KSPe used defaults. [LOG 00:54:15.968] [KSPe.Globals] INFO: KSPe.cfg does not exists. Using defaults. By some reason, MM logging is defaulting to TRACE level, instead of INFO that should be the default. And TRACE is incredibly verbose (essentially, MM logs every single decision it takes while patching - there're about 3,645,852 TRACE entries in your log. My apologies. Copy the PluginData/KSPe.cfg from the KSPe zip package into your local <ksp-root>/PluginData , or just edit a text file with the following contents and save it there (using KSPe.cfg name, of course): KSPe { DebugMode = False Log { ThreadSafe = False LogLevel = 3 } LOCAL { ModuleManager { DebugMode = False Log { ThreadSafe = False LogLevel = 3 } } TweakScale { DebugMode = False Log { ThreadSafe = False LogLevel = 3 } } } } This will shut up MM's TRACE until I fix this thing on the weekend. https://github.com/KSP-ModularManagement/ModuleManager/issues/35

It's absolutely entertaining (on the most positive way!) how different people have different understandings about different metaphors! Talking with people is a learning experience. I should try to do that more times, before ki**... Uh... Never mind. That's what I understood as a "good" step, better communication with the Users. The wrong direction, in my mind, is communicating irrelevant and/or incomplete data - such communication can be easily (and even automatically) worked around by crappy releases, and would really hinder only the ones that really need EA as a chance to score a shoot on this market. Bad players, the one scamming people, would have the money to automate the process rendering the effort meaningless. THIS is what I consider the "right direction" - making the stunt unprofitable or, at very least, way less appealing. Widening the refund window for such games is the way to go IMHO. Indie developers that take months (sometime years) to update the game will not be hindered - they are not making money from the game anyway (otherwise they would be working on it full time!), they are not expecting to get their profits from the EA. And if the game is good, the refunding will barely scratch their (essentially nonexistent) income. But developers aiming to use EA for profit, these ones will be the ones getting screwed by a refunding policy that would hinder profitability for stalled projects (I flatly refuse to call these "abandoned" - this term is historically taken, not to mention that "abandoned" things don't generate incoming). -------- ** Old joke. Check my Twitter profile for it.

Sure thing! A "framework" for 3rd party support is on the works, and I will use Sunkworks as the tech demo on the next PRE RELEASE. https://github.com/net-lisias-ksp/BonVoyage/issues/4 I hope to work on it on the next local holidays, Carnival. Please pray with me to Our Lord Krakens so They would grant us such Grace!

What in.... Kraken's name! Yes, zip this huge monster and publish it. There's something still fishy in your log, this is way abnormal!

Yep! I had listed every add'on I had installed (even cooked a CKAN file to rebuild the test bed), and later listed exactly the ones I was deleting between the sessions. But then CKAN auto-updated (or I clicked something without being aware?), the problem vanished and I wrongly concluded it was the last batch - but perhaps it was some of the still left there that got updated... And then I had to start from scratch. But after rebuilding the test bed, the crash was no more - so the update really changed things. From that point, Real Life™ and Day Job© conspired to keep me away from KSP, so things got behind a lot on this. I will rest now (really need some), and I will go back to this later. The crash itself may had been solved, but something is still screwing SystemHeat's life. https://github.com/orgs/KSP-ModularManagement/discussions/4

Well... There're indeed some exceptions that shouldn't be happening... I suggest you to delete all DLLs named MiniAVC from your rig (there's a nice tool called ZeroMiniAVC) [LOG 11:43:40.240] MiniAVC -> System.IO.IOException: Sharing violation on path C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\KerbinSideRemastered\MiniAVC.xml at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x0019e] in <9577ac7a62ef43179789031239ba8798>:0 at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode) [0x00000] in <9577ac7a62ef43179789031239ba8798>:0 at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode) at MiniAVC.AddonSettings.Load (System.String rootPath) [0x0001b] in <32daf95419734fac8d1e416d1f8be6d5>:0 at MiniAVC.AddonLibrary.ProcessAddonPopulation (System.Object state) [0x0006c] in <32daf95419734fac8d1e416d1f8be6d5>:0 Not every MiniAVC exception is a killer, but it's easier to just get rid of all of them than trying to figure them out. Use KSP-AVC (or CKAN) to keep your rig updated! I found a lot of issues for this problem: [WRN 11:50:26.210] [KSPCF/DragCubeGeneration] Call to 'Assembly-CSharp:ModuleDeployablePart.AssumeDragCubePosition()' failed on part 'bluedog.Mariner3.TV.Camera' for drag cube 'RETRACTED' System.NullReferenceException: Object reference not set to an instance of an object at ModuleDeployablePart.AssumeDragCubePosition (System.String name) [0x00088] in <4b449f2841f84227adfaad3149c8fdba>:0 at KSPCommunityFixes.Performance.DragCubeGeneration+<RenderDragCubesOnCopy>d__21.MoveNext () [0x005a4] in <e997dbbd4fda4eacb68a00719aa5e5dc>:0 and then an almost infinite number or other ones: [EXC 12:02:16.542] ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <9577ac7a62ef43179789031239ba8798>:0) System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <9577ac7a62ef43179789031239ba8798>:0) FlightGlobals.getMainBody (Vector3d refPos) (at <4b449f2841f84227adfaad3149c8fdba>:0) GalaxyCubeControl.Update () (at <4b449f2841f84227adfaad3149c8fdba>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) [LOG 12:02:16.551] MiniAVC -> Starter was destroyed. By bad luck, or perhaps due being involved with the mess, MiniAVC is there again. From this point, I found nearly 45k exceptions like that one: > cat KSP\(6\).log | grep "ArgumentOutOfRangeException: Index was out of range." | wc -l 44870 And the analysis will be a sweat shop. Since MiniAVC had a unfortunate history from triggering some nasty bugs inside KSP's guts, I think that your best line of action is just to remove all instances of MiniAVC from your rig , firing it up again and see what happens: > cat KSP\(6\).log | grep "MiniAVC" | grep "Load(Assembly)" [LOG 11:42:42.236] Load(Assembly): KerbinSideRemastered/MiniAVC [LOG 11:42:42.243] Load(Assembly): KIS/Plugins/MiniAVC-V2 [LOG 11:42:42.339] Load(Assembly): NSS/MiniAVC [LOG 11:42:42.357] Load(Assembly): RESCALE/MiniAVC [LOG 11:42:42.365] Load(Assembly): RLA_Reborn/MiniAVC Delete the following files: C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\KerbinSideRemastered/MiniAVC.dll C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\KIS/Plugins/MiniAVC-V2.dll C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\NSS/MiniAVC.dll C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\RESCALE/MiniAVC.dll C:\Program Files (x86)\Steam\steamapps\common\Kerbal Space Program\GameData\RLA_Reborn/MiniAVC.dll And then fire up KSP again. Anything still wrong, send us a new KSP.log - I expect (or hope) to be way easier to diagnose the problem from this point.

Yep, but now they are friendly firing good developers. I game I'm following had its beta updated a few weeks ago, but the warning about the game not being updated fro 23 months are still there. This will promote crappy public releases just to clear the flag - wasting VALVe's time, storage and bandwidth. Right now, they are working against their own interests - they are still liquiding off indie developers with a longer development cycle (essentially most of the better ones, as these guys have Day Jobs© and Real Life™ to cope with!), and doing nothing concrete to protect the users against ill intended developers (in fact, only the lazy ill intended developers are being affected somehow). It's a good step, I agree. But into the wrong direction. Given the lack of better judgment I'm seeing on the measure, I'm pretty sure it was something done in a hurry for some reason (Steam are usually more careful about these matters - they surely take their time to shoot, but once they pull the trigger, it's usually a clean shot). IMHO they are only moving the noise to another level - into crappy updates intended to merely avoid the flag. As I said above, it's a good step - but on the wrong direction.

Ouch, forgot about you. Sorry. I wish Forum would have some type of "remember me in <n> days" about posts! Well, first things first: you are going to do some serious black magic here, and it can backfire nastily if you are not careful. So, really, really, really follow the instructions carefully and if anything doesn't works as expected, abort everything and come back here for help. DON'T ASSUME that anything will be fine unless happening exactly like I said - and even if it happens, it still can back fire! So, let's go: First: open your console and type diskutil list, as below: > diskutil list In the spoiler, an sample output (using my rig as subject). Note all the "/dev/disk<n>" thingies. These are the current disks plugged into your rig - DO WHAT YOU DO, DO NOT USE THESE NAMES. Now plug your XBox formatted thumb drive and do it again. Follows the sample output from my rig: Did you notice the new "/dev/disk5" on my sample output? This one is the thumbdrive I just plugged on my rig. In yours, the name will be different, obviously. Ignore anything else about that disk, it will change widely for you. In time, it would be very interesting if you could paste the information you got in your rig! It will help me to write a small open source tool to automate the process! Now, type (in ">" the command line, below the tool's output): > diskutil umountDisk /dev/disk<the-number-of-your-thumbdrive> Unmount of all volumes on disk<a-number> was successful Anything different, and you will not be able to mangle with the disk. Reach me here pasting the output so I can see what to do. BE ABSOLUTELY PARANOID FROM THIS POINT. Any mishap and you can destroy the wrong disk, losing data. And if that disk is your boot disk, you will have to reinstall everything from scratch losing any non backup'ed data! If anything different , weird or plain unexpected happens, from a different message to your neighbor farting, stop everything and reach me for instructions! Now do: > sudo fdisk -e /dev/disk5 And follows my inputs and the program outputs (it's a interactive command line tool): fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory Enter 'help' for information fdisk: 1> help fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory Enter 'help' for information fdisk: 1> help help Command help list manual Show entire man page for fdisk reinit Re-initialize loaded MBR (to defaults) auto Auto-partition the disk with a partition style setpid Set the identifier of a given table entry disk Edit current drive stats edit Edit given table entry erase Erase current MBR flag Flag given table entry as bootable update Update machine code in loaded MBR select Select extended partition table entry MBR print Print loaded MBR partition table write Write loaded MBR to disk exit Exit edit of current MBR, without saving changes quit Quit edit of current MBR, saving current changes abort Abort program without saving current changes fdisk: 1> print Disk: /dev/disk5 geometry: 3781/255/63 [60751872 sectors] Offset: 0 Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] ------------------------------------------------------------------------ 1: 0B 1023 254 63 - 1023 254 63 [ 2048 - 60749824] Win95 FAT-32 2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused 3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused 4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused Your output will vary a bit, obviously. These numbers are less scary than it looks: they essentially says where the partition starts and where it ends: The "id" thingy is what I want to know from your thumbdrive. It essentially says the format of the partition, and it's what we are going to change. On mine is "0B" because I formatted this thumbdrive as a FAT-32 volume to make this tutorial easier to cope. This kind of partition is still in use, by the way. Uncommon, but still used. Remember this value if you plan to undo the changes! the "cyl/hd/sec" thingies are deprecated fields, fossils from the 80's and 90's MS-DOS Era. the "start" and "size" says in which logical sector that partition starts, and the size. We will not change these values, but since they are being shown, I'm explaining what they means. Obviously, they can't overlap! If start + size is bigger than the size of any other entry, your disk is screwed and you should try to salvage what you can! As I said, we are going to change the "id" thingy, from whatever you see in your rig to "07" (the id Microsoft uses for NTFS): Note how I used the very same values for "start" and "size". They need to be exactly the same, or you will screw up the partition. Now revise everything and if you are sure you didn't made any mistake, save the partition table and quit the program: Ignore the message "A reboot yada yada yada". It's not meaningful for removable media. If by any reason you are not comfortable with the results, do: fdisk: 1> abort And the tool will exit without saving any changes. From this point, I expect you to be able to read and write in your thumbdrive after removing it and reinserting it. Look for the KSP.log and send it to us! TL;DR: XBox Game Partitions are merely NTFS volumes on a MBR partitioned disk using a different ID. To undo the change, to the process again but replace the now "07" with the original value you found there early (don't forget to tell me this value!). Cheers! (And good luck!! - Don't loose your head, be absolutely sure you are using the right /dev/disk<n> !!) ---- POST EDIT ---- Below, a sample output from what I expect you to find (with a different "start" and "size", obviously) on your thumbdrive, using my edited one as reference: Note the "HPFS/QNX/AUX" thingy. In the UNIX World, the "07" id is used for other types of volumes. Messy, uh? In time, this change is not a "magical" way to convert partitions. My thumbdrive is currently useless because besides I had changed it to look like a NTFS partition, it's still a FAT-32 one and if I try to use it, it will not work. The only reason this stunt works is because Microsoft is, indeed, using NTFS for Xbox Game Partitions - they really only used a different ID to make the partition invisible if you plug it on a Windows machine. In time... It just came to my mind that on Linux, you don't even need to change the ID, you can force the partition type on the mount command. So anyone on Linux, use "-t ntfs" and you are done! sudo mount -t ntfs /dev/<some-disk-id-as-sdb1-or-sdc1-or-whatever> /mnt/<some-dir>