Lisias

Money talks, "Piece of Paper" walks...

Yep. But, sir, the logs are not for you. The logs are meant for people that will provide support for the Add'Ons. These logs are the reason we can diagnose the problem by just telling the user to send us the logs, instead of going through a tedious and long series of "please try this, please execute these steps, please do that".

Problem is... It's our best tool for diagnosing problems. Messages on the screen are useless, as they don't have enough information (there's no enough screen!) - we usually issue messages on screen to alert about nasty conditions, but pushing on the screen all the messages needed to diagnose the problem is unfeasible. Once a problem happens, diagnosing it is not a mere look on the Exception message - it only tell us what happened, not why , and without the why, there's no possible fix without guessing (what, usually, ends up on finger pointing). So, some logging is needed - otherwise you will not get proper support when things goes badly on this Add'On or even others inducing this one to bork by collateral effect. You may think logs is bad - but it's way worse without them. That said, some logging messages are only meaningful on development (we call these "debugging messages" - and I agree that these ones should be suppressed on releases.

Thrust should be something as logarithmic, but this type of scaling are not available (yet) on TweakScale. That said, I totally encourage specialised sets of customised TweakScale patches for a challenge. You don't want engines being scaled? Get rid of these patches. You wanna different scales for weight, thrust and ISP (fuel consumption), talk to me and let's see what we can do. The same for everything else.

Dawn Patrol (who played it?) on KSP 1.9.1 Somewhat glitchy, but I hope fixable. .

Except that the guy explicitly allowed TweakScale, so it's not a pure stock challenge. So the argument itself is bogus. On your original post, you complained about how unrealistically TweakScale scales parts. Well, I can say for sure: it depends. The scaling is doing using linear, quadratic or cubic exponents depending on how you configure the receipts. From my experiments, engines are tricky to scale because in the real life the trust don't scale on a linear curve as the current configs is set, but instead tends to scale on a logarithm or exponential curve - what's theoretically possible if someone rewrites the patches (the scale is not limited to 2 or 3, you can use rational numbers as 0.123 or 2.444 too!). It only happens that nobody did it to this day. So I agree that scaled jet engines can be shady on a contest. However, it can be very handy for propelled engines used on Firespitter and KAX. Control surfaces and wings behave very well on scaling by the way, this allow you to do some very nice looking crafts. Way more realistic than clipping lots of parts in order to get something near what you indented to do - clipping two wings parts to look as one 50% bigger (150% of the original size) will give you twice the drag and twice the lift, while a scaled part to 150% will give exactly what you intend. And the wheels on the Beta too (to be released soon™), with the sturdiness and strength correctly scaled with the sizing. (and.. by the way.... How realistic is a "space simulator" with green guys poofing around on a planet with a soup as atmosphere and one third the size of the Earth but with the same gravity? Had I missed something? )

Well, this guy took it to the next level!

Just an ordinary song for an Ordinary Man.

Oh, my apologies for that! Exactly. And by being a business, they need revenue. Somehow. I'm on this business too, but not on games (something way less entertaining but equally complicated). And let me tell you, I do some of the stunts these guys are doing, I close business for good - it's not the bugs the problem, but how you cope with them. Every time we bork on the development, people will waste time. No one likes wasting time (worse if you on the paying side of this equation), but most of the time, people are willing to take the hit as long they are helping to get a better solution tomorrow. As soon as people realizes that they are having their time wasted because you choose to save yours instead of trying to make their lives better, they will react - and the aggressiveness of the reaction will be exponentially proportional to the efforts they made in the past to withhold your past borks. Users are your customers, not your subjects - and even subjects had deposed their sovereigns in the past when they got enough. Same here. These freaking little green guys helped me to cope with some really nasty situations. The degree of freedom this game (and the Add'Ons) give us allow people to replicate, in a simulacro, real life challenges and this is therapeutic - it helps on going through that Five Stages of Grief. However... Add up what we just said to what I had said on the previous paragraph, and do the math. Whatever is being done right now on KSP, is not being done with users in mind. Whatever are the objectives aimed by the current development practices, they don't aim the user satisfaction. However, make no mistake, they aim to satisfy someone - we just are not going to like it.

Nope. Just install Recall and the latest TweakScale and you are set.

You will need to check with the All Tweaks Maintainer to be sure. IIRC All Tweak overrides the Default TweakScale patches, but I don't remember what it does when a patch is not supported yet by TweakScale, nor when it became supported later...

One need to be invited to be a guest. Sometimes I think I crashed into this party!

Jan Hammer!

ANNOUNCE TweakScale Companion Program has been kickstarted!

TweakScale Companion is a series of "Add'On's Add'Ons", adding TweakScale /L support for third parties, but decoupling the target Add'On's life cycle from TweakScale's , easing maintenance and distribution efforts. The ÜbetPaket is a mega package including all Companions currently published for the lazy installers. This package is updated sparingly, the Companion's repositories (listed below) will always be updated with the latest versions - and are still the canonical way to have everything up to date. In a Hurry: Current Release: 2024.10.09.0 for KSP >= 1.3 Downloads on GitHub (and KSP-AVC users).. on CurseForge.. on SpaceDock. Announce for the current release. Announce for 2022.05.22 Initial Release. Announce for 2023.03.04 Announce for 2023.03.28 Announce for 2023.03.28.4 Announce for 2023.10.21.0 Announce for 2023.10.21.2 Announce for 2024.02.20.0 Announce for 2024.07.13.0 Currently, the following Companions are available: Current Companions Gold Status TweakScale Companion for AirCrafts Airplane Plus Neist Airline Parts Stock eXTension - SXT TweakScale Companion for Firespitter For (surpringly :P) Firespiter and Firespiter Extended TweakScale Companion Frameworks Test Flight Cryo Tanks Space Dust System Heat Waterfall TweakScale Companion for KIAS KIS KAS (unreleased) TweakScale Companion PKMC Far Future Technologies Near Future Technologies Near Future Aeronautics Near Future Construction Near Future Electric Near Future Exploration Near Future Launch Vehicles Near Future Propulsion Near Future Solar Near Future Space Craft Stock alike Space Station Expansion (Redux and Legacy) TweakScale Companion for ReStockPlus For ReStock[+] Alphas, Betas and Release Candidates TweakScale Companion for OPT Alpha For OPT Classic Legacy Continued TweakScale Companion LivingStyle Beta CxAerospace Station Parts PorkJet's HabPack HabTech (1) HabTech 2 Station Parts Expansion (Classic) Station Parts Expansion Redux Tokamak Industries TweakScale Companion Multipass Beta MechJeb 2 Tarsier Space Technologies TweakScale Companion SpannerMonkey Beta Large Ship Parts pack SM Marine TweakScale Companion for Rockets Beta Arc Aerospace RealEngines And more to come! Licensing Terms Notes * ALPHA means Companions terribly new and unstable, with features that can be added, changed or removed on every release. Don't use on "production" (i.e.,serious gaming). * BETA means Companions nearly feature complete, but not 100% reliable yet. Bugs are expected and will be fixed on demand, but no current features will be changed or removed otherwise. While being possible to use these on "production", you may find bugs on the gaming and the fix of some of them may render your savegame problematic. * Release Candidate (RC) means the last stage before going gold. Only bug fixes are applied (if any), nothing will change otherwise. These releases are supported the same way Stable ones, they just are not widely published yet. * You can follow what I'm doing (or planning to do) on the github issue tracker.

Nope. I didn't managed time to research BG scaling. There's a couple patches for blades on the Beta release, but they worked fine on 1.7, and on 1.8 they misbehave - didn't managed to grab an opportunity to retake this task yet

It's the difference between closing an Issue and implementing a feature: Issue #xxxxx : "implement a cheat allowing the user to arbitrarily reposition a landed craft on the PQS map". Feature : implement a cheat allowing the user to safely move the craft to anyplace on the current planet without exploding the damned thing, by checking for obstacles and objects and preventing spawning the craft inside any existing collider. The Developer did his job properly, the issue was closed. The QA team did their job properly, the issue was implemented as specified. The Product Owner (or whatever they call the guy calling the shots there), on the other hand, failed while writing the requirements and specifing the task.

So it's better to hurry up, or you risk attending his funeral and seeing a Unpaid Day Off deducted from your payment...

Copyrights. Private Division directly manages all the KSP1 Intellectual Properties, from textures to source code. Being directly under Private Division grants them direct access to all KSP1 resources, perhaps to the very source code repository without hassle (as having to secure legally rights to access them). It's more a tactical move than a strategical one. Things will happen faster now, I bet.

Risk Management. Your boss will be paying you integral if you get sick and in quarantine for half a month or more? If not, I think it's time to seriously consider a change in your professional hierarchy - i.e. it's time to fire your boss.

KSP Recall aims to be a "for all" solution for Add'Ons in need to survive KSP glitches. TweakScale is just one of them. What happens is that the Resource problem, in particular, can't be solved unilaterally by each Add'On - it will be a ToeStomping fest, with some Add'Ons overwriting what some others had did due Race Conditions (what, historically, leads to a Finger Pointing Fest - with a lot of harassment happening off records). So, ideally, a Standard way that would work for everybody at once is the preferable solution - but implementing it on TweakScale would force people to install it just for the solution, what's, frankly, an anti-feature. Additionally, this thing must be hassle free and without hard dependencies in order to make it free to be used only when needed. I managed to keep it hassle free to Add'Ons that supports TweakScale using Scale_Redist (got kinda lucky on it); I implemented it in a way that will avoid stomping of the toes of Add'Ons that choose to go their own way (just don't patch Resourceful on these parts) now that this thing is working, I'm will go hunting for incompatibilities to prevent MM of patching such parts Using Events, Add'Ons just don't need to care about dependencies. Just shove an OnPartResourceChanged event on the circuit, if Recall is installed it will do its magic, if it's not installed, nothing happens. So I'm pretty much accomplished that. (assuming we don't find new bugs on the solution in the mean time, obviously! ) Yep. If there's no need to fork the thing, I will not fork it. And if there's a need to fork the thing, I will try an alternative solution in order to avoid the forking. Keeping two "products" to do the same job is counter-productive - you can easily note this by the resistance of some Add'On authors in supporting multiple KSP versions when a change is needed due it. They usually supports the latest version of the Add'On on multiple KSP versions as long the Add'On works unchanged on them, raising the bar when a change is needed. Doing this with TweakScale would be harmful to the users. Maintaining two (or more) different forks of TweakScale due "non functional" differences on KSP is a huge pain in the SAS for me. So i think this (KSP Recall style) is the way to go.

You were wrong. The symmetry was the screaming victim - but you nailed the M.O. I was wrong, I was biased due Issue #3 and ended up doing poisoned tests meant to confirm my bias, instead of detecting the problem. But I was right about not being a problem on the symmetry. "All of those clever reasons were wrong." House, Gregory. @Arcwolf, this will fix your issue too. It's essentially the same problem, but with a different victim. And, yeah, you nailed on the Recall deactivation - I put this trigger there to help diagnosing Recall mishaps. It's not interesting that I forgot to use it??? Oh, well... Release 0.0.2.3 will be issued in half a hour. ----------------------- Announce. We are now in Pre-Release status! I have some confidence that this stunt may (eventually) work fine, after all! KSP Recall 0.0.2.3 Pre-Release is available for the brave Kerbonauts willing to risk their SAS with these stunts. Exercise prudence - this thing is still not properly tested with Fuel Switches. Use S.A.V.E. just in case. Good Luck!

Until this moment, all the glitches I had found had a MH part attached on the craft. No craft using only MH parts had such a glitch - and I tested some of them. So, at least for the subset os tests I'm doing, MH parts are always involved on the mess, while the same craft without MH parts worked well. POST EDIT My testing procedures were biased. The MH parts were always involved on the mess because I was attaching them by last, and so, I was taking them from the Part List, as the Stock ones were already on the craft. The biases tests that followed the incident, so, reinforced my bias as I was testing what I was wanting to see... "We formulate our questions based on the answers we want to hear." House, Gregory. However, I have a problem... I managed to build this thing without having the glitch, and this craft has no MH parts. I had, even, added more parts to it right now, randomly, trying to trigger the problem - but everything is working right no matter I scale things before or after getting them from the Part List and shoving and attaching them... /POST EDIT Cloning is involved for sure - as it the only thingy I'm messing up for now. What I found is that the problem is not on the symmetry itself, but in the presence of a MH part on the craft. Or at least, on the MH parts I randomly choose. When I managed to reproduce your issue, I used stock tanks on the radially attached subtrees, but scaled down an MH tank on the main body. Hummm.... I attached the subtrees on the MH tank. perhaps the problem is not on the symmetry, but on the attachment!!! Users like you is the foundations of this Community , believe me. Add'Ons without users are... "userless". Interesting... I will keep it in mind while I do some more testings before bedtime...