Lisias

Unfortunate only when something borks. When the stunt works, everybody's happy. Including me. Being paid or not, TweakScale is a service that affects thousands of users. I break something, my skin gets thicker and my ears, hotter. And a lot of people, their games potentially ruined. Yeah, doing it for free waves any legal and financial responsibilities, but there's the moral one: what would be the point on investing my free time on something that ruin people's games? It would be better to spend my time watching soap-operas. I like to say that Open Source is like that Stone Soup history. In order to everybody get a nice soup, the more people contributing, the better. As long no dud SAS shoves bad tomatoes neither rotten onions on it! You don't have to give your best ingredients, but it's not nice giving bad ones. You will eat the soup too!

Yes, it's exactly this. I like the term "Arbitrator" more than "Coordinator", as this feature needs to be somewhat authoritative on the decision making, but it's it. Even by not allowing re-patching (and I never considered this before, this good idea is your fault!! ), such arbitration appears to be better implemented on Module Manager due it's inherent nature of handling the GameDatabase. Third parties being able to recompiling parts via part loader would be one of the features under the authority of such Arbitrator - the problem to be solved is to allow access to GameDatabase under Critical Sections to prevent the Add'Ons triggering a Toe Stomping Fest. Locking up the whole GameDatabase would be highly inefficient as it would serialize processes that could be executed concurrently, but it's a quick & dirty way to solve the problem for a POC (Proof of Concept).

This is more of a problem to parts, not to Add'ons by themselves. Part Packs that reuse stock textures are way less prone to that than ones with new and detailed textures. People usually goes to eye candiness, however, and then loading times goes through the roof.

All the official links are down. I'm sorry - I'm a user of the Maritime Pack. There're no forum compliant way to download it as far as I am aware. I hope to be wrong about, however.

Additionally, are you running on a Intel? My Mac is running sensibly slower with all that security updates due Intel's messed ups on the CPUs (Spectre et all) since January this year. I fired up KSP 1.4 again one of these days, and had to lower the texture settings a bit to get the thing playable as I remember it (com 2x to 4x). It could be any other thing too, MacOS is suffering from Bit Rotting since some time now. But yet, it worth to mention it.

Use more than one KAL, and attach them to the same Action. It's what I'm doing - I control the left and right legs of a craft on dedicated KALs.

Agreed. I just don't wanna do it myself as I'm the Maintainer, and things I do it's expected to be canon - people expects that new releases do add features, no break them, mainly people from CKAN that do unattended updates. I even only publish debug and testing releases on a Issue for them, and not on a release on Github exactly to prevent people thinking that the thing is good for use (already happened!). What's made me remind, @GennPen, the patches can be anywhere on GameData if you add :NEEDS[TweakScale] after the PART. As a suggestion I add my personal patches on a folder called GameData/__LOCAL/<addon_name> as this keep my changes from being deleted or overwritten by updates, and this weird naming scheme assures that by default these patches are applied by last. Also easy to make backups for you personal stuff.

Logico que vai. Sò não sabemos quando! Faz umas 6 ou 7 semanas que o trampo pegou pesado, e fiquei sem tempo pra brincar.

I wanna give my two cents here: Choose carefully the Add'Ons you get attached to. Check the License terms, and see if they guarantee you the right to download and use old versions - as well the right to you (or someone else) to fork the thing, fix it and republish it. I completely understand the reasons from some Authors to do not allow it, but I also understand that users get emotionally attached to their creations - and some compromise need to be reached. The License is that compromise. Yeah. You push things, they push you back. However, it's also how we move forward. But, hey… Things are improving! Most Authors are not professionals. But it's part of the fun, IMHO. I see a lot of potential on a lot of that "early access Add'Ons" - and if the licensing terms are satisfying , you can contribute back if you want. In the end, it's about the Stone Soup.The "Soup" will gets better (even that somewhat messy) by having more people contributing. But it's OK not liking Soup. It's all about choice, and not willing something is one of that choices. Cheap, Fast, Good - pick two. You will always have to expend something, money, time, whatever, in order to get something you want. You would be surprise by the money you would have to spend if the best Add'Ons around would be for sale! About the replacement, choose your Add'Ons using the Licensing terms as criteria. This will help on the long run. It's part of the development cycle - and one of the reasons that the best Add'Ons are the ones which people help to develop and test. Remember that Stone Soup thing? Yeah, testing and suggesting are contributions too. Like salt and pepper to the Soup. You can't have the cake and eat it too. Things take time to be figured out. And with people doing this on their sparing time, it's pretty understandable that things goes this way. Again, you can contribute to get these time shrunk. The most the people contribute testing and figuring out things, the less time Authors have to spend their own time on it, allowing them to focus on get things done on their side. Stone Soup.

Thanks for the tip. Scaling forces will be somewhat tricky. These parts changes weight to reflect the torque of the electrical motors, and I want to understand how this works before publishing a canonical set of patches - I don't know how the KSP guts will behave by changing some things on parts. For example, I learnt that scaling up the Crew Capacity blews something on the GUI (but the part works! It's the GUI that borks) rendering the game unusable. From UbioWelding, I learnt that ModulePartVariants are safe to mangle - but they can ruin the visuals if not done right. (I got some funny results). Once I publish something, it's almost impossible to change mind without breaking savegames. So expect a lot of betas until this reaches the main distribution.

Had you ever ceased to be one? Congrats! I never did! But you can turn off the "Torque" of the cockpit. Cockpits have a embedded reaction wheel, and by turning it off the craft relies only to friction (ground) and control surfaces to change attitude. (even with the SAS on)

Turning off the reaction wheels, perhaps? — — — POST EDIT — — — It's something related to the breaks!

Old tricks, new dogs.

Yeah. I think I finally realized the reason things changed that way - to allow Wheels to be moveable!! So they delete all struts, move the parts, and reapply them before the frame kicks in the physics. Or something like that. What needs to be done is a way to convince this new engine to do three things: Expand the parts to be handled to include third-parties modules (as KSPWheels) Allow a way to black-list some parts from the default behaviour instead Create a way to communicate the parts that they were re-autostrutted, so parts on the item 2 can do it's own magic (KJRn)

It's not how we do things in Real Life (tm). RTGs are only used at last resource due its price and risk of contamination when the rocket decides to go to Unexpected Instantaneous Disassembly Events, usually following a Lithobreaking On The Wrong Celestial Body scenarios (usually somewhere near the Launchpad). It's cheaper to add some batteries and charge them on daylights and do the science with the sparing energy - unless you are way far from the Sun.

How much memory? Both video and main.

A MM patch would work too, no?

Use MM3 for now. "Stock" MM4 is changing some things, and it's better to work this for good once the changes are finished. Check the dependencies. Also check for ADDON BINDER errors while loading DLLs. A bug on Mono screws up an important thing used to locate code, and this bug is triggered when a DLL fails to be loaded for any reason.

It's not from today (well, technically, it is - the video got ready after midnight! ). This is my first attempt on Breaking Ground. Since I had previous experience with Infernal Robotics, my learning curve was somewhat fast. And let me tell you, dudes… The KAL-1000 alone worths the whole DLC price. For a mile!

Or perhaps they will do something when you fix it on IR/Next !!

Well… The Robotic parts are OK, but as a Infernal Robotics user, it's not out of this World. Except by the KAL-1000. Dude, this worth the DLC by itself for a mile. This is my first experiment on it. Can't wait to have IR supporting KAL-1000! -- -- I will eat my words on that. There's another thing that makes the robotics parts VERY interesting. Suspensions. I completely overlooked that. This adds yet another dimension to the possibilities.

In it's final state - but the idea of being able to apply patches instead can be useful in the long run. However, baby-steps - we don't need to build up Rome in a single shot. What I need on the short run, in a nutshell: A standard method to inject new parts into the GameDatabase without stomping on other people's toes. Handling concurrency, i.e., as more than one can try the stunt at the same time, this mechanism runs the calls in a Critical Region A standard method, probably similar, to edit an existent part on the same requirements (Critical Region, etc) A Reflection safe way to allow Add'Ons to check/instantiate the feature, to overcome that nasty Mono's runtime bug. A strong recommendation to every Add'On author to use that methods, so we can inject/edit/create nodes on the GameDatabase at runtime without wasting scarce resources (as my hair) in the process. I think we can reach these requirements on this way: // Names and symbols as example only - no naming suggestions are intended on what follows using mmgdbu = ModuleManager.GameDatabaseUtils; void function foobar() { List<ConfigNode> nodes_to_add = this.create_a_lot_of_nodes(); using (ConfigNode node = mmgdbu.Find(<some criteria>) // This locks the thread if the MUTEX cannot be acquired now { // Node and everything inside (including other sub nodes) is now locked on MM. node.change("datum", new_value); ConfigNode foo = node.get("BAR"); foo.add("lisias", "was here!"); foo.add("moar_nodes", nodes_to_add); } // The lock is lifted. Any other thread will be able to acquired that node (or its sons) now. } ScanSAT, KIS, KAS, TweakScale and everybody else would need to acquired a lock before finishing their business on the GameDatabase - what will ensure integrity as everybody tries to do that at the same time on startup. This will probably be useful for VAB/SPH editing extensions too on the long run. Some extensions does some computations on the background, and if anyone else changes that same ConfigNode, we can have a crash on the same way TweakScale was getting on Startup in the past.

Changing the behaviour of the autostruts. I'm a player since 1.4.0, about a year and a half - and I would not break autostrut this way - I spent a lot of time experimenting with the different types of auostrut to know that changing the behaviour this way would break heavier things. I didn't even considered the hypothesis, so way out of the line it would be to me to do that. I would add a new autostrut mod : "non symmetric grandparent" or something. I think I know why they did it. If you use GrandParent autostrut over a robotic part, you weld the moving part. But that I fixed by not using autostrut to parent on the parts connected to the roboti part! And yes, this is something that Infernal Robotics users should be aware for some time now. Autostruting to root would do the same, by the way.

Sometimes I think the developers should spend more time playing the game than trying to fix things. That would allow them to get the feeling to minimize breaking things to be fixed at first place. Eat your own dogfood.

Howling Mad Murdock, so this is where you are hiding all the time?