Trigger’s Tools & Games (but mostly tools) |

Working with Wiimotes

2019-05-20T23:10:00+00:00

This post is a more in-depth coverage of the Wiimote Experimentation in the 2018: End of Year Wrap-Up (Part 2). The unorganized source code can be found here.

I started fiddling around with Wiimote control to enable playing games from a couch with an easier-to-use controller. It began with looking at existing libraries and how they communicated with the Wiimote. The current system for Wiimote Bluetooth pairing in Windows 7 was a huge hassle of removing and re-adding the device every time it was needed. Wiimotes that have been turned off must be removed from the device list and then re-added in order to be detected, it’s a big chore to manually do this every time so there needed to be an automatic method. This was one of the goals of this project: To create a better system for easily pairing the Wiimote.

Getting Windows 7’s Bluetooth to cooperate with Wiimote connection and disconnection was a huge headache and ended up as a bit of a hack. In the end I succeeded in creating a system to handle this for the user. No more manually removing and re-adding your Wiimote device! The system revolved around asynchronously checking for available Wiimotes every so often and comparing them with the list of registered Wiimotes. During this phase, we also check to see if any registered Wiimotes are no longer detectable. For new Wiimotes, and no-longer-detectable Wiimotes, we manually remove them from the system’s device list. This ensures that we can quickly add them again when we want to connect, or are about to connect.

The bindings display overlay for the Wiimote controller program I created to replace the Xbox 360 controller using this project.

So this task was accomplished, but the hard part wasn’t removing and re-adding the device, the hard part was determining the correct way to remove re-add the device. When searching for answers, there were many different implementations for connecting the Wiimote to Bluetooth automatically, but they were inconsistent and unreliable, some just not working at all. Some did this through the Windows API, while others recommended installing different Bluetooth drivers just for the sake of your Wiimotes. The Toshiba Bluetooth stack wasn’t that great to work with and I decided that it was not the best approach to solving the problem. I only managed to create a stable system after mashing together different Windows Bluetooth API commands over the course of a week or more.

The answer was to:

Remove the device. BluetoothRemoveDevice
Ask Windows for all services usable by the device. BluetoothEnumerateInstalledServices
Set the device’s service state to enabled. BluetoothSetServiceState
Then for some reason, list the device’s services again. BluetoothEnumerateInstalledServices

BluetoothAuthenticateDevice was often a method present in Wiimote connection examples, but it turned out this method was not only unneeded, but actually made things worse. WSA functions are also necessary to determine if the device is discoverable, and unfortunately as of writing this, it seems this method does not work for Windows 10. Although I primarily connect the Wiimote via the DolphinBar for best connectivity, I should look into finding out why it doesn’t work and what has changed. It’s likely a difference in the Windows 10 Bluetooth stack. This just goes to show how big of a headache the Bluetooth programming is in Windows.

The only world this poor test laptop knew of.

One interesting thing I attempted during the lifetime of the project was to modify the existing HID-Wiimote drivers to help support better pairing and passthrough so that the original controls could be retained without registering it as a different controller. It was interesting to learn how difficult it is to develop drivers, but it was also pretty fun. The two main goals of using custom drivers would be potentially better audio playback, and properly handling connecting and disconnecting of the Wiimote without the extra steps.

I took an old unused laptop and managed to hook it up to my main system with a debugger. Then I proceeded to-Your PC ran into a problem and needs to restart, to-Your PC ran into a problem and needs to restart… I crashed the laptop quite a lot. Although in the end I did learn a bit about HID descriptors and how USB devices work. I never made any usable progress with the drivers.

A report inspector used to read logs of Wiimote reports saved from Dolphin, and translate them into something semi-human-readable.

The most interesting part of working with the Wiimote was how communications were handled and how the Wiimote talked to the system over HID reports. The HID reports were pretty much already fully handled in the existing libraries, so I spent more time focusing on the contents of the reports sent by the Wiimote. Wiimote reports are either sent to or from the Wiimote with a report type, and a fixed buffer of data for that report type.

Not all of the Wiimote’s report types were documented, so I had to do a bit of looking and experimenting. The biggest challenges were figuring out certain data types’ units of measurement, and Wiimote extensions. Specifically the WiimotionPlus.

Wiimotion plus has very different behavior from the average Wiimote extension, like the Nunchuk or Classic Controller, because the WiimotionPlus extension could also have another extension attached to it. In order for the Wiimote to receive input from both the MotionPlus and other extension, something called a passthrough is used. In this mode, every other report is the WiimotionPlus data, and every other other report is the connected extension data.

The audio player used to demo the Wiimote’s speakers. Input sounds and music are downsampled and then can be played via real speakers or via the connected Wiimote.

After getting the library up and running, I wanted to start looking into Wiimote Speaker playback, which for a long time has been relatively impossible to do well. The first part was that I had to purchase the latest Wiimote type which actually had better audio support. I never got the original Wiimote to play anything identifiable. Because PCM playback never sounded right, the main task was getting the ADPCM format down. I eventually found what seems to be the right version of it, but even then, the audio sometimes fades out and in in the Wiimote, and conversion to lower sample rates in general is pretty destructive.

A video demoing the demo for Wiimote speaker support. Showing the world that it is possible for the Wiimote to play user-input audio (under certain specific conditions).

I’ve been using the Wiimote controller application that resulted from this project ever since its inception. This paired with the DolphinBar has made the Wiimote Controller my personally most-used application to date.

trigger_death is now trigger_segfault

2019-05-14T15:10:00+00:00

I’ve been thinking about it over the last few months and decided it was time to rebrand myself from trigger_death to a new online username. I’ve been using trigger_death for about 10 years now but I was starting to get recommendations to change things now that I’m looking to work in a professional environment. A gamer tag name from 10 years ago doesn’t fare well in these times especially with the news lately.

The Decision

It was already decided that I would keep the prefix trigger_, this has been an ongoing theme in my name and I’ve already played around with changing the postfix on Discord servers. Some posibilities were trigger_segfault, trigger_source, trigger_dotnet, and trigger_desu. Some of these names I ruled out due to conflicting search results. Others I ruled out due to the possibility of the name ever being taken, and one I ruled out because the name was already in use.

I ended up deciding on trigger_segfault, I was already leaning this way for awhile and decided that it hosted the most benefits and was easy enough to remember. The old name was straight forwards with what the Source SDK trigger_brush did, but the new name should have a story to it:

trigger_segfault

You walk into a room, there’s a mysterious corner with a health resupply kit.
You walk over to it and then T̄̈̎h̥͛̄e̗̖͝ ̂ͣ͛g̿ͪͨå̪ͣm̊̋ͫe̹̥̦,̷̣̯ ̗̼͚tͩ͒͋h̓̀͌e͍̐͘ ͨ́̓u͒ͮ̃n̏ͮ͛҉͇̙͓i͈͍͂v̐ͤͫê͒́r͂ͪ̋s̍̽͑e̋̃͌,ͧ͋ͩ ͭͤ̈́aͪ̐̉n̹̭͗d͆ͨ̔ ̾̒̐ē̓ͣvͯͤͫě̏̌r̐̉̽y͆̾̅ṫ̎̓hͥ́ͨiͨ̆ͩnͥ̉ͪg̒͌̃ ̋ͨ̒i͋͐̔nͫ̔̽ ̀͆̒î̒ͮt͒͆̑ ̈́̄́҉̖́͞č͆̓rͮ͆ͮȧͬshes.
Then your computer crashes.
Then your electricity shuts off.
Then Elon Musk tweets about genetically engineered catgirls.
Then the whole internet infrastructure collapses and the world is sent into turmoil.

In Short: All the trigger_brush really does is cause a memory access violation. It’s a feature!

The Process

I had to heavily weigh the pros and cons of performing this change. I’ve built up 5 years worth of search results for trigger_death and have already filled out the entire first page. This change would brutally kill my Search Engine Optimization score. The biggest hurdles were first making sure the change in GitHub username would not negatively impact the change of this GitHub Pages site’s URL. I ended up creating a GitHub organization for my old username and setup a GitHub Pages site purely to redirect to the new GitHub pages URL. Sadly GitHub Pages does not support 301 redirects but there’s nothing that can be done about that. It seems to work well so far, and I’ve read Google can handle redirects done the other way too, so I’m not terribly worried anymore.

For every site I can think of off the top of my head, I’ve gone and changed the username (if it supported it), or outright created a new account. This was a pain especially when I learned one site had a 15 character limit leaving me as Triggersegfault with no dash and enforced first letter capitalization. Some forums made things very easy, just a simple help request, and the username was changed, and all old URLs still worked because it relied on an ID at the end.

The Results

The result is that many sites now 404 on my old username, many lead to a now-dead account (only some of which allow me to write out information to redirect people), and others are smart enough to support both names in URLs. Aside from GitHub pages, GitHub itself does an excellent job at redirecting old URLs and will automatically do this indefinitely unless the new trigger_death organization already has an existing repository for the same URL. What’s amazing is even the API supports username changes, all shields.io badges are still functional and working properly!

Hits are already being indexed for trigger_segfault by Google, just 24 hours into the change.

The name change is definitely devastating, but at the same time it was becoming necissary. I have done this once now, and shall hopefully never have to do it again. Better late than never.

One Final Note: You will likely need to update your RSS feeds to be directed to the new trigger_segfault.github.io domain. There isn’t really a proper way to fix this.

Deciphering a Password Save System

2019-05-11T20:00:00+00:00

I’ve worked on reverse engineering binary file formats before, and it can be quite difficult at times. That said, I’ve never tried to decipher a text-based format, even if it was as small as an 8-letter password. The full documentation explained in this post can be found on the Hourglass of Summer: Documentation Wiki.

Special thanks go to Porcupine’s Detailed Walkthrough as it was essential in speeding up my work, thanks to it’s extensive listing of passwords and scene Title-Chapters.

An example fully uncovered password in-game. (Normally you can only view one letter at a time due to technical limitations)

I started Hourglass of Summer on DVD by request of a friend, and I was surprisingly hooked even though the lack of certain key features present in most VNs made things frustrating and slow at times. As a game built to run on a DVD player, there are no save slots, and you are forced to write down an 8-letter password that represents the current point in the game you’re at combined with the relevant choices you have made up until now. By day two, I wanted to tackle the password system and see if I could learn how it works so I could remove a lot of the hassle from the game. I went in expecting to futz around for a bit and get absolutely nowhere. I came out having learned the entirety of the system, the ID for every scene in the game, every game flag operation, and even a handful of glitches surrounding the password input system.

Discovery

The first thing I tried to do was determine how the password stored its data. Did each letter act as a base-26 digit, or was each letter independent from each other? After whipping up a program to calculate password values based on the base-26 theory, I quickly ruled out that this was unlikely, especially because there were often letters that did not change in the password, even after key decisions in the game. If this were base-26, then, changes to one bit in the password would likely change up all letters in the password up to this bit, this being due to the fact that base-26 has no relation to binary base-2. Just like changing a single bit in a number can change numerous digits in a decimal number.

Writing Down Passwords

The first task to help with deciphering was to write down the password for every scene I encountered in the game as I progressed. This slowed down the game progression a bit, but a large pool of data is important to see how the password varies over time, and it certainly did vary over time more than I was expecting. It became apparent that a few letters were changing every scene, and by accident at one point, I looked at half the password and had to go back into the menu to read it again, only to discover that the password had changed without leaving the pause menu.

Notes that were taken for Scene passwords as they were encountered during regular gameplay.

To see how much the password could vary without any changes in game data, I kept closing and opening the password menu to see what changed each time, and what it changed to. It boiled down to 10 letters in the same spots that would freely change between one another whenever I opened the menu. There was one other spot in the password that had different letter randomization, but I only looked into that later. This led to the first discovery of the what I called Garbage Letters, which are letters that represent unused or uninitialized data. Because I doubt any real RNG existed in the game, I expected that this password randomization was based on the timestamp in the pause menu when opening the password menu.

These are the letters determined to be Garbage Letters.

B	D	F	I	K
M	Q	S	V	Y

This first discovery was very helpful, as it simplified writing down, and even inputting passwords. Once memorized, you could easily use a single letter to denote any garabge letter in a password without having to make the password more complex. I often used this to my advantage when inputting large amounts of passwords a day by inputting ---OZYYYY (where the first 3 letters are irrelevant).

What’s What in the Password

With the knowledge of garbage letters, it was now possible to properly track what parts of the password changed every scene. The first obvious change was that every scene, the first letter in the password changed, so that was obviously responsible for directing the game to the correct scene. Because there has to be more than 16 or even 26 scenes in the game, it must mean that at least a second letter would be needed to track the scene. The assumption was that the second letter in the password was likely the second letter in the scene variable. This left the password at 2-3 letters for scene info, and 6-5 letters for flag data.

Letter Values

Once I discovered that 10/26 letters had no meaning, it became very likely that the password Letters were a cipher for hexadecimal, with each non-garbage letter representing a value between 0 and 15. After isolating parts of the password by usage, my first method for determining the value for each letter was by seeing what non-garbage letters changed during KEY choices in the story, then changing the password and going back to the scene to see how the letters changed again. This is where the trouble started, because I failed to record the correct initial values of the flag letters before changing, this led to the issue where estimating the values of each letters based on flag operations always returned inconsistent results that didn’t match up with any operation.

I gave up on the flags for a bit and tried to look more into the scene variable again. I recorded each scene’s password from the beginning of the game as I encountered it while also taking into account choices leading to different scenes. It was still unclear if the Title, Chapter format of DVD sections were used internally in the password, or mapped by the game outside of the password, but after following the progression of the first letter of the password, it seemed like the scene was incrementing the value by one every time, this meant the Scene was stored as an ID instead of Title-Chapter, unlike what I had hoped, but it also gave away the value of every non-garbage letter in the password. Not only did this pattern continue onto the second letter, but that second letter helped enforce the possible values of the letters.

This is the uncovered pattern to the order of the early-game Scene IDs, which uncovers each letter’s numeric order.

A-U? -G-W? -H-N? -T-O?       -CA-GA-*-WA-JA-LA?      -XA-ZU...
| |-E   |-J   |-P   |-X--ZA?        |       |-HA           
| +-C   +-L   +-R   +-AA |          |       +-NA-PA?       
|                        |-UA    Anime OP        |-RA      
Start of Game            +-EA                    |-TA      
                                                 +-OA

Password Input Glitch

While I was trying to work with the early-game scene IDs I discovered and dreaded the fact that early-game passwords were not accepted by the Password Input Menu. I followed the Scene IDs until it did work (which was at scene ZA) and tried replacing the pattern -G-X---- ^{(where G is a garbage letter)} with -Z-O---- based on the assumption that Z was the letter for zero. I got the O based on what was used in later scene IDs. I didn’t fully understand why this worked, or why the glitch occurred until the final days working on the documentation, the only thing I really understood was that the fourth letter of X did not make the Password Input Menu a happy camper. My original assumption was also that garbage letters were presented as such, but were not actually a valid second Scene ID letter, although that was changed when I later learned that later IDs did not like Z for some reason.

You reach this screen and are presented with flawless English when the password you have entered in is considered invalid.

Determined Letter Values

The following Valid Letters were then tested and confirmed to represent these values. I was correct in the assumption that Z stood for zero although most of my other guesses were proven wrong.

#	Bin	Hex	Dec
Z	`0000`	`0`	`0`
A	`0001`	`1`	`1`
U	`0010`	`2`	`2`
E	`0011`	`3`	`3`
C	`0100`	`4`	`4`
G	`0101`	`5`	`5`
W	`0110`	`6`	`6`
J	`0111`	`7`	`7`
L	`1000`	`8`	`8`
H	`1001`	`9`	`9`
N	`1010`	`A`	`10`
P	`1011`	`B`	`11`
R	`1100`	`C`	`12`
T	`1101`	`D`	`13`
O	`1110`	`E`	`14`
X	`1111`	`F`	`15`

Comprehension

At this point I was regularly updating the password Wiki to keep all knowledge up to date, and easy to access anywhere when I had an idea. The next few days were spent writing a framework for the Password structure and also collecting in-game flag operations and in-game Scene IDs for each Title-Chapter. With the letter values known, it was quickly determined that only bitwise OR and bitwise AND were used to modify flags which made uncovering the flags a bit ^(heh) easier.

3rd Scene ID Letter

After looking over my later written down passwords, I noticed that the normal 4 random letters that could be in place for the 3rd letter in the password changed. I looked into the values and noticed that each of these new 4 random letters were one higher than each of the previous 4. This finally explained the other mystery randomized letter in the password. I concluded that the first 2 bits in this letter determined the highest part of the Scene ID, while the last 2 bits were always randomized and could be safely ignored. This assumption turned out to be true right off the bat from testing. The Scene ID was now guessed to be the first 3 letters of the password, and the Flag Data was assumed to be the last 5.

Below are the real letter values, and what other letters can represent them. E and friends are crossed out because there are not enough Scene IDs in the game to reach these high values, and they are not accepted by the Password Input Menu.

Z	A	U	E
Z C L R	A G H T	U W N O	~~E J P X~~

Password Library

I had been updating the password library along with the discoveries I made and now I was finally able to analyze a password and output a coherent explanation of what was input. Garbage and Valid letters were automatically replaced with the proper type of letter, so even normally-invalid passwords could be converted to valid ones, this was more helpful for me as it saved time during input.

The in-progress graphical user interface program password.

Making use of the Knowledge

The first time I tried to make use of everything I had learned, and the flags I had written down, was when trying to jump to the next character route to play. I had already seen all scenes that lead up to this route, so there was no reason I should need to play them again to get there. By combining 5 documented flag operations related to Tomomi, and knowing the Scene ID just before her route was initiated, I came up with the password OEZLWLEB. This worked correctly and put me right at the beginning of the route like I intended.

Garbage Checksum and First Flag Letter

For now I had always assumed that the first flag letter (and 4th letter in the password) F⁴ was a special letter where the operations of OR and AND are reversed. This letter started out as X (all bits set) and slowly lowered in value over time. Messing around with it also proved that it would trigger the Password Input Menu to reject the password. At this point I had no idea how complex the input validator was, but I wanted to fully understand how it worked. I tried seeing if it could function as some sort of checksum based on the rest of the letters in the password. After looking at its change in value through all of the recorded flag operations and scene passwords, I started noticing that it was often changed just during flag operations, but not always. Trying to figure out why it changed, I noticed that one letter was always being changed to or from a garbage letter during every change to the fourth letter.

After furthur investigation, I confirmed that this checksum letter had everything to do with the garbage letters. The next step was figuring out how it was generated and how to take it apart. After looking at the changes in the letter’s bits, only one bit changed every time the checksum changed, this lead to the conclusion that each bit corresponded to a single potential garbage letter in the password. This was quickly confirmed by messing around with the Password Input Menu and generating valid passwords through changing the checksum and potential garbage letters. This is when the term Garbage Checksum was coined to describe the letter’s behavior. Each nth bit in the letter is set, when the nth potential garbage letter in the password is a garbage letter.

Each bit in the Garbage Checksum is set when the specified letter is a garbage letter.

Bit	3	2	1	0
Letter	F⁸	F⁷	F⁶	S²

Although this didn’t directly explain how the Password Input Glitch occurred, it did shed light on why the solution worked. O worked because the first potential garbage letter was Z instead of an actual garbage letter, this validated the garbage checksum without requiring the use of X. This brought on the final big discovery about the password structure…

The End of Garbage Letters

Once I had discovered that Z was a valid replacement for the first potential garbage letter, and changing the garbage checksum actually produced a valid result, I tested if other letters could be Z instead of garbage letters. Z could replace any potential garbage letter! This meant that password input could be simplified even more, AZZZZZZZ was a completely valid password that would take you to the very beginning of the game! It complied with all of the rules, and even supplied the correct flags for that point in time. This was a game changer, as it opened up a whole new way to easily and lazily input passwords.

Once this point was reached, the documentation for the Password Structure was completed and corrected.

Branching Scene IDs

While recording later Scene IDs, I soon discovered that certain IDs were skipped altogether with no real explanation for why that was necessary. After inputting these Scene IDs into the Password Input Menu, it took me to the next Scene ID. What I soon noticed was that the Scene ID I was taken to was a conditional scene. This scene was only hit if you had made certain decisions in the past that set the appropriate flags. By testing different flag combinations, it became clear that the sole purpose of these Scene IDs were to send the game to a different Scene based on a condition. Knowledge of these Scene IDs had very little benefit, but it was simply more information that explained the inner workings of the game.

An example of how a Scene branches based on condition.

I later encountered a few branches in the story that did not make use of a locatable Scene ID which was strange. As the game strictly clamps the range of Scene IDs inputtable in the Password Input Menu, this is one mystery that will never be solved. If they do have Scene IDs, they are not accessible. If they do not have Scene IDs, then the previous scene is likely able to perform the same branching operations. It is also very possible that these are developer Scene IDs, but with no way to confirm this, it will be left as speculation.

Misunderstanding

While testing the conditions for branching scenes, I noticed that conditions weren’t being properly honored while entering in X. This occurred whenever I entered X into the last letter slot. For whatever reason, X in the last slot of the password would always direct you to the first result in a branching scene. The tests so far always brought the game to the positive outcome of a scene and this was incorrectly guessed to be a cheat or developer command to help skip through the story. It only become clear what was really going on near the very end of things.

Mastery

The final stretch of documentation involved finishing the entirety of the game, recording every possible Scene ID’s Title-Chapter, and logging every existing flag operation. This information needed to be done soon, as once the trial for the only software to play Hourglass of Summer was up, there would be no going back to running the game without forking over subscription money for a product that only has one specific use to me.

Password Input Glitch Clarity

The final AHAH moment was when I discovered the truth of the many strange behaviors of the Password Input Menu. X had been known to cause problems or special behavior for a Input Menu in certain places and it was just assumed to be how things were. All of this actually stemmed from one single and annoying glitch with the Password Input Menu: Inputting X at letter C⁴ or F⁸ would retroactively overwrite the 3 previous letters the moment it was entered. This was actually discovered by chance while trying to document a known crash in the game by navigating a previously input password.

X is and can be used as a valid letter at C⁴ or F⁸, but it turns out that the only way to do it right, is by entering it in before entering in the previous 3 letters. If the password input navigation arrows didn’t exist, this would make the bug much more troublesome and impossible to fix in certain situations.

After encountering this, I learned how to trigger the crash. Apparently Garbage letters behave differently when overwritten by the now labeled Propagating X Input glitch. This special behavior also helps because it keeps the garbage letters as such and allows the garbage checksum to stay valid. The problem with these garbage letters, is if you navigate to them in the Password Input Menu after Propagating X Input overwrites it, the game will crash (at least on the player I used).

What the input looks like before Propagating X.

What the input looks like after Propagating X.
Navigating to S² will crash the game as it was previously input as a garbage letter.

Everything is Here

On April 30th, 13 days after starting the game, I had finished writing down every Scene ID Title-Chapter combination, every Branching Scene, every Scene of Interest, and every flag operation that took place in the game. It turned out some Scene IDs were observable, yet outside of the accepted range of the Password Input Menu. The range is from ZZZ to OAU, leaving room for 542 valid Scene IDs. The game recycles flags a lot due to the limited number of available bits in the flag data (16). Often right before a choice, or before a major choice tree, a few or numerous flag bits are cleared or freed so that they can be set by a later choice. These clear operations are always hit to ensure that the flags are never misinterpreted by the game.

Future Plans

Although the documentation is basically complete for Hourglass of Summer, there are a few areas that could use some extra oomph. A flowchart that visually represents the Scene tree in the game would make navigating more straight forwards, although it would be a big endeavor to undertake. Another goal is to take all of this documented information and shove it into a password generator/reader. An application or web app that will give you the password based on supplied conditions, or take apart a password and tell you what all of it means. If either of these are eventually finished, then they will be linked below.

2018: End of Year Wrap-Up (Part 2)

2019-05-05T20:00:00+00:00

2018 Coverage

Now that I have a blog and feel obligated to post things. Let’s follow in my friend’s footsteps and create a wrap-up of this years development (and a little bit of last year’s since a lot went on then too).

Part two is long overdue, so here it so.

2018

Zelda Oracle Engine (Nov - Apr)

The Zelda Oracle Engine is a pet project me and my brother, cube_man have had for a long time, crossing over many languages. In 2015, we gave it a good start in C# XNA and restarted then revived it in late November of 2017. During the revival we made many changes including transitioning to a WPF editor, as that’s what I specialize in, it created a few headaches in some areas, but overall we got a few nice improvements out of it, including a pretty nice script editor using AvalonEdit.

Major Improvements: Everything

We have now surpassed any previous generations of this project (Java, and before that GameMaker). We transitioned to a paletted sprite system for maximum authenticity. We created an editor to feed and build .conscript’s in to get maximum representation of errors while compiling resources and checking that tiles were setup correctly. The new paletting system is a little overwhelming at first glance, although I did end up writing some tutorial conscripts.

The world editor saw some big improvements with an undo feature, which was pretty difficult to nail down. We also got a selection tool with different levels of layer support. My brother finally got the script API implemented, we decided to write the scripts in straight C#, with an API library for access to the game. The script editor uses Roslyn for much more advanced intellisense which is much nicer to work with than just an error message at the bottom of the window.

The physics engine got an overhaul along with monster API. Pretty much every weapon got its implementation down. We also finally got side-scrolling view in, which is quite fun to play around in.

An example of a palette zone transition and making use of the game engine for memes.

We encountered a few interesting bugs along the way.

It was great to get to work on this project again and great to work with my brother, who really knows what he’s doing when he goes to implement something. The game wouldn’t be even 1/10th as good as it is now without his help. cube_man worked mostly on the actual engine, while I worked more in the area of the editor and resource management. Most of my time went to gathering and compiling the tile list we see here. The project went on hiatus in April after slowly losing interest, but I have no doubt we’ll pick it up again in the future, assuming we have the time.

Discord Bot: trigger_chan v1 (Apr - Oct)

The old avatar for Triggy before upgrading to my Bot Framework v2 with a new image.

On April 20th, a Discord server for an anime app I used opened up. Me and the developer knew each other from another server so he gave me the go-ahead to setup a bot for the server to manage basic stuff such as MyAnimeList profile embeds and roles. With this, I made my first trek into writing a Discord Bot, which ended up being a ton of fun. It was pretty basic at first, and the help embeds were not very helpful, but it got the job done.

I decided on the name trigger_chan to play off my own username of trigger_segfault as well as her being the mascot for Studio Trigger.

Working on trigger_chan was also my first delve into really working with relational databases as well as Entity Framework Core. I did work with SQLite databases for Trigger’s PC back in 2016, but these were static and edited by hand, it’s very different to work with ones that require changes being made. It was pretty difficult to get used to, especially while trying to get the hang of code-first implementation.

The MAL embed is still relatively the same as when it first came out.

With v1 of the bot framework, each command was stored in it’s own entry identified by name, so every subcommand of a command got its own entry. It was terrible and awful.

The help list goes on and on and on.

The command help embed was at least a bit more helpful, although it lacked examples.

Unfortunately, in the beginning and even now, Triggy was still hosted locally on my Computer. I didn’t move her to AWS until after the 2019 started, and I still haven’t nailed down what to do once the free year is up.

Discord Bot: trigger_chan v2 (Oct - present)

The new image for Triggy after upgrading to my Bot Framework v2. The avatar is by Zwimmy.

Starting in October I began writing version two of my Discord.NET bot framework implementation. My goal was to fix a lot of the general flaws with the previous framework such as how commands are categorized, and how bad the help commands were. I also wanted to get Triggy up to standards to be Discord TOS compliant, which requires that end user data in databases be encrypted.

During the upgrade, I switched from SQLite to PostgreSQL to allow more advanced database migrations.

One of the other big changes to Triggy was migrating the audio player to using Lavalink, which does most of the hard work for you when it comes to playing audio. It supports YouTube and SoundCloud searches, as well as BandCamp, Twitch, and Vimeo urls.

More in depth view on the current state of trigger_chan can be found here.

Grisaia Extract (May - Jun)

I’d consider the Grisaia trilogy one of my favorite visual novel series of all time. I’d worked with extracting graphics from visual novels before, and there were already existing tools to do it for CatSystem2 games like Grisaia, but I wanted to make the experience better for Grisaia. This process evolved over time from simply wrapping existing programs, to rewriting the existing codebase to be incorporated into C# as a native library. I got started using the helpful existing info on categorization from the /r/Grisaia ripping wiki page. And after that I spent a lot of time sifting through images to figure out the pattern to their name, and where to move each of them programmatically. The tool was pretty much done in May, but I decided to actually make it presentable for release in June, because I didn’t know how long it would take before I made a proper UI. Post-release many hotfixes have come to update categorization.

TriggersTools.SteinsGate.Divergence (Jun)

I created a library to draw the iconic Divergence Meters from the popular visual novel and anime Steins;Gate. The purpose was to make drawing Divergence meters for memes or art quick and easy. I spent the first many days of this project just isolating the nixie tubes from the images that would allow them to be easily combined with one another. After the actual drawing code was done, I wrote a small program to generate the font for other characters using Oslo II. It took awhile to nail down a decent look, and it certainly doesn’t look perfect, but I’m pretty happy with how it turned out.

Discovery of Shields.io Badges (Jun)

I’d seen these badges used a lot in other repos, but never went out of my way to find out more about them, once I finally learned what they were called in June, I proceeded to absolutely plaster them on pretty much every repository that was maintained or of use to some degree.

Wiimote Experimentation (Jun - Sep)

One interesting thing I attempted was to modify the existing HID-Wiimote drivers to help support better pairing and passthrough so that the original controls could be retained without registering it as a different controller. It was interesting to learn how difficult it is to develop drivers, but it was also pretty fun. I took an old unused laptop and managed to hook it up to my main system with a debugger. Then I proceeded to-Your PC ran into a problem and needs to restart, to-Your PC ran into a problem and needs to restart… I crashed the laptop quite a lot. Although in the end I did learn a bit about HID descriptors and how USB devices work. I never made any usable progress with the drivers.

Finally Upgrading to Windows 10 (Jul)

On July 7th I finally caved and upgraded to Windows 10. The reason being: Everytime I tried to install .NET 4.7 in Visual Studio 2017, it would brick the entire IDE. Not even a reinstall could fix it, and I was sick of having to restore from backups everytime I learned this hasn’t been fixed. The initial transition was frustrating at first. I immediately got Winaero Tweaker just to fix a few huge annoyances, messed around with the registry to fix more annoyances, and changed the system window AND taskbar color. I generally like Windows 10 now but there are still some very annoying issues that leave regrets…

My biggest problems with Windows 10 that still persist today are major graphical issues like white flashing when scrolling in certain UIs, the Start Menu just not showing the lower half for a split second when opening, and in-game movies flat out giving me a black screen with audio. I’ve messed around with the NVidia drivers quite a bit and nothing has resolved any of these issues. The other major issue I’m having is that system restores cannot be performed outside of safe mode, which adds an additional layer to the headache of having to perform a system restore in the first place. Once I get a new hard drive to shove my current install on, I plan to do a fresh install of Windows 10 to see if I can fix the issues, if this doesn’t help then my graphics card is likely causing the problems, which is a pain because it worked absolutely fine in Windows 7.

I’m just one of those unlucky few people who have bad luck with Windows 10 on their build.

TriggersTools.Build (Jul)

I started futzing around with MSBuild Task NuGet packages to create a proper system for auto-updating the copyright year and keeping a build timestamp without having to manually set these up for every project. These build tasks have been really handy with the other projects I’ve worked on and allowed for additional laziness.

WinDirStat.Net (Aug)

WinDirStat is tried and true, but their UI is quite outdated at this point, and often quite laggy at times. The scanning can also be slower than it needs to be as pointed out in altWinDirStat.

I started work on creating a WPF implementation of WinDirStat and managed to get pretty far. This ended up being my first delve into MVVM, which was recommended by a friend. This also required a lot of code optimization and memory optimization. A lot of time was put into improving the UI responsiveness while still scanning, and generally improving the treeview render. The program came out quite nicely, but there are still some bugs to iron out and features to implement.

TriggersTools.FileFind (Sep)

I had to recreate file enumeration in WinDirStat because of a large number of flaws with the .NET implementation, including enumeration exceptions and slow speed due to waste of resources. This library allows traversing a Windows file tree in many different orders while avoiding security exceptions and wasting time on checks that don’t need to be made. This also has the option of returning the actual file information acquired during the file enumeration so that it doesn’t go to waste.

TriggersTools.DirectoryCaseSensitivity (Sep)

I’d started fiddling with Windows Subsystem for Linux and wanted to look into API support for Windows 10’s new directory case-sensitivity functionality. Turns out there is no API for this in C#, or even in the Windows C API, we have to call low level Nt functions to get the proper info. I was able to whip up a C# API for getting this info, as well as DirectoryInfo extension methods. You can check, change, and create directories with case sentivity of either type without having to go through native calls yourself.

WebScriptDisplay (Sep)

I got a request from my Dad to write a small page to display the results of cgi scripts on an OpenVMS server for his work. I took the specifications and created a basic HTML page with Javascript that is easily modified to extend or add support for more scripts. The CSS style came later, but it was definitely an improvement over that of no CSS style. Apparently it’s still on the server and in use today by other people, which is nice to hear.

Visual Novel List for a Stats Freak (Oct - present)

By this point in time, I had played a decent number of visual novels, and keeping a blog post in MAL with all the data up to date was getting to be a hastle. I disassembled the MAL list page and recreated it for visual novel display. All visual novel data is now stored in a json file that keeps stores all information needed to display the VN entry. This list made things so much easier to view, enter in, and compare.

You can follow updates to this list by subscribing to the endless Update vnlist.jsonc, Update vnlist.jsonc, Update vnlist.jsonc commits, that are absolutely flooding the commit history and burrying out anything meaningful.

Grisaia Sprite Viewer (Nov - present)

The first public post displaying the progress of the sprite viewer in alpha. A heaping mess that just works.

The Grisaia Sprite Viewer is an ongoing project to create a program to view and manipulate in-game Grisaia sprites by taking all image parts and combining them into a single image. CatSystem2 games like Grisaia store their image parts in thounsands of different images that only get more and more specific as you go down the list of lighting, distance, pose, and blush level. Added with the fact that many characters use sprite parts differently, an entire data file was needed to keep track of how image parts are used and what they’re called. The Sprite Viewer didn’t make its first release until 2019, so more coverge of that will be shown in next year’s blog post.

This Website Upgrade (Nov - present)

Before now, my personal GitHub Pages site was terribly underutilized and outright ignored most of the time. It still is now, but at least it gets some updates besides Update vnlist.jsonc. The previous iteration made use of my ancient Julia set Fractal Viewer program for the header so I decided to keep with this tradition, but go for a more minimal effect. The entire website’s theme is pretty much a copy of the Jekyll’s default Minima theme, but with some improvements and changes. There are also a few pages from the old site that stayed almost identical as they already had their own unique theme, such as the RCT2 Tools and the TriggerCookies (dead) mod.

2018: End of Year Wrap-Up (Part 1)

2019-01-03T18:50:00+00:00

With special guest: Second half of 2017

2017

Terraria Tools (Aug - September)

In late 2017, I pumped out 7 different Terraira tools with different functionality. Although they were built in released in quick succession, I don’t feel that any of them were really rushed.

Terraria Midi Player (Aug 9th)

Starting in July of 2017, I got the idea of playing midi’s through Terraria’s instruments. These instruments function by playing a note based on the distance of the mouse click from the player, which a range of 2 octaves and a high C. I originally looked into doing it through TSA tools but realized programming my own solution would be a lot easier. Through the development of the tool I made 3 videos presenting the potential of the tool, including multiple-musician performances.

Below are the tools in their early stages before they were anywhere close to complete.

The culmination of the tool was creating a performance of one of my favorite retro songs, Tal Tal Heights.

Terraria Item Modifier (Aug 23rd)

In accordance with playing faster notes with Terraria Midi Player, I created a patcher for the purpose of decreasing instrument use-time. I based my code off of TerrariaPatcher and continued from there. Aside from the terrible choice in name due to Item Modifiers being a thing in-game. This tool does its job well.

TConvert (Aug 30th)

TConvert was my attempt to take the existing tool, TExtract, and add an extra layer of being able to convert images and assets back to the original .xnb format. TExtract had been experiencing bugs for awhile with no contact from the author, so eventually TConvert was replaced in the Tools & Modifications pinned posts section.

Using TConvert and Terraria Item Modifier (for placing pots), I created the assets to make this video.

Quick Wave Bank (Sep 7th)

In the past, creating Wave Banks for Terraria was a long and tiresome project. There were tons of prerequisites to install and even then, adding and ordering songs was tough. This tool simplified the process by taking the underlying tool XactBld3.exe and running it through the program after generating a project file automatically.

I’m currently unhappy with the UI layout for how to add songs to the list. They can be reorganized, but songs can’t be put at, say, index 30 if you only have 20 tracks added.

Terraria Rupee Replacer (Sep 10th)

By far my favorite Terraria Tool created: Terraria Rupee Replacer does what it says on the tin, it replaces all instances of coins with Rupees. You have the ability to choose your own color set and optionally modify other assets that mention coins. Any mention of coins in the language packs has been replaced. This was a much more difficult patcher to implement than Terraria Item Modifier. There were many more functions that required hooking into, and getting the coin glow was especially tough.

Terraria Localization Packer (Sep 13th)

This was a small little tool I decided to create after Terraria Rupee Replacer thanks to my experience in delving into the localization files for replacing all mentions of coins with Rupees.

Terra Launcher (Sep 24th)

Because of my patcher programs that relied on modifying the game and associated saves, I wanted a way to access different Terrarias without having to shift around my save folders all the time. The solution was a launcher where you just enter in the versions of Terraria you have and enter the save directory (which gets set through command line arguments). I also added the option for storing different server configurations as well as tools for the game. With the tool feature even having the ability to open up a project file for that tool if you have that path entered in.

RollerCoaster Tycoon 2 Work

I got back into RollerCoaster Tycoon 2 again by tackling the upgrading of my existing RCT2 Tools with WPF variants. This later lead me back to my second round of OpenRCT2 contributions.

RCT2 Tools: WPF Edition (Oct - Nov)

I created a whole new library for WPF controls that looked like RCT2 controls. It works terribly in the designer, but well during runtime. These tools were never finished, or released, but I may as well upload what has been done to GitHub. I tried to rebuild them today and found out that the Pixel Shader BuildTask extension for Visual Studio was gone from CodePlex. Thankfully I managed to extract it from the archive, thanks to the help of CodePlexArchiveExtractor. Seriously this tool is a life saver.

The maze generator was by far the most difficult tool to build because WPF refuses to perform pixel graphics operations efficiently with a passion. I included a ton of new features, my favorite being the maze and entrance textures.

The water creator went through an overhaul of its own with Paint.NET like color sliders and color shifting to help quickly bang out new water colors without much trouble.

The Steam stub added support for all RollerCoaster Tycoon games, including classic. Along with the ability to customize the launcher setup.

OpenRCT2 Contributions: part 2 (Oct - Nov)

For the second time, I ended up adding my own contributions to OpenRCT2 and fixing a few bugs (most notably viewport scrolling). I spent a heavy amount of time on the Title Sequence Editor since I had left it a mess previously.

Because this information is already well documented, all contributions in 2017 can be found here.

2018

2018’s coverage is continued in the long overdue 2018: End of Year Wrap-Up (Part 2).

First Post!

2018-11-14T17:50:00+00:00

Now that I’m running my GitHub Pages site through Jekyll, I may as well take advantage of the blog feature and update this thing every so often. So, have a blog post about my first post. :)

Editing out the text “Pic” in this CG took quite some time. But I’m happy with the result, even if you can clearly see it’s modified near the “o” in “Post”. Source is Grisaia no Meikyuu.