VisuStella Sample Project & MZ Core Plugins

● ARCHIVED · READ-ONLY
Started by VisuStella 961 posts Page 29 of 49 View original ↗
  1. Hi, I'm not sure if this has already been mentioned - are you considering an MZ version of the Row Formation plugin?

    Row Formation (YEP) - Yanfly.moe Wiki
    This would add considerable strategic depth to combat. Not sure how difficult it is to implement. Thanks!
  2. Hi Visustella team,

    I just checked in the 5 actual waves but i can't find an option (It would be more in Core) to stop tileset animations (like water) or block some elements to reduce FPS on mobiles.
    I'm really mobile-device oriented and for a normal size map, with the 5 waves plugins installed without parrallel events i can down until 28 FPS

    Do you plan any script option or optimizations for this? I know a lot of makers chose RMMZ instead of other versions for there iOS/ Android support.

    Un abrazo !
    Sebastián
  3. TheRastaGeek said:
    With the battlecore I can see HPgauge but I can't see the amount of HP, it's normal
    or there is a way to make it appear ?

    For enemies or for players? If it's for enemies that feature hasn't been added yet. If for characters then could be a resolution issue.
  4. What's wrong? bandicam 2020-11-19 22-07-23-663.pngbandicam 2020-11-19 22-07-51-272.png
  5. Saved. If you don't save it, Meyer warns you if you haven't noticed )

    I mistakenly copied files over those that were already in the project. And edited, became unedited. The maker no longer understand them, because they were in fact different for him. It was necessary to manually put the files in the Manager again. However, all settings are lost.
  6. Right click on the visustella plugins in the list in the plugin manager and select refresh or update (can't remember which). You can select multiple plugins by shift clicking.

    I'm guessing you updated the plugins, but missed that step.
  7. After reading some technical details about the database inheritance plugin, I have some technical concerns about its apparent implementations(besides the increased loading time as stated there):
    Inheritance vs Composition
    1. I suppose the original JSON data files won't be changed during the pre-load phase, because it'd involve database entries diffing and separating original and inherited data in the inherited database entries, which would be way too complicated and convoluted to worth the cost of doing so

    2. If the original JSON data files really don't change one bit as expected, this probably means the inherited data have to be stored in the memory, which can be quite sizeable when the database, and the average inheritance breadth(a database entry inherits from many other database entries) and depth(A1 inherits from A2, A2 inherits from A3, A3 inherits from A4, ..., An-1 inherits from An, and n is the depth) are large, and this memory consumption can be a problem in mobile platforms, like a low-end Android phone, where the "out of memory" risk can become pretty high

    So, instead of database inheritance(inherited data are bound in the game starting time, just like OOP inheritance are on the compilation time), I'd suggest database composition(composite data uses its components upon having its composite data used, just like object compositions are on the run time):

    1. For instance, let's say the damage formula of skill A is composed by that of skill B and C, instead of preloading the damage formula of skill A to be something like this:
    JavaScript:
    skillA.damage.formula = `(${skillB.damage.formula}) + (${skillC.damage.formula})`
    How about changing the run time to be something like this?
    JavaScript:
    Game_Action.prototype.evalDamageFormula = function(target) {
        try {
            const item = this.item();
            const a = this.subject(); // eslint-disable-line no-unused-vars
            const b = target; // eslint-disable-line no-unused-vars
            const v = $gameVariables._data; // eslint-disable-line no-unused-vars
            const sign = [3, 4].includes(item.damage.type) ? -1 : 1;
            // Edited to use the composed instead of the original formula if there are really composed ones
            const value = Math.max(eval(item.composite.damage.formula.reduce((formula, skillId) => {
                return `(${formula}) + (${$dataSkills[skillId].damage.formula})`;
            }, item.damage.formula)), 0) * sign;
            //
            return isNaN(value) ? 0 : value;
        } catch (e) {
            return 0;
        }
    };
    Where item.composite.damage.formula stores the list of id of skills to be inherited for the damage formula, and in this case, the list should be the id of skill B and C.

    2. On the time consumption side, compared to having to pre-load everything upon game start, which causes the significant loading time increase with large database, and inheritance breadth and depth, the composite item only has to compose its composite damage formula upon using it, and the extra time needed is nearly negligible per use, unless the formula's composed by those of hundreds of skills, in which pre-loading them all would be a disaster anyway
    Of course, there will be times where some parts of a database entry will be accessed frequently, like being accessed per frame, and in this case, the time consumption can indeed become significant, leading to possible FPS drop in low-end mobile platforms, but for such parts, the inheritance approach can be used, meaning that:
    i - Parts of database entries being accessed per frame should be inherited
    ii. - Parts of database entries not being accessed this frequently should be composed
    It's because, the inheritance approach converges all the extra time consumptions on the pre-load phase, causing tons of small numbers to become a large number, whereas the composition approach diverges all the extra time consumptions on each use case, causing it to be still a small number per use, even when the sum of all those extra time consumptions will be much, much larger than that of the inheritance approach.

    3. On the memory consumption side, compared to having to store all the pre-loaded data from inheritance, the database composition approach only stores the notetag contents, and this part of the memory cost, which is a lot smaller in comparison, is the same as that of database inheritance, because those notetag contents have to be stored anyway
    Nevertheless, I think that the database inheritance plugin will be useful at least for crafting though, like using alchemy to combine weapon A and weapon B into weapon C, causing the plugin users not having to make corresponding changes of the data of weapon C when those of weapon A and/or weapon B change :)
  8. If you feel like something is a bug, send a bug report! For Reporting Bugs:

    Take a look at the Troubleshooting page on the wiki, follow the steps listed and if it still doesn't work, please report your problem through the link in Step 2.8 with as much detail as possible. Please follow this as we might miss any bug reports in this topic.

    This thread isn't meant to be a bug report drop off area. Thank you!

    ---

    Regarding updates, please follow the instructions written on this page carefully!

    ---

    DoubleX said:
    After reading some technical details about the database inheritance plugin, I have some technical concerns about its apparent implementations(besides the increased loading time as stated there):
    Inheritance vs Composition
    1. I suppose the original JSON data files won't be changed during the pre-load phase, because it'd involve database entries diffing and separating original and inherited data in the inherited database entries, which would be way too complicated and convoluted to worth the cost of doing so

    2. If the original JSON data files really don't change one bit as expected, this probably means the inherited data have to be stored in the memory, which can be quite sizeable when the database, and the average inheritance breadth(a database entry inherits from many other database entries) and depth(A1 inherits from A2, A2 inherits from A3, A3 inherits from A4, ..., An-1 inherits from An, and n is the depth) are large, and this memory consumption can be a problem in mobile platforms, like a low-end Android phone, where the "out of memory" risk can become pretty high

    So, instead of database inheritance(inherited data are bound in the game starting time, just like OOP inheritance are on the compilation time), I'd suggest database composition(composite data uses its components upon having its composite data used, just like object compositions are on the run time):

    1. For instance, let's say the damage formula of skill A is composed by that of skill B and C, instead of preloading the damage formula of skill A to be something like this:
    JavaScript:
    skillA.damage.formula = `(${skillB.damage.formula}) + (${skillC.damage.formula})`
    How about changing the run time to be something like this?
    JavaScript:
    Game_Action.prototype.evalDamageFormula = function(target) {
        try {
            const item = this.item();
            const a = this.subject(); // eslint-disable-line no-unused-vars
            const b = target; // eslint-disable-line no-unused-vars
            const v = $gameVariables._data; // eslint-disable-line no-unused-vars
            const sign = [3, 4].includes(item.damage.type) ? -1 : 1;
            // Edited to use the composed instead of the original formula if there are really composed ones
            const value = Math.max(eval(item.composite.damage.formula.reduce((formula, skillId) => {
                return `(${formula}) + (${$dataSkills[skillId].damage.formula})`;
            }, item.damage.formula)), 0) * sign;
            //
            return isNaN(value) ? 0 : value;
        } catch (e) {
            return 0;
        }
    };
    Where item.composite.damage.formula stores the list of id of skills to be inherited for the damage formula, and in this case, the list should be the id of skill B and C.

    2. On the time consumption side, compared to having to pre-load everything upon game start, which causes the significant loading time increase with large database, and inheritance breadth and depth, the composite item only has to compose its composite damage formula upon using it, and the extra time needed is nearly negligible per use, unless the formula's composed by those of hundreds of skills, in which pre-loading them all would be a disaster anyway
    Of course, there will be times where some parts of a database entry will be accessed frequently, like being accessed per frame, and in this case, the time consumption can indeed become significant, leading to possible FPS drop in low-end mobile platforms, but for such parts, the inheritance approach can be used, meaning that:
    i - Parts of database entries being accessed per frame should be inherited
    ii. - Parts of database entries not being accessed this frequently should be composed
    It's because, the inheritance approach converges all the extra time consumptions on the pre-load phase, causing tons of small numbers to become a large number, whereas the composition approach diverges all the extra time consumptions on each use case, causing it to be still a small number per use, even when the sum of all those extra time consumptions will be much, much larger than that of the inheritance approach.

    3. On the memory consumption side, compared to having to store all the pre-loaded data from inheritance, the database composition approach only stores the notetag contents, and this part of the memory cost, which is a lot smaller in comparison, is the same as that of database inheritance, because those notetag contents have to be stored anyway
    Nevertheless, I think that the database inheritance plugin will be useful at least for crafting though, like using alchemy to combine weapon A and weapon B into weapon C, causing the plugin users not having to make corresponding changes of the data of weapon C when those of weapon A and/or weapon B change :)

    We've already ran stress tests regarding this and none of your concerns are things to be worried about. However, in the event that a user does manage to somehow consume more memory with a string than an entire game, that's going to be on the responsibility of the game dev. VisuStella is not responsible for unintended usage as per article 5 of the Terms of Use.
  9. @Yanfly Please do not advertise, announce, or release paid plugins on the forums - anything that's discussed here must be free to download (at least for noncommercial use). I appreciate the good work you and the team are doing, including on the paid stuff, but the rules are pretty clear that Plugin Releases is strictly for plugins that are free to download.
    I've removed the announcement from your most recent post; I'll let the older announcements remain since removing them would break the flow of the thread for anyone reading.

    Reminder to everyone here that discussion in this thread should be for the free VS plugins only. Thanks!
  10. Wavelength said:
    @Yanfly Please do not advertise, announce, or release paid plugins on the forums - anything that's discussed here must be free to download (at least for noncommercial use). I appreciate the good work you and the team are doing, including on the paid stuff, but the rules are pretty clear that Plugin Releases is strictly for plugins that are free to download.
    I've removed the announcement from your most recent post; I'll let the older announcements remain since removing them would break the flow of the thread for anyone reading.

    Reminder to everyone here that discussion in this thread should be for the free VS plugins only. Thanks!

    No problem! My apologies for that.

    ---

    The usual weekend updates are now made.

    We are on update batch #14.

    You can find the full changelog here and here.

    For instructions on how to update the plugins, please follow the steps found here.
  11. In response to Wavelength's post, should a new thread be created somewhere that allows for discussion on the paid waves? I'd still like a place to submit enhancement suggestions on those plugins, or just chat about them in general if the need arises.
  12. @Yanfly


    I'm getting all the waves, and all are fantastic and extremely easy to use. One tip would be to add more customization to the battle HUD.

    Maybe something customizable like MOG plugins for example.

    Or at least, try to review the compatibility with these types of plugins. It would be a great facilitator for everyone.

    Thanks!
  13. wrigty12 said:
    In response to Wavelength's post, should a new thread be created somewhere that allows for discussion on the paid waves? I'd still like a place to submit enhancement suggestions on those plugins, or just chat about them in general if the need arises.

    No. Our policy right now is that paid assets - including plugins - are not allowed to be promoted here unless they are sold in the official store. This is because assets sold outside of the store here are considered in conflict with the products sold officially. (This is a business website after all.)

    If you feel the need to discuss suggestions or such, I'd seek out VisuStella's official discussion whether that be a Discord channel or what. I don't know what that is as I am not a part of VS, I would ask someone who is or see if their website says.
  14. Hi Visustella team,

    A comment.
    I'm using all your scripts but there is a serious problem with the FPS rate when i enable the VisuMZ_0_CoreEngine.
    When i disable it my FPS rate is 60 for a normal map 30x20 with no parrallel events (just a moghunter aditional script for fog). But when i enable the script, and walk on the map using the mouse to emulate a mobile device, the FPS rate is falling of more 30% :

    1606002991661.png


    1606002959464.png
    When I disable the VisuMZ_0_CoreEngine script, the FPS rate go back to 60/61 FPS.

    Any solution to fix this problem?
    Best,

    Sebastian.
  15. I'm unable to replicate the FPS drop at all. The Core Engine does next to nothing regarding the map scene so I have no idea why there's even any FPS drops at all.

    I'm going to ask you to follow the troubleshooting steps here: http://www.yanfly.moe/wiki/Troubleshooting_Plugins_RPG_Maker_MZ

    Do try to replicate the problem in an EMPTY project first. However, do keep in mind we do not offer support for plugins outside of the VisuStella MZ library. This includes Mog Hunter's.

    5. VisuStella is not responsible for problems found in your game due to unintended usage, incompatibility problems with plugins outside of the VisuStella MZ library, plugin versions that aren't up to date, nor responsible for the proper working of compatibility patches made by any third parties. VisuStella is not responsible for errors caused by any user-provided custom code used for custom control effects including advanced JavaScript notetags and/or plugin parameters that allow JavaScript code.
  16. bandicam 2020-11-22 20-12-38-926.png

    Is it supposed to work like this? Without scrolling, without a visible possibility to split into 2 columns, so that there will be no emptiness?
  17. Hi Yanfly,

    Thanks for your last response !
    I tried it again in an empty project and i have tested every script (I only add Yanfly/Visu scripts).

    I got this FPS rate drop only when the event & move core was enabled. So, it wasn't a VisuMZ_0_CoreEngine problem. I disable it and the FPS rate is now OK on Android/ iOS devices !

    Best,
    Sebastian
  18. LittlePIGGY said:
    View attachment 168707

    Is it supposed to work like this? Without scrolling, without a visible possibility to split into 2 columns, so that there will be no emptiness?

    There is no scrolling option. Either you have to change the plugin parameters to adjust for the font size or change your screen to have a larger resolution.

    Elgigante94 said:
    Hi Yanfly,

    Thanks for your last response !
    I tried it again in an empty project and i have tested every script (I only add Yanfly/Visu scripts).

    I got this FPS rate drop only when the event & move core was enabled. So, it wasn't a VisuMZ_0_CoreEngine problem. I disable it and the FPS rate is now OK on Android/ iOS devices !

    Best,
    Sebastian

    Good to know! Unfortunately, I'm still unable to replicate the FPS drop. However, there's been an optimization update scheduled for the Events and Movement Core plugin for next update batch. Maybe that will fix it.
  19. Maybe you just add the ability to scroll? Please make them as user-friendly as possible.
    You release a lot of paid content. Release a plugin that adds visual scrolling everywhere
    In the previous version of the maker, this function was implemented better and more conveniently. It did not require developers to force the player to read ultra-small font.