Lisias

Manual only. It relies on things that are not ready to the mainstream yet (KSPe), and, frankly, I'm more a code integrator than developer for this thing. I can keep it working, but pushing it further demands a lot of time that I can't spend right now. There are people better than me on this (KJR) that are considering taking it. Until he made his mind, I think it's better to avoid confusion on the mainstream. What makes KJR/L great was not written by me.

First you upload Restock to the Consoles. Then I will talk about - I can change my mind once this happens, but not before.

Tell that to Sony. That guys from PlayStation, do you know them? Yes. This includes Paradox. You need their authorisation first. It only happens such authorisation (or denial) is implicitly. Paradox is not always the owner of the intellectual property into a game which it publishes, and therefore, Paradox cannot unconditionally allow modding to all games published by us. If you are unsure of which games are affected, please email support@paradoxplaza.com" https://www.paradoxplaza.com/mod-static-info-ca.html Agreed. I will not further answer on this thread. WE ARE IN THE LOUNGE. Sorry!

I prefer to call them User Customizations. If the feature needs to be supported by the game developers, and uploading a png surelly needs it, then is not a mod! https://support.xbox.com/en-US/games/game-titles/custom-skins-minecraft-windows-10-edition

I said "was". and yet, you still need approval of the console maker, your mod can be kicked out at any time, by any reasons. and you conveniently are ignoring that Modding on Consoles is illegal on Japan, subject to jail time. Modding games is about doing what you want, not what they allow you - this latter option is Content Creation for free.

Pins? What pins? You must see what happens when someone shoves a VGA extender cable plug on a DB9 RS232 port...

One little detail about community driven development: we are prone to community driven borks. And by nature of TweakScale (it mangles with everything!), it have a huge area of exposition for bugs and mishaps. It's part of the job, as it appears. In time. Do you have Python installed? My machine is way smaller than yours, it doesn't withhold your environment, so I guess I need to try a hot patch on your machine before giving this issue as solved. Of course, use it on a copy of your installment, please. [Never mind! This specific issue is on the KSP.log of another fellow Kerbonaut, and I mistake it with yours - "working" late night is rarely the best of ideas!!] — — — — — — — On a side note: after reviewing the last night's job (and realizing I did part of the job on the wrong KSP.log - geriatrics, anyone?), I think that we have the prefab problem resurrected. Frankly, I was very afraid of this and I think I was in denial yesterday night, and my analysis on the wrong KSP.log was an attempt of my subconsciousness to try to avoid the subject. There're a lot of people (including Making History) using the Main Menu as a event starter for a lot of initializations, and some of them are also mangling the GameDatabase, leading to that Race Condition thingy I mentioned above (KSP is a multithreaded game now). The non-deterministic nature of the multithreading makes this very hard to univocally detect and essentially impossible to debug, and it's way dependent of the machine's performance and load. In a nutshell - it can borks on your machine and works fine (by plain luck) on mine. Essentially, it's a Russian Roulette. I would be crying on my bed now if Pellinor didn't advised above - thanks (again!) dude! My next steps is to clone and eye ball all the source code of the add'ons you use that i didn't did that yet. see which of them are mangling the GameDatabase at the same time I'm doing and try to figure out a new stunt to get out of the mess. To anyone that was around last time this happened, no, I can't do it on the Space Center Scene. The prefab data must be checked and fixed before loading a savegame, or the crafts data on your game can be corrupted (as the module data on your crafts would mismatch the prefab ones, and now KSP honor's prefab even on live crafts - my old stunts on handcrafting parts on living crafts are working different nowadays). At the same time, I need to enhance the Sanity Checks to include the behaviours you are describing, this thing is corrupting your savagames and craft files.

Thanks for the advice. This explains better what's happening now. And gave me an idea on that new stunt of mine!

Partially due the log, partially due I'm the one that wrote some of the code - so by the log, I know what code did what. That, and some burnt skin due another problems that lead me to hunting bugs high and low, and knowing them by first name. It's not a problem particular to your setup. It's a problem particular to some few Add'Ons having problem in coping with themselves. Your setup just happened to have one of the possible combinations that leads to the problem (see the chain of events below). People were posting about worse problems (like this one - this happened to me in last October, by the way - so when this guy opened this issue, it was already fixed), that I managed to turn into less critical ones. It's better to cope with some guys complaining about missing support for some parts, then to really angry guys complaining about KSP crashes and savegames corrupted. In time, that NREs of yours were probably saving you from a crash (the first link from the bunch above). I will end up applying yet another stunt on TweakScale2 due this. Some glitches just became a problem recently due some internal changes on KSP and some now common practices on the Add'Ons authoring scene. It's rarely a single cause, but a chain of events that lead to such problems. Some (and just some!) of these events are KSP changing internally - sometimes these changes break the chain (so a problem just "vanishes"), and sometimes they reinstate that chain later (so the problem "resurrects"). Some problems are only really nasty when they happens at the same time with another ones (that have their own chain of events, a few of them in common). Reading historical commits from the Add'Ons I mangle is incredibly useful and informative on this aspect, as they give me information that explain what happens on the ones I really maintain, helping me to identify that very few links common to many chains - and by breaking that links, a lot of problems cease to be a problem and come back to be just glitches - I can fix TweakScale only, all the rest I can only workaround - so turning problems into glitches was my focus on the recent months.

I was looking for the Seal's version, but found this and choose to post it instead. Man, the early 70's had some very good music. And musicians.

Your assessment of the situation was accurate. Something is, indeed, duplicating (or deleting!!!) the TweakScale node on the Spark engine. There's something weird happening here. The internal name of the engine you used (Spark) is liquidEngineMini.v2. In my test bed, this part is working perfectly fine (ie, I can scale and use it without any new issues besides the already known ones - the plumes not scaling). This reflects on my KSP.log (I tested it twice, with and without Making History just to be sure) [LOG 01:08:59.178] ******* Log Initiated for Kerbal Space Program - 1.6.1.2401 (OSXPlayer) en-us ******* Kerbal Space Program - 1.6.1.2401 (OSXPlayer) en-us OS: Mac OS X 10.12.6 CPU: Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz (4) RAM: 16384 GPU: Intel HD Graphics 3000 OpenGL Engine (579MB) SM: 40 (OpenGL 3.3 INTEL-10.2.37) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, RGB111110Float, RG32, RGBAUShort, RG16 <....> [LOG 01:09:58.071] DragCubeSystem: Creating drag cubes for part 'liquidEngineMini.v2' <....> [LOG 01:10:34.416] Part found: liquidEngineMini.v2 [LOG 01:10:34.416] Part liquidEngineMini.v2 has Module ModuleEnginesFX [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModuleJettison [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModuleGimbal [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModuleTestSubject [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModulePartVariants [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module FXModuleAnimateThrottle [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module TweakScale [LOG 01:10:34.417] Part liquidEngineMini.v2 has Module ModulePartInfo [LOG 01:10:34.417] Part liquidEngineMini.v2 has drycost 240 with ignoreResourcesForCost False <....> [LOG 01:12:07.053] liquidEngineMini.v2 added to ship - part count: 3 (my DLL is the debug version, a relentless log spammer! ) But this is what I got from yours: [LOG 21:40:06.797] DragCubeSystem: Creating drag cubes for part 'liquidEngineMini.v2' <.....> [WRN 21:40:23.438] [TweakScale] Removing [LOG 21:39:27.132] ******* Log Initiated for Kerbal Space Program - 1.6.1.2401 (WindowsPlayer x64) en-us ******* Kerbal Space Program - 1.6.1.2401 (WindowsPlayer x64) en-us OS: Windows 10 (10.0.0) 64bit CPU: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12) RAM: 32708 GPU: NVIDIA GeForce GTX 1080 Ti (11127MB) SM: 30 (Direct3D 9.0c [nvldumdx.dll 25.21.14.1935]) RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, RG32 <.....> TweakScale support for liquidEngineMini.v2. [ERR 21:40:23.438] [TweakScale] Part liquidEngineMini.v2 didn't passed the sanity check due having a ModulePartVariants with Mass - see issue #13 https://github.com/net-lisias-ksp/TweakScale/issues/13. <.....> [LOG 21:40:48.730] liquidEngineMini.v2 added to ship - part count: 2 [WRN 21:40:50.841] Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object at TweakScale.TSGenericUpdater.OnRescale (ScalingFactor factor) [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.CallUpdaters () [0x00000] in <filename unknown>:0 [WRN 21:41:36.487] Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object at TweakScale.TSGenericUpdater.OnRescale (ScalingFactor factor) [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.CallUpdaters () [0x00000] in <filename unknown>:0 [WRN 21:41:45.804] Exception on rescale: System.NullReferenceException: Object reference not set to an instance of an object at TweakScale.TSGenericUpdater.OnRescale (ScalingFactor factor) [0x00000] in <filename unknown>:0 at TweakScale.TweakScale.CallUpdaters () [0x00000] in <filename unknown>:0 [LOG 21:43:03.880] deleting part liquidEngineMini.v2 [ERR 21:43:07.222] Cannot find module 'TweakScale' (-699235618) <....> We have the exact same KSP version, the very same TweakScale version (mine is just compiled in debug mode), and you tried the new patches on the github (that I'm using too), and yet, two completely different results. So, or MacOS has something hidden that automatically fix things that bork on Windows ,, or we have something mangling/hijacking/trolling TweakScale patches. A quick search on your KSP reveals the there're more people besides me using the ":FOR" clausule, what's plain wrong. And since they are sorted alphabetically before TweakScale, they got applied first, rendering my patches ineffective or duplicated in second place. That can be a good explanation by the same part passing the Sanity Checks on my installment, but being refused on yours - and since the duplicates detector honors the first occurrence, deactivating the remaining ones, it ends up deactivating my patches. leading to: The second slider doesn't works - as expected, as the duplicate detector got rid of the Module instance that would answer to it The first sliders borking on NREs, as they are tied to the first occurrence of the TweakScale module that was not injected by my patches. Again, your assessment of the situation was accurate - these parts were hijacked by rogue patches. [I got the behaviour right, but pinpoint the wrong doer. This is happening at runtime!] By morning I will generate a report from your log with all the offending patches, so we can fix your copies in situ and, if things became right, start to firing up Issues to the maintainers. In time, "[x] Science!" is borking relentlessly on your KSP. I suggest you update it to a 1.6 compatible release, or plain delete it if such version doesn't exists. This is hurting your KSP, as it's happening on a event handler that can be aborting a chain of events: [ERR 21:40:23.296] Exception handling event onNewGameLevelLoadRequestWasSanctionedAndActioned in class ScienceChecklistAddon:System.MissingMethodException: Method not found: 'MusicLogic.SetVolume'. at ScienceChecklist.ScienceChecklistAddon.onLevelWasLoaded (GameScenes action) [0x00000] in <filename unknown>:0 at EventData`1[GameScenes].Fire (GameScenes data) [0x00000] in <filename unknown>:0 EVE Manager is also borking, but I don't think this is anything but a annoyance by now: [LOG 21:47:47.635] EVEManager: Issue loading ShadowManager! Error: System.NullReferenceException: Object reference not set to an instance of an object at Utils.MaterialPQS.RemoveFromPQSCities () [0x00000] in <filename unknown>:0 at Utils.MaterialPQS.Remove () [0x00000] in <filename unknown>:0 at CelestialShadows.ShadowObject.Remove () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Clean () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Setup () [0x00000] in <filename unknown>:0 at CelestialShadows.ShadowManager.Setup () [0x00000] in <filename unknown>:0 at EVEManager.GlobalEVEManager.Setup (Boolean late) [0x00000] in <filename unknown>:0 [LOG 21:47:47.635] [Scatterer] Celestial Body: Kerbin (CelestialBody)

Do you know this site? https://visualgo.net/bn/sorting

In the 80s, when I was still learning, I attended to a course using one of the first computers to have Floppy Drives as standard. Magnificent two floppy drives, 5.25", 160Kb per face. It was a TRS-80 Model III local clone. Thing is… Some Dud SAS though it would be a good idea to shove a folded EIGHT POL FLOPPY DISK into the boot drive - rendering the machine useless until the drive were replaced, what took some time as that things were horribly expensive around here. I also managed to see a floppy being photocopied and the copy sent by mail, as well floppies being stapled on printed reports and sent by office boy to the opposite side of the city. This is not a joke. These things really happened in the real life!

If they use Windows in their carriers, they should be stranded half way to here by now! On a side note… I think that rick-rolling them will do the trick. =P

Send "All your base are belong to us" to them.

Not harder than doing the same from civil roadways or pretty short airstrips. Carriers are not he only ones in need of short take-off procedures. If you want a way more dangerous approach, give a peek on this: I'm not saying that taking off from Carriers is easier. I'm just saying that it's not necessarily harder. Taking off from any short length strips, being a carrier or not, is harder.

SteamDB is a snitcher!

More than that. It's utterly needed. You don't want realistic living beings blowing up in the skies, neither being smashed and/or ripped by gruesome accidents. Crashes are unavoidable on KSP, so crashes must be fun. So the environment needs to be somewhat cartoony in order to cope with the cartoonist characters - unless you plan to make a follow up to "Who Framed Roger Rabbit" or "Cool World" (while I doubt the late would be a viable option for our kids. ).

Take off from carriers are more dangerous, but not necessarily harder. Landing there, on the other hand, it's almost suicidal.

Traction, centrifugal and inertia. You need a really heavy weight up there, in a geosynchronous orbit, to keep a very resistent and rugged tape tied to it tractioned so the flopness will not occur by mechanical resistence. Clamping wheels would pull the vehicle up by friction. Since to each action there's a reaction, that weight upthere must be such that the weight of the vehicle going up accelerating against the gravity doesn't disturb his orbit (not to mention the weight of the "tape").

Ugh. Appears to be something new. The latest TweakScale gets rid of the duplicates, so at least in theory, you are facing something new. The newest commits (se the orthodox branch) are patches only. You can fetch them and test them on your installment and check what happens. That weird problem I described by last just vanished. The glitch happened on my playing installment, and the dud SAS here forgot it next day and updated some Add'Ons, and now I can't reproduce it anymore. At least this hints that by updating to the newest versions of the Add'Ons the problem goes away. but i'm unrest about it, I want to know what happened. I would like to see your KSP.Log to compare with mine. This can help us to narrow down the glitch's source! — — — — — Guys, I found some Kraken Food between TweakScale and Kerbal Animation Suite. https://github.com/net-lisias-ksp/TweakScale/issues/29 At the moment, there's no other workaround but to do not install both Add'Ons at the same time. It's not clear if it's a TweakScale issue, KerbalAnimationSuite one, or if there's something else inducing the borking by side effect. More news on it ASAP.

Please, Dear God. Not on Friday, I have a deploy schedule and it's hard to deploy things while playing KSP!

Now you pulled a good argument from your hat. "Look, you *need* to add some clouds and novelties to the game, as the present Look&Fell are making you look as a kid's toy". I'm not exactly dissatisfied with the current Look&Feel - it allows the game to run on my MacPotato, and since it's currently the only gaming machine I have, I'm counting my blessings. But yet, I already bought the game, and Squad needs to convince new players to buy it in order to keep their revenue flowing. So, as long such GPU intensive thingies can be disabled so I can keep playing for some more time on my MacPotato, yeah, I can agree with you now. And yet, KSP "looks like a child's game". I can see your point now, but look both sides of the coin: a the same time they need new gamers buying the thing, they can't make their current user base angry - or they will face a backslash, and the fallout could cost them more than any new incoming they would get on the stunt. They need to measure the consequences with prudence. This is probably one of that weird situations in which two opposite points of view can be simultaneously right (or simultaneously wrong!). Hard nut to crack, if you ask me.

KAX uses FSplanePropellerSpinner, FSswitchEngineThrustTransform and ModuleAlternator. The only novelty is ModuleEnginesFX and EFFECTS nodes (that, frankly, I'm rolling back to FSEngineSounds as they behaves better with it). I have KAX historical releases since 2.0, and this part had born on KAX 2.3.4 (KSP 0.90). Problem is… Nothing had change significantly on the thrusting model. But your hint leaded me to FSswitchEngineThrustTransform: MODULE { name = FSswitchEngineThrustTransform defaultTTName = thrustTransform alternateTTName = alternateThrustTransform useNamedAlternate = 1 So I think I had to search for the problem on Firespitter itself anyway. KSP 1.3 appears to have break this. Problem is… This is already an stablished behaviour for KAX since 1.4.0. I'm unsure about the decision I have to make - to break (new) expected behaviour, or rollback it to the previous one (assuming I can fix Firespitter).