Lisias

Found this one by accident today! (Earth Wind and Fire - Let's Groove). Boy… How colourful!

The Flying Pinto. (to bad it ended in tragedy - but…)

And the funny thingy about the @Noobi's problem is that, besides all our efforts, the problem just solved by itself (probably a Windows automatic update). This was one of the most Kerbal threads in the last few months!!

Not willing to be a…. hum… SAS Mohole . but I think Private Division needs to rethink their Store policy pretty fast. U.S.A. is one of the largest markets in the World, not doubt, but there's life (and money ) on the rest of the World too! And 3rd parties are already exploiting this market, as the link above clearly demonstrates. There's shipito, there's paypal - you don't need to handle the mess yourselves.

Oh, yes. This year could not end without a Houston for the New Year's Day! Oukey, let's tackle this down before popping the champagne! [LOG 08:19:56.435] [TweakScale] INFO: WriteDryCost Concluded : 3711 parts found ; 0 checks failed ; 0 parts with hotfixes ; 0 parts with issues overruled ; 2 Show Stoppers found; 9 Sanity Check failed; 9 unscalable parts. [LOG 08:19:56.443] [TweakScale] "Houston, we have a Problem!" about show stoppers on patching was displayed Not too bad. 2 show stoppers - but that 9 parts failing to be checked is something that unrest me. Well, one problem at time: [LOG 08:19:55.256] [TweakScale] ERROR: **FATAL** Part bluedog.CXA.APAS.A.L04F (CADS 0.9375m Docking Port (Active)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 [LOG 08:19:55.257] [TweakScale] ERROR: **FATAL** Part bluedog.CXA.APAS.P (CADS 0.9375m Docking System (Passive)) has a fatal problem due having duplicated properties - see issue [#34]( https://github.com/net-lisias-ksp/TweakScale/issues/34 ). at error:0 Hummm, let's check who is patching these parts: [LOG 07:56:42.527] Applying update Bluedog_DB/Compatibility/Tweakscale/tweakscale_APAS/@PART[bluedog_CXA_APAS_A_L04F]:NEEDS[TweakScale] to Bluedog_DB/OldParts/APAS/CXA_APAS_A_L04F.cfg/PART[bluedog_CXA_APAS_A_L04F] [LOG 07:57:23.352] Applying update CxAerospace/Station Parts/MM_configs/CXA_TweakScale/@PART[*]:HAS[#author[cxg2827]:HAS[!MODULE[ModuleCommand]]]:AFTER[CxAerospace] to Bluedog_DB/OldParts/APAS/CXA_APAS_A_L04F.cfg/PART[bluedog_CXA_APAS_A_L04F] Oh yeah, "old friend". The CxAerospace patches for TweakScale are, well, terrible. There's a long history of problems about it... TL;DR: someone thought it would be a good idea to patch parts from a specific author, but then this author transfered the rights for some of his parts to 3rd parties, and now these old patches are messing with parts from unrelated add'ons. I tried to reach CxAerospace's author some years ago, but.. No dice. And I can't fix the thing myself due licensing issues. The other part from BDB is also affected by the same problem. There's no fix for this problem other than delete the file GameData/CxAerospace/Station Parts/MM_configs/CXA_TweakScale.cfg and install the TweakScale Companion for Living Style, where patches for CxA were reimplemented in a safer way. Link for download: https://github.com/net-lisias-ksp/TweakScaleCompanion_LivingStyle/releases/ Happy New Year!

Scania Aerobus 1986. This one is from the hermanos from Argentina. They essentially took a single aisle airliner cabin and shoved wheels on it. As we do on KSP!! (Yep, there's a 14" CRT TV there , over what I think it's the "galley"!!) (in pt-br, sorry) https://diariodotransporte.com.br/2017/01/15/historia-aerobus-o-aviao-sem-asas-da-argentina/ — — post edit — — A article in castelhaño with better pictures! https://www.revistacolectibondi.com.ar/2020/11/10/bigdatabus-scania-k112-galactico-bus-bala/

Hi! Not a waste at all - sorry not being able to answer you in time, but Real Life™ stroke again and I'm terribly busy this last week of the year (long story made short: something that just could not break broke on Day Job© , and I'm burning the midnight oil to get it fixed…) Cheers.

Hi! Yep, it's something on DOE. What happens is that the atmosphere is drawn before the planets and other distant objects (pun not intended), and so any attempt to use a z-index or similar technic is doomed - there's no way to override that. But... There's a stunt I think it may work (besides not being perfect). This is the very second github issue for DOE/L by the way! https://github.com/net-lisias-ksp/DistantObject/issues/2 I had planned to use exactly these days between Christmas and New Year to tackle DOE's issues down, but as usual Real Life™ overrun me - I'm currently diagnosing a pretty nasty problem on a critical component for a big customer that it'd expecting the product for the first days of 2022… As soon as I manage to put the day-job on rails (pun not intended again) I will work on DOE again, and this one will be mitigated for sure. Cheers!

I'm spending the holidays playing Planet Nomads. I'm enjoying it, once I managed to get my way on the basics. It can be pretty frustrating at first - but logical, once you get the basics and understand how to keep yourself fed, things start to happen way better. I had read than Empyrion is a more mature game, nut Planet Nomads has something than Empyrion (neither Space Engineer) has: Linux and Mac support, and that settled the matter for me! https://www.gog.com/game/planet_nomads

Hi. I have a proposition for you: how about splitting the current HLAirships in two , a HLAirships Core with basic assets (like the ones from the initial releases), and then HLAirships "Full Pack", that would have the "Core" as dependency and/or embedded? More or less as it is done with TweakScale and Interstellar Extended. Think the basic assets as the "Reference Implementation" - everything following the Reference Implementation will be guaranteed to work with Core. This way, everything related to code (and perhaps the basic assets, as they will the assets that will guarantee the HLA will not deviate from specs as time goes by) will go to the Core repo, freeing you from handling them. You can distribute the Core embedded when you release the "Full Pack" (as it's done by Interstellar Extended about TweakScale) and the users will always be able to update Core by themselves using CKAN or CurseForge (or even manually) between your releases (as it happens to TweakScale on Interstellar).

NOTAM KSP-Recall 0.2.1.3 is on the wild, finally tackling down the problem described on the previous posts for all affected KSP versions. See KSP-Recall thread for download links. There's a gotcha, however: the first time you load a craft after installing KSP-Recall, the problem will still be there (I need to workaround somehow the Upgrade Pipeline thingy). But once you fix the craft and save it, it will stay fixed. I think you can work around this problem by manually adding the AttachedOnEditor config node by hand on parts that have variants and TweakScale on the craft file: MODULE { name = AttachedOnEditor isEnabled = True active = True stagingEnabled = True EVENTS { } ACTIONS { } UPGRADESAPPLIED { } } This will "fool" the Upgrade Pipeline, and so your crafts should work fine from the start. But I didn't tested this yet, and you need to be careful to do not mess up the craft file! (make backups, just in case). Cheers, and Scale Safe!!

Impressive. Mostly impressive... Space Lion (Cowboy Bebop) on Virtual Session 2020.

Here, good luck! https://www.fileformat.info/info/charset/UTF-32/list.htm?start=1024 I wish to be a KSP Add'On Author.

ANNOUNCE KSP Recall 0.2.1.1 0.2.1.2 0.2.1.3 is on the Wild, featuring: Changes: 0.2.1.3 Implements a missing Use Case from Issue #32, handled on #34 Lifts the ban for KSP >= 1.10, the thing is known to work on everything since KSP 1.9 Works the issues: #34 NEW Misbehaviour on KSP introduced by AttachedOnEditor 0.2.1.2 Rework Issue #32, handling OnCopy too. 0.2.1.1 The fix from 0.2.1.0 ended up working fine only on KSP 1.9.x . On KSP 1.10.x and newer, a new misbehaviour (probably related, but not sure at this point) was detected. This is Research In Progress right now. This release locks the current work around to KSP 1.9.x, and leaves KSP >= 1.10.0 unfixed for now, as the collateral effect ended up worsening the problem on newer KSPs. Known Issues: The first time a craft file is loaded after installing KSP-Recall, the surface attachment problem still happens. This is due the UpgradePipeline breaking the expected chain of events where the workaround is applied. Once you fix the craft and save it, it will stay fixed. I think it may be possible to work around the Upgrade Pipeline and save the work of the initial fix, but this is something I will need some time to tackle down, and I already spent all the time I could for now (more, to tell you the true). With a bit of luck, this will be handled before the New Year's day. All users still using 0.2.1.0 are urged to download this release ASAP, as it will prevent you some teeth grinding. Completely remove the old files before applying the update. Sorry, this thingy ended up bitting me where I was not looking. — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right now. CurseForge. Right Now. SpaceDock (and CKAN users). Right Now. The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with a new eventual mishap - I'm running against the clock on Day Job, I'm trying to avoid working (too much, as it's a fact by now that I will work a bit) the entire holidays!

METAR Uh… I borked the last release, I let a old binary leak into the distribution. (sigh) Please delete the file <GameData>/999_KSP-Recall/Plugins/KSPRecall.dll (it's dated way older than the other DLLs) for while. I will issue a new Release in the next few hours, with this mishap fixed - as soon as I manage to understand why my building tools failed on this. — — POST EDIT -- WORST! I think I found the reason KSP squandered the OnStart method - someone tried to fix what appears to be a OnCopy mishap by brute force!!! Details on https://github.com/net-lisias-ksp/KSP-Recall/issues/34 If I understood correctly, the Parts Position are not being echoed on the Copied Parts. So someone decided to shove it back on everything (being a copy or not) before OnStarting the part. (sigh) — — POST EDIT — — It was detected that the problem happens from KSP 1.10 to newer. The original misbehaviour WAS FIXED for KSP 1.9.1. Ladies and gentleman, we have a NEW KSP problem to cope with.

METAR KSP-Recall 0.2.1.0 , with the (proper) fix discussed on the last post, is on the wild! NOPE! New bug found!! All TweakScale users are advised to update as soon as it is available on your favorite Distribution Channel. NOT ANYMORE!!! SEE BELOW! I will deploy the release gradually - right now, only Github is up to date. CurseForge and Spacedock will follow as soon as I'm confident this stunt will not break something I didn't foresee: empirical tests suggests that it's unlikely this will cause undesired collateral effects on most add'ons, mas some Fuel Switches and similar add'ons may be affected (mostly the ones that tried to cope with the problem themselves). Since unfortunately Day Job is still bitting, I'm currently without enough time to check anything but Stock + TweakScale. — — POST EDIT — — I found a new misbehaviour, and probably the reason that sadly excuse of a fix on KSP 1.9 was coded. Details on https://github.com/net-lisias-ksp/KSP-Recall/issues/34 . This new problem is worse than the other Recall fixed, so I'm demoting this release as PRE-RELEASE and I advise installing it unless you want to help me diagnosing this new problem. TL;DR: Apparently someone on Squad brute forced a hack to every part to overcome a bug (that it's still there) on OnCopy. DAMN, I opened a can of worms… — — POST POST EDIT — — It was detected that the problem happens from KSP 1.10 to newer. The original misbehaviour WAS FIXED for KSP 1.9.1. Ladies and gentleman, we have a NEW KSP problem to cope with. — — POST POST POST EDIT — — — KSP-Recall 0.2.1.1 was released, see KSP-Recall thread. The fix published on 0.2.1.0 worked fine, but only on KSP 1.9.x. On KSP 1.10.x a new misbehaviour was detected, I'm not sure yet if it's really a new bug or a new corner case that to be tackled down by a new incarnation of the work around (the current one is written on stone now, KSP 1.9.x users may rest assured that this work around is here to stay). For the curious, follow https://github.com/net-lisias-ksp/KSP-Recall/issues/34 for more details. This one is going to fight back, as it appears. — — POST POST POST POST EDIT — — KSP-Recall 0.2.1.2 was released, see KSP-Recall thread. I forgot to handle OnCopy on the damned stunt. Fixed. — — POST POST POST POST POST EDIT — — KSP-Recall 0.2.1.3 was released, see KSP-Recall thread. FINALLY tackles down the problem, including on newer KSPs!

ANNOUNCE KSP Recall 0.2.1.0 is on the Wild, featuring: Fixes: #32 Correctly handle KSP 1.9 (and later) borking while loading Crafts on Editor with scaled Variants A new module, AttachedOnEditor, was created to work around a (pretty old by this time) yet another KSP bug that was screwing up the surface attached parts when loading crafts on the Editor (loading on the Runway, Launchpad or flying crafts were - thanks God - not affected) since KSP 1.9, and that was incorrectly (and badly) worked around on TweakScale. Thanks to @Krazy1 for the report! — — — — — This Release will be published using the following Schedule: GitHub, reaching manual installers and users of KSP-AVC first. Right now. CurseForge. Will not be released. SpaceDock (and CKAN users). Will not be released. The reasoning is to gradually distribute the Release to easily monitor the deployment and cope with eventual mishap - I'm running against the clock on Day Job, I'm trying to avoid working the entire holidays!

I would love a way to buy these stuff from outside the "available regions". I'm in Brazil, and there's no way to do that without using a VPN (what's probably would break some contractual clausule on my credit card operator) and a door-to-door courier service as shipito or something (what's not a problem, as I will pay the taxes the same as the package is internalised on my country).

Hit me on TweakScale's thread or in Private Message if you need any assistance!

METAR The problem described on my last post was handled on KSP-Recall. The rationale is simple: THIS IS A KSP SCREW UP, TweakScale was doing it right until Release 2.4.3.14, when I naively found it would be a good idea to tackle the problem on TweakScale itself, since apparently only TS was being hit by the problem. Huge mistake, that I regret bitterly. In the end, the problem was not on the attachment nodes as I concluded at that time (and kept believing until recently). By some reason beyound my comprehension, the Part's position was being mangled by Editor somewhere after PartModule.OnLoad and before the PartModule.OnStart event. Well, once I finally understood what was happening and where, the fix was incredibly obvious: save the current part position after loading it from the config node, and restore it on OnStart. Only on the Editor Scene. A new KSP-Recall release will be issued today (probably on lunch or late afternoon - I want some time testing it on my rig first), keep an eye on KSP-Recall's thread. In the mean time, I'm considering locking up the fix only for TweakScale at first - it's kinda defeating the very purpose of KSP-Recall, but after more than an year since the problem stroke our SASes, it is reasonable to consider that the most used add'ons that were affected by this problem had handled it themselves in a way or another, and fixing this now may break them. I may be wrong, however, so any comments about are more than welcome. In a way or another, KSP-Recall goes that extra-mile to ensure every single component can be locally activated or deactivated by the user or even 3rd-parties add'ons, so this fix can be activated if needed even if I decide to do not activate it by default for parts without TweakScale. DISCLAIMER No "illegal" (please note the quotes), EULA "forbidden" (please note the quotes again) or Non Forum Compliant practices were employed on this research.

No need to crack down such mods - an update introducing… "incompatibilities" does the same job without the fuss. It worked very well on KSP1.

5/10 Lack of typos in disguise. If making tyops are the criteria, I'm Nietzsche's übermensch!!

Order the parts. I'm on the exactly opposite situation as you: I have a pile of parts on my kitchen waiting for me having time to use them . I have some very interesting toys on that pile for almost an year now. Well, there's a chance I will have some time to spare on this holidays, so it's good to have the parts around. Two years ago I had a whole month to spare - but since I didn't ordered any part (as I didn't knew I would have that time in advance), I spent that time playing videogame and watching animes. So I learnt my lesson: better having the parts hoping for time to use them, than having the time and no parts at all. — — pOST eDIT — — I didn't paid enough attention, and missed the income thingy. Money changes everything. Yet, when I got on the same situation last year I choose to spend some money - and I don't regret, as some of the parts I bought are almost twice the price now. Granted, a few are cheaper… Well… You don't have to buy everything at once. Try to plan ahead what you will do if the time is available and buy only the parts needed for that task - at least, it is what I woul do. Additionally, and this is something I do now and then, you can try to find second hand components - perhaps buying broken equipment to scavenge working parts. You will have to cope with the trash later, so this is not always an option - this is easier when you have partners on the same situation and so you can exchange components you don't need for the ones you do with them. I have a friend on USA that used to go a flea-market that happens regularly on MIT - he told me that he was able to find some good pieces of equipament for pennies, some even working at is. Flea markets can be your solution if you find the time to scavenge working components from such material.

Jeb felt a great disturbance in the Force, as if millions of lines of code cried out in Null Reference Exceptions and were suddenly logged into KSP.log, crashing into the Desktop with a dreadful stack dump!

1926 Fordson Snowmotor.