Lisias

But all of that would demand a pretty serious rewrite of KSP's guts - this thing is heavily tied to C# "way of life". You could probably port a very strict subset of KSP on Sega Saturn if you really want - as long you rewrite the whole thing to cope with DSP's and other shenanigans (what made the Saturn and the incredibly messy MegaDrive with peripherals interesting to code at home, but a nightmare to do it professionally). On the other hand... Controlling the Kerbal on EVA using motion controllers would be absolutely fantastic. Hummm... .Time to grab some cheap aftermarket Wii Remote & Nunchuck...

You need to see some other videos I can't post here. These guys inspired Polyphonic Spree once, and a flash game some years ago (a lot, to tell you the true) was made with music from Spree. It was how I discovered both of them. The Quest for My Rest is the name o the little game. It's still available on the designer's homepage, but how to play flash thingies nowadays? https://adventuregamers.com/games/view/15651

ANNOUNCE KSP Recall 0.2.0.0 is on the Wild, featuring: A minor change to cope with MAS being a little picky about resources, even on hidden ones. 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. Cheers!

Alice Animal. Pretty good!

A nice interview with @HarvesteRwith his impressionists of that time (and perhaps the current one) it's something I would like to see.

the problem is not the change, it's changing unexpectedly. Many Add-ons changed this way in the past, dropping or adding features incompatible with previous versions. A major version bump and a warning about breaking legacy would had helped, @R-T-B, as well as some pre releases in parallel to wet your feet on how the change will impact the ecosystem, and then use this knowledge to make a smooth transition. It's a bit laborious, but feasible.

Tried that on a "naked" installment (only Recall and TweakScale) - but no Exceptions where detected on KSP.log . It's not the Refunding neither TweakScale for sure. Full report : https://github.com/net-lisias-ksp/KSP-Recall/issues/19#issuecomment-832551502

Bisiluro Dalmonar. Dude, I don't now what the guy that designed this was drinking, but I want some. https://www.roadandtrack.com/motorsports/news/a29718/the-nardi-750-bisiluro-was-the-strangest-car-to-race-le-mans/

Well, sorry about your experience. But, as people said above, without further information not even me (TweakScale maintainer) can help. If you installed it using CKAN, and it didn't worked, reach CKAN guys first - I don't use CKAN myself, but last time I tested it (a couple months ago, I think), things worked as expected. If you installed it using CurseForge, I would like to have feedback about. I can't test the CurseForge install, so I'm flying blind on this - the Curse Installer don't knows how to handle Steam. So I will need some help if the problem is, indeed, the CurseForge installer. If you did a manual install, then you didn't read the INSTALL.md instructions. There's a file called 999_Scale_Redist.dll that must be copied into the GameData folder (on the same place ModuleManager.dll is). It's a limitation on KSP >= 1.8 that would bork when more than one copy of Scale_Redist is found on the system, what rendered the Redist concept useless. So I need to shove the Scale Redist on a place where it would be found and loaded before any DLL that would use it, and the GameData is the only place where I can be absolutely sure of this.

KSP is not known to tackle down all the bugs of a major release before issuing the next - it's exactly the opposite. Once a bug happens, you can expect it to linger for years without being correctly handled. So, unfortunately, every bug that happened in the past cannot be considered completely fixed and need to be considered a probable suspect when coincidences are detected on 'new bugs' (that, not rarely, are only different side effects of a root cause that was not tackled down). So the thing is specific to Mk1 Illuminator? That makes things easier (or less hard) to replicate. I will give it a try, now that I know where to look. One thing that the other types of light have different from Illuminator Mk1 (and Mk2!) is that Illuminator is not stackable, while the other lights are. I failed to detect any other meaningful diference while looking the CFGs. Since we are here, try this stunt: @PART[spotLight1_v2] { @MODULE[ModuleLight] { %stackableQuantity = 2 } } This will make the Mk1 Illuminator "more like" the other lights (of course, do it on a disposable installment, we are mangling with the KSP's stock parts!). If the problem goes away, we found a trigger. Knowing for sure about the trigger, we can try to zero into the problem from there. Dude, we have a problem. I can't set the MaxAmount to a "reasonable" value, or the part of KSP that is working fine will nullify the Refunding stunt by deducting the "total value of the Resource" on recovering. I.e., if you fire up a vessel with 200 Units of Fuel, and on recovering it has 10 Units of Fuel left, then KSP will deduct 200*FuelCost and will refund 10*FuelCost. On this example, MaxAmount = 200 and Amount = 10. So I need to keep MaxMount on 0.0, so KSP is fooled on the deduction I depicted above. I didn't managed to find a solution to this yet (my last attempt, setting MaxAmount to 0.00001d fired backwards). I may need to just remove Refunding support when MAS is installed.[Naaah... I tested the wrong binary! ] So I tried a stunt - I set MaxAmount to be pretty small (0.0000001d) so it would get round down by KSP on recovering, but yet would give a non 0 value to MAS play with. Please check this on your rig (I have little to no time to play KSP this week). https://github.com/net-lisias-ksp/KSP-Recall/releases/tag/RELEASE%2F0.2.0.0 In time - I checked the MAS code, it's not trying to handle hidden resources as I imagined. It's calculating the current mass of the PART, and so it really needs to take hidden resources into account.

Now I got it. The problem is not about Storage in the sense of Cargo or Inventory, but about the Resource's MaxAmount. My initial approach was to shove the Refunding Resource on everything at startup and then setting the thing at Editor as needed (tried freezing the amount to 1 and then set the price per unit as the Refunding, between other stunts), and so I had to convince the Editor to never "filler up" the part - so the MaxAmount was set to zero. I remember seeing a Resource like this somewhere, but I forgot from what Add'On. But, then, to comply with new use cases I ended up creating the Refunding Resource on flight time when needed only - and since the Refunding is now a hidden Resource, the user cannot "cheat" by transferring Refunds between parts as they were Fuel or ElectricCharge. So I think I can set the MaxAmount to be equal the Amount at runtime - this will make MAS happy, I think. On a side note, ideally I would create the Refunding Resource only on recovering the Craft - but I realised that this would work only when recovering the craft under focus at the moment - crafts on rails would fail. I tried removing the Refunding everytime the craft gets the focus, and then adding it only when the craft goes to rails, but then I realised that KSP don't issue the recover event when the craft don't have the focus, but yet it's on the physics range of the focused craft - (sigh) had KSP did that, all these problems would just no be able to happen. On another side note, I think MAS should not be handling hidden Resources - they are set to hidden for a reason. [Nope. See this comment.] In a way or another, I will set the MaxAmount to the equal the Amount today by night and see what happens - I think this change will not cause impact on the expected behaviour, and it should make MAS happy. Thanks for the heads up!

You are probably right, since MAS aims to provide information about parts. However, how MAS behave with the Ablator Resource? I modelled refunding using Ablator exactly due the use Ablator have on parts - it's something that will vary with use (but, of course, without being "refilled" normally), and there's not storage for them. The only difference is that Ablator has some density, while I choose to go the ElectricCharge way on it to avoid taxing the physics of the part. Understanding how MAS handles Ablator can help on creating a solution for this on my side. That Quick&Dirty patch of mine (giving 0.0001 density to Refunding) will trick the MAS into behave, but it will affect the physics of the part (very slightly, but will).

I think you found something wrong on KSP. These messages: [WRN 22:50:22.613] [Part]: PartModule indexing mismatch at seatExternalCmd, index 2. Node 'ModuleTripLogger' found in loaded data, but 'Refunding' is defined in prefab. Looking for ModuleTripLogger in other indices... [WRN 22:50:22.613] ...ModuleTripLogger module found at index 3. [WRN 22:50:30.276] [Part]: PartModule indexing mismatch at seatExternalCmd, index 2. Node 'ModuleTripLogger' found in loaded data, but 'Refunding' is defined in prefab. Looking for ModuleTripLogger in other indices... [WRN 22:50:30.276] ...ModuleTripLogger module found at index 3. Are scattered on your KSP.log, and it means only that the index of a module on the savegame is different from the index of that same module on prefab. This happens when you add or remove a Module (by MM patching) between the time you saved that craft (on a file or on a savegame) and the time you load it again. This happens all the time, so it's not a surprise that you locate these messages near nasty exceptions, as they happens when there're no exceptions too. What are really happening on your game is this: [EXC 23:06:43.190] NullReferenceException: Object reference not set to an instance of an object ModuleInventoryPart.PreviewLimits (Part newPart, System.Int32 amountToStore, AvailablePart slotPart, System.Int32 slotIndex) (at <06f13185617646e5bc801baeab53ab75>:0) ModuleInventoryPart.Update () (at <06f13185617646e5bc801baeab53ab75>:0) UnityEngine.DebugLogHandler:LogException(Exception, Object) ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object) UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object) And this suggests there's something wrong on the ModuleInventoryPart itself. It also worth to mention that Lights were recently involved on another set of bugs too, so perhaps we have some more unfixed problems on KSP itself? The KSP bug fixing is not known for hunting root causes, but for merely patching the effects where they are found - so perhaps this could be a missed effect from an old problem that it's arising now that the previous effect on the chain was patched? Without knowing how ModuleInventoryPart.PreviewLimits works, I can only guess - but by looking on the parameters of that function, it appears to be simulating what would happen by storing this light on a part with Inventory. It worth to mention that TweakScale do not touches the ModuleInventoryPart neither ModuleCargoPart, so it's very unlikely it's playing a role on this problem. Refunding, theoretically, could be a trigger as it adds Resources at runtime and badly written code would bork on it. You can check this by deactivating Refunding on the lights and trying to reproduce the problem.

How MAS do about ElectricCharge or Ablator? It appears to be a bug on MAS, because I modelled the Refunding stunt to be like the Ablator - but "weighting" like the ElectricCharge (no weight at all). I checked the code, and I don't see where it tell one thing to another... And I don't even understand why this check is there at first place... Parts with Ablator has this same problem? At first look, it appears that yes, it should be complaining about the ElectricCharge too... Well, a quick&dirty workaround for it is to give some weight to the Refunding Stunt. It will fool the code I mentioned above, but it will affect your part's weight slightly - so it may affect the performance of your craft. It may even unbalance it if by some reason the counter-part on a symmetry gets a different refunding value. Shove what follows somewhere in the GameData (I suggest __LOCAL, to make it easier to locate later): @RESOURCE_DEFINITION[RefundingForKSP111x] { @density = 0.001 } But, and again, it should not be a problem - I failed to see why MAS is wasting time doing this check again and again (this thing is called on FixedUpdate, it appears) and why this should be a problem to it. Ideally @MOARdV should be reached and asked why this check is there at first place, so I can at least understand why this would be a problem.

If the warnings are being issued every time you boot KSP, you have errors on the MM patching process. TweakScale stops emitting the non fatal warnings once the MM cache is one hour old, and the MM cache only gets built when the patching process is completed. Publish your KSP.log and I will see what can be done. Patches can only be made when I know they need to be made.

you have a problem with DRM, not with (just) Steam. Buy DRM free games on Steam and you are done. The problem with GOG is that I can't easily download older versions of a game - what's on KSP is a necessity. And on Steam this is a breeze. And it's I do on Steam - only DRM free games. But I do GOG too, most of my games are bought there - but usually older games that are not updated anymore and have all eventual problems already tackled down.

Missed by a tad! Perhaps @Just Jim is around?

I could not manage to find a solution for this problem, I'm sorry. There're some limitations on CKAN that I can't work around, and the CKAN guys are satisfied with the current solution - so I can't further help on this. Any further discussions about CKAN should be redirect to CKAN thread. Cheers!

Not a problem. May I redirect future requests from users to this thread so?

If someone writes the patches for it, it will probably work. The problem is not incompatibility, it's lack of support - I didn't had time to write and test patches for the Robotics yet.

More or less... It's not a funcional problem, because Recall behaves and only activate what's needed on the host KSP version (so it doesn't even wastes CPU cycles), but some users (and I'm one of them) really hate installing things that are not needed (bloatware ). The problem is that Recall is an indirect dependency for some add'ons on some KSP versions, and this relationship is tied to the KSP version, not to the add'on only. For example: Any Add'On that customizes Resources needs Recall on KSP 1.9, but works fine on everything else Any Add'On that customizes Cost needs Recall on KSP 1.11, but works fine on everything else Some (few) Add'Ons have parts that blow up fiercely on spawning on KSP 1.10, but work fine on everything else. And it's a soft dependency - Recall works behind the scenes. You only note it is installed because the problem goes away. Installing KSP Recall on everything is an acceptable solution, but only installing when really needed would be an optimal solution (and this is whats being requested at the moment) Ugh... Well, I think this is a good time to bump the versioning for 0.2... Thanks for the heads up!

No. The complain is that Recall is needed on KSP 1.11 and 1.9 due bugs on KSP itself, but not on 1.10 - the version the user is using - where none of the bugs affects TweakScale. No. KSP Recall aims to fix or work around problems on specific KSP versions, something completely out of scope for TweakScale (that only aims to scale parts) as well any other add'on affected, as B9PS, FSFuelSwitch, Pay for Play, ODFC and the list goes on. The problem is that different KSP versions break different Add'Ons differently - so Recall may be needed when you use a set of Add'Ons on 1.9, but not on 1.10 or 1.11, while the set of add'ons that need Recall on 1.10 and 1.11 are completely different than on 1.9 (or between 1.10 and 1.11). Moreover, it's pretty dangerous to have more than one add'on trying to solve the same problem by themselves - or you will have the workaround being applied multiple times (something extremely undesirable when fixing the Refund problem on recovering vessels on KSP 1.11). All I can do (and I'm doing) is to code warnings on TweakScale prompting the user to install KSP Recall on the KSP versions TS needs it - but I can do anything about Recall being installed when TS doesn't need it (please remember that Recall may be needed by another add'on, even when TweakScale doesn't need it on that KSP Version). Yep, pretty messy. No if we have the "fallback" netkan (the current one, that would accept being installed anywhere) for new installs. The replaced-by would not solve the problem? Once a new KSP version is released, the TweakScale-for-1.11 netkan would be updated with the replaced-by pinpointing TweakScale-for-1.12 . And since both TweakScale-for-1.11 and TweakScale-for-1.12 will be tagged to work only on that expecific KSP versions (using ksp_version_strict), we would have a solution for this problem - assuming these features work as I expect.

KSP have some fixes for KSP 1.10.x too but, granted, they are not as critical as the KSP 1.11.x ones. KSP 1.9.x on the other hand has also a pretty nasty flaw affecting all add'ons that customise resources (this one affecting all game modes) and so KSP-Recall is needed by TweakScale on it. Problem is that CKAN doesn't have support for "KSP Versions specific requirements" - it's everything or nothing. However, I agree with you, you should not be forced into downloading a dependency you don't need, and I had engineered TwealScale and Recall to allow such flexibility. I'm working on a possible solution for this problem. That's the problem - on this specific use case, Recall was marked as a dependency because there was no other way to guarantee having Recall installed for KSP 1.9 and KSP 1.11, where the Recall absence would play havoc with a lot of add'ons, TweakScale one of them. There're really no need for install Recall on 1.10.x due TweakScale, the work arounds it provides are targeted at things completely unrelated to TweakScale and that will not bother a significantly portion of the user base. Had CKAN a way to choose dependencies based on the target KSP version being installed, I would be using it but since it's all of them or none of them, we had to pick up this stunt from our hats. Now with things settled up (the Refunding stunt has stuck, apparently!), I have time to consider new solutions for this problem. Let's see what we can do about. -- -- -- POST EDIT -- -- -- People interested on this problem are invited to follow this thread.

Hi, @DasSkelett, That's the thing: some people (not unsurprisingly) are complaining about the need to install KSP-Recall even by not requiring it. Since CKAN currently don't allow targeting specific versions of KSP for dependencies, how about different netkan files for the same add'on targetting them? Using TweakScale and KSP-Recall as examples, how about three different netkan files: TweakScale for 1.11.x, locked on KSP 1.11.x and requiring KSP-Recall TweakScale for 1.9.x, locked on KSP 1.9.x and requiring KSP-Recall The current TweakScale would so be the fallback option, targeting anything above 1.4.0 and only suggesting KSP-Recall (or not even that). This is feasible? Would CKAN allow such a solution?

Now I understand. Yep, you found a serious incompatibility - UbioWeld cannot be used on KSP 1.11.x...