Lisias

Gone Jackals is great!!! (in time, the theme music from the Full Throttle is 'Legacy")

I made this test, WITHOUT TweakScale installed. And I got the same results, only a very few parts are Stackable. And some Stock parts (as the Go-ob ED Monitor) could not even be placed on the KIS container. So, nope. This is not on TweakScale - this need to go back to the KIS Maintainer. And below the same test but with TweakScale and TweakScale Companion for KIS installed: You see, whatever was not Stackable without TweakScale, continue to be not Stackable. And whatever was Stackable without TweakScale, continued to be Stackable when I installed it. However, this was not a waste of time - you warned up that I need to update the KISConfig with the TweakScalerKISInventory module! For now, update that patch to @KISConfig:AFTER[KIS]:NEEDS[TweakScaleCompanion_KIS] { @StackableModule { moduleName = TweakScale moduleName = TweakScalerKISInventory } } It will not solve your issue, but it will prevent the TweakScalerKISInventory to be a problem when things start to work for you.

Unsurprisingly because KISConfig already have the data. Yes, I want the log and the craft for inspection, please.

I will give this a try by night to see what I get. Yes. I'm adding this patch to the next release of the Companion for KIS, but until there, yes, you can name this patch anything and put it on your personal folder (I use GameData/__LOCAL )

The following patch should do the trick: @KISConfig:AFTER[KIS]:NEEDS[TweakScaleCompanion_KIS] { @StackableModule { moduleName = TweakScale } } And, to tell you the true, this should be on the respective Companion, I completely missed that. (after checking KIS) However.... TweakScale is already on the Stackable section on the latest KIS release, you should be able to stack parts with TweakScale already... What's the part borking on you? It may be some other module.

To tell you the true, from 2.4.4.0 and forward, the correct thread is the TweakScale Companion Program one - TweakScale "vanilla" aims to support Stock and DLC only, everything else is now supported on a Companion. But using the TweakScale thread as a jump point doesn't hurts.

Donatien Alphonse, on the other hand, has never been so in vogue - he found an important role on Software Development.

Check this thread The KIS support has gone Gold early this year. (report any problems on that thread too)

If you are not allowed to criticise something, you are not allowed to praise it neither.

Since my first thread here, at least... A show of horrors... I never really understood why some people was allowed to treat newcomers that way. On that account, I can't complain. Kraken knows how many times I publicly and harshly criticised some cornerstones of this Community - but only got moderated when some Forum rule was violated. I agree that some rules are not exactly ideal, and can be (ab)used sometimes, though. Got some of that too. On the brigth side, I kinda "won" an argument or two, besides never managing to revert a moderation act. Perhaps this could be related to "how" did you argumented? Some people are terribly sensitive to how you say things, completely ignoring what are you saying. I was educated on a way where the content of the message was the important thing, being the format secondary - as long you say the True, the format of the message is handled separately (i.e., you misbehave while saying the True, you got admosted by the misbehaviour, but without prejudice of the message itself). Obviously, this is not the norm nowadays. Man Made style? Some people are allowed to publish some things, and some others aren't?

Taking a break from debugging, I was wondering about something fun to do on this Sunday. So. that's the deal: do a leisure Kerbin circumnavigation journey using a hypersonic craft for 6 rich and bored tourists with more money than common sense. To make things more interesting, the circumnavigation will be made from pole to pole instead of following the Equator. Problem: doing it on Stock Kerbin is terribly easy. Solution: 2.5x Scaled Kerbin. Complete Screenshots Gallery on my site. Cheers!

You are my hero!

Sounds more like something you are not using, but first I need to test some hypotheses on the latest code (I'm still using an intermediary stage, after the first Meier's refactoring, but before the latest one).

First I need to understand why things are happening this way. KSP nowadays have this terrible habit of mangling living parts, and if B9FS is squashing prefab data on the part in order to overcome a previous squash from KSP itself, there's no fix possible on the B9FS side - and so, all I can do is to reapply TS from scratch every time a part is "OnCopied". What I will need to do every time B9FS switches something (as I had to do with ModulePartVariants - there're still some loose ends, by way), so this is more an (additional) annoyance than a problem...

Well, as was said by that famous london personality from the 1888 Jack the Ripper... "Let's do it by parts". I'm assuming this is on KSP 1.11.x, so I will give this a try on a clean + TweakScale 1.11.x and 1.10.1 to see what I get. I remember fixing this in the past, by the way.... Perhaps I should reactivate KSP-Recall's Resourcefull on KSP 1.11.x too? Hope not.... Sounds like someone borking the nodes resizing. This one I fixed for sure on TweakScale - one does not forget this kind of mistake... --- --- --- -- -- Well, lets try to reproduce these symptoms on my rig: (firing up "clean + TS" KSP 1.11.1) * Symptom 1: worked fine for me, could not reproduce * Sympton 2: worked fine for me, could not reproduce Oukey, TS alone on KSP 1.11.x does not triggers any of the 2 symptons. No exactly a surprise, as you stated that the fuel tank need to have switch options (what kinda hints about the problem - besides not hinting about who is causing the problem yet). I will skip clean + ts on 1.10.x tests so. (firing up "CryoTanks + b9ts.mine + CommunityResourcePack + DynamicBatteryStorage + TS" KSP 1.10.1) * Symptom 1: confirmed. * Symptom 2: confirmed. Oukey, this is not KSP related. Good. Looking on how things happens (and now that I know a bit better B9PS' guts), I know the source of the problem - both TS and B9TS are working disregarding each other: on both cases, the B9TS's OnCopy and the Switch Handling code are overwriting whatever the TS had done on the part (as it's copying fresh node and resources data from the prefab the exact same way ModulePartVariant does). I can't say it's a bug on any of them, because B9TS doesn't care about TS, and TS aims to support only Stock and DLC parts leaving to the companions the responsibility to work with third-parties. But yet, it's a problem on the userland that must be tackled down. I will implement B9PS on a new Companion. The task for it is the Companion Issue #17. (I have another similar request for Fuel Switches, I think it's time to reschedule things). Well, I need to reschedule some things (I was working on another Companion before the need for the KSP-Recall's Refunding stunt), but this will be worked out in the near future for sure. Until there, I found that configuring first the fuel type for the tank and then scaling will work around the Symptom 1. Unfortunately, it didn't did the trick for Symptom 2, and I consider this a flaw on B9PS - why squashing prefab data back on the part while handling OnCopy? In a way or another, the Companion will solve both cases. Worst case, I do what I did while implementing support for FS's FSBuoyancy - I will intercept the UI and coordinate B9TS and TS from the companion. Stay tunned.

I think you nailed, sir! Now I know what's happening!!! That would not help. There's code in need to be written to cope with the new KSP features!!

Modules that implements IPartCostModifier and IPartMassModifier (and perhaps others) are being called by zombies copies of B9PS Modules, and if any of these called modules make a call to Unity, you have a NRE Exception inside it. Such zombies happens every time you switch Scenes (launch a craft, revert to editor, etc). On every scene where the current craft is destroyed, you earn a lot of zombies on the system. And every one of these ones may call other living modules from dead contexts. It's a mishap on B9PS . Since not all modules make calls to Unity from their interface implementations, not all of them are deadly affected by this problem. But all modules are affected in a way or another - at least, by wasting CPU and memory on dead objects lingering around.

ANNOUNCE KSP Recall 0.0.7.3 KSP-Recall 0.0.7.5 is on the Wild, featuring: A (dirty) workaround for the KSP 1.11.x faulty calculation of Funds on recovering crafts (Issue #12) Fixes a deployment mishap for CurseForge A new module, Refunding, as well a new Resource was introduced for KSP 1.11, to counter attack the miscalculation mentioned above. When recovering the craft, the badly calculated refunds will still be there, but an additional Resource called Refunding will be present stealing giving back the losses. Users of EVERY add'on that implementsIPastCostModifier and are running on KSP 1.11.x NEED to install KSP-Recall - or your Career will be seriously hindered. Affected (known) add'ons are: Darth Pointer's Pay to Play FreeThinker's Interstellar Fuel Switch allista's Cargo Accelerators All Angel 125 Add'Ons that uses WildBlueTools Nathan Kell's Modular Fuel System (and Real Fuels) IgorZ's Kerbal Inventory System KOS Kerbalism And many, many others - perhaps Squad's own modules (who knows?) 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 eventual mishaps. -- -- POST EDIT ---- A lame mistake was detected and fixed. KSP-Recall 0.0.7.5 was published.

Sounds like cryogenics boiling up. Fuels like Hydrogen can't be stored on fueltanks for too much time, they just boil up and leak into space. Choosing the right fuel for the mission (what limits the engines you can use on the mission) is the reason Real Fuels were made. Rule of thumb: Cryogenics (chilled kerosene, LOX, etc) are excellent for first and second stages. Once you establish a parking orbit and start to plan the rest of the mission, it's best to rely on non-cryogenics fuels: kerolox, hypergolic, nuclear, ion, etc. If you really don't want to cope with these details, you can try removing Real Fuels from the system. It will probably screw up any vessels already launched, however - make backups while experimenting things. (I use S.A.V.E to make things automatic).

ROMBUS. Dr Werner is proud. (If you are Brazilian, i can hear your laughing from here!)

I'm playing on a MacMini 6,2 - I7-3615QM, Intel HD 4000 and 16GB . It's way from being a beefy machine, but it does the trick as long I keep the Textures quality at 50% and the Anti Aliasing low or off to save memory bandwidth. Try to lower the Texture Quality, it will probably help. About TweakScale, it deactivates itself on unescaled parts, so if the blowing craft has no part scaled, I can tell you for sure TweakScale is not the culprit. There're a recent bug fixed on B9 Part Switch (still unpublished, sadly) that was injecting bad contexts on TS (and many more too, but TS is sensitive on this problem because it needs to call Unity on that calls), leading it to bork - but this is only a problem if you have the Forum's B9PS installed.

Somehow, this post came to my timeline, so I thought to myself it would be a good idea to add my bits on it! Scaling engines on Career can potentially spoil your game. Make things too easy - in real life, economics and limitations on material engineering prevents us to resize engines at our will, so if you want to follow a "plausible path" on your game, avoid scaling engines. Wheels, tanks, wings, control surfaces, fuselages (a pity we can't scale crewed parts correctly, but this is hardlocked on KSP's guts, nothing I can do), lights, even parachutes, that are the things I scale up and down without a second thought. On the other hand, on my SandBox games, dude... (I'm TweakScale maintainer, by the way )

ANNOUNCE KSP Recall 0.0.7.2 BETA is on the Wild, featuring: Further ehances the workaround for the KSP 1.11.x faulty calculation of Funds on recovering crafts (Issue #12), (hopefully) solving the problem on a way that would work for every Add'On. A new module, Refunding, as well a new Resource was introduced for KSP 1.11, to counter attack the miscalculation mentioned above. When recovering the craft, the badly calculated refunds will still be there, but an additional Resource called Refunding will be present stealing giving back the losses. Now works too with PayToPlay! And without double charges happening due a mishap while launching the craft! DANGER, WILL ROBINSON, DANGER This is a preliminary BETA version intended to be tested on the field. The kludge, I mean, the workaround worked on controlled environments, but I need to test this thing on the field in order to check both the effectiveness and safety of the stunt. PLEASE, PRETTY PLEASE USE THIS ONLY ON DISPOSABLE SAVEGAMES. Add'On authors that make use of the IPartCostModifier please report your findings on the Issue #12. I need your feedback. This Release will be published using the following Schedule: GitHub, reaching manual installers first and users of KSP-AVC. Right now. CurseForge, will not be published. SpaceDock (and CKAN users), will not be published.

Are you sure? My empirical tests pinpoints 1.4.0 as the source of the problem! Did you see how the lifting forces are terribly unbalanced on KSP >= 1.4.0 ? I ended up managing to control roll on all KSPs (buggy or not) by carefully adjusting the Authority Limiter on flight, but I must admit that on 1.3.1 this was way easier, probably because the lifting forces are equally distributed on the surfaces. Also, check the SAS, it's way easier to control the thing using it. Well, in a way or another I never did any tests on anything older than 1.2.2, so I will give this a shot. -- -- POST EDIT -- -- You see, you may have a point! I did the following test on KSP 1.1.3: The behaviour of the Lifting Surface themselves on KSP 1.1.3 didn't differed from my tests on 1.3.1 (and recently 1.2.2), but the SAS behaviour appears to be more... consistent, and the craft is easier to control even without trimming the Authority Limit. I think you found something - whatever the problem is, apparently SAS is involved on it....