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.