Lisias

Had you ever asked why such sites have so many ads, and "some" of them so many "buttons"? Business plan. These guys have bills to pay. The 90's are over. New kids nowadays have to compete with that guys, and they have 20 years of advantage over them. Life is tough. I agree. SpaceDock is much better. But CurseForge is good enough, and good enough is enough for a business plan. And another thing that it's good for business plans is long term support. Unfortunately, the lack of a viable long term business plan talks louder than the technical excellence.

Hummm…. That's explains a lot. On the other hand, makes me confused about the reason some people thinks that, so, Squad should ditch CurseForge in favor of SpaceDock! There's no way a company would trust its name, reputation and incoming on a donation based site run by a "couple guys".

Now that we have a good dozen hours of release, about 1500 downloads and the skies didn't fall (yet) on my head , I think we can go back to the ideas for future development. I find this idea a really good one. In my first career savegame, I borked beautifully due abusing TweakScale. I progressed too fast - I probably should had tried an unmodded game first, but I was hungry for using some of that magnificent mods I was using on sandbox for months (using blimps on career is something that I really recommend!). Such implementation would allow green players (as I was) to use TweakScale on their game without unattended cheating. However… TweakScale would have to proactively handle the Tech Tree itself, as "boolean operations" on Tech Tree requirements are not (to my best acknowledge) implemented on KSP. Since all the metadata would be on the GameDatabase, I don't see difficulties on implementing the code, but I see a lot of friendly fire happening with fellow modders that also handle the TechTree. HideEmptyTechTreeNodes is one those feet would be probably stomped by me. Should TweakScale act before or after HETT? Should I handle both situations, as I don't have control on the order the plugins are executed on Space Center Scene? How about some mods "hijacking" the TechTree unconditionally, forcing the others add-ons to "hijack" it back? How I would insert myself, deterministically, in such chain of "hijecks" in order to prevent a huge Kraken's Poo Storm?

Currently, KSP is the only moddable game I play, so I can't say. But CKAN appears to be the tool for it, no? From my old times of Quake and TeamFortress (1 !!), people were expected to handle command line tools, and Norton Commander and X-Tree were absolutely ubiquitous. Nowadays? People do what people do - we made computers so easy on doing complex things that they became hard on doing simple things. I did a small research about the status quo of the Quake/TF1 scene, and found that TF28 still need to be manually unzipped into your Quake runtime. But from that point, the custom maps are automatically downloaded from the QuakeWorld server. Note, however, that such a scene is frozen in time. There're very few (if any) development there nowadays, what make things easier to cope. Nice trick. Thanks!

Everything and the kitchen's sink. A copy of your running KSP installment would be perfect, as it would be a mirror of the "production line". It's what I do after the SmokeTests (controlled, minimalistic setups). This also make easier to spot subtle errors, as you know how your setup behave, and will note fast if something "became weird". My current concerning is what I call "Unholy nInteractions between add-ons".

Ugh. I just realized something. SpaceDock "headquarters" is on Germany, what makes them directly subjected to the GDPR, and so, also their clients. That thing about Data Processors and Data Controllers would demand that every client of them would need to hire a GDPR Contact on the EU to handle European data requests. When you have direct revenue involved, you can repass the costs to your customers. But with indirect [unsubstantial] revenues?

But what would be the practical effects of this? There're no requirement on the SpaceDock to have a login here, so a hypothetical stunt-man don't have to fear such consequences here from their stunts. SpaceDock has their own, minimalistic EULA, where they make clear that they can remove content at their own discretion. So, the moderators can pesky them to get the content removed by violating forum rules. But should they comply? You, as a content creator, would rely on a site willing to remove your work due rules from a site you are not associated? This sounds like a bad business model for me. CurseForge business model, on the other hand, is to provide curated content using very clear rules approved by their stakeholders (content creators between them). It's a predictable environment, something companies like a lot. And, as a bonus, CurseForge acts preemptively to enforce that very clear set of rules - something that on SpaceDock would be done only after such hypothetical damage* had already been done. * As "damage" understand anything that TTI/Squad consider hurting to KSP image, what's not necessarily the same as you or me consider as such. We, adults, can laugh and like things that are unappropriated for kids, and since Squad do market KSP to kids too, they can consider "damage" something that we would approve in good faith.

On the first page of Curse Forge https://kerbal.curseforge.com/ksp-mods I can see a lot of mods updated in the last hour, in the last few days, and in the last few months. I'm aware that some maintainers are ignoring CurseForge, but not all of them. There's an additional advantage by TTI/Squad sticking on CurseForge. Their content is curated. Every submission of mine need to be reviewed before being published, what prevents KSP having his name associated to undesired content. On SpaceDock, everything goes right to the front page. I think it's unlikely that someone here would do such a stunt as to publish something that would hurt KSP's image, but companies like impossible more than unlikely.

And we need to define what's "better'. And to whom. The SpaceDock's API is excellent, but Curse allows me to fine trim exactly what versions of KSP my mod runs, while SpaceDock only allow me to define one. Right now, there're mods that runs on 1.4.1 to 1.4.4, but not on 1.4.5. And there're others that runs fine on 1.4.5 and on 1.5.1. CurseForge allows me to set this, SpaceDock doesn't.

TweakScale 2.4.0.6 gone Gold. Available on CurseForge, GitHub and SpaceDock. CKAN is Work in Progress. [It's done already.]

Coming back to the Steam issue, the inability to install mods "properly" (whatever this means) is not the only reason one would want to use Mods on a Steam managed game. Steam adds a serious amount of value to their users by the plugins they embed on the Game. There're an online, integrated community available from inside the game - chat included. These guys want this feature and the mods. If we don't provide this to them, sooner or later someone else will. Just like that. There're currently about 810 people reading this forum: 141 MEMBERS, 2 ANONYMOUS, 665 GUESTS (SEE FULL LIST) But there are about 5.000 playing KSP on Steam right now. https://steamcharts.com/app/220200 Now put yourselves on @SQUAD's shoes: where would you bet your money?

Being that the exact reason they rely on CKAN - probably the second most important KSP add-on nowadays. Frankly, this elitist attitude is not the greatest way to keep a Community bounded. Dude, I almost scolded someone in another site due this. And then I was properly scolded by that demi-scold I did. If memory serves, a nasty issue was detected on some big, mainstream game on Steam, and a kind of emergency update had to be forced down into the users. Since they realized that they got away with this stunt, someone thought it was a good idea to do it to everybody else. I think this Kraken's poo hit the turbo-fans int he beginning of this year - I have the remembrance of seeing the option to delay updates available on December or January, I think.

#sigh I forgot to merge a code on the 2.4.0.5. The current new PreRelease is the 2.4.0.6, and the previous one silently ceased to exist.

Anyone here is using TweakableEverything? I would be very grateful if one could help me testing this before going gold!

No, you can't. This is a already known issue on Steam, I think you should update yourself about the issue: https://appuals.com/how-to-disable-steam-auto-updates/ The only way to really prevent an update is to manually edit the AppManifest. But then, you need to edit back when you decide you want the updates. Not really what the majority of the users are going to do - some of them don't want even to copy the game to another folder, how much editing the guts of the Steam, risking a typo on a file that will be hard (for them) to diagnose later. All the other measures are hacks that induce the desired behavior by collateral effects - and that, frankly, are very prone to errors. The best solution would be Steam warning about the new version, and asking you if you are ready to update or if you want to postpone it for some time (a week, a month, whatever). That's a proper behaviour that would directly benefit the Modders.

ANNOUNCE Pre Release 2.4.0.6 available for testing, see OP for links. The NREs appears to be fixed. TweakScale is proved to work fine under the following environments: KSP 1.4.3 (with and without Making History) with TweakScale 2.4.0.5, B9* and Impossible Innovations KSP 1.4.5 (with and without Making History) with TweakScale 2.4.0.5, B9* and Impossible Innovations KSP 1.5.1 (with and without Making History) with TweakScale 2.4.0.5, B9* and Impossible Innovations KSP 1.5.1 is now officially supported - or, at least, didn't capsized on me yet. TweakScale is good to go gold. If everything works fine to the end of the day, Tomorrow morning we will have a Proper Release for TweakScale! Known Issues: An Unholy Interaction between add-ons is currently responsible for B9PartsSwitch borking on TweakScale. This is not on B9's shoulders, everything is working fine on a reduced add-on installment. This is not on TweakScale shoulders neither. Another Unholy Interaction between add-ons (perhaps the same one?) is causing some NREs on TweakScale at initialization on the parts used for Kerbal EVA. This is not on TweakScale shoulders. Everything works fine on a reduced add-on installment. This doesn't cause any collateral effect, so I decided to keep things this way with luck, someone else can help on pinpointing the cause.] NOTE: To the ones still willing to live dangerously and are taking their chances with the Experimental release, please update to the latest PreRelease of KSPe. And backup your savegames!

This will never happens - at least, while KSP is being sold as a product. KSP is a Program, not a Project. There will be never a final edition of KSP by the same reason will be never a final edition of SpaceX's Falcon 9. There will be, however, a last edition. The last one before closing shop - as it happened with the Space Shuttle Program.

I second that. But we need to address @SQUAD's needs first - they are the ones whom need KSP to pay the bills. Releasing early a Beta of the product can compromise some internal demands, as secrecy about some features. P/R is a nightmare, the Product Owner must announce novelties each new public release, it's how Marketing works. Not to mention Intelectual Properties agreements, where some assets can only be distributed after a specific date - but I think this doesn't applies to KSP. Anyway, two weeks is too few. Ideally, there should be a program with weekly deliverables, so modders could make a good use of their Continuous Integration tools in order to discover the problems as soon as possible. But… The real problem here is the distribution network. All of this would be less necessary if users could have control about when to update KSP on their machines - Steam, I'm talking to you. Another thing that could help, and this is over our shoulders, is a more mature Versioning system where KSP 1.4.5 users would not be bothered by updates on mods that works only on 1.5.1 . That alone would make wonders, believe me. A beta program would be wonderful, and I'll be on it if available. But it doesn't fixes some structural problems we have on the distribution network.

Now I see. Don't know of anything that could help you this way, but perhaps I had found the place to ask for it! Such a feature appears to fit this mod:

I'm a dumb-SAS that must learn to keep his big mouth shut. I'm supposed to know better, by the Kraken's sake - I'm the self-proclaimed dinosaur on this industry. Ok. I vent it out. Move on, nothing (else) to see here.

Only two years (2016). The CurseForge goes to KSP 0.24.2 (2014)!

On a second though… Perhaps deleting it is a bad idea (sorry for that, I should had though twice before posting). Locking up the project with a warning to check this page would be a better option, perhaps? There're a good ammount of history there (4 years of releases)

Hi. May I suggest continuing support the CurseForge? (Or perhaps delete the project from there?) CF is a well know source, and people relying on it would be left behind from mainstream!

How I missed that add-on? Great one! And exactly what I was needing. Well, in theory, should be simple: Download the 2.4.0.4 PreRelease on the first post of this thread, download Tantares.zip and TantaresLV.zip, unzip them on the GameData from your KSP, and that's it. The Tantares_TweakScale.cfg is "run" automatically, and patches some parts from Tantares to suppor TweakScale. The parts that the current config patches are the ones between "@PART[" and "]". You can create more patches by copying this file into somewhere else (do not edit the original, not only you loose your "warranty", but you will also loose your changes on updates), and changing the names for the ones you want to add support. Delete everything you do not edit (to avoid double patching), and see what happens. About the Tantares_TweakScale.cfg, I found no obvious problems except that I didn't found some parts on the Tantares zip file. Perhaps name changes? If yes, we need to update it. I checked, and only a few parts are, indeed, patched. The L-K15 Luna Lander Can works fine - besides not increasing the crew capacity. I also found this that can be of use: https://github.com/julienrosa/TantaresRebalanceOverhaul