[optimization finale: "fuck i gotta stop doing this"]

13 hours ago, Aeodyn said:

@Maruno Something you may be interested in is that mkxp-z can be compiled to use any version of Ruby, and at least with Reborn, getting it to work with Ruby 2.7 is relatively straightforward. ~50% performance increase.

There's also the Tilemap improvements/fixes I implemented in mkxp-z (used in Reborn 18.4.3), which means you can just completely toss out CustomTilemap. (Feel free to PM me about either, if you want.)

It's on the list. A lot of things are on the list.

[optimization finale: "fuck i gotta stop doing this"]

39 minutes ago, andracass said:

okay, so this is the big thing.

from where i'm standing, right now it seems like there are two major versions of essentials- there's the base one that you're working on, and there's what reborn runs, which is effectively just a branch of essentials 15. somehow we've gotta bring them up to date with each other.

i don't know if you keep any records on specific changes (i sure don't) but it seems like the best way to merge the two is to bring reborn up-to-date, make sure that everything still functions (at least to as much of an extent as is reasonably possible), and then start integrating reborn's stuff into main essentials.

i imagine the best time to do this would be after essentials 18 is done (since it sounds like you're pretty close to that anyway), though I don't really want to hold back any major optimizations/changes that may be useful until after that. i'd be open to coordinating some of that stuff in advance if you're open to it.

I'm afraid I don't keep notes other than the change logs I post when a new version comes out. Upgrading will definitely be a harder task if you don't have some kind of record about what code you've changed. You can at least compare Reborn's code with vanilla Essentials v15 to get an idea (if you need a copy of that, let me know). (I recommend upgrading by starting with a clean copy of Essentials and porting code changes from Reborn into it, rather than backporting new code into Reborn.) While you're upgrading (or at any time), if you find anything worth contributing to Essentials itself, I'm always willing to listen.

 

When Essentials gets put onto a GitThing, all its script sections will be split up into separate .rb files for easier editing. This will also make it easier to spot changes, not to mention having multiple people working on them at once and being able to immediately make small changes rather than saving them all up for a big release. I don't have experience working in this way, but it definitely sounds like a good thing to do and get used to.

 

I can't say for sure when Essentials v18 will come out, but I'd be surprised if it was more than a couple of weeks from now. That's not too long to wait, is it?

 

43 minutes ago, andracass said:

i appreciate that you're open to this! hopefully changing how things are done will improve the engine for everyone's sake.

Definitely! It's been on the To Do list for months, but I didn't want to do it in the middle of a version's development (and this latest version has been in development for an awfully long time, which is one of the reasons why the current process is not sustainable). Apparently Pokémon SDK benefits a lot from a more open source approach, so hopefully Essentials will too.

[optimization finale: "fuck i gotta stop doing this"]

It's clear you do an immense amount of work, and it's nice to see you post so much about it. I've taken inspiration from some of the things you've talked about and applied them to Essentials. It's just a shame that I can't help you out as much as would be decent, given your massive modifications to what is now an older version of Essentials. I don't support older versions of Essentials simply because working with just one version is quite enough for me (and because I forget how older versions worked).

 

The Compiler is definitely a terrifying thing. It was made to do its job and nothing more. I recently pushed myself to figure out exactly what it actually does (even if I still don't quite know how or even why) - in addition to converting the plain text PBS files into data files, it also scans through the maps and makes various changes, such as turning events into trainers or item balls. I also changed, in much the way you described, how a bunch of the data files are saved and loaded, to eliminate that fgetb mess and to put information in nice arrays where it belongs (and it all gets cached too). I still haven't tackled the compiling/data files for pokemon.txt, though, just because it's that daunting.

 

The original creator of Essentials seemed very keen to make it work exactly like the GBA games, which means data being stored in byte streams and relying on calculations rather than setting variables as much as possible. This isn't reasonable or useful for a PC game, but it'll take quite an effort to get everything improved.

 

After the next version of Essentials has come out (it's currently in beta testing), I intend to put it on GitHub or GitLab or somewhere. My experience with developing this version (primarily a huge overhaul of the battle system) showed me that the current development process for Essentials is untenable. It needs a revolution.

[optimization overtime]

So if abil is 1, it doesn't actually run pbDexDataOffset to ensure that it's getting the correct byte from dexdata (i.e. the ID number of the second natural ability available to the Pokémon).

 

And if abil is 2 (perhaps by mistake) and there happens to be no hidden ability available to that species, it doesn't fall back on one of the natural abilities and instead returns ret, which is actually undefined in this case and will cause a crash (or at least make things work very wrongly).

 

At least the code in Essentials worked properly, even if it's not quite speedy enough for you (and I doubt making this change would noticeably affect anything; 20% quicker than almost no time at all is practically the same).