MV's plugin command setup is the current bane of RETRO's existence. To a degree, so is MZ's. Especially when trying to make MV's plugin command interface play nice with MZ plugin commands with complex arguments.
Another new RETRO milestone! 3 actually. It's reached 500 lines of code (includes whitespace and comments, so technically the actual code is still less than that), it's reached version 0.05, and there are now over 10 plugins on its known compatibility list!
I think RETRO's hit its first real brick wall. Not insurmountable, the problem is my lack of understanding the graphical systems. But with no errors, it's extremely difficult to track down the problem. Oh well, plenty of other plugins to try to work with! I'll just have to stick this one on the back burner.
It all comes down to the pesky MZ plugin commands... the more I try to make the implementation user-friendly, the more complicated this thing becomes. Rewriting the parser for it... AGAIN. Only now I have to be able to detect and deal with structures. Cue banging my head into a wall....
Gotta love having to put a simple function branch somewhere OTHER than where it logically should be simply because someone's core plugin wants to put stuff in weird, seemingly arbitrary locations.... and as far as I can tell, does stuff it doesn't need to do. It all looks stupidly inefficient/unnecessary and it bugs me. And makes RETRO's job just that much harder in order to make it functional.
Mwahahahaha! I've discovered how to figure out which plugin, if any, is calling a function! This will make RETRO's work SO MUCH EASIER when dealing with functions with identical names but different functions/executions! Honestly that's been the biggest headache in this project, trying to figure out if a function is being called by an MZ plugin, MV plugin, or MV itself. Looking at you, help window. >.>
I have discovered that the plugin manager throws a low-key fit if your plugin contains "/*:" and/or "*/" in the code. I kinda get why... but that means the way it reads its stuff is... simplistic and without any additional checking. And it fails to load any of the actual working comment block information as a result, so it's all or nothing.
I just saw one of SigmaSuccor's RPG Maker news videos, it mentioned one of my plugins. Now I kind of wish I'd made a demo project for it, having nothing in that segment but a scroll down the code feels a little underwhelming given what the plugin COULD do. Except I suck at making demo stuff, and my testing project isn't fit for that.
Definitely glad I haven't released a few of my plugins that are technically done. As I learn more, I find ways to make my code more efficient, and in one case so far, discovered an existing function that did EXACTLY what I created my own function to do.
Mad props to Yanfly and the VS team. Making a plugin that does a focused fraction of what one of their core scripts can do is extremely slow, exhausting, and occasionally frustrating. Granted, I'm learning JS as I go instead of from the ground up beforehand, but so many elements of this script are requiring either DEEP experience, or LOTS of trial and error to figure out.
I'm currently scratching my head on how to design plains. What do I even put in plains? Some trees (but not too many or it turns into a forest)? Grass? A few bushes? That's a bit dull.
I'm looking for tutorials but Google didn't seem to find much (or maybe I have the wrong keywords). I don't know how to map plains and I don't know how to learn.