Let's speak about VisuStella term of service as Plugins developpers

[Kupotepo]

@Dr.Yami, what you think about this? You are highly talented based on your amazing plugins. Do care or not about the topic? Or just wait and see? Thank you for responding to us. Just would like to know what you think about this, not a coder myself lol.

Many people who are senior coders do not care that much because they just ported MV to MZ and done this matter.

 

[TheoAllen]

@Dr.Yami, what you think about this? You are highly talented based on your amazing plugins. Do care or not about the topic? Or just wait and see? Thank you for responding to us. Just would like to know what you think about this, not a coder myself lol.

Many people who are senior coders do not care that much because they just ported MV to MZ and done this matter.

I would avoid a direct mention because that's kind of rude when 1. they haven't replied, 2. no direct relation.

 

[Hudell]

while I can see it being necessary in some extreme cases, in 5 years working with MV I've never needed to copy any piece of code to make a compatibility patch...

 

[nio kasgami]

Anyways,
The whole conspiracy is a little far fetched but yeah it sucks we not forced to support.

Also from an official tweet they did say : we will not provide any patch compatibility support for third party plugins.
So pretty much if a compatibility have to be dome its by us solo creator.

Anyway i guess its their choices

 

[Galenmereth]

while I can see it being necessary in some extreme cases, in 5 years working with MV I've never needed to copy any piece of code to make a compatibility patch...

Really? I'm going to make a really rough but simple example of something I saw a lot in plugins and core code:

someMethod(params) {
    let someVar = someParserMethod(params.something);
    if (someVar == "whatever") {
        doOneThing(params);
    }
    else {
        let someOtherVar = someOtherParserMethod(param.example);
        doAnotherThing(someOtherVar);
    }
}

Now say you want to add an "else if" clause here and retain the other functionality. What do you do?

 

[TheoAllen]

Also from an official tweet they did say : we will not provide any patch compatibility support for third party plugins. So pretty much if a compatibility have to be dome its by us solo creator.

This is understandable. Personally I would not make a compatibility patch to some plugins I don't like. Heck, even Mog don't even create compatibility patches to various plugins, and they're doing fine.

 

[Hudell]

Really? I'm going to make a really rough but simple example of something I saw a lot in plugins and core code:

someMethod(params) {
    let someVar = someParserMethod(params.something);
    if (someVar == "whatever") {
        doOneThing(params);
    }
    else {
        let someOtherVar = someOtherParserMethod(param.example);
        doAnotherThing(someOtherVar);
    }
}

Now say you want to add an "else if" clause here and retain the other functionality. What do you do?

you can alias the method, check for your condition and call the old method if it's not what you wanted to handle...

in fact, this is a perfect example of where you should NOT copy the code, because you'll just be opening it up to more incompatibilities. You would need to update your patch every time the base plugin changed that part of the code.

 

[TheoAllen]

because you'll just be opening it up to more incompatibilities.

Not when the plugin is directly placed below the target plugin that is basically change the behavior of it before anything else.

You would need to update your patch every time the base plugin changed that part of the code.

This is expected, but that depends on how crucial that part is.

 

[Hudell]

Not when the plugin is directly placed below the target plugin that is basically change the behavior of it before anything else.

Unless someone else did a patch the same way and then they would need a separate patch to be compatible with your patch as well.

This is expected...

But it doesn't have to be.

 

[TheoAllen]

Unless someone else did a patch the same way and then they would need a separate patch to be compatible with your patch as well.

This is true when you share the patch for public use, however, most of the cases (my cases) patch are custom made by very specific requirements. The user posted a request in plugin support (or DM/chat) that X and Y are not compatible. Patch made specifically for them in their case. Overwrite is inevitable, the patch was made, the user was happy with the result.

But it doesn't have to be.

Good when you can avoid it though.

 

[??????]

patches on patches... the plugins arent even out yet guys, calm down

 

[Kupotepo]

I would avoid a direct mention because that's kind of rude when 1. they haven't replied, 2. no direct relation.

ok, I do stop direct questions then. You are an adult more than me lol.

 

[mlogan]

I’m obviously not a coder, but if I were, I would be concerned about submitting something, having it denied, and having them turn around and add it themselves.

 

[nio kasgami]

I’m obviously not a coder, but if I were, I would be concerned about submitting something, having it denied, and having them turn around and add it themselves.

fortunately, they can't do that without suffering severe backlash from the community so I wouldn't consider this section.
especially it'S a Legal hole that can be very costly for both side

 

[??????]

There would certainly be nothing stopping them from paying their coders to rewrite the core features that your submitted plugin/patch added. Also nothing to stop them from deciding that your code was not up to par with their standards for whatever reason and that it *had* to be rewritten.

 

[Archeia]

First of all, please read this clause carefully:

If a compatibility patch needs to be made through a third party that is unaffiliated with VisuStella that involves using code from the VisuStella MZ library, contact must be made with a member from VisuStella and have it approved.

If you use a part of the code and made a plugin adjustment, then ask for our permission. That's it. If you didn't copy paste any part of the plugin to make a compatibility, we're not going to force you to ask for our permission.

If you copy an entire function, "made a compatibility patch" and then sold it in a storefront or whatever. Or literally making a living out of someone else's code that is not under MIT or Open Source, we're not OK with that.

 

[Tea's Jams]

Preach it sister.

 

[nio kasgami]

That's what I understood from the tweet after they answered/ general explanation from the thread.

 

[Driftwood Gaming]

I thought most people already knew this.

 

[Galenmereth]

First of all, please read this clause carefully:



If you use a part of the code and made a plugin adjustment, then ask for our permission. That's it. If you didn't copy paste any part of the plugin to make a compatibility, we're not going to force you to ask for our permission.

If you copy an entire function, "made a compatibility patch" and then sold it in a storefront or whatever. Or literally making a living out of someone else's code that is not under MIT or Open Source, we're not OK with that.

In said clause it doesn't state selling it as the limiter. So could you clarify the following scenario:

To make a compatibility patch for a function where one needs to extend functionality within the function itself, and where simply "aliasing" (or extending it) isn't sufficient to maintain functionality, thus having to copy the function but make changes to it. Does this count as "copying the code"? And does one need permission even if the patch is completely non-commercial?