Lisias

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/

And that's the whole point! There will be no user experience without modders writting code and assets to create such experience. Modding is a hobby, not a job. If you want paramount quality on something, pay for it: hire the guys and pay a proper fare. You can't push your weight on people doing Pro Bono work. No. We have reasons to avoid modding KSP2 because the people that are paving the way for it are behaving very similarly to the people that screwed the Scene at that times. You were being criticised, not attacked. We were being asked about the reasons we would be avoiding modding KSP, and some of us had answered the call.

What suggests that things are being made to make programers' life easier at the expenses of the modders. Well, we had reasons to avoid modding KSP2 as it appears. And we still have. I'm afraid you can't tell cause from consequence. MM had flaws, no doubt, but it was not the flaws that played havoc on the Scene. You are reducing the problem as a technical one, ignoring the fact that the technical problems were the logical consequence of something else. I may be wrong though. I hope I am. Time will tell, but I'm afraid this is something that it's already being told. We will need to wait and see what happens from now. And this is the root of all evils - no documentation. It was what played havoc around here in the past, and apparently this is not going to change!

With all due respect, I disagree. Letting a pivotal feature be handled by 3rd parties puts them in a weak spot in the long run. In 2016 a serious drama happened around here, made worst by MM being withdrawn from CKAN and playing havoc on the users' installations that relied on it. Not to mention everything and the Kitchen's sink embedding differeent versions of MM in the distribution packages, and so a Windows graded DLL hell infected the scene, with older MM being inadvertently injected on the GameData - and Kraken knows how may man/months I spent diagnosing and fixing user's installations due the breakage (made worst by the inifinite number of bugs on KSP itself). From the strategic point of view, I.G. is going to commit the same mistakes Squad did on this matter. I'm a absolutely sure you guys are intending to do better, but earning trust of the OG's is going to be an uphill battle: once bitten, twice shy...

They are risking the whole scene going South - MM, besides all its flaws (and there're many) works as an effective arbitrator to inject/remove new features on existing parts, or even creating new ones using the existent as templates. Having many different noses sniffing programatically the GameDatabase is going to be a hell of a headache in the instant new people start to get into the Modding Scene. They lost a huge opportunity here, a critical one IMHO.

I'm a huge fan of Cirque du Soleil, to the point to collect the DVDs on the good times. All the shows are magnificent, but IMHO the best OST of all of them is Alegría - by a mile!

Support for Real Fuels is not done yet, it will be available when I finish the respective TweakScale Companion. I don't have the slightest idea about the reason RF and TweakScale worked 12 months ago, and I didn't changed anything related to it in the mean time. Whatever it happened, happened by a 3rd party (perhaps a change on RF that I didn't detected, perhaps a 4th party interfering somehow). In a way or another, this will be implemented on the next TweakScale Companion release, so there's no need to keep such diagnosing from your part. Humm… Since we are here, there will be a catch… The TSCoFuel will probably only work with the next TweakScale 2.5 release - I will not further develop the current 2.4 for obvious reasons, but I will keep 2.4 available for some months in parallel in case someone can't use 2.5 for a reason or another (and then I check that reason and fix it on the 2.5).

Humm… Weird… Let me see what can had gone South from my side... (hack, hack, slice and hack again) Nope, I didn't changed anything from my side, and did a superficial peek on RealFuels and I think they didn't neither. Do you have some other Fuel Switch installed? Things usually go South pretty badly when more than one Fuel Switch is installed on a part (as B9PS and FSFuelSwitch), and TweakScale withdraws itself from these parts to prevent a major borkage...

ANNOUNCE Release 4.2.1.0 is available for downloading, with the following changes: New Action to turn on whatever is the current mode at the moment The Toggle Action was correctly labeled (and localized) Less confusion on Editor when configuring Actions Enhanced API to make easier 3rd parties interactions The different modes toggles now really toggles the Light no matter what is the current mode. I finally got some time for really playing KSP again, instead of squandering my free time on diagnosing problems, and then I realised that some small details on Aviation Lights could be slightly improved. So I did it. Downloads on the OP. This Release will be published using the following Schedule: GitHub, reaching first manual installers and users of KSP-AVC. Right now. CurseForge. Whoopsie™. SpaceDock. Whoopsie™. The reasoning is to gradually distribute a potentially Support Fest release in a way that would me allow to provide proper support if anything else goes wrong.

Commercial use are, well, "tolerated" - we would not have parodies otherwise (like Star Wars vs Spaceballs). But, it also bring liabilities to you - Ok, you can try to exploit it commercially, but if you lose a Fair Use claim on a Court, you will pay some damages based on the money you earned on the stunt. Unless you are willing to make a living from this thing (and, so, will have a budget with money reserved for legalities), I suggest you to avoid commercially exploiting anything you do under the Fair Use. And this includes Patreon and "Donations" - without filing a Section 501(c)(3), you need to even pay taxes over these "Donations". Only Non Profit Organisations can receive Donations, for everybody else the name is "Funding".