Moving notetag reading in Yanfly plugins

Discussion in 'Javascript/Plugin Support' started by Galenmereth, Nov 29, 2015.

  1. KockaAdmiralac

    KockaAdmiralac Cube-shaped garbage can Veteran

    Messages:
    570
    Likes Received:
    156
    Location:
    Belgrade
    First Language:
    Serbian
    Primarily Uses:
    N/A
    I have no idea why we started talking about fastest loops.

    I just said i++ is a bit slower than ++i, because I wanted to point out at "a bit", not at "slower".

    I think whatever we decide we should make it a community standard, because we currently have 4 types of reading notetags.

    Also, nobody explained, why is in-game loading more noticeable? Any examples?
     
    #21
  2. Iavra

    Iavra Veteran Veteran

    Messages:
    1,797
    Likes Received:
    856
    First Language:
    German
    If you are doing lazy loading of notetags, that's an additional "if" to test, whether the tag has already been read and (for the first time) an additional operation to read it, which might be noticable depending on the regex used. In general it's more accepted to have a longer startup time, than having stutters mid-game, so preloading is preferred.
     
    #22
    DoubleX likes this.
  3. KockaAdmiralac

    KockaAdmiralac Cube-shaped garbage can Veteran

    Messages:
    570
    Likes Received:
    156
    Location:
    Belgrade
    First Language:
    Serbian
    Primarily Uses:
    N/A
    @Iavra

    As I said, I never noticed any bug while in-game loading.

    Additional if isn't THAT slow, and loading 10000 notetags at the beginning is bugging 10000 times more than loading 1 notetag in-game.

    But I heavily disagree on bug is more likely to be noticed in-game rather than on start.

    That's just my opinion.
     
    #23
  4. Iavra

    Iavra Veteran Veteran

    Messages:
    1,797
    Likes Received:
    856
    First Language:
    German
    More noticable, yes, but also more accepted and that's what i wrote above ;)
     
    #24
  5. DoubleX

    DoubleX Just a nameless weakling Veteran

    Messages:
    1,456
    Likes Received:
    541
    First Language:
    Chinese
    Primarily Uses:
    N/A
    From the RM coding community history, we all know that the default RM codebase almost always dominate over any community standard. It's simply a well-known reality.

    So I think the best move we can make is to ask for a better codebase in the next RM.

    But let's assume a community standard could dominate in the RMMV coding community:

    1. There are always some popular coders falling outside of the community standard(like Moghunter, as he/she isn't even a member here and he/she clearly has his/her own ways of doing things).

    When some users want to use their plugins and those conforming the community standard, compatibility issues can come into play:

    - Without the community standard enforced, the other plugin developers can use some workarounds that don't conform to the standard.

    - With the community standard endorced, they can only ask those popular coders falling outside the standard to follow suit, and they've little to no control on the outcomes.

    On a side note: Standards that aren't enforced are effectively useless.

    2. Plugin developers develop their plugins based on their plugin developing philosophies and the underlying contexts they've to work with, and in many cases they've little to no control over any of those contexts.

    If conforming to the community standard can mean they won't have accesses to the desirable enough solutions, some of them will breach the standard to use the desirable enough ones, even if the standard's properly enforced.

    3. Different plugin developers have different views on what the community standard should be, so it's extremely likely that there will be quite some of them ignoring/rebelling against the standard no matter what that standard is.

    It'd either lead to the standard being ignored, rendering it useless, or a noticeable portions of the plugin developers leaving the community and residenting in somewhere else(or even just making new communities).

    4. The very purpose of the RM coding community is to provide a platform for plugin developers to publish plugins that can meet the RM users' demands and for RM users to get their desired plugins.

    If enforcing a community standard can probably lead to the shrinking of the RM coding community, it'll most likely defeat its very purpose to be served(and I don't think Degica would want that to happen).
    In this concrete example:

    Upon all the notetag loading timings we're currently exploring(choosing among all available timings for the community is the point of the community standard here):

    - DataManager.onLoad

    - DataManager.createGameObjects

    - DataManager.extractMetaData

    - DataManager.isDataBaseLoaded

    - Scene_Boot.prototype.start

    - Scene_Boot.prototype.create

    - Scene_Boot.prototype.terminate

    - getTag in plugin MVCommons(assuming it's indeed a new timing)

    - Right before using the notetag values

    We've already discussed that each of the above timing(except getTag in plugin MVCommons maybe) can have its own problems under some specific cases, for instance:

    - DataManager.onLoad is undesirable when some data types need to access some other data types when reading notetags, and there are cases where this requirement's vital.

    - DataManager.isDataBaseLoaded can break its referentailly transperant nature which is assumed by other plugins that are important to be compatible with, and such breach can lead to compatibility issues that's extremely hard to solve(unless the standard managed to ban any repeated DataManager.isDataBaseLoaded call as well, but this can impose even greater problems).

    - DataManager.createGameObjects, Scene_Boot.prototype.start and Scene_Boot.prototype.create can have a high chance to be rewritten by other plugins that are important to be compatible with, and such rewrites will lead to compatibility issues that's extremely hard to solve(unless the standard managed to ban all DataManager.createGameObjects rewrites as well, but this can impose even greater problems).

    - DataManager.extractMetaData is extremely inefficient at checking the data type when reading notetags(and would lead to exceptioanlly unreadable codes as well):

    AuthorName.PluginName.DataManager_loadDataFile = DataManager.loadDataFile;DataManager.loadDataFile = function(name, src) { this._pluginNameSrc = src; // Added to mark the current source file name AuthorName.PluginName.DataManager_loadDataFile.call(this, name, src);}; // DataManager.loadDataFileAuthorName.PluginName.DataManager_isDatabaseLoaded = DataManager.isDatabaseLoaded;DataManager.isDatabaseLoaded = function() { this._pluginNameSrc = undefined; // Added return AuthorName.PluginName.DataManager_isDatabaseLoaded.call(this);}; // DataManager.isDatabaseLoadedAuthorName.PluginName.DataManager_extractMetadata = DataManager.extractMetadata;DataManager.extractMetadata = function(data) { AuthorName.PluginName.DataManager_extractMetadata.call(this, data); // Added to load each data type notetag via its own notetag reading function this.loadAllPluginNameNotes(data); //}; // DataManager.extractMetadataDataManager.loadAllPluginNameNotes = function(data) { // New if (this._pluginNameSrc.match(/Actors/)) { this.loadPluginNameActorNotes(data); } else if (this._pluginNameSrc.match(/Classes/)) { this.loadPluginNameClassNotes(data); } else if (this._pluginNameSrc.match(/Skills/)) { this.loadPluginNameSkillNotes(data); } else if (this._pluginNameSrc.match(/Items/)) { this.loadPluginNameItemNotes(data); } else if (this._pluginNameSrc.match(/Weapons/)) { this.loadPluginNameWeaponNotes(data); } else if (this._pluginNameSrc.match(/Armors/)) { this.loadPluginNameArmorNotes(data); } else if (this._pluginNameSrc.match(/Enemies/)) { this.loadPluginNameEnemyNotes(data); } else if (this._pluginNameSrc.match(/Troops/)) { this.loadPluginNameTroopNotes(data); } else if (this._pluginNameSrc.match(/States/)) { this.loadPluginNameStateNotes(data); } else if (this._pluginNameSrc.match(/Animations/)) { this.loadPluginNameAnimationNotes(data); } else if (this._pluginNameSrc.match(/Tilesets/)) { this.loadPluginNameTilesetNotes(data); } else if (this._pluginNameSrc.match(/CommonEvents/)) { this.loadPluginNameCommonEventNotes(data); } else if (this._pluginNameSrc.match(/System/)) { this.loadPluginNameSystemNotes(data); } else if (this._pluginNameSrc.match(/MapInfos/)) { this.loadPluginNameMapInfoNotes(data); }}; // DataManager.loadAllPluginNameNotes
    - Scene_Boot.prototype.terminate can be too late in some cases, as some notetag data already have to be read before that timing.

    While I don't have any actual data for this in RMMV, I've some of them in RMVXA.

    In a RMVXA atb system script I've worked with, all the notetags are read right before use, and they're used per battler per frame. It's entirely possible and not extreme for dozens of notetags to be used per battler per frame, and it's also not uncommon that there will be 12+ battlers in the same battle, leading to hundreds of notetag readings per frame. All the rest of the codes are optimized for time performance.

    In my machine(i7-3820 + 2 * 2GB DDR3 1333 + GeForce 550Ti), this lead to the fps drop from 120 to 60(whereas the optimized one that reads all notetags upon game start and some other optimization tricks that will only be possible afterwards has no fps drop at all inb my machine). Less powerful ones can only suffer even more.

    Of course, I think the fps drop wouldn't be so severe if it were a RMMV plugin, as javascript runs much, much faster than Ruby in general. However, I still don't think the fps drop would just suddenly disappear.

    If reading the notetag values right before using them would become the community standard(even though you didn't mean this), those facing such cases(like some atb system plugin developers) would have a hard time optimizing for performance, which can be vital in those cases.
     
    Last edited by a moderator: Nov 29, 2015
    #25
    KockaAdmiralac likes this.
  6. KockaAdmiralac

    KockaAdmiralac Cube-shaped garbage can Veteran

    Messages:
    570
    Likes Received:
    156
    Location:
    Belgrade
    First Language:
    Serbian
    Primarily Uses:
    N/A
    @DoubleX

    @Iavra

    I see your point.

    In time-based systems in-game notetag loading can only screw things up.

    Since it looks like I caused only spam and stress in this topic with my lack of informations, I'll stop commenting and try to apply to my plugins anything you decide it's the best.

    And it's strange that this topic was started by Galenmereth, directed to Yanfly, but both of them left...
     
    #26
  7. Galenmereth

    Galenmereth I thought what I'd do was Veteran

    Messages:
    2,206
    Likes Received:
    1,905
    Location:
    Norway
    First Language:
    English
    Primarily Uses:
    RMMV
    I left because notetag reading should be done during the Scene_Boot.start() process, but Yanfly has his reasons for not doing that which he has explained in detail. And I disagree with those reasons because I think that there should be a point where we don't prematurely optimize for the sake of potential compatibility. And thus I agree to disagree on it. I'm not saying I'm right and he's wrong, because it depends on what angle you come at the problem from.

    Reading notetags during the running of the game is probably very seldomly the right choice. But if you actually just simply saved the read notetag result once parsed the first time, it'll only have to be parsed once and shouldn't have a big effect on gameplay. However seeing as notetags should not change during gameplay -- they are static data after all -- then there's little reason to do this and I really see no benefits for the end user at all.
     
    #27
  8. bgillisp

    bgillisp Global Moderators Global Mod

    Messages:
    11,768
    Likes Received:
    11,798
    Location:
    USA
    First Language:
    English
    Primarily Uses:
    RMVXA
    My thought on this is to me it looks like Yanfly is trying to make their plug-ins work with the JP community too, which tend to overwrite the Scene_boot command more than the EN community do. At least that is my take on it.

    Now, that being said, I know if Dekita or someone were to write a plug in to parse all notetags for us and make it a separate plug-in I'd use it. After all, it would make scripting/plug-in writing so much easier for me as parsing those notetags has been my bane in scripting so far in ACE, and I don't see it getting any easier in MV.
     
    #28
  9. DoubleX

    DoubleX Just a nameless weakling Veteran

    Messages:
    1,456
    Likes Received:
    541
    First Language:
    Chinese
    Primarily Uses:
    N/A
    This time I'll be direct and say that Yanfly isn't prematurely optimizing for potential compatibility at all, as he/she indeed does have actual real data. Why?

    1. He/she's written many RMMV plugins, each with many users. As many of them will use some other plugins and some of them will have compatibility issues with Yanfly's, he/she will receive some compatibility issues.

    Now he/she knows which other plugins he/she'll have to be compatible with his/hers, to meet how many users' demands.

    Some of them are/would be(if the new way's used instead of the existing way) incompatible with his/hers due to the ways the notetags are read, so for him/her to solve as many existing compatibility issues as he/she can, he/she will have to choose the notetag reading timings that best meet this requirements.

    All these are actual real data gathered from his/her existing users directly.

    2. It's crystal clear and obvious that he/she wants his/her plugins to be used by the JP community as well, so he/she'll have to know how his/her plugins will interact will the popular ones there.

    As he/she highly values his/her users, he/she'll value those in the JP community too, meaning he/she'll want his/her plugins to be compatible with those popular ones there once his/hers land there, instead of reacting after some users have already reported compatibility issues.

    As he/she already noticed that some notetag reading timings can cause compatibility issues there, to achieve his/her aim, he/she'll have to choose the notetag reading timings that are the compatible with the largest number of the most important ones of those popular plugins there.

    All these are actual real data gathered from his/her new targeting community that already exists.

    Permaturely optimizing for compatibility only happens when the plugin developer doesn't know which plugins to be compatibile with, leading to attempts aiming to be compatible with as many plugins as possible without any actual real data. It's crystal clear and obvious that Yanfly just isn't doing that, as he/she already knows which plugins to be compatible with and how this target can be achieved.
     
    Last edited by a moderator: Nov 30, 2015
    #29
    Archeia likes this.
  10. Galenmereth

    Galenmereth I thought what I'd do was Veteran

    Messages:
    2,206
    Likes Received:
    1,905
    Location:
    Norway
    First Language:
    English
    Primarily Uses:
    RMMV
    Optimizing plugins made for the MV battle system to acommodate someone who overwrites Scene_Boot.start() completely because they're making a schmup in the engine is premature in my book.

    I get your point, but it's irrelevant. The reasoning for not extending Scene_Boot.start() (where such a function should be placed, just look at how the core code works) is because some plugin writers completely overwrite said function and Yanfly didn't want to require users to put those plugins above his in the manager (as this would easily alleviate the compatibility problems). Yet do we not have to put the YEP_CoreEngine plugin above other YEP_* plugins? Is it not normal to require users to put one plugin above or below another for compatibility?

    The solution is actually right there and I have already written about it: if plugins overwrite Scene_Boot.start() completely, put them above Yanfly's and voila; Scene_Boot.start() can be aliased and used appropriately. You can blow as much bold text smoke as you want, but I won't agree with the reasoning put forth.
     
    Last edited by a moderator: Nov 30, 2015
    #30
  11. Archeia

    Archeia Level 99 Demi-fiend Staff Member Developer

    Messages:
    14,537
    Likes Received:
    14,195
    Location:
    Game Dev Salt Mines
    First Language:
    Filipino
    Primarily Uses:
    VNM
    Didn't Yanfly already stated that he DID in fact used to utilize Scene_Boot.start() until he saw the JP RM Scene. I know where he's coming from since we're both in Twitter, 2ch and various other Japanese scenes and we did observe that they have overwritten Scene_Boot.start(); The easiest example is Tomoaky.


    The thing is, I found your claims about helping players and Devs very contradictory. "I won't agree with providing solutions for better compatibility optimization over 'good practice'."


    I already think RM's entire codebase as not 'good practice' and that it's RPG Maker History that we have to do really dumb workarounds to do some features. And it's not like Yanfly's scripts need to be in a specific order, he just says recommended just to be safe.
     
    #31
  12. Galenmereth

    Galenmereth I thought what I'd do was Veteran

    Messages:
    2,206
    Likes Received:
    1,905
    Location:
    Norway
    First Language:
    English
    Primarily Uses:
    RMMV
    Sometimes helping players and devs can go hand in hand. I am not saying to value good practice over compatibility or otherwise if there are no concrete drawbacks to the code in question, but like I've explained many times there are actually real problems with the current solution that both can and will affect boot time, and other people's plugins. Where me and Yanfly disagree is that I don't think said problems are worth it versus simply telling users some plugins would need to be placed before his. It's not uncommon and many plugins will require this, especially with plugins that completely overwrite core engine functions. This does indeed boil down to poor design of some of the core code in MV, yet that doesn't mean we should just continue down that road to cause even more challenges for ourselves.

    I repeated this for the sake of clarity as a reply to DoubleX when he questioned my viewpoint on this. I'm not saying Yanfly has to agree with me, but neither do I have to agree with him.
     
    #32
  13. DoubleX

    DoubleX Just a nameless weakling Veteran

    Messages:
    1,456
    Likes Received:
    541
    First Language:
    Chinese
    Primarily Uses:
    N/A
    You're assuming that those plugins to be compatible with can always be placed above Yanfly's and no other compatibility issues that are extremely hard to solve will come into play. You simply don't get the full picture at all.

    Given the number of plugins Yanfly has, the number of plugins he/she aims to be compatible with, and the complexity of their interactions, even Yanfly can't be so sure that your way can solve all the compatibility issues raised by reading notetags at Scene_Boot.prototype.start, without making some other extremely hard to solve compatibility issues. I've been wondering from the very beginning that how you can so sure about that, as I'm 100% certain that you've absolutely no data on this at all.

    Let's return what you've said:

    Onto yours:

    I can only agree to disagree when a major reasoning is that putting the incompatible plugins above Yanfly's can solve the compatibility issues without making some others that can be extremely hard to solve. There are no data to back it up, there is only conjecture. We are fooling ourselves if we think we can solve compatibility issues between these plugins by just trying different orderings without considering that all those orderings can still fail due to some other reasons. It's not how it works. The problem posed by going down that route is that we never thoroughly comprehend how those plugins interact with each other as a whole(which are already problematic to begin with) and making premature assumptions based on guesses and a thin attempt at just focusing on the existing and known issues while ignoring the very nature of compatibility issues between those plugins as a whole.

    If you think that's not the case in the Yanfly's context or it's just impossible under any possible context, you've to prove it, as you're the one saying that this way will work, meaning the burden of proof is on you.

    TL;DR: It's entirely possible that without new compatibility issues imposed by changing the notetag reading timing, Yanfyl's plugins have to be placed below those to be compatible with in the first place to solve compatibility issues, and such ordering requirements can have nothing to do with the original notetag reading timing at all. If you don't think so, you'll have to prove it.
     
    Last edited by a moderator: Nov 30, 2015
    #33
  14. Galenmereth

    Galenmereth I thought what I'd do was Veteran

    Messages:
    2,206
    Likes Received:
    1,905
    Location:
    Norway
    First Language:
    English
    Primarily Uses:
    RMMV
    Do you realize what this means though? It means that "first to market" plugins have priority over later plugins, and that those later plugins need to work around the compatibility issues of the other plugins. This leads to nothing but an utter clustercluck of spaghetti code the longer MV stays relevant and the more plugins are written for it. This is what I mean with bad practice: it's not about something as arbitrary as "style" or how "clean" the code is. It's about considering the ramifications of said practices. Plugin writers will have to work together at some point for the best possible compatibility.

    When it comes to the ordering of plugins, I've been going off the examples given for plugins that are currently a problem when using Scene_Boot's start(), and all of those would be solved with placing them above Yanfly's plugins. Yes I am aware some plugins might not have such an easy time. But in this case, compatibility is up to the person writing said plugin too, no? If I make a plugin now that affects anything touched by other people's plugins, I have to consider their work too and/or deal with compatibility problems as they arise when users of my plugins stumble upon them using plugins I haven't used myself.

    The entire reasoning for using isDatabaseLoaded() is that it's less likely to be overwritten with current plugin practices in mind and that reading the notetags a few times repeatedly isn't a significant enough performance problem right now. However with the extreme prevalence of complicated notetags that even use inline JS that is eval'ed upon reading the notetag, and taking into consideration that this practice might be what other plugin writers also use since this sets an example, you don't have to be clairvoyant to realize that reading said data -- even if just a few times extra if only a few plugins need to check said function -- will cause performance issues on boot. The more plugins that do this (and all of Yanfly's that read notetags currently use this), the worse it gets. This is excluding the fact that the function isn't intended for this; I agree that RM's poor structure forces our hand here and with this reasoning it is indeed acceptable from a practical standpoint.

    You present the challenges as if the current solution is some magic bullet for compatibility, but it isn't. Mine isn't either. Just as you say reordering plugins isn't the solution in all circumstances (of course it isn't), neither is this. This current solution is only seen as better than extending Scene_Boot's start() because as of right now, it means Yanfly doesn't have to ask others to make changes to their plugins, nor ask users to put some plugins before others. It's also only a singular source of compatibility problems that might cause that very thing to become necessary, but there will be way more the more plugins are written. We cannot expect our plugins to work in isolation without ever having to ask others to perhaps change theirs as we also change ours to be compatible, or place them above or below specific other plugins. It's a sad result of the limited plugin system in place.

    But I see this as choosing between either using the easy solution right now that works only right now and has demonstrable problems (that have yet to become "Bad Enough"), or doing it the slightly harder way that might require communication with other plugin devs to make plugins that work better in harmony, and which doesn't distort the fundamental functions of a status function. Right now it seems like the mindset that prevails is that we shouldn't impose on other plugin writers because that's not in our place, yet we all make plugins for the same software. If we go down this route of what I consider unnecessary hacks to not step on other's toes in the here and now, sooner or later the chickens come home to roost and changing things causes an avalanche of problems that affects countless other plugins out there.

    As an addendum, the current solution does impact me for instance. I have to write my own isDatabaseLoaded() function as I need to check it's loaded outside of the scene update process and because there's no way I want to add one more iteration of a possible exhaustive notetag reading chain to my user's game. I don't mind this, but the current solution does in fact force my hand. So it's already enforcing the will of one plugin writer on another through code. And since I know this will be misinterpreted: this is not why I'm arguing here, because that fix took me fifteen seconds to write. I'm arguing because I care about the community. I'm not saying you or Yanfly don't, but that's why I'm here spending my limited time arguing this.
     
    Last edited by a moderator: Nov 30, 2015
    #34
  15. Iavra

    Iavra Veteran Veteran

    Messages:
    1,797
    Likes Received:
    856
    First Language:
    German
    If you are completely overwriting a function, you have to expect to be incompatible with another plugin that does the same thing and be only compatible with plugins that rely on it, when your plugin is placed above them.

    Completely overwriting one of the basic scene functions (start, create, isReady, update, terminate) of the built-in scenes sounds like poor style to me and i wouldn't care about being compatible with such a plugin.
     
    #35
    DoubleX and Galenmereth like this.
  16. DoubleX

    DoubleX Just a nameless weakling Veteran

    Messages:
    1,456
    Likes Received:
    541
    First Language:
    Chinese
    Primarily Uses:
    N/A
    You're assuming most of us will always have to frequently work with many of Yanfly's plugins. While it's true uptil now, it can become not so true later on.

    In RMVXA, Victor Sant has his/her own scripts, many of them being incompatible with many of Yanfly's and used by many users.

    The same can happen in RMMV. Maybe it's Victor Sant again, maybe it's someone else, maybe it's those completely outside of the community. I wonder if the situation you mentioned will really continue to last.

    Actually, I'd argue that it'll generally do more good than harm for most users, as they'll have more choices available, even though it'll mean significantly more work on plugin developers solving compatibility issues and offering alternatives.

    In RMVXA, while many users complained on incompatibility between Yanfly's scripts and Victor's, scripters can always replicate some of those scripts having those features the users wanted to solve some of those compatibility issues, if they're extremely hard and costly to be solved directly.

    On the other hand, let's pretend that Victor's RMVXA scripts didn't exist at all. How many of their users will switch to Yanfly's instead? Some of them(including some I've actually dealt with) just dislike some of Yanfly's to the point that they won't use some of them even if they've no other existing choice(so they'll keep requesting for new ones until there's one or even just giving up and I've seen that as well). This means the addition of Victor's RMVXA scripts, despite many of them being incompatible with many of Yanfly's, still lead to generally increased user demand satisfaction. I wonder why the same won't be applied to RMMV as well.

    The most important difference between this move and yours is that, however, able, ready and willing plugin developers have a high to total control on the former move(although it'd still mean tons of efforts), while most plugin developers(including Yanfly him/herself) have little to no control on the latter.

    Also, conforming to what you've said, for Yanfly it'd mean:

    1. When he/she faces situations like this, for each of his/her plugins, he might have to choose either:

    - Sticking with his/her current notetag reading timing to continue to be compatible with as many plugins he/she targeted as he/she can and/or solve some existing compatibility requests from some users as well, while making some other plugins used by his/her users to continue to be incompatible with his/hers(although only Yanfly will have these data)

    - Switching to a new notetag reading timing causing some of his/her plugins to be incompatible with some plugins he/she targeted and/or some of those used by his/her users, while making some other plugins used by some of his/her users to become compatible with his/hers(again only Yanfly will have these data).

    It's crystal clear and obvious that it's actually a balance Yanfly has to make. As he/she highly values his/her users, he/she will have to think, using this existing actual real data gathered from his/her current users directly, which direction will meet more of his/her current users' demands? Of course, when his/her user demands change, he/she will have to reconsider his/her decision too, to accurately adapt to the new user demands.

    2. While only Yanfly has data on this, if he/she has chosen your way, and unfortunately it makes much more dissatisfaction than satisfaction from his/her users due to compatibility issues, what should he/she do?

    - Should he/she promise he/she will write similar plugins having all those features those users really demanded to solve the compatibility issues?(Only Yanfly can answer if he/she will be able to do so)

    - Should he/she deny those compatibility requests with a nice apology, stating there's nothing he/she can do and only those plugin developers can solve the compatibility issues, and promise he/she will try his/her best to request those plugin developers to do so although he/she can't control the outcomes so there's no guarantee?

    - Should he/she deny those compatibility requests with a nice apology, stating there's nothing he/she can do and only those plugin developers can solve the compatibility issues, and suggest for other plugins that are compatible with those plugins and offering what his/hers can offer?

    - Should he/she deny those compatibility requests with a nice apology, stating there's nothing he/she can do and only those plugin developers can solve the compatibility issues, and offers a specific snippet based on the users' projects for each project of each user?

    If you've some other options that highly value the users, please feel free to list them and I'd be glad to explore them with an open mind.

    Of course, if he/she keeps using his/her way, he/she'll still face the same issue on existing incompatibilities, only from some different users. But what those users are is exactly what Yanfly highly values.

    Any plugin developer caring about compatibility issues will agree that plugin writers will have to work together at some point for the best possible compatibility. What Yanfly's concerning is how much control he/she has on this one. He/she's talking about his/her abilities, not wills.

    As it closely resembles to(if not just is) establishing a RMMV plugin developer community standard, my #25 reply about community standard applies to here as well.
    While any plugin developer caring about compatibility issues will agree on this, unfortunately, some plugin developers just don't care about that, and Yanfly has little to no control on this, as he/she have said many times.

    What he/she high values is how his/her changes on his/her plugins will affect his/her current users.
    If I were Yanfly, I'd ask myself this: Given all the existing actual real data gathered from my current users directly and all the benchmarks on the performance impact upon game start with all such plugins involved, the individual projects and machines taken into account(I'd really strongly suggest Yanfly to actually do so seriously when he/she has time even though it'd really mean lots of hard work), which choice will lead to more of his/her current user satisfaction(assuming his/her existing notetag reading timing will lead to less compatibility issues from his/her current users, although only Yanfly can tell)?

    - Keeps the current notetag reading timing to solve more compatibility requests from his/her users, at the cost of the increased boot up time.

    - Switches to a new timing to reduce the boot up time, at the cost of solving less compatibility requests from his/her users.

    Of course, only Yanfly can make this choice, as only he/she can have those data. Those details are vital in making this choice.

    For example, if the increased boot up time on an exceptionally massive project using extremely many of such plugins running on a machine barely meeting the RMMV requirements is 0.5 second, then it's trivial enough for most users and players to even notice, let alone care(Although I do have encountered an user being able to notice an extra 0.5 second delay upon battle start and keep focusing on that exclusively when I can barely notice any difference lol).

    On the other hand, if the increased boot up time on the above case is 10 seconds, then it's really, really so severe that, almost everyone will notice and care about it. Plugin developers not caring such delay will likely be punished by many of their users.

    The key is to perform actual real benchmark to gather actual real data(both you and Yanfly as least, and preferably as many of us concerning this issue as possible). Otherwise I can return those same words you've said onto you again XD

    If you're really going to take the future into account to that extent, though, Yanfly can do the same on compatibility issues too:

    - More and more popular plugins that he/she will have to care about will rewrite Scene_Boot.prototype.start for whatever reasons, despite doing so is an extremely bad move(let's assume so ignoring the contexts of those plugin developers having to face).

    - Fewer and fewer popular plugins that he/she will have to care about will call Database.isDatabaseLoaded more than once in the whole game execution, despite that function's supposed to be referentially transparent(side effect free).

    If you truly think your prophecy will probably land eventually, please prove it, as you're using this prophecy to support your points, meaning the burden of proof is on you.

    Of course, if Yanfly does make his/her prophecy and use it to support his/her points, he/she'll have to prove it too.

    If both will probably land, however, then Yanfly will have to choose again, based on the actual real data gathered from his/her users at the time both prophecies land.

    So what else the RM community as a whole can do to solve the issue? I'm pessimistic on this one, as I'd go to far to say the best move we can make is to request an excellent enough(much better than the current one) default codebase for the next RM, even though I don't think we actually have much control over this. The second best move is to enlighten most of the plugin users that Yanfly's setup will casue many incompatibilities and those plugins needing such setups to be compatible with are themselves responsible for the compatibility issues, even though it's obviously unrealistic given the number of users we've to deal with versus the number of plugin developers being such teachers.
    Please just stop twisting my/our(if "you" refers to Yanfly as well) words or putting yours into my/our(again, if "you" refers to Yanfly as well) mouth already. In fact, no one here have said that the current solution is something like that. If you truly think anyone here's presenting the current solution as a magic bullet for compatibility, please explicitly quote all those exact relevant parts of the replies. If you can't find any such reply, you're just using a strawman to support your points.

    All what Yanfly is saying is that, under his/her contexts he/she has to work with, the current solution is the best among all the currently available ones he/she has thoroughly tested under all those contexts, even though he/she fathoms that it's still a bad solution.

    All I've said is that, you can't say that you way will work better than Yanfly's for him/her under all those contexts without thoroughly comprehending what Yanfly really values and all those contexts first. If you think Yanfly should change his/her very value system in plugin development and/or those contexts can be ignored to solve the issue, this discussion will become discussing about plugin developer philopophies.

    Also, any plugin developer experienced in solving compatibility issues will agree that sometimes we'll have to ask the other plugin developers for cooperation/help in order to solve the compatibility issues.

    What Yanfly has said is that, he/she treats this as the last resort as he/she has little to no control on the outcomes for this move, so he/she'll try his/her best to use some other working alternatives without causing too much new troubles. For each case he/she has to work with, he/she's trying to find the best balance, with his/her value system applied, between the cost and risk for the failure of the last resort, and the new troubles caused by each of the working alternatives.
    Please just try to grasp what Yanfly really means once again. He/she means he/she has little to no control on the outcome of communicating with the other plugin developers, not he/she isn't wanting to solve the issue this way. The essence here is his/her abilities rather than wills.

    If you think that most of the time, most of the other plugin developers he/she has to deal with, will cooperate/help him/her eventually(let alone quickly to avoid his/her users from having to wait for too long), you'll have to prove it, as you're using your proposal that this way will most likely work to support your points, meaning the burden of proof is on you.

    If you think the community as a whole can be changed so your way will become feasible, please elaborate your detailed executable action plan by thoroughly explaining how the community can change from the current state to the desired state with all the intermediate steps fully covered and all the conditions and constraints to be completely met and conformed with respectively for the plan to really work well in the practical reality(perhaps In a separate topic).

    If you think popular plugin developers, like Yanfly, are responsible for this(assuming this can be done in the first place), this discussion will again become discussing about plugin developer philosophies, as they'll have to choose between meeting as many of their users' demands as they can and improving the plugin developing community as a whole(which has a time limit for them: before the next RM lands). I doubt if any of them can do both effectively and efficiently enough even if the community is their whole life, let alone many of them have their real lives to deal with as well.
    Unfortunately, all I can say about that is this: Most, if not all, plugin developers have to focus on their own targeting audiences in order to truly value them due to those plugin developers' limitations on their abilities and resources.

    Sometimes the reality is this brutal: Under the current notetag reading timing, some plugins will have compatibility issues that are extremely hard to solve; Under your new timing, some other plugins will have some other compatibility issues that are extremely hard to solve too.

    At the community level, if the former's the default codebase's fault while the latter's due to those other plugin developers' fault(like rewriting Scene_Boot.prototype.start without very, very solid reasons under the contexts they've to work with), then yes, it's those plugin developers' responsibility to cleanse the plague they've unleased in the first place.

    At the plugin developer level, as long as he/she highly values his/her users, he/she'll only do what he/she can do(under his/her control) to meet as many of his/her users' demands as he/she can. He/she'll put into his/her users' shoes to truly understand those demands.

    At the plugin user level, few of them will ever care what has been covered in this discussion all along. When it's about compatibility issues, all they care is whether a plugin's compatible with another plugin and almost nothing else.

    So right now, what we, as plugin developers, can do when such compatibility issues come into play?

    - We can first try to communicate with the involved plugin developers(like what you're doing to Yanfly), to hope that they'll cooperate with and help us(although in this case you haven't succeeded yet).

    - If the above attempt fails, we can inform the involved users that the attempt failed with a nice apology, then ask them what they really want from the involved plugins, and suggest for alternates(like using some other plugins or writing our own meeting those demands) to see if they'll accept any of them.

    - If all those alternates failed, we can apologize nicely again and ask those users to ask for those other plugin developers to do something to make those other plugins to be compatible with ours.

    - If this also failed, then perhaps we can apologize nicely yet again and ask those users to find some other plugins that are compatible with those other plugins and offering what ours can offer.

    - If this last resort failed as well, then we can only apologize nicely once more and write specific snippets based on their projects directly for each project of each user.

    Also, what the target audience would think, if they know that their compatibility issues can be solved but the plugin developers refused to do so because any such solution will wreck much more havoc on something having nothing to do with their targeting audience?

    - Some of them will just post the solutions that those plugin developers refused to use(then suggest the plugin developers to use it and/or stating them as alternatives to other users)

    - Some of them will understand and even appreciate for the immense efforts made by the plugin developers(fortunately to me, many of mine are this nice).

    - Some of them will express their disappointments but still be polite with the plugin developers(some of mine are this and I still sincerely thank them for using my scripts)

    - Some of them will react badly and lost lots of respects to the plugin developers(luckily to me that I've only encountered 1 such user)

    While many plugin users won't know any of these, some of them do. Plugin developers highly valuing their users will have to think about these as well, even though it won't be a major issue.

    Finally, no one said you don't value the users nor the community. We all know that you do, simply by observing how well you're interacting with your users and how much you've contributed to the community. I even think you're one of the most caring plugin developer.

    No one has said that you're here to complain about the compatibility issues between his/hers with yours either. We also all know that you're trying to offer a better solution for him/her in this case, and perhaps for the community as a whole too.

    Yanfly's simply saying that uptil now your way isn't the best way under his/her value system and all the contexts he/she has to work with.

    I'm simply saying that it seems to me that when some user demands and some good practices are doomed to be mutually exclusive(which is what Yanfly has been saying for countless times and what I've suspected but not confirmed), you'll likely go for those good practices at the cost of not meeting those(not all) user demands.
    P.S.: Given that Yanfly highly values his/her users, how I'd persuade him/her to use your way?

    1. Thoroughly comprehend his/her plugin developer philosophies and all the underlying contexts he/she has to work with by explicitly asking him/her these.

    2. Suggest all available alternatives with his/her plugin developer philosophies and all the underlying contexts he/she has to work with taken into the account including offering some other plugins that can offer what the ones he/she targeted to be compatible with can offer.

    3. Enlighten his/her users that his/her current way is bad and all those plugin needing such a bad way to be compatible with are themselves bad to hope that his/her users will change their minds to force him/her to react accordingly.

    4. Offer his/her users working alternatives conforming to your way including some other plugins that can offer what the ones they want to use as well can offer.
     
    Last edited by a moderator: Dec 1, 2015
    #36
    kiriseo and Yanfly like this.
  17. Galenmereth

    Galenmereth I thought what I'd do was Veteran

    Messages:
    2,206
    Likes Received:
    1,905
    Location:
    Norway
    First Language:
    English
    Primarily Uses:
    RMMV
    I thought I'd made it perfectly clear that I understand Yanfly's arguments, I just don't agree with them. We're now running in circles, really. I feel like I've also elaborated sufficiently as to why this is. There really isn't anything more to gain by arguing it. It doesn't mean I'll stop trying to make my plugins compatible with Yanfly's, nor that I'll tell people not to use his. It just means we couldn't agree on this.
     
    #37
  18. DoubleX

    DoubleX Just a nameless weakling Veteran

    Messages:
    1,456
    Likes Received:
    541
    First Language:
    Chinese
    Primarily Uses:
    N/A
    Then I can only say that you and Yanfly just have no common ground at all on this one(although I wished Yanfly to come back to this topic, as he/she's the best person speaking his/her plugin developing philosophies and the contexts he/she has to deal with). Discussons without any common ground to begin with will never reach agreements(which can be 100% fine, and is totally fine in this case) :)
     
    Last edited by a moderator: Dec 1, 2015
    #38
    Yanfly likes this.
  19. Yanfly

    Yanfly Developer

    Messages:
    1,696
    Likes Received:
    2,314
    As I've been prompted by a particular individual to respond to this thread:

    My philosophies are a reverse of iRobot's three laws...

    1. First Law. Follow good programming practices.
    2. Second Law. If good programming practices interfere with delivering to developers, bypass the first law.
    3. Third law. If good programming practices and/or delivering to developers interfere with making players happy, bypass the first and/or second law.
    My predictions aren't mere conjecture. They are made based off data through previous RPG Maker iterations and current MV iterations. The source of my data comes from this:

    VX Ace: [​IMG]

    RMMV: [​IMG]

    Mind you, that's not even counting the support I've had from VX itself, to which, I'm unable to obtain the data due to the loss of my former website out of my control. I'm not gong to break down and datamine each comment for exact figures, (you can do that for me if you wish), but more than what I estimate to be 70% to 80% of the comments on Wordpress and RMW are support-related. About 40% to 50% of the comments from Youtube are support-related. Support-related questions contain an estimated 30% to 40% of the comments asking about compatibility. You can distrust these percentages if you wish as even I distrust them myself since I simply do not have the time to read through each one let alone turn it into data.

    Over the years I've worked with RPG Maker based on support alone, I've made compatibility patches for what I believe to be numbering over a hundred scripts either publicly or privately. However, due to my lack of time, I'm able to comply with those compatibility patches today but that's another story. The point is, I've seen and know the scripting styles of several dozens of scripters, including Yami, Galv, Ramiro, Victor Sant, KGC, Tomoaki, StrayCat, Modern Algebra, OriginalWij, the list keeps going. Based on this past knowledge, I applied it to RPG Maker MV and determined that DataManager.isDatabaseLoaded() is the idea loading location for the reasons I've already explained before in the past posts.

    However, as a quick refresher:

    • DataManager.isDatabaseLoaded() has close to 0% reason to be overwritten for legitimate reasons based on what I perceive are the programming styles of the scripters I've made compatibility patches for before in the past..
    • DataManager.isDatabaseLoaded() is only called upon at the start of a game and has close to 0% reason to be called upon mid-game for legitimate reasons based on what I perceive are the programming styles of the scripters I've made compatibility patches for before in the past..
    • Parsing notetags in the DataManager.isDatabaseLoaded() function has little impact on performance for the above two reasons.
    • Scene_Boot.start() has already been overwritten by a few plugin makers, thus already making it not an ideal location for me.
    • Scene_Boot.terminate() is out of question because it occurs too late. If anyone disagrees, try loading some enemy notetags that run upon BattleTest start up and see it youself.
    Telling scripters to not overwrite Scene_Boot.start() is not something I'm going to do. It is not my business to tell people how to do their work and change their code, for better or for worse. Starting a holy crusade against bad programming practices is not a hobby of mine. Telling plugin users to place any plugins that overwrite Scene_Boot.start() above my plugins would also suggest that we should assume the users are programming savvy to look through the plugin's codebase to confirm such a thing. However, it's not my business to assume a user is programming savvy when using my plugins, thus, I will sacrifice what Galen deems to be "good practice" for the sake of maximizing compatibility options with the least amount of conflict by my standards. If anyone believes that my notetag parsing for DataManager.isDatabaseLoaded() will lead to a snowballing effect, I would like for them to provide data on why they believe it so with legitimate reasoning.

    Once again, I'm willing to shift my notetag parsing from DataManager.isDatabaseLoaded() to a different function provided it complies with what I deem to be reasonable conditions, but only after someone has provided me that solution. Until then, that burden is not placed on me, but the person challenging me to make such a change. I'm open to criticism, willing to change my plugins, but at the same time, my conditions remain in the sense that my programming philosophies are met.

    Until then, I would like to ask a favor for Galenmereth to change this topic's title to something else without my name in it.

    Thanks.
     
    #39
    Ahuramazda and kiriseo like this.

Share This Page