enu

Disclaimer: You can consider the initiative still open to new applications even if you’re reading this a long time after posting. This is most likely the last blog post before the 19.5 community release. But in a way it might be the most important one for the future of the game. Since I started working on Reborn I took the initiative on several occasions to put together the new team, set up some workflows and good practices. This time I’m going a step further because this initiative isn’t targeting just the team but the community as well. Let’s see how this goes. Okay, here is a little confession. I’m a big fan of open-source software and have a lot of personal experience with both contributing to and maintaining open-source projects. When I look at this community with 3 different games sharing the same engine and how many mods the community made for these games I can’t help but think that the games could be even better if we involve the community and modders more actively. So today I’m introducing an experiment I proposed to Ame and the team and which we decided to try. No, we aren’t fully going open-source but it’s somewhat close to it. The idea is that we can give the more experienced community members and modders an opportunity to improve the game directly. You can help to fix some annoying bugs, make changes in the base game to make modding easier, and if the dev team likes your idea you can even contribute a new feature. We have a private Discord server for this purpose. The way to get in is to apply by filling our form. The development team will review your applications and decide who to invite. We decided against having the Discord server public in order to keep the discussions productive and avoid having too many random people discussing things without actually being there to contribute themselves. How strict we’ll be when selecting who to invite depends a lot on how many applications we’ll get. But there is no need to be shy to send one! It is also alright to send a new application later if your first was denied and your situation changed since then in some relevant way - for instance you learned new skills, started working on a new mod, joined a team which has other members already part of the initiative and so on. We can reconsider. Next, we have private GitHub repositories for the game and the scripts. Git is a version control system - if you’re not familiar with it, here is a nice introduction video. You don’t necessarily need to have previous Git experience to contribute. You will only need the basics mentioned in the video and a bit about submodules which we will explain. We can help you learn more if it becomes relevant. Our motivation is to invite the authors of the large mods who often need to make many changes to the scripts and tend to add new features or fix bugs that should preferably be made in the base game instead. This is also intended to be the place where we give you some support to update your mods to the new engine and give you tips on how to maintain the mods afterwards in order to make future updates easier. And some good practices to have your mod compatible with online features and such. Challenge runners who often find or hear about a bug and aren’t shy to dig into the code to fix it are also very welcome. This is how Stardust started after all! But the initiative is by no means limited to these cases. If you just want to try and help make the game better, you can. Some examples: We want to make modding easy and who would know better what’s needed than the modders, right? The engine should have Gen 9 battle mechanics implemented for usage by mods even if not by Reborn base game. Rejuvenation or Desolation might also want to add Gen 9 in a future release. Gen 8 dynamic speed mechanic. We still don’t have it implemented in the engine even though Rejuvenation and Desolation are using Gen 8. Reborn doesn’t have a quest log like Rejuv and Deso. But if the community implements one it could become part of the game. Text-to-speech support for blind players doesn’t work for all game screens and features yet. It would really help them to have the rest implemented. We also have other ideas on how to improve their experience. Contributing to graphics and other assets. We could use a few spriters to help out with some work. For instance we’d like to update the overworld player sprites and will need some help to create all the variants (running, bike, surf, mine cart, fishing, riding). Fixing bugs discovered by yourself, the devs or the community. Your own idea which you think might be good for the base game! Even if the feature may not be suitable for all players we might still accept it as a password. And last but certainly not least, this is also a good opportunity for those who would like to join our team as actual developers. If we’re happy with your contributions, it’s a real possibility. Of course not every suggested change will actually appear in the main game. Our team will discuss the ideas with you, review the changes and decide if both the idea and the actual implementation are something we want to include. Application form: https://docs.google.com/forms/d/e/1FAIpQLSfwtMIEZTDqEEdBDHTELuoSawaO2tKPOAP3HAgamS52XgG97w/viewform FAQ: > How demanding is the role? How much time do you expect the applicants to dedicate to this project? You're not applying to become a dev here. There are no big expectations, we do understand ppl are busy and modders already dedicate lot of time to their mods. Occasional contribution is enough. It would be nice to have some regular contributors as well but it doesn't need to be everyone.

Hi everyone, today we have a mix of improvements. Most of them come from Lucent but there are some bits from the rest of us too. But let’s start with what Lucent prepared for you! Hey y’all! I’m Lucent (formerly Luke Duke, but feel free to call me whatever you’d like). I was introduced to this game shortly after starting college. A friend was showing me Reborn’s latest gym battle (Episode 17 at the time) on his laptop. It was a double battle that took place in an underwater arena! Needless to say, this game grew on me in an instant and it means a great deal to me today. I was grateful to recently find an opportunity to help contribute to the next update. This post will showcase some of my contributions that I find worth sharing today, as well as some very important features stardust and enu have been hard at work on. Online Play The Online Play experience has been touched up. There were internal refactors to some data structures that warranted updates to the online scripts, and once online functionality was restored, more work was needed to fix some issues that trainers reported over time. I can’t even begin to give enough credit to enu for handling the work for setting up the server environment for development, deployment, and automation. Lots of these improvements aren’t too flashy, but here’s a few to take a peek at. The server has undergone some security improvements. You will need to reregister your account for online play when the update releases. All online battling and trading will attempt to connect you to another trainer with a matching game configuration. For example, if you decide to wonder trade while using a mod with an expanded dex, the server will handle it and set you up to trade with a trainer using the same mod. There are checks to help make sure trades stay legal for the safety of the recipient. Online battle handling has been improved, fixing many graphical and sync issues. The game client no longer accepts battle requests while waiting for a trade, and vice versa. The goals of these improvements are to improve online stability and to allow all future versions of Reborn to safely hop online without any worries about incompatibilities. I hope that these improvements will properly accommodate the already-existing online player base and invite even more to join in on the fun! Battle Inspect Many of you reading this post have likely played Rejuvenation. It has a battle feature that I really appreciate: Inspect! You select a battler and view more detailed information about them! Shoutouts to DemICE for creating this awesome feature. Inspecting is useful when attempting to track everything going on in a battle. How many turns of rain and tailwind are left? Did that Hawlucha activate Unburden? What field is under the one we’re fighting on? Now all of this information will be at your fingertips while playing Reborn. We’ve also changed the control scheme for the inspect feature, utilizing the Q and W keys (that’s L1 and R1 on controller) instead of pressing the S key (Triangle/Y) to pull up the selector. Please give us feedback on this after trying it out. We want to make this feature feel the best it can. (enu’s note: The idea behind using Q / W is to skip the selection steps and get to inspection of any battler with a maximum of two keypresses instead of up to four as Reju has it.) …Have you noticed the button above the text box yet? Field Notes in Battle Here’s something I’m really excited to show off. You will now be able to open up the Field App during battle! Trainers can press the S key to open their app and read notes on the active field if the corresponding readout has been collected. Make sure to find all of the field notes or use the “fieldapp” password to unlock them all. This feature also works with the PULSE Dex, letting you press the D key (Right Stick) to view notes about any foe PULSE machine inhabitants. These features are also programmed with page navigation in case more than one field is in play. That’s all I’ll share for today, but rest assured there’s plenty more to be excited for. I sincerely hope you all enjoy these new features. I’m personally going to love using the inspect feature alongside in-game field notes for my next run of the game. patch directory Hi, stardust here! If you’ve ever modded Reborn before, you’re probably familiar with the old way to install mods: either having an entirely separate copy of the game with the mod (common for bigger mods) or overwriting the game files with the assets/code/data you wanted to change. Script modifications could alternatively go in a Mods folder in the Data folder to allow modders to only work with the functions they needed to modify, but nothing else got that special treatment. This is not the most convenient thing, with one particular issue being that it’s really hard to get rid of any mod that’s not a script mod: either you had the foresight to keep the original files that you ended up overwriting, or you have to reinstall the entire game. Also, modded files might get overwritten when you update the game (which is particularly relevant now that the game is actually updating again). As of v19.5, however, this won’t be the case, because mods now have their own “patch” folder where they can override the base game assets without you actually needing to mess with the main game files! This isn’t technically a new feature we added: mkxp (the engine Reborn runs on) and Joiplay already have this functionality via a patch folder, and it only took a few modifications to our own code to get it working. (As the name might suggest, it was originally meant for dev-released patches, but the in-built updater takes care of that for us. Unfortunately, we can’t change the folder name on Joiplay.) This only works for assets but not scripts. Script mods still work as they used to, except that we moved the directory for mod scripts from Data/Mods to patch/Mods. There will be a text file with more detailed instructions in the game folder when the update is released, but the basic idea is that the files you want to modify/add go in the patch folder, following the same subfolder structure as the base game. Shortcut keys Enu again! I want to share a small improvement I implemented. You remember how I mentioned game controls improvements in one of the previous blog posts? Well this is a little follow-up to that. I implemented an improvement to Party screen and Storage. You can now use keys to quickly perform the most common actions and not go through the menu all the time. You can now use A for the Move / Switch action, S for Item action and D for Summary. Additionally in the PC Storage you can use Q to add/remove a mon from Multi-move selection and W to Store / Withdraw. That’s all for today. We have one more important announcement to make before the release, mainly for the modding community. Stay tuned!

The idea of adding some accessibility features for players with sight handicap has been briefly discussed a few times but there was always one main blocker. There is not much point in that unless there is a TTS (text-to-speech) functionality to let blind players hear the dialogues and menus. Ame linked a library that could be used to send a text to a screen reader called NVDA to read the text out loud. But since it wasn’t a Ruby library, just a DLL, we had no way to actually use it. Encoding the Endians! However during my previous tweaks of mkxp-z I randomly stumbled upon FFI bindings. I had no clue mkxp-z even had this feature but I immediately knew this might become useful. FFI means Foreign Function Interface. It lets you call functions from shared libraries, even if they were written in a completely different programming language than what you’re working with. So I made a note that FFI exists in mkxp-z but didn’t investigate further at the time as I had other priorities like actually fixing the game or onboarding the new team members. Also I just roughly knew what FFI was but never actually used it myself so I didn’t have practical experience with it. Few months later a blind player joined Ame’s Patreon so the topic of accessibility was discussed once more. But once again I thought there is no point without TTS but since I had that hunch that it might be possible with FFI, I went ahead and tried it. And it didn’t work. So I did more research and tried various tweaks but still nothing. Only suddenly, after an hour or so, the library started talking. Except not really. Instead of the text I was feeding it it only read the last letter. Ehm what ??? Of course I had no clue what was going on but thought that the mkxp-z community might have some idea so I asked them. We were brainstorming the issue for a while before the mkxp-z maintainer Splendide Imaginarius had the correct idea that it’s an encoding issue. Here I should make a short note of what an encoding is. Basically an encoding determines how letters and other text symbols are represented in memory and are often language-specific. Ruby comes from linux so it is generally using UTF-8. He had a theory that the library was instead expecting UTF-16. It didn’t work either but after some more trial and error I finally stumbled on a trick that actually fixed it. The library didn’t want just UTF-16 but specifically UTF-16LE where LE stands for Little Endian. See the issue was not just encoding but also endianness. Endianness affects the internal order of bytes in memory. This is an oversimplification but basically Windows is using the reverse order (Little Endian) than most other systems (Big Endian). And since Ruby originates from the Linux world, it is using Big Endian internally. So with explicit UTF-16LE encoding TTS using NVDA finally worked. [image description for blind players: It's a Discord screenshot with AiedailEclipsed saying: "enumag once again destroying everything in his path. great job!"] Of course all of this is windows-only since we didn’t find any equivalents for other platforms but Windows is the most important in this case anyway. The roadmap With that proof of concept, accessibility suddenly became a realistic topic so we started working on it. Accessibility ofc isn’t just about TTS. We also integrated an existing mod from Torre which adds some ambient sounds to help the blind players know the distance from the closest obstacle in each direction. That was still just the first step though. I might have kickstarted it but from here on it was a team work where everyone contributed some parts. For TTS I pretty much just figured out the proof of concept. It was Cad48 who did the heavy lifting to add the TTS calls throughout most of the codebase. And there was a lot more than that. Some of the features we implemented because of accessibility made sense for all players - for instance puzzle skipping because even with TTS and other improvements there is no way blind players will be able to solve the puzzles. Text-to-speech Hi! Cad here. I don’t have a whole lot to say– a lot of what’s happened so far has been fairly simple. Did you know there’s a lot of text in this game, displayed in a lot of different ways? There is! Messages, choices, battle, shop screen, town map, dex, field notes, gear apps, jukebox, tile puzzles… Most of what I’ve done for accessibility has been TTS calls on various pieces of this text– but there’s still a lot to be done. I also implemented a few other accessibility features for blind folks, such as Itemfinder now giving a message, but there’s still a lot to be done in that regard as well. enu’s note: Cad really spent a lot of time on adding TTS calls to all the core parts of the game like dialogue, choices, battle, bag, move learning and so on. Later on both Lucent Flash and Stardust also made significant contributions for adding TTS support to various menus. If I remember correctly I think Stardust handled the Time & Weather app + Jukebox while Lucent took the most complicated part which was the field notes. Puzzle skips This is a project I (hi, stardust here!) have been working on for quite a while, but became more relevant with the push towards making the game more accessible. If you’re not aware, Reborn has a new game plus (NG+) feature that keeps track of whether you’ve done some specific puzzles/sidequests on previous saves so that you can skip them on future playthroughs. A couple months after Reborn e19 came out, I started work on an NG++ mod that added more puzzle skips, and this mod will be integrated into the base game in 19.5 Reborn. One of the big limitations of this feature is that it only applies to repeat playthroughs: first-timers are out of luck. And while I may consider Reborn’s puzzles a core part of the experience, I (and the rest of the dev team) am aware that not everyone shares that opinion. Especially blind players, for whom many of the puzzles are much more difficult or near-impossible without someone else helping them through. [image description for blind players: Just showing off the "Do you want to skip this tile puzzle?" option you get in Agate Circus with blindstep password] Recently, I went through (hopefully) all of Reborn’s various puzzles, looking at which could and should be skippable to help improve player experiences. The result: as of v19.5, there will be a new password to add to your games: “nopuzzles”, which activates nearly all the NG+ skips (old and new) without needing save data, in addition to a couple minor skips not covered by the NG+ feature. This feature is also activated with the blindstep accessibility password mentioned later. [image description for blind players: Showing passwords menu with active nopuzzles password] There’s also a few additional NG+ puzzle skips that you’ll be able to find scattered around the game. In total, between the existing, new, and password-specific ones, there’s over 40 such skips in the new version. blindstep password Next we needed a way for the blind players to activate the improvements we added for them specifically such as the mod from Torre. This is what the blindstep password is for. It also enables several other things we implemented such as custom item finder by Cad, separate fly menu because the map was a bit difficult for them and some other things. Then there is the F9 key to get the current map and coordinates read to them for navigation… And of course the password also activates stardust’s puzzle skips. [image description for blind players: Showing the custom fly menu for blindstep password] TTS actually isn’t locked behind this password. It’s enabled by default but for most players it has no effect because they don’t have a screen reader such as NVDA running on their PC. Contextual sounds Enu again although this isn’t just my work. Next we needed to improve the sound effects. For example the bump sounds needed to be different based on what you bump into. So stardust implemented a feature where if you bump into an obstacle the game can detect what you bump into and use a different sound based on if it was an NPC, a strength boulder, an item or like 10 other different things we accounted for. This is an improvement for all players so it’s not restricted to the blindstep password. Next we also needed a way for blind players to know when they’re on a diving spot so the game is now able to play a background sound while you’re in a place where you can dive or resurface. Again no need to restrict this for blindstep password. Then there are sound effects when you jump over the jumping stones - along with a dust animation for sighted players. There is also new debris animation for rock climbs. Both of these improvements were only possible thanks to eevee because doing it all manually would be madness. Also fishing has some sound effects now so that blind players can actually catch their Lanturns. In all cases Amethyst is providing the actual sound effects! Tolk During testing one of the blind players also recommended a library to support more screen readers than just NVDA. There are actually two libraries - Tolk and Universal Speech. I went with Tolk for now but there doesn’t seem to be much difference between them. What it does is that it detects the screen reader you’re using and sends the line to it for TTS. There are still a lot more improvements we can do. Certain menus still don’t have full TTS support, minigames such as game corner or mining need a skip, we should have a way to detect doors, itemfinder should detect non-hidden items, maybe a key to replay the last line, sound effect when activating or deactivating turbo mode… the list goes on. Let us know if you’d like to help with this effort. We’re slowly working on these tasks but we have other features to work on as well so this isn’t our only focus. Any such improvement means a lot to these players.

Alright, enough of the boring dev-ops things. I needed to get it out of the way first because all that setup was a pre-requisite for the changes I’ll talk about today. The dev-ops features were already used in Rejuvenation 13.5. On the other hand these improvements are brand new in Reborn 19.5. Rejuvenation and Desolation will of course get them as well when they make their next releases. That said, some of these features would not have been possible without all the dev-ops work. JoiPlay One thing we noticed when Rejuvenation 13.5 came out was that quite a few people tried to play on Android using JoiPlay. This was on my radar for a while, but I didn’t know there were so many people who wanted to play on their phone so it didn’t seem important. Well, I clearly underestimated the demand. Several times a day someone asked on either Rejuv’s or JoiPlay’s Discord about how to make it work. I reached out to the person who prepared the fixing patch who is quite knowledgeable regarding JoiPlay and got a lot of useful info about how I can make the games run better on JoiPlay and how to set up default controls. Because of this, the next major releases of all three games will come out with an experimental JoiPlay version, set up with good default controls and a few other tweaks. For instance, JoiPlay has a feature where it can optimize the tilesets to be smaller to fix some problems. I took the script they’re using, added it into eevee (also fixed three minor bugs I found in the script) and made our workflows automatically prepare these optimized tilesets when building a release. This involved some more technicalities such as building a Docker image for eevee where I had to compile a library which has been unmaintained for 11 years but let’s skip these dev-ops details. I also tried to set up good default controls while using JoiPlay with a gamepad. Here I’m not actually sure if and how well it works because JoiPlay can only recognize around half of the buttons of my Dual Sense. With a different gamepad it might work better but I can’t test it myself. Feedback will be appreciated when this comes out. Improved controls The nice thing about the new mkxp-z setup is that it’s now much easier for us to update it to a newer version and to make occasional custom tweaks when needed. For instance I wanted to tweak the default controls because it always bugged me that the Previous Page and Next Page (for pokedex, bag etc.) were only bound to Q and W but not to Page Up and Page Down by default. These defaults are baked in mkxp-z’s source code. Yes, players can add them through the F1 menu but I wanted to improve the defaults. Also not all things can be changed through the F1 menu because for instance the F12 soft reset is an internal function of mkxp-z which you can’t rebind. This meant there was no way to soft reset while using a gamepad except for some clunky external programs where you would make a gamepad button trigger F12. I tweaked our mkxp-z fork so that a gamepad guide button triggers soft-reset. Then I went through the default controls for both keyboard and gamepad, discussed it with the team a little and changed a few default keybinds to make more sense. Keyboard only got small changes while the gamepad controls were tweaked quite a bit. Also after some research I found out that I can actually detect the strength of the press on a gamepad L2 and R2 buttons. This is a bit of an experiment but I made turbo speed dynamic depending how strong you hold L2. This might be a subject to change depending on player feedback but we can adjust it quite easily. There is another button to make turbo permanent without holding anything if you prefer that. During the game intro there is this screen with the default controls, right? Except it was a bit outdated because it was an image which was difficult to edit. And there was no such screen for gamepad controls. So I scrapped that and made a new screen which is up to date and actually generated by code so it’s easy to edit later. Then a second one for gamepads. And you can access them any time, not just during the game intro. There are a few conditions in there to account for game differences because Reborn has rotating tile puzzles while the other two don't. Old screen from Rejuv (quite a few keys are incorrect here): New screens: (note: small mistake there, first line should be C / Enter / Space instead) One new thing you can notice among keyboard controls is that you can now quickly go through long menus such as pokedex or debug menus using Ctrl+Q/W (or R2+L1/R1 on gamepad) to skip 10 pages at once. Another nice change is that some minigames such as rotation puzzles and mining have their special actions like tile rotation or mining tool switch bound to several buttons at once so that you don’t need to think too hard about which button to use. Sorry for those blacked out parts. Those are some new features Lucent implemented recently. They’ll be revealed in another post! Built-in updater Reborn e19 came with an updater (shout out to Aie who wrote this) which you could use to get patches. It did its job well but had some issues such as mac support. Later on when Desolation 6 was about to come out I whipped up my own updater called gogoat. (It’s written in Golang so why not continue the Pokemon naming convention, right?) After some tweaks, this worked on mac as well by the time Rejuvenation 13.5 entered testing. However the problem was that even this would be clunky on Android even if I could compile it to run there. If we were to make a release for JoiPlay I wanted the patches to be easily available there as well. So back to the drawing board. The JoiPlay community member I mentioned earlier came up with an idea to download and apply a patch from a preload script. This was a cool proof of concept, but if we can make the game update itself, it should work that way on all platforms. It sounds very cool and user-friendly so I wanted to see if it was feasible. To achieve this I basically needed two things: To download a patch and to unzip it, meaning an HTTP client and a zip library. An HTTP client is like a web browser for programs. It makes a request to a server and gets a response back– in our case, the patch zip. Sounds pretty easy, but it turned out to be around 100 times more complicated than it has any right to be. Why? Because the Ruby instance which mkxp-z and JoiPlay are running internally is severely restricted. Neither an HTTP client nor an unzipping library is available in mkxp-z. Well, technically, mkxp-z has HTTPLite, but you can’t really use that for file downloads. So I reached out to the mkxp-z community and, after some trial and error, we managed to get Ruby’s standard library working in mkxp-z on all three platforms. This contains an HTTP client. The rubyzip gem is written purely in ruby so we could just copy its source code and get it working as well. However, this didn’t support HTTPS. (a security layer for web browsing that's very important.) After a while, and some more help from the mkxp-z maintainer, I managed to patch it to make openssl available, and HTTPS was working correctly. It didn’t have root certificates, but I can get those elsewhere. (These are needed for openssl to decide if the server can be trusted.) So, in the next release you might see directories called stdlib and gems, two new dlls for openssl and crypto and a cacert file. All of that is purely for the built-in updater to work. But, even if it’s quite a few extra files, it’s only around 15 MBs total so it's not a big deal. Alright, now that mkxp-z is done, let’s get back to JoiPlay. While there is no way to get Ruby’s entire standard library running on JoiPlay, it actually comes with an additional method called HTTPLite.download built-in. So it should be easier to download the patch there, right? Wrong. For one, while it does make HTTPS requests, I suspect it doesn’t actually check whether the certificate is valid. However, I can neither verify that nor do anything about it. At least it works, except for one important detail. In some cases (patreon-only builds) we also need to send an additional authorization header to the server with an access password. The download method does have a headers argument, but it’s broken and the headers are not actually sent. So I had to implement some server-side band-aid to accept the authorization in the url instead of a header. As for unzipping it, while the rubyzip gem doesn’t fully work on JoiPlay because some dependencies are missing and impossible to add, the important part– unzipping– does actually work, after a few tweaks in the code to suppress unrelated errors. Finally, after all of this, the new built-in updater seems to work correctly on all four platforms. JoiPlay still had several nasty issues during the beta - optimized tilesets were not updating meaning the game essentially never got any map updates. Then a new JoiPlay built completely broke loading of Ruby libraries. I fixed that and a week later it broke again. Luckily, we had a JoiPlay player in the beta (ty reispher!) who helped me with testing all of it. This is where Ame’s quote at the top came from. I really really hope this won’t fall apart due to some unforeseen and unfixable problem. Fingers crossed! To clarify, this updater is intended only for bugfix patches as it cannot update the Game.exe itself or its equivalents on other platforms. Updating from 19.5.0-rc.0 community release to 19.5.0 stable release will still require manual installation. Same for updating to 19.6.0 or 20.0.0 later on. Favorite Items For a long time, I didn’t like the fact that the first bag pocket is used for way too many items, some of which are mostly useless, while others are often the best in the game. I often had trouble finding the useful ones among the rest. On the other hand, the X-Items pocket only had a very few items. It felt like they didn't even deserve their own pocket. Most challenge runners don’t even use these items to begin with, making the pocket utterly useless for some. So, in this update, X-Items are moved into the Medicine pocket. The Battle Items pocket has been repurposed for a new Favorite Items pocket. You now have the option to mark any item in any pocket as Favorite which will make it show up in the Favorite Items pocket in addition to its normal location. Discord integration Another project I was working on was Discord integration. Discord has a feature called “Rich Presence”. A game can use this to tell Discord some details of what you’re doing in the game and have the details shown as your status. With this Discord can show which area of Reborn you’re currently exploring or which trainer you’re fighting. As usual, we had some complications while setting this up. Aie did all the hard work around what the game will actually report. My part was making sure the integration works on all platforms where Discord’s SDK is available. I cooperated with rainefall, the author of the extension which sits between our scripts and Discord’s SDK. Our scripts are written in Ruby programming language and this extension is a Ruby gem (library) written in the C programming language. Compiling this extension for Windows, Linux and MacOS in a way that actually worked required some adjustments for each platform. Admittedly, rainefall was the one making the breakthrough in all three cases as I know next to nothing about C. Still, I did plenty of work on testing it, setting up the automated compilation and researching possible causes for the issues we saw. For Windows, it actually needs to be done as part of the mkxp-z compilation pipeline or at least using mkxp-z’s fork of Ruby. Linux required some special flags for the C compiler. MacOS was, as usual, the most problematic because not only did we have to make sure it works on both AMD and ARM processors, but the compiler somehow insisted on linking some required libraries using an absolute path rather than relative, which makes no sense. Still no clue if there is a way to tell the compiler to not do that but after more research I found a tool capable of fixing the link. It was quite a relief when we actually had a setup working for all three desktop platforms. So, Reborn 19.5 will come with this feature included. There is an option to disable it of course. The leaders of the Rejuvenation and Desolation teams also seemed interested so there is a good chance for this to eventually drop in those games as well. Hopefully you’ll enjoy the improvements! We still have quite a bit more to show you so keep an eye on this blog for more posts!

In my first post I mentioned that I’m the dev-ops guy. But what does that even mean? Most of the playerbase likely won’t be familiar with it or only have a vague idea. So in this post I’d like to give you some insight into what I’m doing for the team. Part of it is, of course, Eevee which I introduced last time. Another part of my work is about automating boring repetitive stuff like releases which need to be done very carefully and are very easy to mess up. Aside from actual game scripts, maps and graphics there are a lot of other parts that need to work correctly. Typically, compilation for all four platforms including all the libraries and binaries the game is using internally. The requirements have increased dramatically because of some of our new features and it would be next to impossible to maintain all of that manually across three games and four platforms. Disclaimer: Some of this will be very technical but if you’re curious what developing these games involves behind the scenes it can be interesting nonetheless. It could also be good for other game authors and modders to see how automation can help them. Patches After the initial version of eevee, the next thing on my hit list was the release process. I wanted to automate the process of detecting all files that were changed, zip it and upload the zip somewhere for the players to download. The first part was this Git command: git diff --name-only --diff-filter=ACMRTUX <commit>..HEAD Git knows the entire history of the codebase so you can get some interesting data from it. In this case the command above gives you a list of all the files that were changed since the given commit. Normally I’d feed the result to another command that would zip all those files– however, with eevee involved it’s not as easy because Git would give you the yaml / ruby files instead of the rxdata files that the players need. So, I wrote the logic to generate a patch into eevee directly. It uses this command internally but then detects which files need to be replaced by rxdata files in the patch. GitHub Actions Even when you have the patch zip you still need to upload it somewhere. And while we’re at it why would you even make the zip yourself even when it’s faster using the command? Software developers automate all of it these days. GitHub Actions can do exactly that so I wrote a simple workflow that would trigger any time Ame tagged a new release in Git, use eevee to generate a patch and immediately upload it to her server where the players can get it. With that making a new patch was just a few clicks, Ame could focus more on e19 development and easily release several patches per hour if she felt like it. I think we first used this for Reborn’s e19 public release. Since then the workflow has evolved a lot. Desolation e6 and Rejuvenation v13.5 were also using some newer versions of this and I made even more changes for the upcoming version of Reborn. Of course, now it’s mostly me and the new team actually triggering the workflow. mkxp-z With eevee and my release workflow being adopted by Rejuv and Deso I suddenly had Git access to not just Reborn but all three games. So… time for more fun, right? The workflow I mentioned above could only handle the small incremental patches; the main releases of Reborn e19 and Desolation e6 were still handled manually. Changing that would be a much bigger fish to catch– more like a whale, in fact. The main complication is that the games are not Windows-only but also have macOS and Linux releases. It wasn’t enough to just remove the dev-specific files and zip the rest because the repository didn’t contain the runtimes for the other platforms. The engine the games are using for runtime is called mkxp-z. It can be built for all three platforms and compiling it is not an easy process. Particularly because to compile it for a particular platform you need to compile it on that platform. And I don’t have a mac. There are pre-compiled versions of it available but to complicate things further the games are using a modified version of mkxp-z so that they could have a custom game icon and increased frame rate cap. If only there was a way to compile this automatically with our modifications, right? Well, guess what, there is. The maintainers of mkxp-z have their own GitHub Actions workflows to compile that thing for all platforms, so I didn’t need my own mac. I just forked it, applied the tweaks we needed and soon I was able to get a compiled version for Rejuv. It took several tries and each compilation takes over an hour because mkxp-z is a beast, but it worked. Afterwards I could set up another workflow to combine the compiled mkxp-z with the game files. A couple test versions later and we could fully automate Rejuvenation’s main release 13.5.0 for all platforms; no need for Jan, Cass or anyone else to painstakingly prepare it on their own. I won’t share the workflows here as I’m still working on some details for the community release. But there is no harm in sharing these so in case you want to set up some automation like this for your own mods or games and you feel getting your hand on our workflows would help, hit me on Discord. Engine tweaks This ended up opening several more possibilities in the future. For instance, I was able to adjust the default controls of the game which are baked into mkxp-z’s source code itself. Next I was able to make it so that the engine contained some extra libraries which we needed for some other new features– more on those in the next post! Then there was the very controversial topic of input repeat– how often an action is repeated while holding down a key. This has a big impact on how fast you can scroll through Bag and debug menus. The mkxp-z defaults (which were used in Rejuvenation 13.5) are too slow, while Reborn e19 had it adjusted for debug convenience which was slightly too fast. In our mkxp-z fork I was able to change these settings to be configurable in the mkxp.json file. So, while the default input repeat is ultimately set somewhere in between the normal defaults and Reborn e19 speed, you can now adjust it to your liking. And finally it means we can fix some bugs in the engine. It’s written in C++ which I’m not familiar with so my options are limited but I can tweak a line or two when we find a problem. Segmentation Fault hunt First I should clarify what a segmentation fault even is. I’m no expert on this topic, but from my understanding a segfault happens when a program tries to access an area of memory it doesn't have access to, causing the operating system to kill the program. In general, there is next to no way to recover from these errors because the system just kills the program with no chance to react. In general, these happen only when incorrectly using some low-level things such as pointers in C. Higher level programming languages such as Ruby, Javascript, PHP, Go and so on generally won’t let you mess up like that, and if it does happen anyway it usually means there is a bug in the language itself. Well guess what? We had a segmentation fault in Reborn during 19.5 alpha. You know how the game sometimes shows a popup with an error message? Those are our errors in the Ruby code and generally not a big issue. Segfaults instead just end the game: no popup, no message in the log, nothing. This signifies a bug in the game engine itself - mkxp-z. To make things worse, we didn’t have a reliable way to reproduce the error, it just sometimes happened during or after a battle with no consistency. Sometimes you could play for a week without getting a crash, other times you could get it three times in a day. (Like I did! -editor Cad) There are, of course, some ways to debug these cases. I consulted the mkxp-z devs about this issue and was able to make a mkxp-z build with debug symbols. Debug symbols are basically a mapping between the compiled program and the original source code, so if a segfault happens the GNU Debugger (gdb) can be used to process the core dump and find the lines in the original code where the problem occurred. It took a few more hours but I did manage to get a gdb backtrace of the issue. With that additional info we eventually discovered that someone else from the mkxp-z community already had a fix for the problem (which had to do with certain move animations accessing invalid files). Without the backtrace, there was no way to know what to look for, so we wouldn’t have found the connection between the issue and the available patch. The game has been stable ever since, so it was well worth it. And, because I already had all the infrastructure around our own mkxp-z fork already developed, I was able to simply merge the patch into the fork and use the fixed mkxp-z in the 19.5 beta release for Ame’s patrons. That’s all for today! Sorry if my posts are more technically oriented. Next time I’ll finally get into some improvements for the players! If you have some questions feel free to ask in the comments or Discord DMs.

“The dev blog was a bit desolate, but now we've rejuvenated it to let y'all know about reborn Reborn.” ~ Stardust Time for another blog post! Today I’d like to introduce a development tool which we have been using internally for almost two years. Reborn was my guinea pig here but both Rejuvenation and Desolation are using it as well these days. Big thanks to Ame that she was willing to try this out on her game even though I was just an alpha tester at the time and the e19 release period was very busy! This one is meant especially for those of you who maintain large mods that include map changes and creators of their own games. Several features we’ll be introducing in the 19.5 update and more features that we’re planning for later would not have been possible without this tool. The problem In my previous post I mentioned that the team is using a version control system called Git. It’s an essential tool for any kind of software development. It lets you keep track of every change that was ever done to the game with the possibility to go back and see the changes, merge together the work of several teammates, and so on. One notable thing about Git is that it works well with text files but not with binary files. Such files are basically computer gibberish which can mean anything and therefore is unreadable for Git. Think images, audio, video, executable and so on. The issue with RPG Maker XP (the editor which is used to create these games) is that it stores maps and some other things in a binary format. You know, the .rxdata files in the Data directory of the game? Yeah, those. I didn’t like that so after some research I found a super old tool capable of decoding them. So I forked that, made it more useful for actual development and called it the Easy Essentials VErsioning Engine, aka Eevee. Eevee basics Now what can this little fella do for you? Well it can transform .rxdata files to a text format and vice-versa. Git is very good at versioning text: it can track when each line was changed, who did it, let you merge changes from two people even in a single file and so on. So for Git to be able to work with maps it was very important to have the maps in a text format. For the team this is very important as it allows us to have several long-term projects that need a lot of map changes in separate git branches and we can easily sync them with whatever changes we make in the main branch. Synchronizing that without Eevee would be a nightmare and very prone to accidentally undoing someone’s work. But this way we can easily keep everything up to date internally as a part of our routine and those long-term projects can spend as much time in the oven as they need without causing any problems. Another no less important advantage is that text files are human-readable and search-able. Wanna know all the places where you can obtain a particular item? Find all events where a mon is removed because all of those were bugged? (Yes they are all bugged in Reborn 19.0.16.) We can do that! The format Now originally the format eevee produced was simply YAML. Which was okay but I didn’t have full control over the output so it still contained a lot of extra gibberish. However, near the end of last year I finally sat down and implemented a custom format for Eevee which makes it even more useful. It allowed me to make many custom improvements to the format for easier usage - making sure that important data is there in a readable form while useless and redundant data from the old yamls is simply cut. For example all the options that can have one of a limited number of options in RPG maker are transformed from their internal number representation into text here for much better readability. To give you an idea what a map looks like in this format, here is Lapis Gym in the new format (scroll down a bit, the events at the top aren’t very interesting). You can see all the dialogue and all other data the map contains. We can also easily find all the places where a particular switch or variable is used or where a particular audio track is played. And finally, it allows doing some bulk changes by simply string replacing across the entire project. For instance, some typos were in many places all throughout the game. There are three other things worth pointing out in the example file. Firstly, the comment at the top of the file shows you where to find the map in question in RPG Maker. Secondly, unlike the rxdata files, the filename also contains the name of the map. Other features Eevee is also able to run in the background while you’re working in RPG Maker and output your changes to ruby files on the fly. There are more features which you can read about in Eevee’s documentation if the tool looks useful to you! We use it to generate patches and validate our maps so that they don’t contain common errors. There is also a guide to help update your modded maps to the new version of the game. It’s not an easy process but for large mods it should be a lot faster and cause less issues than redoing all the work manually. The source-code is entirely open on GitHub so you can see how it works internally and help improve it if you find a problem.

Hi, Community! This might come as a bit of a surprise. Almost two years since e19, is it? Can't blame you if you thought the game was done. Admittedly there was a hiatus for a while and we have been a bit quiet about the recent revival, but the game is very much alive now. In fact, we're planning a new release in the not too distant future. Wait, who is this random person? Right, I never wrote here before... Well, hi! Enu here. I'm the dev-ops guy. While my main focus is Reborn, most of my work benefits Rejuvenation and Desolation as well. I created some tools that make the development and release process easier for the teams and later I also worked on improving some aspects of the player experience. I first found Reborn around episode 14 and it quickly became my favorite Poké game. Occasionally I tried to look into some bugs that were really annoying - the veterans among you might remember them. The long text lines where the first part disappeared before you could read it? Or funky NPC follower movement, especially around ledges? I helped out with those. Also I know Git quite well (it’s a version control system, a great thing for software development) so when Ame's team started to use it I gave her an introduction about what it can do. Later when she started talking about episode 19 alpha on Patreon I half jokingly asked where to apply. I didn’t really expect to get in but thanks to those past involvements Ame actually did invite me into the alpha testing group. What happened afterwards was that I stayed active even after alpha testing concluded, wrote some tools for the team and kept working on fixing bugs even after the e19 release cycle finished. In the meantime most of the original Reborn team moved on to other projects though a few of them still make a change or two occasionally. Desolation and Rejuvenation teams were working hard on their respective updates. I helped with updating the games to take advantage of the new tools we had available. And eventually after these updates were released I ended up building a new team for Reborn together with Ame. So what is this update about? First to avoid too-high expectations, this is not a story update. There are only a few dialogue changes overall - such as new NPCs mentioning new passwords. There is no big graphical overhaul, no new gen or something either. The game still looks and plays the same. Our main focus was the engine. Modders might have noticed that latest versions of Desolation and Rejuvenation have a very different code base than Reborn e19 had. It was mostly Cass and the Reju / Deso teams who did the engine overhaul. This update gets Reborn running on this new engine as well. The main benefit is that the engine is shared between the three games which means that future bug fixes and even some features can easily be applied to all three games. In fact many of the new features coming to Reborn will appear in the other games as well in their next update! This way we'll all have a good base for future updates and benefit from the hard work of the other teams. The new engine should also make the creation of new mods easier than ever. For players, this update brings many long-requested QoL features, a couple of new passwords, improved controller support, accessibility improvements and an official (if experimental) JoiPlay version to be played on Android among other things. More about these in upcoming blog posts! We also fixed hundreds of bugs - both in overworld and in battle. Small clarification about version numbers. Reborn e19 had versions 19.00 to 19.16. However, they should have been 19.0.0 to 19.0.16. The convention was just incorrect back then. The new update will be version 19.5.0. Introducing new team Amethyst No introduction needed! As you all know Amethyst mostly moved on to work on Starlight. So while setting up the new team my main goal was to do it in a way that the team is capable of working without Amethyst keeping an eye on all the details. She makes some changes herself every now and then and we make sure to ask her about priorities, what features she wants included and other decision making. This way we can keep making the game better but still very much in line with her vision and wishes. Other than that her hands are free to work on what she wants and not lose time on minor details that don't necessarily need her attention. Crim A veteran from the original team! Many things from e19 and before are their handiwork and we’re very lucky to still have them on the team. Crim has the skills to do just about anything the game needs - graphics, animations, mapping, story writing and scripting. They’re looking into tweaking many of these aspects in the future and we’re very excited to see it. stardust A very experienced Reborn challenge runner! She’ll often take note of random battle bugs either from her own runs or community conversations, then go and fix them before we knew the bug even existed! Other than that she's also the author of the NG++ mod for e19. This mod will not be updated for 19.5.0 as it was merged into the main game, along with a number of new skips and improvements. Lucent Flash Lucent is constantly proving his expertise at analyzing... well frankly anything I throw at him. He fixed many random issues and we can rely on him for some larger projects as well. For instance the new engine completely broke many Reborn-specific features such as all Online stuff. Lucent fixed all of that and additionally made it possible for these features to work with the other games and even with large mods that add newer generations or fakemons. Cad48 I'm always amazed about the amount of random trivia that Cad knows about the franchise. It often helps to have him validate how things should work. A large part of the upcoming accessibility improvements are his work, not to mention many other random fixes. Together with Lucent he also added Battle Pavilion bosses for double battles. He’s also been putting a lot of work into ████████████. Haru They're the person behind Randomizer which is also greatly improved in this upcoming release. I don't know all the details but the Randomizer improvements will be revealed when the time comes! Haru also did the hard work of updating the Battle Pavillion and Battle Factory in the Nightclub to the new version of the engine. This alone was a LOT of work. And last but not least, several important engine refactorings are Haru's work as well. Pyrolusite Errr... this is probably a dead give away to what we're planning, isn't it? Can we announce this one early, Ame? Yes, Pyro is the author of the very popular UI mod Pyrolusitium. Yes, he's on the team to improve the UI and we’re very much looking forward to it. Unfortunately, no, it isn't ready just yet and won't be included in this update. It will become part of the game later. ...Oh and myself. I maintain the dev tools, and introduce various initiatives to improve our work. You'll hear more about some of my work in upcoming posts! Some of the old devs also occasionally float in and out to help out with something and we can consult with them when we need to. I don't have an exact date for when this release will go public. There will be a community testing version first because we're still running into random quests being broken because of the engine update every now and then. But overall the game is quite stable now. Thanks for reading and stay tuned for more updates!