Lisias

"Wildcards on patches"

More or less. The ConfigCache is how things will be on the prefab. Then, after MM data injection, on the Main Menu a lot of Add'Ons are triggered, and they do some specialised changes on the GameData. SscanSAT, KAS, Mission History, and more, do that. And now TweakScale. The net result is that the GameData doesn't reflects anymore what ConfigCache have in its records. TweakScale, however, appear to be the only one that undo some things when it detects a problem. It plain withdraw any TweakScale support from problematic parts, so the problem is not even saved on a craft file (and savegames) with TweakScale support, preventing triggering problems on older TweakScale installations. What caught me with my pants down is KSP insisting on using prefab's TweakScale module information from a part that have the info on its MODULE node. If such data is on the craft, what's the point on trying to use the prefab data to overrule the craft data? And if the prefab data is meant to overrule craft data, why such data is saved on the craft file at first place? In a way or another, it's unfeasible to expect KSP change this (be it a mistake or a valid change that fixed some other problem), so it's up to me to deal with it.

Hummm .. So this is what happening. I didn't understood the first time this was reported https://github.com/net-lisias-ksp/TweakScale/issues/41 Yeah. Somehow, KSP is using both prefab and craft data to instantiate something. Now that I have a deterministic way to reproduce the problem, I can test it and try a fix. On a wild guess, I think I should instrument TweakScale to detect these issues and shutdown itself for that part.

Statistically, perhaps. But don't undervalue a good hint given by someone outside the machine room where I'm living from some time. We usually narrow our mindset when solving problems, what sometimes lead us to take a not so good decision. Not to mention learning a new trick or two from people that knows better some details (yeah, I learnt something too!).

The cannonical way is to fork the project, hack the changes, commit, push and from the GitHub site issue a pull request. It's easier than it looks, but is usually a bit cumbersome for non developers. But you also can publish the file using pastebin or something and publish the link here. We can compare the fixes, sometimes we miss things. --------- On a side note, I expect to release a new version tomorrow. Real Life got into my way about releasing something today.

(moved from the wrong thread!) Yep. There's TweakScale, the MODULE, and there's TweakScale, the "stock" Patches. It's not Module's fault, it is doing exactly what it's being told to do. I'm "teaching" it to detect some bugs, but there's a limit on what can be done automatically. About the Patches…Well. Some of the problems are on me. Some of the TweakScale stock patches have the problem too, and to tell you the true I completely forgot to check my own patches before doing the release. Until the moment, not a single report was due only the Stock Patches, but yet they are there. On my defense only my Career game (still on 1.4.3 , the mainstream version on the last time I really played) detected these problems now that I fired up with the newest TweakScaçe, but as I said, it's more exactly ONE YEAR since I fire up it since the last time!!! (dude, it was running one of my first "unofficial" compilations of TweakScale yet!) Somewhere else on this forum I said that would be a good idea having more developers playing more the game in order to foresee in advance some possible consequences about the decisions they make. Guess what? It applies perfectly to me too. Once TweakScale 2.5 goes gold (the Milestone I'm slowly pursuing through the 2.4.* series) I will take a break on this and go back to my Career. No Kerbal should be dragged away from his game for that time! There's a possible compromise on this. Until the moment, almost every single rogue patch was trying to "overcome" the default behaviour. These ones, once everything is fixed, will still be the dominant ones - with the additional benefit of not risking ruining games when Add'Ons are installed, updated or even removed - destabilising the brittle balance that is allowing things to work at the moment. There're some others that are applying the same patch twice. These ones are 'almost' harmless - but since they are applying themselves twice, they will be being applied twice even if something else tries to overrule them. And then we would have a new instance of the last problem. The nastiest problems, however, is when different patches are applied by error on the same part. This is a serious game braker because these patches are not only changing things in a unattended way (the others were doing it on purpose to get a new, predefined behaviour), ruining the current game, but they also are "vengeful" as they also ruin the game when things are fixed! This is not safe, as some rogue patches ends up acting only under determined circumstances. Anything gets different, the savegame is ruined as the brittle balance that were reached is broken and the chain ends up with different results. So we need a set of deterministic, custom made patches, that would allow these savegames to carry on without being at risk. This is the reason I'm asking people to send me their KSP.log and MM ConfigCaches - to be able to detect if these Doomsday scenarios will be a reality and then, when the TweakScale 2.4.3.1 is issued, I will be able to provide custom parches that would mangle the parts back to the wrong behaviour (saving the game), but without the risk of things going through the tubes due rogue patches going straight.or something. EXACTLY!! Backup everything and kick my up. Once I detect exactly where thing are wrong, I can handcraft a patch that would "break things again", but this time in a deterministic and safe way. What makes me think that I should "mark" these parts somehow and tell TweakScale to remember the user, regularly, that he doesn't should start new games using that installment. Good brainstorming, @zer0Kerbal . This is what the good software feed on! Thanks!

It's not TweakScale, it's the Patch. TweakScale patches are made of building blocks, and the default ones can be found in the ScaleExpoents file: TWEAKSCALEBEHAVIOR { name = SRB MODULE { name = TweakScale TWEAKSCALEEXPONENTS { name = ModuleEngines minFuelFlow = 3 maxFuelFlow = 3 maxThrust = 3 -ignore = ModuleEngineConfigs } } } So you can create your own TweakScale Behaviour, using the scales that suits you. And then just apply them to your parts as it's done on the "Stock" Patches: @PART[LaunchEscapeSystem] // Launch Escape System { #@TWEAKSCALEBEHAVIOR[SRB]/MODULE[TweakScale] { } %MODULE[TweakScale] { type = stack defaultScale = 1.25 } } This makes TweakScale extremely flexible. Of course, I'm just explaining how things can be done. By no means I intend to do nothing else but to explain TweakScale inner workings.

Whoops. I posted on the wrong thread, moving the post to the right one!

This is not wise due reasons explained here: In a nutshell, it will wash the detectable symptom away, but the nasty bugs will by still there ruining savegames - and I will have to cook yet another sanity check to reach the same goal. What would made the whole effort useless.

Advise your users before updating. This will break the savegames of every user your Add'On that have scaled parts.

Essentially, we lost the control of the order and incidence of the parts being patched. We have some double patching happening on the wild, and this are triggering some unhappy events on the user's savegames. The problem is described on this post and its being handled by this issue.

I think that, probably, we should think about that idea of deleting all default patches from TweakScale in order to make things a bit more "friendly" to users, what do you think? Alternatively, someone on TweakScale thread hinted another possible way to cope with that, by deleting previous patches before applying yours (didn't teste it myself yet): @PART[<part_name>]:NEEDS[TweakScale] { -MODULE[TweakScale],* MODULE[TweakScale] { type = stack defaultScale = 1.875 } } source:

Yes, this is the main problem I need to solve since the beginning : the lack of ":FOR" on TweakScale Patches that would help to solve the ordering of the patches. It's what triggered all this checks, by way, as I realized early that this would cause some issues and started to implement the safety-checks. What caught me with my pants down is how widely these problems were already happening on the wild. I can't thank @Jammer-TD enough for the incredibly worthy help he did on the issue #42, by the way. I could had theorized the possible problems, but I was not aware of how much of them were indeed current until he hinted me about with his tests.

That is TweakScale's default patching borking. Will be fixed for the weekend. If you are absolutely sure you are not scaling MK4 parts, you can delete GameData/TweakScale/patches/MarkIVSystem_TweakScale.cfg . This will make the Alert go away by bluntly removing all Mk4 patches (the good and the bad ones). on a side note: I have a savegame with Mark IV parts scaled. I confess to you that I'm finding courage to check that savegame!

Fixed. Thanks for the heads up. I don't understand what is happening. By using https on the link, we get that weird red page. So I put http instead - that so redirects to a https URL equal to the link that was there before. go figure it out. Krakens.

Well, I don't know from where is that patch, but you found the problem yourself. There're two patches for smallwingConnectortip on this file. And for tbmProp too. The good news is that the patch being applied twice have the same content, so this is that single situation in which this issue is not a problem - so your savegames are not at risk for this. But I recommend fix the file (search for every duplicate, and delete it). Ideally you should apply the fixes to the upstream, but I didn't recognized the file content (it's way different from the TMasterson's one), and there're no identification on it. Well… But this part of your problem is diagnosed. That's what matters now. About the fatals on the MK4 parts, these are TweakScale's fault - and, yeah, these ones are the serious ones. Sorry. I will fix this on the next minor release, that will be issue in this weekend. I will do my best to have this being published Friday night so you people don't lose another weekend due this. Until there, don't use any MK4 with scaling on your game or we will have some trouble on your savegames.

Thanks. From your log, one of the problematic parts is smallwingConnectortip from AirplanePlus. However, there're no standard support for it (i,e., not from me neither from AirplanePlus maintainer), so I think that you are using TMasteron5's patches. However, your patches doesn't appears on the TMasterson5's original place, as we can see here: [LOG 09:19:19.017] Config(@PART[smallwingConnectortip]) AirplanePlus/TweakScale/@PART[smallwingConnectortip] Originally, it is expected to be on GameData/TMasterson5TweakscalePatches/AirplanesPlusTweakscale/tweakscaleConfigPatch.cfg . So I'm afraid I can't help no this for now. Can you confirm the source of the patch you are using? The following issues, however, are on me. I found that the MK4 patches from TweakScale are using wildcards, and are a potential source of problems. This will be fixed in the next minor release, that will be issued as soon as possible. Interesting. Appears to be something on one of the event handlers of the part. Yep, you are right - there's a good chance it's a bug on TweakScale's code. Opened a bug for it: https://github.com/net-lisias-ksp/TweakScale/issues/52 I will work on it for sure, but not for while. Please be patient. Thank you.

How in hell we get rid of the stink of burnt popcorn? I was making some popcorns to make a bit easier some midnight oil burning, but suddenly I had that urgent call of nature and forgot to turn off the stove. Now I have a ruined pan and the entire house is smelling burnt popcorn. Terrible!

Me too. Had Airplane Plus fixed that terribly overpowered engines (the small props has more power than an F18 engine!)? It's a long time since I used A+ engines, as I found KAX more reliable on this!

I didn't gave enough thinking on the feature, granted. This will be implemented on the next minor release. Yes. Thank you for nailing this for me. :) It will be fixed for sure in the next minor release! The IR/Next guys found a problem on the "Classic" IR code that leaded to something like what you described. Could you reach them first and check if this is the same reason? If yes, and this is happening to Serenity too, then definitively I need to act. For reference, and assuming is the same thing, there's an issue about: https://github.com/net-lisias-ksp/TweakScale/issues/39

I need your whole KSP.log, and probably the MemoryManager.ConfigCACHE too. Put these things on GoogleDrive, Dropbox or something and post the links. This will help me to identify the details of your installment so I can look for the trouble maker.

Give me your whole kSP.log - from that, I will find the faulty patch and then I can fix that for your, while applying a pull request to the maintainer. I need the whole thing as it lists everything that is happening on your installment, including every Add'On. From this, I can locate the rogue patch (assuming it was not one of mine… ). — — POST EDIT — — @Kiro, I really need your KSP.log and I ModuleManager.ConfigCACHE too. M2X_EndCap is a part from Mark2 Extensions, and I just confirmed that the M2X's TweakScale patches are working fine on a minimal installment (M2X, Dependencies and TweakScale). So there's something else on your installment stomping some toes. I want to tell that the M2X patches are very well written (using :NEEDS and :FINAL - besides using "%" on value names, what would make diagnosing harder if the problem was it) so it's surely something else borking up things.

Hi @RoverDude. I'm trying some changes as proposed here on the Principia thread. Some guys are getting trouble using Firespitter on Principia due it still using Rigibody.Part.AddForceAtPosition, instead of the Part one (something about allowing modules to inspect the forces being applied). I applied the @eggrobin suggested fixes and I'm using it for some hours without problems - but I didn't tried Principia yet, so I can't say for sure if this is enough. However, with newer modules using Part.AddForceAtPosition nowadays, I think that this hardly would be a bad move. https://github.com/snjo/Firespitter/pull/211 — POST EDIT — The pull requests were reissued against the branch DEVELOPMENT as requested.

It's not a solution for this problem. But there're valid use cases for this operator! (but it would be safer not to use it together wildcards, I think) Yep, I will revisit that pull request. It may be related to some issues I had with SXT, but didn't found the time to properly address them: https://github.com/net-lisias-ksp/TweakScale/issues/14 (this is is about the FSBuoyancy) https://github.com/net-lisias-ksp/TweakScale/issues/17 They are on my backlog, I just could not find the time to address them yet. Yeah, I'm working on it already. I have as habit to, once I detect a problem, to check the whole history of the file to locate when the change happened. This gets me insights about the reason the change was made, and sometimes it prevents me to resurrect an old problem while fixing a new one. (public repositories are simply the very best thing that even happened on my life - except by some non-forum-compliant activities with partners of the opposite gender) I'm checking every stock patch AGAIN (using Shadowzone's voice) about the use of wildcards, and then for double patching (that will be hugely easier to detect without then). I have a nasty rogue patch on the Mark IV too, and I bet my SAS I will find some more. On a side note: This is going to be a bit painful on the short run, but it will make everybody's gaming better on the long run. Once we reach a good compromise on the status-quo, any mishap will be promptly detected while testing on the dev's machine before going gold. It will worth it.

About the "%type" thingy, I want to explain again why this is terribly important. Consider the following scenario: Things are fine and good. Your vessels scale well. But then a new patch is applied on the GameData folder - an new Add'On, or perhaos an Add'On being updated. By some bad luck (and it happens - you, humans, are prone to err!! ), a patch is applied twice . Usually due using a wildcard on the name or the PART, but obviously, sometimes we just forget to check if we already patched it - or just don't check if the patch was already patched by a third party! So, in the next KSP boot, you get this: And, now, EVERY SINGLE CRAFT on your savegames that uses this part, be it flying or not, will get something as this: As we can see, it's pretty straight forward to detect the problem. In TweakScale there can be only one. So any duplication is necessarily the result of a Toe Stomping Fest between patches. If patches start to blindly use %type (or any other name) for values, we will have what follows: MODULE { name = TweakScale type = free defaultScale = 1.25 } And now it's not easily detected anymore, but till leads to the same results - corrupted crafts and savegames. So, and again: this stunt renders my Sanity Check useless, BUT STILL CAUSES THE PROBLEM. I want to make perfectly clear to everyone: I'm not patching symptoms, I'm fixing problems. Any symptom patch (as using "%") will just make the problem harder to detect, but will still corrupt the savegames and crafts.