MV - Community Lighting MV & MZ

● ARCHIVED · READ-ONLY
Started by ImaginaryVillain 1279 posts Page 2 of 64 View original ↗
  1. Putting the commands into the notetag format is certainly a welcome addition. Mostly because I actually have multiple notetags in the event notebox.

    The only thing is, now I have to update all of my lightsources again and replace the notetags.
    But no matter, it is certainly worth it. Good job everyone!
  2. To be fair, the help section changes were really just the notes I made on what command/note tag did what because I got tired of hunting through the Great Wall to find "how to do x." Anyway I would've merged your 1.02 with it, but I figured you probably had a better idea of which lines were changed than I did.

    As for the daynight stuff, It should all work, I tested it pretty thoroughly but if I missed anything, I hope somebody pipes up.

    Region/tile lights: I actually do use those for a few maps (region anyway) although mostly for lava tiles.
  3. Haha that's entirely fair and not a bad idea. As for the changes I made, I'll take a look and see. I'm pretty certain it was a handful of frames faster overall. Mostly I removed a weird debug system, and did a lot of restructuring to break up that colossal function. Largely in preparation of making it more object oriented, and maybe even "readable" one day. :LZSwink:

    Also my primary usage is essentially just having 6 events that are color coated, then spawning them 80-100 times on a map. And at least 10 lit up events behind the player.. With new events spawning and despawning every second. So I'm pretty ideally setup to speedtest it. But I only ever use it to light up events... So, everything else I'm kind of hoping other people who use it for that stuff will test those for us. :LZSexcite:
  4. Hmm... depending on how many people end up working on this plugin, you might need to organize this a little bit. At the moment, it does not seem to be too big of a problem, but...

    If - say - 3 people work on it at the same time with no internal communication, you'll end up with 3 different versions of the plugin. And if each of them has added new and different functionalities to the plugin, you have 3 different great versions of the same plugin.

    So with that, people would either be forced to pick one of the 3 versions or someone else has to go through the process of merging all of them together.
  5. That's true, not going to lie that would be a wonderful problem to have though. It is after all the point of this "experiment". But I figure worse comes to worse I'll merge them, unless someone else wants to volunteer for the job.
  6. If you guys put this on github or gitlab, I’ll definitely help out some. Organization is key, having a place to write down current issues and wanted features as well as to see the changes happening visually are important. Now if no one knows how to use git then maybe it’s not such a great idea lol but it would help tremendously.
  7. I can't say I've ever used GitHub besides downloading from it. But if the others are interested, then it seems fine to me.

    Here's the updated version with the changes I made merged with the ones Aesica made.
    Change Notes:
    Removed a strange debug system that ran twice per light per frame.
    Removed a speed test system.
    Restructured the code to use a switch statement and objects instead of a huge stack of Ifs.
    Removed assorted commented out code from the original plugin.

    Seems to be faster, but it's 5am here... So the world seems "faster" at the moment. Let me know if I broke anything. If it's all good, I'll update the first post when I wake up. :LZSwink:
  8. ImaginaryVillain said:
    At the moment I'm waiting to see what Aesica comes up with before messing with the code anymore (to avoid having to redo stuff). Maybe you'll get lucky and whatever she changes will fix the Ultra Mode 7 problem. :LZSexcite:

    Though if Ocram's gets the job done for you, that works too. Maybe BBlizzard will make a compatibility fix for it to solve the misaligned lights. Worth a try at least. Let us know how the testing goes.

    So far, no luck with the M7 glitch but at least I know how to recreate it easily, whenever I have a map that is big enough I only need to have a light near the bottom and for some reason the entire screen will "flash" with the same color (of that light) when walking near the top/middle of the map (it's quite random and even changes position depending of the camera pitch).. With the original Terrax I never encountered that problem in years so maybe I was lucky, or it was some kind of "dormant" problem waiting to be unleashed.

    But anyway, I found an old laptop with an i5 CPU (2012 gen) and its integrated HD3000 GPU so here are my results with each plugin:

    The community lighting plugin performs around 5 to 10fps faster than original Terrax in the scenario I checked (just a few lights in a mode7 map with some pixi filters), around 40-45fps instead of 35.

    The OcRam plugin is somewhere between the original Terrax and the community version, it's a bit hard to exactly get the same scenario but I would say that it feels a bit more demanding.

    Maybe the performance gap is bigger if you use a large amount of lights, my scenario wasn't very generous on that side, but having those fullscreen pixi filters on such a weak GPU is enough to see it struggle and make any kind of improvement quite visible.

    But anyway, other than performances I would add that Terrax gives the best visual results with light sources, it might be a matter of tastes but it's like the "threshold" is smoother with Terrax, and it feels a bit more natural. Hopefully the mode7 glitch will get fixed so I can enjoy the extra FPS on weak devices, and I'll be less reluctant to have more light sources, but at that point I might have some kind of "lighting-plugin PTSD" and will forever restrain myself. :LZSlol:
  9. I was afraid this might happen with the merging of 1.015 and 1.02, but it's not surprising given how rickety the whole thing is: it seems a few things broke, specifically with the daynight system. I'm looking into fixing them now.

    Also, I see you don't like my style of curly brace usage. ;)

    Edit: Oh, and I agree with @LTN Games in that this should probably be on github to make collaboration less of a mess. I mean, if the two of us have already stumbled over each other, I can only imagine what might happen with 3 or more actively working on it.

    Edit2: Okay all fixed. It was (thankfully) just a scoping issue:
    • Fixed a variable scoping issue introduced by the lastest optimization pass.
    Version posted below is: 1.017

    Edit3: Added explanation how to set speeds via the daynight map note tag to the help section. Version otherwise unchanged.
  10. Haha, I was thinking about the whole "your style of curly brace usage" trying to figure out what you meant. Then I realized why I couldn't find it... I had Visual Studio Code format the whole document at the end of editing (since I moved so much around). So er... Visual Studio Code is a hater and doesn't like your style of curly brace usage apparently. :LZSwink:

    And yeah, I needed to go through and see how the new variables were defined and moved them to their respective objects. Call that a 5am my bad. :kaoswt: I should really have a project setup to test each possible option... Though on the plus side, as I switch it more and more to objects it will be a lot easier to see what broke and fix it. :LZSexcite:

    As for Github I kind of figure the only reason we're trampling over each other right now is "everybody" is so excited and jumping on a "new toy". Give it a couple of weeks and likely edits will slow to a crawl or be non-existent once excitement dies down. But when I get some free time, I'll look into Github and whole that whole thing works.

    @KaYsEr
    Excellent, glad to hear we're the fastest "on the market". I'll definitely keep working towards figuring out what that problem occurs. Though like I said earlier, mostly I'm just trying to get this plugin to be as efficient and readable as possible at the moment. I'm hoping that will make finding the issue that causes that bug much easier. :LZSwink:
  11. I figured it was some sort of auto-formatting. Normally, I do my stuff like this...
    Code:
    function butts()
    {
       someStuffHere();
    };
    ...since I find it less of a pain to make sure brace pairs match up. I'm actually fairly certain that Satan temporarily manifested himself on this world just to make sure the coding "norm" was to put opening curly braces on the same line as function declarations, etc)

    And yeah, week 1 excitement is probably it. I mean already, now that my stuff is in and I can upgrade my main project to this for a bit of a performance boost, I'll probably mostly just stick to bugfixes. And eventually, an optimization pass to make sure there aren't other wasteful things like that "read the map note tag as many times as there are events on the map during every update cycle" issue going on.
  12. If that's the case I can't recommend something like Visual Studio Code enough, not only does it draw vertical lines to show what's inside each function. But you can also mouse over a bracket and it will light up the bracket (or brace) that corresponds to it.

    I've gotten so used to that,that I absolutely hate writing code bits in MV, because I don't even think to check for that stuff since VSC will just point up such an errors. In fact... I've been moving most of my game to plugins for that and performance reasons. Turns out MV's a good program, it tries it really does... But wow does it bloat stuff. :kaoswt:

    As for the plugin, I've updated the main post with the latest version and changes. But with two of us essentially just doing optimization and nobody currently looking to add more features. I suspect in a couple of weeks we'll arrive at the final plugin barring someone deciding to add something. I will likely look into some PIXI stuff for it... But I'm also trying to shove a demo out the door for my game in a couple of months. So I probably shouldn't fall too far down that rabbit hole... yet. :LZSexcite:
  13. Oh yeah I use VSC, but mainly for larger projects. Plugins are a lot simpler and as such, I generally just write them in NP++, which also has the same features (matching bracket highlighting, code block collapsing, etc). And thankfully, I was able to configure VSC to not F with my curly brace preferences. ;)
  14. The epic curly brace battle continues. :LZSwink:
  15. I love your initiative, so functional that this plugin is, it really needed some cleaning.

    I made a long time ago an addon who allowed to use Terrax Lighting during battle,
    I don't know if it enters in the scope of this experiment.

    Also, little suggestion: may be put some additional typings (@type) tags for the Plugin Manager.
    (See https://forums.rpgmakerweb.com/inde...w-plugin-manager-in-rpg-maker-mv-1-5-0.79764/)
    For example, the kill switch parameter would nice with '@type select' or '@type combo' where None, A, B, C and D would be the options.
  16. I was willing to give it a try. But I'm afraid that I code something that you don't like it xD
    I mean, there are ways to improve the performance of the code but some coders may not like what they look like in terms of readability. SO I prefer to write it here, and you choose if you want to do it or not(I even can implement if you guys approve it). ^^

    For loops
    There is a common mistake that a lot of coders do, which is to check the length property in the loop body several times. When you make a for loop:
    JavaScript:
    for (let i = 0; i < $gameMap.events().length; i++)
    Each and every time he runs, it will take a property lookup for $gameMap.events().length.
    We do not need this(unless the length of the iterable array or object can change during the loop).
    And also it will be searching for a 'variable' outside the loop scope in each loop.
    Instead of that, we can use a local variable to save time and just do only property lookup:
    JavaScript:
    for (let i = 0, len = $gameMap.events().length; i < len; i++)

    There is also another thing to speed up the loop if the order to iterate the array doesn't matter.
    Is reversing the order in which the loop runs, like this:
    JavaScript:
    for (let i = $gameMap.events().length;i--;)
    We see now that we just set the length property to the iterator variable.
    And we set the loop control condition to 'i--'.
    Control conditions are compared to the true value. And any number that is not zero, is already true.
    So now, we are making a simple comparison against 0, which means that before reversing the order we are making two comparisons inside the control condition, per iteration:
    'i < len = Is iterator value less than the total(len) and this value is true?'
    But after reverse the order, we are only making one comparison per iteration:
    'i-- = Is this value true?'

    Example in line 521:

    JavaScript:
                    for(let i = $gameMap.events().length; i--;){
                        if ($gameMap.events()[i]) {
                            for (let j = lightarray_id.length; j--;) {
                                if (lightarray_id[j] == lightid) {
                                    let mapid = $gameMap.mapId();
                                    let eventid = $gameMap.events()[i]._eventId;
                                    let key = [mapid, eventid, 'D'];
                                    $gameSelfSwitches.setValue(key, false);
                                }
                            }
                        }
                    }

    Long Switch/If statements
    When we have a long switch or if statement, we can try to make an array lookup table instead.
    Like this, in the plugin command:
    JavaScript:
            let tileType = {
                'tileblock': 1,
                'regionblock': 2,
                'tilelight': 3,
                'regionlight': 4,
                'tilefire': 5,
                'regionfire': 6,
                'tileglow': 7,
                'regionglow': 8
            }
            if(tiletype[command.toLowerCase()]){
                tiletype = tiletype[command.toLowerCase()]
            }

    the problem is, that the other switch cases executes different results:
    JavaScript:
    case 'tint':
                            Community.Lighting.tint(args);
                            break;
                        case 'daynight':
                            Community.Lighting.DayNight(args);
                            break;
    So that will not work properly. There is a way to work around, putting function names as a string and make a literal object as I did in one my plugins:
    JavaScript:
    Eli.CheckPoint.Game_Interpreter_pluginCommand = Game_Interpreter.prototype.pluginCommand;
    Game_Interpreter.prototype.pluginCommand = function (command, args) {
        Eli.CheckPoint.Game_Interpreter_pluginCommand.call(this, command, args);
        this.checkPoint_executeCommand(command, args);
    };
    
    Game_Interpreter.prototype.checkPoint_executeCommand = function(command, args){
        const allCommands = {
            AUTOSAVE: 'checkPoint_AutoSave',
            AUTOLOAD: 'checkPoint_AutoLoad',
        };
        const result = allCommands[command.toUpperCase()];
        if(result) this[result](args);
    };
    
    Game_Interpreter.prototype.checkPoint_AutoSave = function(args){
        $gameSystem.autoSave();
    };
    
    Game_Interpreter.prototype.checkPoint_AutoLoad = function(args){
        $gameSystem.autoLoad();
    };

    RegExp
    Another little thing that we can do is save the RegExp in variables so we do not have to compile them each time we will use it. We can save it in the list of let declarations that are at the beginning of the plugin:

    JavaScript:
    let myRegExp = RegExp("<" + noteTagKey + ":[ ]*([^>]+)>", "I");
    
    function getTag() {
            let result;
            let note = this.note;
            if (typeof note === "string") {
                if (noteTagKey) {
                    result = note.match(myRegExp );
                    result = result ? result[1].trim() : "";
                }
                else result = note.trim();
            }
            return result;
        };
    I assume that the plugin uses a lot of checks in note tags right? So I guess that it can be useful.

    NOTE: I do not take a deep look in the plugin code and only use it once, a long time ago. So maybe are some things that can be off context that I don't know, like if it matters reverse the order of the iterator in the for a loop.
  17. Oh don't be afraid to update the code and post it here @Eliaquim that's the point of this, to let people do exactly that. It's not about if anybody likes the code, just that it ends up at the best possible plugin in the end. :LZSwink: So feel free to post your upgraded version here, we'll test it and if it's better it just becomes the plugin in the first post. No questions asked. :LZSexcite:

    @Alexandre Actually, that's exactly the scope of the experiment. To let the community update and improve the script, so we welcome you adding your battle add-on to it. Or any other such changes that you would like. :LZSexcite:
  18. ImaginaryVillain said:
    Oh don't be afraid to update the code and post it here @Eliaquim that's the point of this, to let people do exactly that. It's not about if anybody likes the code, just that it ends up at the best possible plugin in the end. :LZSwink: So feel free to post your upgraded version here, we'll test it and if it's better it just becomes the plugin in the first post. No questions asked. :LZSexcite:

    @Alexandre Actually, that's exactly the scope of the experiment. To let the community update and improve the script, so we welcome you adding your battle add-on to it. Or any other such changes that you would like. :LZSexcite:
    Here it goes!

    CHANGE LOG 1.018
    1. Stored the RegExp note tag into a variable for the code does not compile the RegExp every time he uses getTag() function.
    2. Replace the plugin command switch statements with an array/object lookup table.
    3. Optimized some for loops changing the way they are handled from this:
    for (let i = 0; i < tilearray.length; i++)
    to this:
    for (let i = 0, len = tilearray.length; i < len; i++)
    *I did not reverse the iterator order because I don't know how the plugin works, to be sure if the order matter or not.
    4. Some minor changes to if statements that are redundants like:
    if(args[0] == 'on' || args[0] == 'ON') to if(args[0].toLowerCase() == 'on')

    Hoping that I did not break anything xD
    There are other things to do, but I'm not fell confident without really know the code and his functionality inside a game.
  19. Hi I like your idea!

    Although as the main request can you host it on a GitHub? which is easier to sent PR requests? @ImaginaryVillain
    also I was thinking if it's not already done that we should update it to the new MZ standard (ES6) for readability purpose
  20. I guess I should learn my way around Github then. Seems interest in this is way higher than I expected, which is great! :LZSexcite:

    As for ES6 the big joke behind the original plugin was it was written by a guy who hates object oriented programming. So a lot of the work so far has been deciphering it and working it towards something that's well... Not a very large code Jenga tower. So er..., rewriting it in ES6 is totally available for anybody who wants to do it. :LZSwink:

    @Eliaquim
    Unfortunately your version gives this error...
    error.jpg