Lisias

There're no patches yet for Breaking Ground. I started toying with the blades first, and it appeared to work fine on 1.7, but something apparently changed on 1.8 and I didn't had time to investigate yet. The blades support should be available on 2.5 Beta, if anyone is interested.

And if you use the current Beta for TweakScale 2.5, you can scale the wheels and get the expected behaviour too!!

Alternatively, and this suggestion need a lot of thinking on their side before being really considered (how many people are still using older KSP? Why? Can we really trust the Unity telemetry without getting caught on a Survivorship Bias?), backporting some fixes as "hot patches" to these KSP versions can be a good idea, leveraging the gap between older KSP and newer, making it feasible the user reconsidering and migrate. Issuing new releases for KSP older versions (1.4.6, 1.5.2, 1.6.2, 1.7.4, 1.8.2) will be probably not cost effective, but "hot patches" may be. Microsoft did this with some success on the Windows 95 times (OSR1, OSR2, etc). Public Bug Tracks has a P/R value, refusing bugs for older KSP may help on the technical level, but could have some backslash on the P/R one. However, I agree that the current status quo is less than effective - and in the end of the day, if you don't have a way of win the war, all that can be done is to choose the less painful way to lose it. The problem is that sooner than later, whatever you are doing will be the past, and so you will care for it. Every single newbie will be a veteran soon. And if you don't care for your veterans, they leave - eroding the Community that you need to help you supporting the product. KSP has a long term gaming mechanics, I know people that play their savegames for more time than I have an account here. These guys have a huge knowledge about how things works, and even these guys being a minority around here, they are the foundations that in the past made this Community to thrive. Of course, nothing of this makes sense on casual gaming (like Angry Birds, Happy Farm et all), where gamers happily exhausts the game potential and then wants a new release to fulfil their wishes. There's nothing wrong on this game model, but I don't think that KSP would thrive on it (do you know Space Agency for Android? Hell of a nice game, good for some playing on wait rooms or bank lines - but I never managed to like playing it on my TV using my Android setupbox).

Use S.A.V.E.!!! (#TweakScaleFeelings)

As far as I know, nope. Sorry (I'm looking for them too). Not on a strictly legal way. On USA there's a loophole on the law that can allow you to receive a copy of a software you are legally entitled to use no mater how, but AFAIK the guy sending you such a copy is not protected by this loophole. So, yeah, theoretically someone can be in legal trouble by providing you something you are legally entitled to receive. Go figure it out... On other countries, you need to research the local laws. Some countries are specially draconian and even asinine on the matter. In a way or another, Forum rules forbids discussing these alternatives ways here (they need to comply with the legislation of different countries, and this is the safest way to cope with them all). So even if you find a way and it's legal for you, please don't disclose it here. Stupid laws are a pain in the SAS, but they are still the Law.

Thanks, but I don't have problems on finding the information I need. I have problems on using Stock MM for that. :) From my duties on TweakScale, I also had read a lot of logs, and my opinions are based on my experience. Right now, I rely on TweakScale and customisations on personal forks, as the current MM is terribly awkward for troubleshooting complex interactions, where the order in which things happens leads to the diagnosis - and cross-referencing many different files is way less practical than just generating a report from a single KSP.log. Not to mention things that MM just don't check, and some people think it should.

No, sir. You are missing that there are people in need of better diagnosing tools, and would be better than such tools could be implemented on MM. It's perfectly OK you not willing to do so. But so someone else will step up and fulfill the need. The current way the mainstream MM works is less than ideal, and we (I'm not the only one) are saying it to you.

A primeira vez que eu rodei o 1.9 também acontecia isso - e eu estou no MacOS. Eu resolvi aqui apagando o arquivo settings.cfg. Qdo rodei o KSP 1.9 de novo, funcionou.

Venting ore through the valve would be something interesting to see, indeed. anyway, there's always the old and faithful Tac Fuel Balance for this function, if you prefer resources (including ore) to just vanish from the tank.

METAR After some hours of tinkering and good laughs on committing absurdities on scaled parts, the current weather report is: Clear skies, with no expected thunderstorms (of any substance, aromatic or not) for TweakScale aircrafts - as long you scale things using the U.I, Some windshear can caught you from behind , however, if you try to brute force your way working around the U.I. Brute forcing my way on craft files revealed some glitches and funny moments. But since these situations are not reachable by the user interface, it's not considered relevant. AND KSP didn't blew up anyway, so no damage is done. Cost and Mass, as expected, didn't underflow and so no crashes were induced on/by the physics engine or problems related to costs are expected (at lest, due this). But the colliders started to misbehave on scales about 100 times less than the default (1% on free scale, defautScale/100 on stack). Crafts at that small scale suffered the Jumpin' Jack Effect - somewhat hard to visualise as the craft essentially has the size of a flee by now (had to turn aerodynamics on to see something, the camera's zoom was not enough). The following entries on the log were detected for (almost?) all the absurdly scaled down parts: [WRN 15:07:44.755] BoxColliders does not support negative scale or size. The effective box size has been forced positive and is likely to give unexpected collision geometry. If you absolutely need to use negative scaling you can use the convex MeshCollider. Scene hierarchy path "strutCube/strutCube/strutCube/strutCube/strutCube As well some complains from KSP on ground contact (again, for the absurdly scaled down parts): [LOG 15:07:49.035] [Arrow-E]: ground contact! - error. Moving Vessel down -0.430m This last one being known to be associated to the Jumpin' Jack Effect (inclusive on Firespitter wheels!). I see no reasons to believe that any bug we could find on TweakScale would not affect also KSPs from 1.4 to 1.8, and nothing on KSP 1.9 induced any collateral effect that would make it behave differently from what we have on previous KSPs. So let's light that candles, boys. Our Kerbals are eager to fly!

I think you cannot get anything older than 1.0.5 on the Beta Program. But you can download them by brute force using the Steam Console. You need to open a browser and then type on the URL "steam://nav/console" . This will open steam with an extra tab, Console, on top right. From there you can type commands: download_depot 220200 220201 7104947787544389563 This is the older manifest (the last big number) available on steamdb - if Steam has something yet older, it's not registered on steamdb but if you manage to find the manifest for it, you can use it to download it (is steam still have it). The command above will download KSP (220200), PC 32bits version (220201), manifest from 13 November 2013 – 19:20:46 UTC that this page says it must be 0.22 (as it was released on Oct/16, and 0.23 was released in Dec/17). https://steamdb.info/depot/220201/manifests/ (for PC 32) https://steamdb.info/depot/220202/manifests/ (for OSX) https://steamdb.info/depot/220203/manifests/ (for linux) https://steamdb.info/depot/220204/manifests/ (for win64) — — POST EDIT — — The command line above was wrong. Thanks to @Nazalassafor the heads up (see below)

Yes I want. So I did it. Yes I found some problems. I fixed them. It is what helps me to find correlations between different problems - or cross dependent ones. I'm not asking about a feature I couldn't managed to implement. I'm talking about a feature I had implemented myself and it's what helping me solve problems on interaction between different Add'Ons for more than a year. It's a field hardened feature. A close and cautious inspection of the KSP.log will reveal that textures and models are not the only things happening. There're exceptions happening too, and some of them can be very interesting while diagnosing problems. No. The log is the source of data. A Report is a consolidation of that data, sometimes cross-referenced, sometimes punctual, tailored to a specific need. The current MM log is a report that cannot be easily used to solve more complex situations. Copying the MM log as a blob in the middle of the log doesn't helps. we need the events being logged when it happens, so we can easily try to find correlations. Having the MM log on a single file is not bad. What's hurting is not having that data on the KSP.log too so more complex reports can be built in a simple and straightforward way. Threading are old news. There's no excuse for not being able to handle them 12 years after the first HT CPU, P4, hit the consumer market. Even mobiles have 4 or 8 cores nowadays, we really need to move on. Another good way to make very clear what Module Manager is doing is prefix each line with "[ModuleManager]" . Check how TweakScale (and everything else I code and/or fork) and see what I mean.

This one. The NOTICE file will credit TweakScaleCompanion-* as my Trade Mark, but you will own the patches as the original Author. I suggest cloning the repo and issuing Pull Requests, once I incept it, so you will have github supporting you in the years to come about the original authorship of the patches. Of course, we need to settle on a licensing terms that make both of us happy - but since parches are not code, it will be easy to find a common ground on the matter!

Wow. Sorry for your loss. I know how it can be hard, my father passed away not too many years ago. It's exactly as I intend to pursue this thing. The prefix "TweakScaleCompanion" I intend to reserve to add'ons I personally curate (not necessarily own), so people knows it's something cared by a paranoid stand-up guy like me that do his best to avoid breaking things and purse bugs as they were vampires and he, the current Van Helsing reincarnation. (it's the reason I asked for co-authorship at that time). Before adding these stunts to CKAN, I need to finish and kick TweakScale 2.4 trough the doors. Our fellow Kerbonaut @Jammer-TD gave a hell of a bashing on the Beta Release, and his reports hinted me that I should change my previous Road Map, pushing the :FOR thingy on TweakScale sooner. I need the next local holidays on Brazil (Carnival) in order to properly release this stunt to the Wild Wide Web. With :FOR properly used by TweakScale, more complex interactions between different Add'Ons are possible and safe, and so I can focus on CKAN . Ideally, TweakScale should suggest/recommend all the Companions, and CKAN would prevent the installation of the Companions that doesn't have all the requirements met (TweakScale and the target Add'On). But since Everybody Borks , the :AFTER and :BEFORE thingies can help us to write more bulletproof patches (and so the need to have :FOR on Wild first). And the recent minimumMass and minimumCost features on KSP 1.9 surely will make our lives a lot easier from now on. This surely lifted a hell of a weight from my shoulders, at least.

I beg to differ. It makes it easier to look for problems on interactions of different modules - as we get a log of something exactly when it happens, and it makes easier to detect when a problem happens always after something "weird". My life would be considerably harder and I would not be able to detect a lot of misbehaviours I had detected if I would be using your way of logging things. I consider this an anti-feature. Something that can be replaced by a report at the end of the loading system, informing the user about any problems it was found. Reports are useful, but we need the source data to make it meaningful when pursuing problems that happens by unholy interactions from add'ons. (Kraken food).

You are right. He didn't made money on that. He makes a lot of money due stunts like that. More or less what Musk did kicking a Tesla into an orbit around the Sun. https://www.whereisroadster.com It's essentially "This is what I do when I'm bored. Now try to figure out what I can do working for you". We don't make money distributing business cards. We distribute business cards to make money!

I think this can be related to this issue, in special my test craft that demonstrates the problem: https://bugs.kerbalspaceprogram.com/issues/24614#change-138874 I make an engine to bounce on the ground, instead of exploding. Perhaps the PQS.radiusmax fix mentioned on the KSP 1.9 could help on this issue?

This guy on the thread below appears to have a similar issue (but I'm guessing). Try to run KSP 1.9 in DX9 mode. If this works, give @pmborg a thanks - I'm just the messenger.

I beg to differ. source: https://en.wikipedia.org/wiki/Atari_2600_homebrew All that matters are the intended target audience. You are not the one defining the hardware constraints of your project - your target audience is.

Flickering can be happening due your rig being beefy enough to render more frames than your monitor is able to take, Check the Main Menu / Settings / Graphics page and mangle a bit with the options on the right panel (specially, V-Sync and Max Frame Rate). Don't try to make reasonable choices - go combinatorial analysis until you solve the problem. Once the problem is solved, you can tweak things to get the graphics you want. Higher frame rates are not necessarily the best experience, and the V-Sync thingy can be both a bless as a plague, it depends highly of the Video Card and the Monitor manufacturers/models you are using. I suggest you start with these ones - but since we can be dealing with a device driver glitch (otherwise Unity 2019 would be working, right?), anything goes. ------- post edit ------- i think you may be interested on this. https://www.techspot.com/amp/news/84005-gamers-ditching-radeon-graphics-cards-over-driver-issues.html ---- post post edit ---- I found this: TL;DR: Give DX9 a try:

I'm running out of ideas. Sorry.

Since I'm very comfortable with the command line, I use this only now and then, but TextWrangler (MacOS) have a very handy feature, customisable filters. It's simply a bash script where TextWrangler pipes it the document's content (or only the current selected text) and then takes the script output into a new document (or replacing the current one, its configurable). Check if NPP has something like this. See, this is the KSP.log from my last test run for KSP 1.9: And this is the custom filter I run when I'm on the mood for a GUI: It has the advantage to forcing you to write REGEX Mambo Jambo only once, if you are more a GUI than a TUI guy. And, of course, there's way more things you can do with this trick:

Open a new thread somewhere else on the Lounge and I will gladly talk about - I think we are starting to derail @Azimech's thread, as this is not about the reasons that could be influencing his decisions. Since I don't know exactly how you intent to handle this subject, I don't know how to name such thread, so I leave it to you.

Aiming the future versus keeping the current userbase satisfied, instead of leaving or locking themselves on older KSP versions (eroding the changes of selling them DLCs). Exactly. It's pointless to have a Cake if you don't intent to eat it. On the other hand, you need to let it go in order toe eat it, as you won't have it anymore. You want to have the Cake? Don't eat it. But if you will not eat it, why have the Cake? Old adage. Useful reading: https://en.wikipedia.org/wiki/You_can't_have_your_cake_and_eat_it . It teaches people that when choices need to be made, you can't avoid the consequences of that choices.

Something came to my mind this afternoon, as I'm specially interested on drag as my designs are also failing (besides not exactly as you describes). Check the Alt-F12/Cheats/Part Clipping in Editor and also the Alt-F12/Physics/Drag settings. Compare them with the values on the KSP that it's working as intended.