DoubleX

Purpose Lets you sets a timer that will cause all actors not inputted actions yet to have their turns skipped in turn based battles Video Games using this plugin None so far Parameters Script Calls Plugin Commands Prerequisites Terms Of Use Instructions Contributors Changelog Download Link

With RMMZ released for a while, it seems to me that there's not much demand on applying the ES6 standard to RMMZ, so I decided to drop this idea. However, those wanting to continue on this whole idea can freely take over my failed experiment

I think such a plugin has at least the following potential advantages: 1. Those avoiding direct prototyping like a plague can work with an ES6 version 2. Those not being familiar with ES5 don't have to learn this outdated approach, especially when it's just for writing RMMZ plugins 3. As this plugin can be directly maintained by the RMMZ plugin developer community, it might address their needs more effectively and efficiently(as long as such changes won't break plugins not written with this plugin in mind) And at least the following potential disadvantages: 1. This plugin will need to be kept in sync with the default RMMZ codebase changes, which can be very complicated and convoluted for the plugin developers involved to detect all the changes in the latter(while letting the plugin users/other plugin developers know if the plugin's outdated is an easy, simple and small task) 2. This can further "encourage and recommend" ES5 vs ES6 flame wars among some plugin developers(and can be a serious community trouble if it becomes a widespread drama), as some will write plugins in the ES6 standard with this plugin and some will continue to write ES5 with direct prototyping without this plugin 3. Some plugin users touching plugin implementations will have to deal with both ES5 and ES6 styles, as some plugins will be written in the former and some will be written in the latter(or even mixed styles in the same plugin in some rare extreme cases) To make this post more effective and efficient, I've used nearly 35 hours in 3 days to write 1 such plugin(0.9.5 with just the core parts). While it might break some plugins not written with this plugin in mind despite the fact that I've checked about that several times already, I want the discussion to focus on whether THIS DIRECTION AS A WHOLE is a good idea, so I hope it's not so poorly written that it'll defeat its purpose in this post :)

I don't know, maybe that's because RMMZ tries to let RM users target mobile platforms?

By default, the RMMZ saves are zipped, but is also set to issue a warning when it's above 50KB, so I want to stick to that setting

Updates * { codebase: "1.0.0", plugin: "v1.01a" }(2020 Aug 28 GMT 0100): * 1. Added the following notetags - * - memWithAnyUsableSkill * - memWithAllUsableSkills * - memWithoutAnyUsableSkill * - memWithoutAllUsableSkills Note that you've to update DoubleX RMMZ Unit Filters to v1.01a as well

Updates * { codebase: "1.0.0", plugin: "v1.01a" }(2020 Aug 28 GMT 0000): * 1. Added the following battler manipulation script calls - * - hasAnyUsableSkill(skillIds) * - hasAllUsableSkills(skillIds) * 2. Added the following unit manipulation script calls - * - memWithAnyUsableSkill(skillIds, mems) * - memWithAllUsableSkills(skillIds, mems) * - memWithoutAnyUsableSkill(skillIds, mems) * - memWithoutAllUsableSkills(skillIds, mems)

Disclaimer: This post doesn't mean that I support the idea of releasing plugins with obfuscated implementation codes, and in fact I'm personally against it in most cases(but my feeling on this isn't the point of this post at all), it's just that there might be some really extreme and rare cases making this approach at least a considerable backup plan for some plugin developers(but making this move should still never be taken lightly). I've obfuscated 1 of my RMMV plugins(an advanced complex battle system plugin with way more than 3K LoC of implementation codes), which isn't published yet and is an older version, and I've posted it in my github repository: RMMV Plugin Obfuscation Test Please feel free to deobfuscate this plugin(and please submit a pull request with your fully deobfuscated version), as it's a very, very old and outdated version anyway, and the current version I'm working on already has much, much more contents than that highly deprecated version(and it's still far from being complete). I've tried to deobfuscate this obfuscated version using several online deobfuscators, but none of them can fully deobfuscate it, even though they do help quite a bit, so I don' think deobfuscating the whole thing all at once will be an easy, simple and small task(unless you're a deobsucation experts of course). The supposed workflow of revealing parts of codes is as follows: 1. Users asks plugin developers to make some tunes and tweaks on the plugins but failed to do so(goes to 2) 2. If such tunes and tweaks can be done by editing parameters/configurations/notetags/script calls/plugin commands, then teach those users to do so, otherwise go to 3 3. If these tunes and tweaks are(after considering all factors) worthwhile to be supported by the plugins directly, then upgrade the plugins to support them(or at least announce such plans), otherwise go to 4 4. If these tunes and tweaks can be independent from the plugins, then teach those users to make those workarounds, otherwise go to 5 5. Gives the minimum amount of relevant codes(minified then deminified) to the users, and ensures those codes won't work without the rest of the plugins Then scammers trying to steal the whole thing will have to ask for tunes and tweaks for tons of different plugin parts very quickly, and this will make their true nature very obvious, especially when it's clear that they aren't even taking time to actually implement their tunes and tweaks with the help of those revealed codes(plugin developers can also setup a policy to restrict the same user to ask, say, only 1 small group of revealed code parts per day per plugin or even per week per plugin). I've also added 3 examples on some users requesting some parts of the plugins to be tuned and tweaked, even though I know that real plugins really using this approach will have way more than 3 groups of revealed code parts: Add Delay Between Becoming Able To Act And Actually Inputting Actions Change ATB Bar Window Opacity And Padding Set The Actor And Enemy Starting ATB Values I've tried to use them to help further deobfuscating what's already deobfuscated by online deobfuscators, but I can't even recognize which parts of the still highly deobfuscated implementation codes correspond to the revealed original versions(being minified then deminified before being revealed), so again, I feel that deobfuscating the whole thing will still be complicated and convoluted, even with the help of these revealed codes(please exclude the deobfuscation experts here). Please STRICTLY FOCUS ON THESE 2 ASPECTS: 1. Does this approach let users effectively and efficiently tune and tweak the parts of the plugins they wanted, and what obstacles will they face if the reality isn't as ideal as it should be(possibly other than the cheap one time payment/periodic subscription needed to have such accesses)? 2. Will this approach help a scammer deobfuscate the whole plugin implementation codes, or at least enough parts of them to make a standalone plugin that can make profits way more than what those scammers costed(I'm specifically excluding the case of a highly coordinated team of scammers with many teammates)? But not anything involving the pros and cons/rights and wrongs of obfuscating plugin implementation codes, because I've made this example as a little experiment to test whether this idea can indeed let users tune and tweak the parts of the plugins they want while still stopping scammers from stealing plugins, and I don't want this post to be severely derailed or even closed

Note: This post doesn't talk about specific commissions for specific projects. As the release date and price of MZ are announced, some upcoming MZ users are already thinking of making/using upcoming MZ resources, and free vs paid ones is an important consideration for most in both sides(some resource users are also resource makers of course). Be warned: I expect this post to have very heated debates, those hating these things a lot are better off staying away from this post :D There are several dimensions on free vs paid resources. Needless to say, those being always free on all RM projects will be the most generous(whether it's sustainable is a different thing entirely), while the following combination will be the most money sucking: Fortunately, from what I know, such a money sucking resource haven't existed yet and I don't think it'll ever exist, as I consider this combination "voluntary robbery"(I guess that's as far as how pathetic one can become without making the terms of use illegal) lol On the other hand, the following paid combinations seems to be the especially common(I don't know if it's the most common though): Perhaps because of the following reasons: Now let's think of the following possible scenarios involving the amount of free vs paid resources: 1. All resources are free 2. All resources are paid 3. Most resources are paid but some are free 4. Most resources are free but some are paid I don't know much about other resources, but in the case of plugins, I prefer most to be free but some to be paid. That's my current take on free vs paid RM plugins (I decided to share it even though I know mine's too naive to be shared), and I'd like to know what's yours on plugins or other resource types :P

I've just read some articles having a rather interesting payment model: Those articles are free to read, but also come with QR Codes attached to fixed prices, meaning that you can voluntarily pay the fixed price for reading each article, but you won't gain anything directly right after the payment, and you can still read the complete version of the article even if you don't pay a penny. It sounds like donations, but is different enough to worth mentioning, because donations are generally either voluntary periodic subscriptions or one time voluntary payment with the amount decided by the donators. With the voluntary payment model of those articles, the supposedly one time prices are still decided by the author rather than the users, so the author can use it to reflect what the author thinks of the worth(rather than the cost) of each piece. Applying this to RM resources, an easy, simple and small resource might have a fixed voluntary price of 1USD, while those flagship ones reaching professional levels might have a fixed voluntary price of 100+USD, even though the actual voluntary pricing will be up to each resource maker per resource. Of course, it'd be natural for some resource makers to set the voluntary price in terms of cost rather than worth, but it's their job to be clear of the difference. Ideally, a resource should cost only a little but worth a lot, meaning that only little effort and energy is needed to create an extremely useful masterpiece. The opposite case is that, a resource costing tons of efforts and energy end up being an utterly useless trash that nobody cares about one bit, even when that resource's free. Simply put, cost is the measure of the amount of actual input while worth is the measure of the amount of actual output. Therefore, cost is largely objective in general because accurately measuring the amount of effort and energy without bias is mostly feasible, even though it can still be complicated and convoluted. On the other hand, worth is largely subjective because different consumers have different needs and wants, and are under different circumstances(e.g.: the opportunity costs of the same resource is different for each user), so evaluating the worth of a resource for a user needs to be done on a case-by-case basis per user, as a "one size fits all" measure of worth simply doesn't align well with the reality and will thus rarely work well, unless the targeting audience's very, very well-defined and researched. However, different pricing for different users will only lead to even greater disasters, at least because of the issues of fairness and operational difficulties, so a "one size fits all" price as the best approximations of the worth of the resources in the eyes of the targeting audience is a lesser/necessary evil as long as the donation model still isn't safe enough for the resource maker to apply on the resource yet. This also brings another difference between mandatory pricing in most ordinary paid resources and the more innovative voluntary pricing. In short, the former's likely the result of maximizing the net profits of the resource maker, meaning that it's probably more linked to the cost than the worth, even though the price will try to fit into the "formula" of price = cost + worth(it's a very questionable formula anyway). In contrast, the latter's likely the result of reflecting the worth of the resource in the eyes of the resource maker, meaning that it's probably even more subjective than the mandatory price number, and it's up to the resource user to decide whether the resource really worth that price for that user on a case-by-case basis. It seems to me that this voluntary payment model works for those articles using that model, so I wonder if any resource maker will at least consider thinking about this idea

While I'm personally fine with ES5 direct prototyping, quite some potential MZ plugin developers have rather strong opinions against the default RMMZ codebase sticking to that style, so I've come up with this whole idea and made a little experiment with it :)

With ES6 classes, trying to extend the parent class in plugins can lead to its children still using the old parent codes. For instance, you can place this in a JavaScript sandbox and verify the console output yourselves: So normally, you'll still have to directly type prototypes: But I wanted to offer an alternative for those not being familiar with ES5 or avoiding prototypes like a plague despite the fact that many RMMZ codes are written that way, and this is what I've come up with: I've tested that it works for adding new instance variables and prototype methods in base classes, and extending and overriding existing prototype methods there(you can place the linked snippet into a JavaScript sandbox and verify the console output yourselves). While I failed to inherit the changes in the static functions of the base classes from plugins as well, this can be easily mitigated by using BaseClass.staticFunc.call(this) instead of super.staticFunc(). Basically, the essence of the issue when aliasing ES6 class inheritance without direct prototyping is this: 1. The original child class inherits the original base class 2. A plugin extends the original base class to alias some of its prototype methods 3. The child class still inherits the original base class So to solve this, simply store the linkage between the child class and the base class right after creating that child class, then points the parent of the child class to the extended base class right after extending it. As for the static functions in classes, while I tried to use the linkage to let the exiting children class use the new static functions from the extended parent class, I failed to cover the case for aliasing existing parent class static functions, because it's just impossible: 1. The super in the static functions of the child class always points to the original parent class 2. The super in the static functions of the extened parent class always points to the original parent class 3. The super in the static functions of the child class's supposed to always point to the extended parent class Clearly, combining 1 and 2 will contradict with 3, which is the goal I've trying to achieve. For those not being familiar with ES5 or avoiding prototypes like a plague, I hope using ExtendedClassAlias won't be too demanding for you, as all you need to do is sticking to these: /* * Do these 2 additional things when using ES6 class inheritance aliasing * without directly typing prototypes: * 1. Add the following code right below a new class inheriting another one: * - ExtendedClassAlias.inherit(Klass); * Where Klass is the new class inheriting another one * 2. Add the following code right below extending an existing class as a way * to alias its methods: * - ExtendedClassAlias.updateClass(Klass); * Where Klass is the existing class being extended as a way to alias its * methods * Right now it doesn't work well with inheriting static functions in classes, * so those in children classes should use ParentClass.staticFunc.call(this) * instead of super.staticFunc() */ P.S.: I've spent almost 24 hours on this and I enjoyed the process a lot, even though this might not be practical enough to be used in MZ :)

Fortunately, this has been working well in some communities(at least including RMW and this forum). Those proven to be not respecting the terms of use of the resources, if not just being banished by the community, will at least have a very hard time on using any other paid, or even free, resources, as most resource makers knowing the incident will likely openly or secretly blacklist such offenders already. Also, the community will probably "advertise" the game so even some players will know the truth, and at least some of them will care about this. Similarly, the offenders will usually have a harder and harder time selling their next games, due to generally more and more potential buyers knowing the truth and boycotting such games. Of course, it really depends on which community the offenders mainly access, and I won't be surprised if there are communities standing for treating resource terms of use like dirt :)

When it comes to the issue of letting resource users try the paid resources without having to pay first while still ensuring the resource makers can earn money, I've thinking of an idea besides the traditional "free for free projects/paid for commercial projects" - The resources can be used for free for all PRIVATE/UNPUBLISHED PROJECTS, but must be paid right before they're PUBLIC/PUBLISHED. Of course, if I were one such resource user, I can already come up with a scheme to circumvent such a terms of use, but if most resource users are honest enough to actually stick to the terms of use, I wonder if this will work better for commercial projects(at least those turning out to be failures won't have to pay for those resources yet) :)