BlueManedHawk

⚗︎

/blu.mɛin.dʰak/

shortens to "Hawk"

he/him/his/himself/Mr.

my wobsite

— BlueManedHawk

joined
ago

recent posts

BlueManedHawk #3965

BLOG

BlueManedHawk #3960

LONG

BlueManedHawk #3912

It sure is long.

BlueManedHawk #3906

uh oh

BlueManedHawk (edited ) #3901

Bmh is known for occasionally doing that (making up his own definition)

No i don't. Often it's just a misinterpretation of the real most common definition.

BlueManedHawk #3898

…at the expense of taking far more time for those capabilities to come to fruition.

what?

The modding API is a subsystem of the project that requires continuous effort to be put into it, leaving less time to work on other things.

The fracturing of the community also leads to a fracturing of the effort. I would much rather have a few good choices than many bad choices.

would it? i think there would be less effort overall. you dont encourage modding by.. making it harder

I don't think that modding should be encouraged. I think that forks and patching should be encouraged.

the advantage of mod apis is that you can have hundreds and thousands of mods, all of which are going to be mostly compatible with each other, and the individual player gets to choose exactly what combination they want. if you merged all these features into the base game (or a relatively smaller number of forks) then you wouldn't have that freedom of choice.

But if the mods clearly make the game better if implemented either as-is or as a per-savefile option, what rational person would choose not to play with them? What purpose is there to a choice nobody would take?

and if you are thinking 'well, that freedom of choice doesn't sound like fun to me' that's fine, but given the popularity of modding across a wide variety of video games, it seems like a lot of people have a different idea of fun to you.

My issue is that there are too many mods to choose from and most of them are not fun. It's difficult to figure out which ones are good.

What points do you think i've ignored?

The point about being able to install arbitrary numbers of mods for starters. […]

What is that point?

modifications/plugins are literally just advanced scripts. some even are literally just scripts.

When i think of a modding API, i think of something that is used to fundamentally and completely change what exists in a piece of software, where one entity makes and maintains a mod for distribution to others. When i think of a scripting API, i think of something used to do stuff, where people make their own scripts for quick little things, often only to use them once or twice, and frequently using a REPL or equivalent to do so. To me, these are two distinct things that fill unique niches.

anyway, why are you so stubborn in your beliefs?

I don't mean to come off that way. I'm completely willing to change my mind if i should, but i don't want to blindly accept things.

you made this thread like a question, and then argue like it's a debate.

I'm sorry that i've come off that way. I don't want this to seem like an argument. I wanted this to be a discussion mutually beneficial for all parties.

if you really had genuine curiosity, then why do you refuse to accept the given answer?

Because i don't understand why that's the answer.

is it because you're still curious on the specific details? well it's not like we're going to explain human sociology to you to say why humans want to have multiple modifications working together and modularly, with an easy and convenient way to achieve that. you've got the best answer we can reasonably give.

Well, based upon this statement, it appears as though this thread has served its purpose. Thank you all for coming.

BlueManedHawk #3893

ok, i guess you don't need an operating system then. just flash software to your ROM directly. since, an OS is literally a modification API for computers.

I'd say that an OS is more akin to a scripting API or a programming language, which i am completely fine with.

I know that the work itself never addresses that

and therefore, is not a valid counterpoint. if it's so trivial to derive, then provide a point-by-point breakdown of your trivial derivation.

Okay then: The claim is that forking will lead to people being overwhelmed because there will be too many forks. The essay explains that there will not be that many forks. Therefore, people will not be overwhelmed because there will not be too many forks.

I think that forks rarely become many because most attempts to fork a project will invariably get absorbed into the main project or one of the few forks that fills a unique niche different from the original project.

and also a plugin API. that's a very important reason that cannot be overlooked.

What evidence do you have that a plugin API prevents fracturing?

How else am I supposed to respond to "you're acting like a capitalist" we've explained to you numerous times why a plugin API is better than just forking it. And you've ignored us every time.

What points do you think i've ignored? I didn't mean to do that, and i'd be glad to respond to them now.

You're acting like a capitalist, trying to prove your own point by simply saying it again instead of refuting the refutations of others.

i never knew capitalism was about proving points via repeating oneself infinitely. i thought it was about the ruthless drive for profit above literally everything else. but i suppose it's about being a poor debater?

No, it's just that capitalists tend to defend capitalism by just repeating themselves over and over. Example:

"They deserve their money because they invested capital!" «And i don't think we should have a system where a person having money should be rewarded with giving them more money.» "…but they invested capital!"

Of course, the it to is isn't what what do it what it's not only.

hey, speaking of poor debate skills, i'm pretty sure calling someone a capitalist, or « acting like a capitalist » is some kind of fallacy. it's certainly name-calling. ad hominem perhaps?

It's not ad-hominem because the analogue has direct relevance to the debate.

BlueManedHawk #3890

💀

Well, that's not a very informative response.

BlueManedHawk #3886

Again, a modification api allows the user to pick and choose which mods to use rather than being able to only use one at a time. It gives the user choose, which is a Good Thing™

You're acting like a capitalist, trying to prove your own point by simply saying it again instead of refuting the refutations of others.

BlueManedHawk #3884

yes, the instances of forking are about it being legally fine. nothing to do with the psychological overwhelming of forks.

I know that the work itself never addresses that, but it seems to me as though it's trivial to derive.

also, death of the author just means that the interpretation of a work is independent from the author's intention. nothing to do with categorisation.

Does the author having it categorized in a certain way not count as the author's intention?

[forks rarely become many] because people add plugin APIs/modification APIs. which makes making many forks unnecessary.

I don't think that's true. I think that forks rarely become many because most attempts to fork a project will invariably get absorbed into the main project or one of the few forks that fills a unique niche different from the original project. I don't think that a modification API helps with anything.

BlueManedHawk #3882

the document is not an essay explaining how the fear of an overwhelming number of incompatible forks of a project is not upheld by reality.

It seems to me like that's clearly what it's about: it gives several examples of instances of forking in many other projects that have been perfectly fine, and in the final section explains why that has happened. In the BSD section, it explicitly talks about how yes, sometimes forks persist, but it's because they fill a specific niche, creating a situation where it's clear which fork to select based upon actually substantive differences.

it is about the legal fear of forks. as in incompatible licensing and cetera. there's a reason it's under a subdirectory literally titled « Licensing and Law ».

Eh, death of the author. I don't think that what it says on the legal issues of forking are the main thing worth taking away from it.

the document does not address the psychological overwhelming of many forks to choose from, which is only a counterargument addressing your argument that many modifications to choose from is overwhelming.

I think it addresses that by explaining that forks rarely become many.

BlueManedHawk #3879

this document refutes everything bmh says. read it. https://www.mozilla.org/media/MPL/2.0/index.48a3fe23ed13.txt

I do not see which of my points this file you linked refutes, nor what particular relation it has to forking. Could you please be more specific?

I suspect you may be parodying message #3800 that i sent earlier. If this is the case, i want to make it clear that the file i linked in message #3800 was not a legal document about the legal nuances of forks, as you so claimed, but instead an essay explaining how the fear of an overwhelming number of incompatible forks of a project is not upheld by reality; i would suggest you be more clear (and a little less hostile) in parodization in the future if you want them to land better. If this is not the case, ignore the preceeding sentence.

BlueManedHawk #3864

I mean, it's pretty simple: people need to be happy in order to be productive.

Well yes but they can't be productive if they're playing games.

Of course. There's a balance to be struck, and modern capitalism encourages a shitty one that leans way too heavily on productivity, leading to an overall worse society. (Besides, the reason people are productive is so that they can be happy.)

Modding APIs also bring downsides by being a complex subsystem of the project for the maintainers to deal with, taking away time that could be used to solve other problems in the software,

but it also increases the capabilities of the project by approximately ∞%!

…at the expense of taking far more time for those capabilities to come to fruition.

and (in my experience) they often lead to fracturing of a community and too many options to choose from.

this is good! i like having choices. you can always choose not to use mods

The fracturing of the community also leads to a fracturing of the effort. I would much rather have a few good choices than many bad choices.

BlueManedHawk #3859

How do 10 very different mods all fill the same niche?

They all play their part in filling the corners of the niche, so that the niche as a whole is filled.

That's not how i think of it. I would say the the usefulness of video games is that they're entertaining.

Please try to convince literally any school of that.

I mean, it's pretty simple: people need to be happy in order to be productive.

BlueManedHawk #3857

That kind of unification of competition within a niche is exactly the type of thing that i was supporting in my original message.

That's not at all what I was referring to. Many modpacks combine many trivially related mods. It's not as fun to play with 10 mods that all overhaul, say, caves, than 10 mods that each do different things.

That sounds like exactly what i'm referring to: unification of things within a niche.

[Video games a]re meant to entertain, not be useful.

That's not how i think of it. I would say the the usefulness of video games is that they're entertaining.

If doing things differently than other softwares makes them be more entertaining, then so be it.

Of course—the rules should be broken when it's beneficial for everyone.

(Also sorry for not replying to message #3874 earlier.)

What problems do[ modding APIs] create? (You probably already said it but it would be nice to have it all in one place)

Indeed i did, in #3822:

Modding APIs also bring downsides by being a complex subsystem of the project for the maintainers to deal with, taking away time that could be used to solve other problems in the software, and (in my experience) they often lead to fracturing of a community and too many options to choose from.

BlueManedHawk #3851

ok! plugins/add-ons/mods are much easier to manage and install and use than forks. anyone can drag a bunch of files into a folder, add things they want, or remove things they dont. modularity!

Why is that worth the problems that a modding API creates?

BlueManedHawk (edited ) #3850

bees

BlueManedHawk #3836

I really don't like the mentality that video games are somehow special pieces of software.

they aren't though?

Exactly.

a lot of libre software has mods, they're just usually called "plugins"

I guess that a lot of my thoughts here on video game modding also apply to software plugins, and i just didn't realize. Funny how that works.

BlueManedHawk #3832

using a modding API is a lot easier than forking an entire source tree and building the application yourself

Why is that ease worth it?

also, a lot of modding APIs present a cleaner interface than directly editing the source would.

How do they do that?

also i read the page about forking and it seems to have little relevance here. it focuses entirely on tools, that is, software which performs work. games are entirely different, because they are intended to entertain.

I really don't like the mentality that video games are somehow special pieces of software. While it's true that the purpose of video games is to entertain, that doesn't mean that a video game can completely ignore the fundamental principles of software design (i've talked about this before as a part of this thing). The idea behind the page that "a fork of copylefted software cannot survive unless it fills a niche unique from the original software" is, i think, completely applicable to video games.

folding every mod anyone has ever made back into the main branch and putting under a menu option would be hopelessly impractical to manage and it would push source tree and binary sizes through the roof, for features that a lot of players won't even use.

Exactly, which is why i don't advocate for that. Only the mods that are good and are competing in the niche that the original software fills should be merged into the original software; mods that compete in other niches could be merged into forks if they happen to be good.

BlueManedHawk #3826

mu

BlueManedHawk #3822

Have you... ever tried to get a large group of people to agree on something? It's nearly impossible.

I know it can be difficult sometimes. But i don't think it's anywhere close to impossible.

[[]Th[]]at would seem to indicate that those forks are competing within the same niche and ought to be unified.

Not at all true, it's often fun to run many mods at once. In fact, people make modpacks to make doing exactly that much easier.

That kind of unification of competition within a niche is exactly the type of thing that i was supporting in my original message.

[…]different people want different sets of features at different times and in different contexts, so [modding APIs] make this easy to achieve.

But modding APIs aren't the only way to allow that; having in-game settings available for changing small things and forks available for changing large things are another way. Modding APIs also bring downsides by being a complex subsystem of the project for the maintainers to deal with, taking away time that could be used to solve other problems in the software, and (in my experience) they often lead to fracturing of a community and too many options to choose from.

i feel like bees apioid beeoid. also, apioforms.

Foul! No non-sequiteurs!

all reasonable discussion ended when bmh posted a link to a completely unrelated legal document about the law regarding forks in response to a valid point that a lot of forks would be an overwhelming choice to the user too

Did you read the document? This is the second time that i have asked this.

BlueManedHawk #3816

Software that is well-maintained should make its decisions based upon the consensus of the users.

That's a great idea but there will always be people who are unhappy no matter how you do it.

That's a rather pessimistic claim.

What if you wanna run multiple of such forks together?

That would seem to indicate that those forks are competing within the same niche and ought to be unified.

BlueManedHawk #3813

What happens if the developers don't like the mod?

Software that is well-maintained should make its decisions based upon the consensus of the users.

Also then how would players pick and choose which mods to use?

If having such a choice would benefit the game (determined by the consensus of the users), it could be implemented as an optional thing.

a lot of mods would very much not fit in the main game

Then in that case, they fill a niche distinct from the original game, and would be perfect for a fork.

BlueManedHawk #3810

Why not instead tweak and change the original game so as to allow for those emergent properties?

So... make a mod for the game? That seems to be exactly what you described.

No, i meant that the original game should be changed, by means of e.g. submitting a patch.

BlueManedHawk #3808

discovery, especially of emergent mechanics, is a major part of what can make a game fun and enduring.

If the desire is for emergent mechanics, what's the point in piling more and more completely new and non-emergent mechanics on top of the game through mods? Why not instead tweak and change the original game so as to allow for those emergent properties?

people would be overwhelmed with loads of competing forks? i shall actually prove you wrong by sending you to a link to a completely unrelated legal document about the legal nuances of forks!!

Did you read the page? And there's no need to be mocking.

BlueManedHawk #3804

Why?

BlueManedHawk #3802

Even if the users agree that what the implementations do is more useful than what the specification demands they do?

BlueManedHawk #3800

what would be actually overwhelming is many, many competing forks, as the codebase fails to accommodate the flexibility that people desire from the game.

http://linuxmafia.com/faq/Licensing_and_Law/forking.html

you seem to think that a game must be composed entirely of things that are meticulously and perfectly designed to interact with each other, that if it isn't perfect, it isn't worth playing.

I don't think that's true. There are many reasons a game could be worth playing—while i think that fun is certainly the most common reason, and my personal experience has shown that making a fun game requires meticulous thought, there are other reasons, like playing a classic game to understand why it's a classic, even if it's a not fun or even sometimes actively bad game.

you're also taking quite a pessimistic point of view of mods' ability to work together. it is incredibly realistic for two mods that are not written with each other in mind to work quite well with each other[…]

I suppose i am being a little pessimistic, aren't i?

in modded games (well, mostly just minecraft), I find myself changing the mods around between play sessions to create new gameplay situations and interactions.

That sounds like an addiction to novelty.