Lisias

And exactly how you intend to make it look good for KSP2? You are praising Juno:New Origins better than I could ever would be able to!!! (I didn't knew they were just 7 devs!!!) Do you have positive feedback from the Juno devs about not going to implement colonies and multiplayer? I fully agree on this one. IMHO, KSP2 should walk away from such game model, and this is the reason I'm advocating for some kind of structural challenge. KSP¹ can be way more challenging than Juno exactly because of these constraints. And for people that want to play without these constraints, there's Juno. Exactly, see my Agena video somewhere in this thread's previous posts. Interesting enough, structural abuse on KSP¹ is "punished" by the wobbling, so yeah.. KSP¹ is way more similar (or less dissimilar) to Real Life™ than Juno. So, if wobbling it set to go, it must be replaced by something else - otherwise we would have… Sugared Juno On A Golden Plate, and not a KSP¹ sucessor.

I agree. There're some on KSP¹, very minimalistic and even naive - but better than nothing. It's the auto-struts. The auto-struts can also be seen as a tool for structural reinforcement. My problem with it is it being dirty cheap - using auto-struts should tax the user both on Funds and Weight on every part affected by it. Using your ISS example (that bends 2 to 3 millimetres each 100 meters), you can bet your Slide Rule it costed NASA a lot of money in reinforcements, that by their turn taxed the whole structure with mass. But still better than nothing! Where I'm saying it does? I'm pinpointing how ridiculous would be a 220 meters, 7.5 meters wide rocket standing on the launchpad to be considered "realistic", as the people advocating for the plain removal of the wobble are telling. But since we are here, let's put your claims on check: So you have a point, but it's (frankly) irrelevant to this discussion because it didn't impeded me from doing something more or less similar from what we would do on real life: reinforcing the structures. In a way or another, my argument stands: KSP¹ behave way more similar (or less dissimilar) to Real Life™ than Juno:New Origins, the model that some people is willing to see KSP2 taking. My complain about the AutoStruts being dirty cheap, however, still holds - reinforcing the MK0 parts should had taxed me on Funds and Mass. Perhaps, but so what would be the difference between KSP2 and Juno:New Origins? Real differences, not the sugar coating that rich game publishers use to make up simple, lousily designed dumbed down games. — — — — It essentially boils down to what kind of game we want: a KSP¹ sucessor, with the building challenges improved; or a glorified, sugar coated, gold plated (and way more expensive and buggier) Juno:New Origins clone. (that Lego versus Modelling Dough paradigm I had talked about). On a side note, Juno:New Origins is already on the market, it's cheaper, it's fun enough and it runs perfectly fine on my current rig (not to mention being way better reviewed on Steam - they just released an update with propelled craft, by the way!!!). If KSP2 is going to be a Juno rip off, why bother buying it and still wait months and months until be able to play it?

And that's the difference between a "Modelling Dough" model from a "Lego" one. You need to respect the bricks limitations, otherwise where would be the challenge? On KSP2, for sure! I find hard to believe that people really want to dumb down the game to the point in which a 7.5M wide, 220M tall rocket being able to even take off is… "realistic". That damned thing would not even manage to get on its feet on real life, what to say take off????? Where is the "STEM promoting" thing of the game?

ANNOUNCE Release 2.4.7.2 is available for downloading, with the following changes: A new Feature was introduced that automatically deactivates the Auto Scale and the Chain Scale features every time the user enters the Editor, creates a new Craft or loads one. Aims to minimize support tickets opened by users that forget the features active and then thinks it's a bug on TweakScale Default is On, can be turned off on the TweakScale Settings dialog. Updates KNOWN ISSUES with workarounds for the following Work In Progress bugs: #297 #283 Updates MMWD to 1.1.1.1 Now and then an User opens a Support Ticket about an issue on TweakScale that, in essence, it was the Auto Scale or the Chain Scale forgotten active. Since this is happening with some frequency, I decided to code this Feature. Now, every time the user enters the Editor (VAB or SPH), or clicks on the "New" button, or loads a craft, all the TweakScale features are reset to disabled - unless the user unchecks the respective option. This dialog, as usual, is available by clicking on the TweakScale's button on the Toolbar: When scaling is available, and no features are enabled. When scaling is available, and at least one feature is enabled When there's no TweakScale support for the last part you selected (or opened the PAW). Know Issues https://github.com/TweakScale/TweakScale/issues/297 Under a certain, more or less convoluted, sequence of movements on a Part, TweakScale starts to misbehave the placements of cloned parts of such convolutely edited part. It's a pain in the SAS when it happens, but the work around is simple enough: instead of Alt+Click the displaced part, take a new one from the Part's Palette. I intend to fix this (it's a bug on TweakScale for sure), but I will priorize some TweskScale Companions first. https://github.com/TweakScale/TweakScale/issues/283 This one is a crappy one. When scaling parts with resources under symmetry, only the "original" part gets its resources scaled correctly, the cloned ones get the prefab values. This is unrelated to the previous one, by the way - the reason this is happening is completely different, I checked it. However, by saving and loading back the craft, or by launching it from the Editor, the values are "fixed" - this strongly suggests that TweakScale is doing its job right on this one, and since this started to happen only on KSP 1.11.x (I tested only 1.11.2 and 1.12.5), the matter is settled. HOWEVER The freaking bug vanished while I was Smoke Testing this release. Kraken knows why, I'm currently clueless about the reason the problem is "fixed" I don't even know how and why, but I had updated some other add'ons that were smoked tested together. Anyway… Let's see what happens on the field.. Your Attention Please Due a major screw up of mine (hate you, Windows!!), you will need to manually remove the following files before updating - unless you install things manually, when you will overwrite them anyway! <KSP_ROOT>/GameData/666_ModuleManagerWatchDog.dll Disclaimer By last, but not the least... This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Right Now. SpaceDock. Right Now.

ANNOUNCE KSP Recall 0.4.0.2 on the Wild, featuring: Implements a missing use case from TweakScale, OnPartAttachmentNodesChanged. Updates MMWD to 1.1.1.1 Your Attention Please Due a major screw up of mine (hate you, Windows!!), you will need to manually remove the following files before updating - unless you install things manually, when you will overwrite them anyway! <KSP_ROOT>/GameData/666_ModuleManagerWatchDog.dll — — — — — 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. Soon™.

Fantastic! Source:

This is a NOTAM about a NOTAM About the problem reported by @AccidentalDisassembly here, I just found that if you keep the scaling parts' PAWs opened (clicking on the pin), then all parts scales all right! I'm guessing we have yet another new race condition on the Editor (between the numerous ones) (from KSP 1.11.x and forward), and the PAWs being active probably injects some delays somewhere and then the Kraken damned screwing code from Editor "loses" the sweet spot and don't screw up TweakScale anymore - as a matter of fact, it's possible the thing is screwing with KSP-Recall, undoing whatever TweakScale was did on the cloned parts. Saving and loading the craft "fixes" the problem. Launching directly from VAB ends up with a valid craft on the launch pad - at least using Stock parts. https://github.com/TweakScale/TweakScale/issues/283 Still working on it. Additionally, I think I diagnosed the problem also reported by @Krazy1 here, and formalised on https://github.com/TweakScale/TweakScale/issues/297 . When you clone a Part, the attPos is not "refreshed" from the prefab, but used as is. This affects the calculation of the attPos0, but TweakScale uses the prefab as reference to rescale things. The difference between the cloned attPos and the respective prefab appears to explain the end result. Still working on it².

Please send me your KSP.log. Without it I'm on the dark! Wait! Did you have the "Enable Auto Scale" option active, link on this image? If yes, we found the "problem": deactivate it and I think you will be fine! If you have the problem even with all the options above UNCHECKED (ie., deactivated), then we have a problem. Send me your KSP.log and I will inspect it!

TweakScale scales everything - including the bugs!!

Yes. It's not a good idea shoving experimental/unofficial forks of something that CKAN handles. Speaking frankly, CKAN is already prone to borkage on updates if you do everything by (their) book, replacing CKAN managed packages with "alien" ones is a certain path to disaster, unless you really know what you are doing - but, then, you would be probably handling your GameData without CKAN...

Uh… Seriously?

Did you set up the GameData directory when you installed the plugin? There's a list of manual configurations you need to do before being able import a mu file.

The Welding tool was only really tested with parts without VARIANTS (that thingy on KSP that allows you to switch features on a part), and most of the parts on KSP 1.12 have this thing (if you can change color, size, etc, the part has that VARIANT thingy). That said, the thing will run at least - it will weld such parts pretty badly, but it will run - at least, it's running on my 1.12.5 test bed right now, I just welded two trusses. But, since the tool doesn't works to every part on KSP 1.12 (and since I'm just keeping the thing alive, without any development), this thing will not be available on CKAN - unless someone else decides to proper maintain the thing (what I'm not doing). What you are telling me suggests that there's something on your GameData triggering the infamous Assembly Loader/Resolver bug on KSP - it's a bug that prevents anything that loads a DLL or use a thingy called Reflection from working once someone triggers it, and this affects a lot of add'ons. I suggest you to publish your KSP.log on dropbox or something and then post the link here. I will inspect your KSP.log and will diagnose the problem on your rig, In time, since my unofficial fork of UbioWeld needs my fork of MM, you should not use CKAN on this instalment. If you are using CKAN, you should follow CKAN rules, and the MM published on CKAN doesn't works with Ubioweld (the original, neither my unofficial fork). My advise is to maintain a secondary KSP installation for Ubioweld, its dependencies and the things you want to weld, and then copy the welded parts into your CKAN managed installation for playing.

Turbonique: a creaping turbo engine attached to the differential of an automobile, fuelled by propyl nitrate:

I didn't gone trough the current KSP2 documentation yet both by practical reasons (I can't even run KSP2 yet) as legal (on my Country's Legislation, the Fruit of the Poisoned Tree Doctrine applies to IP and, so, if by any reason such material would be considered non legit, I could not be able to ever mod KSP2 without risking legal issues on my country - I want to emphasise it again, my country, not yours). But I can openly criticise KSP¹'s API because it was willingly published by the IP owners. There're a huge amount of undocumented artefacts on it, and there're very few ones really explaining why and where such calls can be made. By trial and error, I determined that a vessel's life cycle being destroyed can overlap with another one being created (i.e., some parts of the older are only destroyed after the new vessel's parts start to be created). This is by design or it's an accident? I'm calling the ShipConstruct's methods on the wrong place? Or in the right place but on the wrong time? This is very important because parts can change IDs under certain circunstances, and if such ID changing happens with the new vessel being created while I'm destroying an older version, I can't track the parts' life cycle and some very interesting features can' be safely implemented (and this potentially affects more than one add'on, by the way). Right now the only way to check things is to publish the damned thing into the wild and hope it will not break anything on the user's machine - at least, without relying on… Hummm… you got it. Another example happened with KJR/Next in the past. When Serenity was published, the new robotics parts utterly broke KJR/Next besides it using the (apparently) correct API calls to do the job. The older API calls were deprecated? If not, why new ones were created? It was a oversight from Squad, or that API used by KJR/Next was never meant to be used at first place? Another thing in need to be documented is the Upgrade Pipeline. This thing gave me YEARS of headaches until I finally got a grasp on it. How to use it? How I can write my own Upgrade Pipeline for my addons so I can migrate versions without royally screwing the user's savegames? How to prevent it from screwing my Add'Ons with improper "upgrades"? [edit:another one] Why the following logspam is happening: [LOG 00:02:31.256] [PartSet]: Failed to add Resource 1566956177 to Simulation PartSet:60079 as corresponding Part Mk0 Liquid Fuel Fuselage-4274492751 SimulationResource was not found. when I use this.part.Resources.Add(…), but things apparently work fine by using this.part.Resources.dict.Add(…) ? It's really safer to use the later? I'm obviously bypassing something! Or even: what in hell is the MonkeyPatching? This thing royally screwed me last year, and the damned thing came and gone out of the blue - and now I'm unsure what and how I can publish anything new, because I don't know if I'm going to be bitten by this crap again. And so it goes. At last, but not at least: please understand that I'm not doubting your (you and the others) intentions, I would not be wasting my time here if I had any reason to doubt your intentions. But I ask from you the same consideration - I may be wrong sometimes, but I'm never malicious on my postings: I'm not trying to undo anyone or anything.

If the IP owner didn't published it themselves, you had to somehow extract the information from an artefact that was given to you with the information embedded. Extracting such information from such artefacts can be considered Piracy on this Forum. That said, I will not touch this issue again. I already had enough about this subject and I can't further comment about the subject without breaking yet another Forum rule, subjecting myself to be moderated again.

He's still the Game Designer, no? I'm not, Forum is. I got moderated in the past for posting something pretty near what you just posted!

And that's the problem, please check the Forum's Publishing Guidelines. And no, the KSP¹ Documentation is lacking, and it's not a model to be followed. What we are asking for is the fulfilment of a promise made by the Game Designer 3 years ago: proper documentation, and not more relying on shady practices considered Piracy by this Forum. And I could not disagree more with you. Whoever is maintaining this pivotal piece of Software, should be someone committed to the Franchise and willing to accept criticism and act accordingly. MM had many flaws, but it wasn't any of them that played havoc around here - it was the cavalier attitude from the maintainers on handling not only the constructive criticism, but on badly diagnosing key issues on the environment that ended up promoting spreading of false information that at best, made people wasting time and at worse, wrongly pinpointed innocent Add'Ons from causing trouble. This kind of abuse should not be allowed to happen again, and having it handled First Party is the best way of accomplishing that.

Hi! It's the LShipPartsRequired/LBP_tweakableComplete.cfg file. Unfortunately, these patches didn't aged very well, and this one in particular was impossible to fix "the proper way". Download this file: https://raw.githubusercontent.com/TweakScale/Companion_SMCE/master/GameData/LShipPartsRequired/LBP_tweakableComplete.cfg And replace the <KSP_ROOT>/GameData/LShipPartsRequired/LBP_tweakableComplete.cfg with it. This will fix things for you. Cheers!

And not only that, they made the thing extremely friendly to newbies. Notepad and PaintBrush, is all what you really needed to toy around in your first custom part set (reusing current meshes, of course). With a bit of 3d modelling using practically any format ever published under the Sun (they supported Collada!!) and you are in the selected group of innovative part sets. They really gone the extra mile to lure people of all ages and backgrounds into modding KSP¹. Addionaly, for each new modder that published something, you have about 20 (rhetorical number, I pulled it from my… hat..) that did the same for themselves at home but didn't bored to publish their changes. The ones that published things are just the tip of the iceberg, they wouldn't be afloat without the rest of the iceberg under the water. A bad standard is better than no standard at all. We didn't did what we did because of the MM's many flaws, we did besides them. We did that because MM made it very easy to anyone to do that. We had problems with it? A lot, newbies can really screw up things sometimes. But every single one of us was a newbie screwing things once, it's part of the growing pains. We get rid of the growing pains, we lose growing itself.

None of them have NASA, ESA and SpaceX engineers using and probably modding the game - even at work. KSP¹ is not an ordinary game. You are not modding just for kids, still unable to tell good from evil - not to mention nuances on the different copyrights laws around the World. You are also modding for full grown adults, professionals on many different areas, including aerospace engineers - and these guys have a very low tolerance to push overs and unethical practices in general. You want their help? You need to cope with their needs. However, I'm assuming KSP2 is taking the same route KSP¹ took, but perhaps I'm wrong? If KSP2 is going to be just another one of these recent games "following that pattern" focused on kids and mainstream gaming, then definitively KSP2 is not for me neither for such people. And, then, you are right and don't need to hear our pledges, as we are not going to play KSP2 anyway.

No. It's a set of documentation provided by people that wrote the code, knew the requirements the code aimed to fulfil and understand why things were coded that way. In a moment of conflict or confusion, these guys are the ones that are in a position to take a decision that is going to stick on the long run. Downplaying the reason the KSP1 modders are pledging for an sanctioned documentation is not exactly the best way to conquer their hearts…

I know it as RATO (Rocket Assisted Take Off). And it was used more than once by the Military!!!

Because we don't do all the work by ourselves. We need help on tests and feedback on features, and we don't get that if people don't play our toys. Modding is not all fun, there're some serious efforts on debugging when things go South and we don't know why. The more people are helping you on the task, more time you have to implement new and fun things. Modding alone is essentially doing Q/A all the time - All work and no play makes Jack a dull boy. I didn't said they are harming KSP2's modding (besides I'm considering it now). I said they are reproducing the problems that harmed KSP1's modding in the past. For starters, the cavalier attitude about what we are asking and the praising of tools that are not solving our problems as a solution for our problems because such tools are solving their problems. Or, in fewer words, which ones of my list of concerns such tools are going to fix so I can be lured into modding KSP2? You can't push your weight on people doing Pro Bono work: you give them what they need, or they will leave - what's exactly what happened in the past, and I'm afraid is what may be happening now. One of the main reasons we had only one bad option is the bad behaviour of the maintainers of the thing, pushing away people that were trying to make the thing better by criticising what it was doing wrong. Another one was the impossibly of offering an alternative by non technical reasons.

An ongoing discussion about the matter is happening here: https://forum.kerbalspaceprogram.com/topic/217495-what-is-keeping-you-from-starting-your-ksp2-mod/