Alt-F4 #18 - The Road to Clusterio 2.0

Post all other topics which do not belong to any other category.
Post Reply
AlternativeFFFF
Inserter
Inserter
Posts: 27
Joined: Fri Aug 28, 2020 12:07 pm
Contact:

Alt-F4 #18 - The Road to Clusterio 2.0

Post by AlternativeFFFF »

As the year draws to a close, we picked two mod-related topics for this week’s 18th issue of Alt-F4. First, Hornwitser gives us some insight into the long development progress of Clusterio 2.0 and the challenges that it poses. Then, DedlySpyder talks about their process of developing a simple mod and the compatibility challenges they face.

Continue reading: https://alt-f4.blog/ALTF4-18/

Amarula
Filter Inserter
Filter Inserter
Posts: 363
Joined: Fri Apr 27, 2018 1:29 pm
Contact:

Re: Alt-F4 #18 - The Road to Clusterio 2.0

Post by Amarula »

I enjoyed both articles very much - they both provide the 'here take a little peak behind the scenes' vibe from the best FFFs. Thank you to everyone who has contributed to Alt-F4 this year; wishing you all the best with lots more Factorio in the new year!
Luck is not a robust control.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 4868
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Alt-F4 #18 - The Road to Clusterio 2.0

Post by eradicator »

Mini rant incoming. Sorry couldn't resist ;).

I think the factorio mod cosmos has a problem with the abuse of the word "compatibility". I'll try to explain in reverse: "Incompatible" means that two mods can not be used together no matter what. I.e. if they try to change the same recipe. Incompatible mods will either outright crash or have uncraftable items or missing technology etc. Under that definition "compatible" simply means that two mods can be used side-by-side without crashing. And each mod works as the author intended within it's own scope. For example if @DedlySpyer had made a mod that rotates only vanilla equipment it would still have been "compatible" with any other mod. It just wouldn't have been able to rotate their equipment too.

But what most users expect when they read "compatible" is actually what i shall call "interoperable". They expect a mod to also apply it's features to any other mods that are installed, even if those others didn't even exist when the original mod was made. For example two mods both adding "gold ore" would be compatible even if the player ends up having to use two different items both called "gold". But for the two mods to become interoperable - i.e. for them both to use the same "gold" item - either of them or both will have to change their balancing to accomodate for the fact that gold *can* come from a completely different source now if another mod is installed.

The problem with the abuse of the word "compatible" is that it raises way too high expectations. Making a mod interoperable is ten times more work than just making it compatible. And in some cases it can't even be automated, severely compromises the balancing or is straight out technically impossilbe.

TL;DR: The next time you - dear reader - feel the urge to tell a mod author that their mod isn't "compatible" with some-random-other-mod-the-author-doesn't-even-know... try to be nice. Think of it as a feature request, not a bug report.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

Post Reply

Return to “General discussion”