rvtr/rmc_website
1
Fork 0
mirror of https://github.com/rvtr/rmc_website.git synced 2025-10-31 13:31:21 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity
a3b4186054
rmc_website/_site/feed.xml
IanSkinner1982 a3b4186054 super awesome layout for future reviews
2022-08-26 02:34:23 -04:00

288 lines
98 KiB
XML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="4.2.1">Jekyll</generator><link href="http://localhost:4000/feed.xml" rel="self" type="application/atom+xml" /><link href="http://localhost:4000/" rel="alternate" type="text/html" /><updated>2022-08-26T02:33:53-04:00</updated><id>http://localhost:4000/feed.xml</id><title type="html">rmc’s site</title><entry><title type="html">Bringing RNGTool to Your Wrist (Maybe)</title><link href="http://localhost:4000/2022/02/01/bringing-rngtool-to-apple-watch.html" rel="alternate" type="text/html" title="Bringing RNGTool to Your Wrist (Maybe)" /><published>2022-02-01T00:00:00-05:00</published><updated>2022-02-01T00:00:00-05:00</updated><id>http://localhost:4000/2022/02/01/bringing-rngtool-to-apple-watch</id><content type="html" xml:base="http://localhost:4000/2022/02/01/bringing-rngtool-to-apple-watch.html"><![CDATA[<p>Hmm this title sounds familiar...</p>
<p>More RNGTool updates! This time I'm porting RNGTool to watchOS rather than iOS. And it's interesting. The most difficult part of this is dealing with the limited screen real estate that the Apple Watch has. The solution? Cutting out the fat.</p>
<p>RNGTool is by no means a visually simple app. I've definitely overcomplicated its UI. This gives me a good chance to really cut out any parts of the app's UI that aren't needed so that you can fit the parts that matter. The actual process of porting the app's code was a lot easier than from macOS to iOS because most of the parts that aren't support on watchOS were being removed anyway, so I won't go over it here.</p>
<p>Here's the interesting part, a comparison of the iOS and watchOS apps:</p>
<div style="display:inline-block;padding-left:8px;">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-02-01/rngtool-mobile-number-mode.png" width="20%">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-02-01/rngtool-wrist-number-mode.png" width="15%">
</div>
<div style="display:inline-block;padding-left:8px;">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-02-01/rngtool-mobile-dice-mode.png" width="20%">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-02-01/rngtool-wrist-dice-mode.png" width="15%">
</div>
<div style="display:inline-block;padding-left:8px;">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-02-01/rngtool-mobile-about.png" width="20%">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-02-01/rngtool-wrist-about.png" width="15%">
</div>
<p>Unfortunately those are all of the screens I've completely finished at this point. I will likely make a post updating on when I finish the rest.</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[Hmm this title sounds familiar... More RNGTool updates! This time I'm porting RNGTool to watchOS rather than iOS. And it's interesting. The most difficult part of this is dealing with the limited screen real estate that the Apple Watch has. The solution? Cutting out the fat. RNGTool is by no means a visually simple app. I've definitely overcomplicated its UI. This gives me a good chance to really cut out any parts of the app's UI that aren't needed so that you can fit the parts that matter. The actual process of porting the app's code was a lot easier than from macOS to iOS because most of the parts that aren't support on watchOS were being removed anyway, so I won't go over it here. Here's the interesting part, a comparison of the iOS and watchOS apps: Unfortunately those are all of the screens I've completely finished at this point. I will likely make a post updating on when I finish the rest.]]></summary></entry><entry><title type="html">Bringing RNGTool to Your Pocket (Kinda)</title><link href="http://localhost:4000/2022/01/07/bringing-rngtool-to-phones.html" rel="alternate" type="text/html" title="Bringing RNGTool to Your Pocket (Kinda)" /><published>2022-01-07T00:00:00-05:00</published><updated>2022-01-07T00:00:00-05:00</updated><id>http://localhost:4000/2022/01/07/bringing-rngtool-to-phones</id><content type="html" xml:base="http://localhost:4000/2022/01/07/bringing-rngtool-to-phones.html"><![CDATA[<p>hey look, the first article of the year! happy new year!</p>
<p>So, what have I been up to recently (in terms of programming)? Mostly improving RNGTool. Since I've gotten more comfortable with Swift, it's started to push me away from C a little bit. Now I'm sure I'll return to it eventually, but for now this means I'm working on RNGTool and my websites exclusively. But hey, that means that RNGTool is becoming more usable!</p>
<p><b>Some quick clarification:</b> since this is Swift, the only pockets RNGTool is coming to are the ones with iPhones (or iPods (or even iPads if you have <i>really</i> big pockets)) in them. Sorry Android users.</p>
<p>So I finally made the realization that one can actually deploy iOS apps to their iDevices for testing. For some reason I genuinely thought you had to be an Apple Developer to even run your own app on your phone. Whoops. I also realized like 2 months later that I can actually run iDevice simulators on my Mac without much trouble so this wasn't even really an issue in the end.</p>
<p>Armed with this new information, I decided it was about time that I tried to port RNGTool to iOS. It's something that I've always wanted to do since I first created it but because of the afformentioned testing issues I didn't have a good way to make sure it actually did what it was supposed to. The basic porting process wasn't actually too hard. The beauty of Swift is that <i>most</i> code will work on all Apple platforms (especially since macOS 11.0, which added some previously iOS-specific features to Mac). At first the iOS version was actually just the macOS Swift files for the modes and settings with a new view listing. And then it got hard.</p>
<p>While my basic direct code porting was fine to get a working prototype, most of the UI was not really that usable. You can see this early UI below.</p>
<div style="display:inline-block;padding-left:8px;">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-01-07/rngtool-mobile-mode-list-beta.jpg" width="15%">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-01-07/rngtool-mobile-marble-mode-beta.jpg" width="15%">
</div>
<p>And thus began the quest to make RNGTool usable. I started with the settings, as they were a trainwreck that I unfortunately don't have any pictures of (and it was never committed to GitHub so it's long gone). These actually came out pretty well in the end. I managed to keep using the exact same code in both the macOS and iOS versions, just with different wrappings around the actual settings in the two <code>SettingsView.swift</code> files. The result is something arguably nicer to use than the macOS version, though I'll let you judge that for yourself.</p>
<div style="display:inline-block;padding-left:8px;">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-01-07/rngtool-mobile-settings1.png" width="15%">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-01-07/rngtool-mobile-settings2.png" width="15%">
</div>
<p>Next on the to-do list was to make brand new mobile-focused UIs for the actual generator modes. I tried to do what I did with the settings but it just wasn't working out; the UI needed to be basically redesigned from the ground up to work well on screens as small as 4 inches diagonally (looking at you, iPod Touch 7th gen). The easiest place to start was the text, so I shrank it all down until it was small enough to fit comfortably without being so small that it was hard to read. Then it was time to address the controls.</p>
<p>The annoying thing with the controls is that on macOS you really <i>have</i> to add extra properties to make them look decent. On iOS, however, that isn't an issue an raw controls look fine, excluding the buttons. The buttons needed some extra tinkering but what I came up with ended up looking pretty good, which is really only because all of my buttons use SF Symbols rather than text, so adding a rounded border was enough to make them big enough to press.</p>
<p>So by this point we've got working settings and working control (and of course functional number generation). What could possibly be left? Images.</p>
<p>While I briefly considered dropping the the dice and card images, I just felt like it would be weird since that was a feature I put a lot of time into on macOS. Thankfully, for literally the first time ever (that I can remember), math was useful in my code. Incredible, isn't it? I figured out how to read the usable screen size, and then used some fancy math to scale the dice and cards (as well as set the card offsets) to fit your screen nicely. The results can be seen below.</p>
<div style="display:inline-block;padding-left:8px;">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-01-07/rngtool-mobile-dice-mode.png" width="15%">
<img src="https://cdn.ncxprogramming.com/file/blog/2022-01-07/rngtool-mobile-card-mode.png" width="15%">
</div>
<p>So with that, RNGTool on iOS reached what it is today (more or less, new features have been added that I'm not mentioning here because they weren't part of the inital port). Now, about the "Kinda" in the title. Unfortunately, as I'm not an Apple Developer, I can't publish the app on the App Store or really distribute it at all. So if you want to run it, you'll either need a Jailbroken device on iOS 15 (which is not currently possible) or a sideloading method like <a href="https://sideloadly.io">Sideloadly!</a> or <a href="https://altstore.io">AltStore</a>. I won't be covering that here, but neither of those programs are particularly hard to use, so it shouldn't be hard to get RNGTool installed. Downloads can be found in the <a href="https://github.com/NCX-Programming/RNGTool/releases/latest">latest release</a> or as a build artifact in the latest <a href="https://github.com/NCX-Programming/RNGTool/actions">GitHub Actions run</a>.</p>
<p>That's all for now! Hopefully it won't be a full month between articles next time.</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[hey look, the first article of the year! happy new year! So, what have I been up to recently (in terms of programming)? Mostly improving RNGTool. Since I've gotten more comfortable with Swift, it's started to push me away from C a little bit. Now I'm sure I'll return to it eventually, but for now this means I'm working on RNGTool and my websites exclusively. But hey, that means that RNGTool is becoming more usable! Some quick clarification: since this is Swift, the only pockets RNGTool is coming to are the ones with iPhones (or iPods (or even iPads if you have really big pockets)) in them. Sorry Android users. So I finally made the realization that one can actually deploy iOS apps to their iDevices for testing. For some reason I genuinely thought you had to be an Apple Developer to even run your own app on your phone. Whoops. I also realized like 2 months later that I can actually run iDevice simulators on my Mac without much trouble so this wasn't even really an issue in the end. Armed with this new information, I decided it was about time that I tried to port RNGTool to iOS. It's something that I've always wanted to do since I first created it but because of the afformentioned testing issues I didn't have a good way to make sure it actually did what it was supposed to. The basic porting process wasn't actually too hard. The beauty of Swift is that most code will work on all Apple platforms (especially since macOS 11.0, which added some previously iOS-specific features to Mac). At first the iOS version was actually just the macOS Swift files for the modes and settings with a new view listing. And then it got hard. While my basic direct code porting was fine to get a working prototype, most of the UI was not really that usable. You can see this early UI below. And thus began the quest to make RNGTool usable. I started with the settings, as they were a trainwreck that I unfortunately don't have any pictures of (and it was never committed to GitHub so it's long gone). These actually came out pretty well in the end. I managed to keep using the exact same code in both the macOS and iOS versions, just with different wrappings around the actual settings in the two SettingsView.swift files. The result is something arguably nicer to use than the macOS version, though I'll let you judge that for yourself. Next on the to-do list was to make brand new mobile-focused UIs for the actual generator modes. I tried to do what I did with the settings but it just wasn't working out; the UI needed to be basically redesigned from the ground up to work well on screens as small as 4 inches diagonally (looking at you, iPod Touch 7th gen). The easiest place to start was the text, so I shrank it all down until it was small enough to fit comfortably without being so small that it was hard to read. Then it was time to address the controls. The annoying thing with the controls is that on macOS you really have to add extra properties to make them look decent. On iOS, however, that isn't an issue an raw controls look fine, excluding the buttons. The buttons needed some extra tinkering but what I came up with ended up looking pretty good, which is really only because all of my buttons use SF Symbols rather than text, so adding a rounded border was enough to make them big enough to press. So by this point we've got working settings and working control (and of course functional number generation). What could possibly be left? Images. While I briefly considered dropping the the dice and card images, I just felt like it would be weird since that was a feature I put a lot of time into on macOS. Thankfully, for literally the first time ever (that I can remember), math was useful in my code. Incredible, isn't it? I figured out how to read the usable screen size, and then used some fancy math to scale the dice and cards (as well as set the card offsets) to fit your screen nicely. The results can be seen below. So with that, RNGTool on iOS reached what it is today (more or less, new features have been added that I'm not mentioning here because they weren't part of the inital port). Now, about the "Kinda" in the title. Unfortunately, as I'm not an Apple Developer, I can't publish the app on the App Store or really distribute it at all. So if you want to run it, you'll either need a Jailbroken device on iOS 15 (which is not currently possible) or a sideloading method like Sideloadly! or AltStore. I won't be covering that here, but neither of those programs are particularly hard to use, so it shouldn't be hard to get RNGTool installed. Downloads can be found in the latest release or as a build artifact in the latest GitHub Actions run. That's all for now! Hopefully it won't be a full month between articles next time.]]></summary></entry><entry><title type="html">Giving NCX-Core Some CPR</title><link href="http://localhost:4000/2021/12/07/giving-ncx-core-cpr.html" rel="alternate" type="text/html" title="Giving NCX-Core Some CPR" /><published>2021-12-07T00:00:00-05:00</published><updated>2021-12-07T00:00:00-05:00</updated><id>http://localhost:4000/2021/12/07/giving-ncx-core-cpr</id><content type="html" xml:base="http://localhost:4000/2021/12/07/giving-ncx-core-cpr.html"><![CDATA[<p><i>Welcome back to another edition of I Don't Stick With Anything.</i></p>
<p>I went back on my decision to completely stop using Windows because some stuff still absolutely requires it. <i>Chilling, isn't it?</i></p>
<h3>Atrocity #1: The Code</h3>
<p>Since I was already here using Windows 10 again (however it's the LTSC 2021 version so less telemetry and no Windows Store at least) I figured that I'd pop in and look at how NCX-Core's code was holding up (with the "new" and exciting VS2022!); this was my first mistake. Now to be fair I acknowledged that the code was bad when I first wrote it, but I hadn't quite realized just how severe it truly was. Most likely the worst (publically available) code I've ever written and ever will write. But hey, it was one of my first major projects so I can't be too hard on it.</p>
<p>Honestly I didn't do a lot to fix the code, but I did finally correct all of the incorrect file paths that would cause the program to inexplicably crash whenever it tried to access them since I continue to put off error handling. I also fixed a decent bit of inefficient code and removed a bunch of feature stubs that were just taking up space. Oh and button code stubs. There was a large amount of those for some reason.</p>
<h3>Atrocity #2: The GUI</h3>
<p>The GUI was the next thing I took another look at. Now, <i>overall</i> the GUI isn't awful. Yes, the fact that the Library has hardcoded icon positions is dumb and since even <i>I</i> don't have CSharpCollection installed, there's always an awkward gap in the first slot. The About screen is also not nice to look at. Oh and the Settings screen is far too empty. Like really.</p>
<p>The real issue with the GUI is all of the photo-based elements. This includes all of the buttons, menu bar items and program icons. If you weren't already aware, all of the buttons are PNGs. Really big PNGs. Like, really big.</p>
<img src="https://cdn.ncxprogramming.com/file/blog/2021-12-07/what-is-this-res.png" style="margin-left:8px;" alt="Image showing the resolution of the image is 1700x1100.">
<p>Yeah... And for some reason, I expected this to scale down to 104x66 for some reason (let's just ignore this bizarre resolution). I believe I though that the bigger the image the better it would scale down? I'm not even really sure at this point. So I decided step one for fixing this mess would be to create some brand new assets, this time as vector graphics so they'd scale down nicely. (Read 'A Love Letter to Vector Graphics' which may or may not ever come out for that backstory.) Since these are vector graphics, it means geometric shapes, which means that not only do they scale better but they also just look nicer to begin with. If you'd like to see a fun comparison, <a href="https://cdn.ncxprogramming.com/file/internal/NCX-Core%20Asset%20Pack.zip">click here</a> to download <code>NCX-Core Asset Pack.zip</code> from our not-CDN that has the old assets and the new ones.</p>
<p>With all of the new assets in, I can say that NCX-Core is now at least slightly less painful to use (not that anyone does anyway). Yay.</p>
<h3>The State of NCX-Core and its Future</h3>
<p><b>Can it be used?</b></p>
<p>Yes, but it's not very useful to anyone. I've made enough changes that it's now relatively usable. The issue is just that there's no real need for it.</p>
<p><b>If that's the case then what's going to happen to it?</b></p>
<p>I honestly don't know. My current plan is to finish polishing what's there and release it as v3.2, and then leave it. It's an important piece of "programmer history" so it's not going to get deleted or be privated. For now it's also not going to be archived. So if I ever decide to pick it up and use it's code for something new it's there.</p>
<h3>Wow this was kind of sad</h3>
<p>Yeah I know. But, officially saying this is done-ish means I'm finally going to stop holding out on NCX-Core-Lite and work on a proper big program, so stay tuned!</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[Welcome back to another edition of I Don't Stick With Anything. I went back on my decision to completely stop using Windows because some stuff still absolutely requires it. Chilling, isn't it? Atrocity #1: The Code Since I was already here using Windows 10 again (however it's the LTSC 2021 version so less telemetry and no Windows Store at least) I figured that I'd pop in and look at how NCX-Core's code was holding up (with the "new" and exciting VS2022!); this was my first mistake. Now to be fair I acknowledged that the code was bad when I first wrote it, but I hadn't quite realized just how severe it truly was. Most likely the worst (publically available) code I've ever written and ever will write. But hey, it was one of my first major projects so I can't be too hard on it. Honestly I didn't do a lot to fix the code, but I did finally correct all of the incorrect file paths that would cause the program to inexplicably crash whenever it tried to access them since I continue to put off error handling. I also fixed a decent bit of inefficient code and removed a bunch of feature stubs that were just taking up space. Oh and button code stubs. There was a large amount of those for some reason. Atrocity #2: The GUI The GUI was the next thing I took another look at. Now, overall the GUI isn't awful. Yes, the fact that the Library has hardcoded icon positions is dumb and since even I don't have CSharpCollection installed, there's always an awkward gap in the first slot. The About screen is also not nice to look at. Oh and the Settings screen is far too empty. Like really. The real issue with the GUI is all of the photo-based elements. This includes all of the buttons, menu bar items and program icons. If you weren't already aware, all of the buttons are PNGs. Really big PNGs. Like, really big. Yeah... And for some reason, I expected this to scale down to 104x66 for some reason (let's just ignore this bizarre resolution). I believe I though that the bigger the image the better it would scale down? I'm not even really sure at this point. So I decided step one for fixing this mess would be to create some brand new assets, this time as vector graphics so they'd scale down nicely. (Read 'A Love Letter to Vector Graphics' which may or may not ever come out for that backstory.) Since these are vector graphics, it means geometric shapes, which means that not only do they scale better but they also just look nicer to begin with. If you'd like to see a fun comparison, click here to download NCX-Core Asset Pack.zip from our not-CDN that has the old assets and the new ones. With all of the new assets in, I can say that NCX-Core is now at least slightly less painful to use (not that anyone does anyway). Yay. The State of NCX-Core and its Future Can it be used? Yes, but it's not very useful to anyone. I've made enough changes that it's now relatively usable. The issue is just that there's no real need for it. If that's the case then what's going to happen to it? I honestly don't know. My current plan is to finish polishing what's there and release it as v3.2, and then leave it. It's an important piece of "programmer history" so it's not going to get deleted or be privated. For now it's also not going to be archived. So if I ever decide to pick it up and use it's code for something new it's there. Wow this was kind of sad Yeah I know. But, officially saying this is done-ish means I'm finally going to stop holding out on NCX-Core-Lite and work on a proper big program, so stay tuned!]]></summary></entry><entry><title type="html">Love Letter to Vector Graphics</title><link href="http://localhost:4000/2021/12/07/love-letter-to-svgs.html" rel="alternate" type="text/html" title="Love Letter to Vector Graphics" /><published>2021-12-07T00:00:00-05:00</published><updated>2021-12-07T00:00:00-05:00</updated><id>http://localhost:4000/2021/12/07/love-letter-to-svgs</id><content type="html" xml:base="http://localhost:4000/2021/12/07/love-letter-to-svgs.html"><![CDATA[<p>I finally reached that point in my life where I learned what an SVG is! Not sure how I made it this far without that knowledge.</p>
<p>If you don't know what vector graphics are, I suggest reading <a href="https://en.wikipedia.org/wiki/Scalable_Vector_Graphics">Wikipedia - Scalable Vector Graphics</a> first. To sum it up briefly, SVGs are made of geometric shapes instead of pixels so they can be easily scaled up without losing quality.</p>
<p>Currently I'm only making brand new images as SVGs, but I intend to remake some other old images, especially the banners on this site. If you have a really big monitor (or at least one that's really high res), you can really see this difference by visiting either <a href="/">the homepage</a> or <a href="/programs">the programs page</a> and then <a href="/products/icons">our icon sales page</a> <i>(hmm what could this be)</i> and scroll down to the banner. Now, uh, I don't have a high-res screen (in fact my MacBook Pro is the last pre-Retina display) so I have no idea if this will work. But it probably should. Feel free to yell at me in an issue or something if this doesn't work.</p>
<p>That's all for now. Look forward to some scalable goodness in the near future.</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[I finally reached that point in my life where I learned what an SVG is! Not sure how I made it this far without that knowledge. If you don't know what vector graphics are, I suggest reading Wikipedia - Scalable Vector Graphics first. To sum it up briefly, SVGs are made of geometric shapes instead of pixels so they can be easily scaled up without losing quality. Currently I'm only making brand new images as SVGs, but I intend to remake some other old images, especially the banners on this site. If you have a really big monitor (or at least one that's really high res), you can really see this difference by visiting either the homepage or the programs page and then our icon sales page (hmm what could this be) and scroll down to the banner. Now, uh, I don't have a high-res screen (in fact my MacBook Pro is the last pre-Retina display) so I have no idea if this will work. But it probably should. Feel free to yell at me in an issue or something if this doesn't work. That's all for now. Look forward to some scalable goodness in the near future.]]></summary></entry><entry><title type="html">Unsupported Mac Adventures Part 2</title><link href="http://localhost:4000/2021/10/01/unsupported-mac-adventures-2.html" rel="alternate" type="text/html" title="Unsupported Mac Adventures Part 2" /><published>2021-10-01T00:00:00-04:00</published><updated>2021-10-01T00:00:00-04:00</updated><id>http://localhost:4000/2021/10/01/unsupported-mac-adventures-2</id><content type="html" xml:base="http://localhost:4000/2021/10/01/unsupported-mac-adventures-2.html"><![CDATA[<h3>Part 2: My First Personal MacBook</h3>
<p>The second old (but newer than the other!) Mac that I had was a 2012 Unibody MacBook Pro (Model identifier <code>MacBookPro9,2</code>) with 4GB RAM, a 500GB HDD, and a 2.5 GHz Dual-Core Intel Core i5 CPU. This MacBook Pro was the first MacBook that was actually mine as the 2010 White MacBook is still my parents'.</p>
<p>When I got this one, I already knew that I'd need <a href="https://github.com/dortania/OpenCore-Legacy-Patcher">OpenCore Legacy Patcher</a> to patch it. The nice thing about this Mac is that it supports Apple's Metal API, meaning that it could do graphical acceleration in Big Sur wthout any patches (so I can use System Integrity Protection and Secure Boot Model!). Before patching though, I took the SSD out of my ThinkPad, which is a Samsung EVO 960, and put it in the Mac. I tried using it with the 5400RPM HDD that it came with in Catalina and it was too slow for me, especially coming from an SSD in my old Mac.</p>
<p>The initial patching went fine and I had Big Sur up and running without any issues. However, after updating from Big Sur 11.5.2 to Big Sur 11.6, I started to notice crashing. Apps and system processes would experience a memory leak of some kind, and then would crash itself and other programs until I either rebooted or a kernel panic occurred (I later discovered that the 11.6 update had no relevance). I tried debugging it by changing some OCLP settings and repatching, but it wouldn't help. My next idea was that maybe my backup, which came from my original patched Mojave install and had been updated through every version since, was causing problems because of all the potentially left over patches. Unfortunately a clean install of 11.6 didn't fix it.</p>
<p>After that I decided to wipe and do a fresh install of 11.5.2, because at this point I thought that the software update had caused my issues. Judging from the fact that the crashing still happened, it was safe to say that 11.6 wasn't the issue.</p>
<p>I then turned my attention to potential hardware problems. The first and easiest thing to try was putting the HDD back in and installing Big Sur to that, just in the off chance that something was wrong with my SSD (not that I though there was, since it was relatively new). No luck there. I then ran <a href="https://www.memtest86.com">memtest86</a>, a free bootable environment for testing RAM, and all 4 passes passed the tests. So for the time being, I just gave up and accepted that I'd have to deal with the crashing.</p>
<p>Luckily, someone in the OCLP discord server knew of the issue and said you could use the command <code>sudo purge</code> to purge the leaking memory, effectively fixing the issue for the time being (it would still come back eventually). Since I couldn't open apps while it was crashing, I enabled SSH and created a shortcut in the Shortcuts app on my iPhone to run <code>sudo purge</code> over SSH right from my home screen whenever I needed it, which worked pretty well. I later created an Automation quick action workflow on the Mac itself so that I could run my workflow just by pressing a key combination. This would let me stop a crash that had already quit all my apps but hadn't killed Finder yet (as I needed at least one app to be open to run the workflow).</p>
<p>So, what now? At this point this is what I was wondering because I just couldn't figure out what was wrong. That is until someone suggested to me that my RAM might be bad, as they had RAM that was bad but could pass memtest86. So, like with the SSD, I stole the 8GB of RAM from my ThinkPad and put it in my Mac.</p>
<p>And that brings us to now, where I'm writing this article on my seemingly no longer crashing Mac. Will this be the end? I hope so. If it's not, expect a part 3 ;)</p>
<p>Another fun fact: most of RNGTool's code was written on this 2012 MacBook Pro! (the entire Jekyll conversion for this site was done on here too!)</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[Part 2: My First Personal MacBook The second old (but newer than the other!) Mac that I had was a 2012 Unibody MacBook Pro (Model identifier MacBookPro9,2) with 4GB RAM, a 500GB HDD, and a 2.5 GHz Dual-Core Intel Core i5 CPU. This MacBook Pro was the first MacBook that was actually mine as the 2010 White MacBook is still my parents'. When I got this one, I already knew that I'd need OpenCore Legacy Patcher to patch it. The nice thing about this Mac is that it supports Apple's Metal API, meaning that it could do graphical acceleration in Big Sur wthout any patches (so I can use System Integrity Protection and Secure Boot Model!). Before patching though, I took the SSD out of my ThinkPad, which is a Samsung EVO 960, and put it in the Mac. I tried using it with the 5400RPM HDD that it came with in Catalina and it was too slow for me, especially coming from an SSD in my old Mac. The initial patching went fine and I had Big Sur up and running without any issues. However, after updating from Big Sur 11.5.2 to Big Sur 11.6, I started to notice crashing. Apps and system processes would experience a memory leak of some kind, and then would crash itself and other programs until I either rebooted or a kernel panic occurred (I later discovered that the 11.6 update had no relevance). I tried debugging it by changing some OCLP settings and repatching, but it wouldn't help. My next idea was that maybe my backup, which came from my original patched Mojave install and had been updated through every version since, was causing problems because of all the potentially left over patches. Unfortunately a clean install of 11.6 didn't fix it. After that I decided to wipe and do a fresh install of 11.5.2, because at this point I thought that the software update had caused my issues. Judging from the fact that the crashing still happened, it was safe to say that 11.6 wasn't the issue. I then turned my attention to potential hardware problems. The first and easiest thing to try was putting the HDD back in and installing Big Sur to that, just in the off chance that something was wrong with my SSD (not that I though there was, since it was relatively new). No luck there. I then ran memtest86, a free bootable environment for testing RAM, and all 4 passes passed the tests. So for the time being, I just gave up and accepted that I'd have to deal with the crashing. Luckily, someone in the OCLP discord server knew of the issue and said you could use the command sudo purge to purge the leaking memory, effectively fixing the issue for the time being (it would still come back eventually). Since I couldn't open apps while it was crashing, I enabled SSH and created a shortcut in the Shortcuts app on my iPhone to run sudo purge over SSH right from my home screen whenever I needed it, which worked pretty well. I later created an Automation quick action workflow on the Mac itself so that I could run my workflow just by pressing a key combination. This would let me stop a crash that had already quit all my apps but hadn't killed Finder yet (as I needed at least one app to be open to run the workflow). So, what now? At this point this is what I was wondering because I just couldn't figure out what was wrong. That is until someone suggested to me that my RAM might be bad, as they had RAM that was bad but could pass memtest86. So, like with the SSD, I stole the 8GB of RAM from my ThinkPad and put it in my Mac. And that brings us to now, where I'm writing this article on my seemingly no longer crashing Mac. Will this be the end? I hope so. If it's not, expect a part 3 ;) Another fun fact: most of RNGTool's code was written on this 2012 MacBook Pro! (the entire Jekyll conversion for this site was done on here too!)]]></summary></entry><entry><title type="html">Unsupported Mac Adventures</title><link href="http://localhost:4000/2021/09/21/unsupported-mac-adventures.html" rel="alternate" type="text/html" title="Unsupported Mac Adventures" /><published>2021-09-21T00:00:00-04:00</published><updated>2021-09-21T00:00:00-04:00</updated><id>http://localhost:4000/2021/09/21/unsupported-mac-adventures</id><content type="html" xml:base="http://localhost:4000/2021/09/21/unsupported-mac-adventures.html"><![CDATA[<p>So as a fun way to document my work on my MacBooks, I thought I'd make a blog article out of them. Blog articles that are actually about our software will be coming soon.</p>
<h3>Part 1: My First Macbook</h3>
<p>The first old Mac I had to work on was my parents old 2010 White Unibody MacBook (Model identifier <code>MacBook7,2</code>) with 4GB of RAM, a 500GB HDD and a 2.4GHz Core 2 Duo CPU. The title of this part has a double meaning of sorts. It was indeed the first MacBook I experimented with, but it was also the first MacBook I ever used (and also the first computer I really used) and is what really got me interested in computers, so it's pretty cool that I've now come back to it.</p>
<p>When I first pulled it out, all I knew about was <a href="http://dosdude1.com/mojave/">dosdude1's Mojave patcher</a>, so my intention was just to install Mojave and then tinker with that. The installation was relatively uneventful, other than the minor stress I had from doing a BootROM update (since an interruption could brick your Mac!). I only had to do that update because this Mac was still running the macOS (or more accurately, Mac OS X) version that it came with, 10.6 Snow Leopard, and so it never got the APFS support update that I needed for Mojave updates to work, otherwise I would have avoided it.</p>
<p>After a while, I wanted some programs (mostly just Xcode) that needed Catalina, so I decided to check the compatibility list for <a href="http://dosdude1.com/catalina/"> dosdude1's Catalina patcher</a>... Lo and behold, my Mac was on the list! So I immediately went and downloaded the patcher and began preparing my USB, making sure to get a backup first (I learned my lesson after one of my laptops' HDD failed). Attempting to upgrade failed, but luckily one fresh install and a restore later and I had Catalina up and running with all my files, and that was enough for me.. For about a month.</p>
<p>Mostly by chance, I went to check on the MacRumours <a href="https://forums.macrumors.com/threads/macos-11-big-sur-on-unsupported-macs-thread.2242172/">macOS 11 Big Sur on Unsupported Macs</a> thread, and discovered that someone going by ASentientBot had added Graphical Acceleration back to older, non-metal GPUs, and mine was one of the ones it supported! So, like before, I made a backup and got to work getting my USB all set up. This time I was using <a href="https://github.com/dortania/OpenCore-Legacy-Patcher">OpenCore Legacy Patcher</a> instead of an OS patcher like dosdude1's, which allowed system updates without having to re-patch the system (possibly excluding the GPU Acceleration patches, I never got a chance to test that). This process was a lot more of a headache than for Mojave and Catalina. My biggest issue was that once I had Big Sur installed, it would lock up on boot when the progress bar was about 1/3 of the way across. I eventually figured out that the NVRAM needed to be reset, and since then that Mac has been running Big Sur about as smoothly (or likely more so) than you'd expect for an 11 year old Mac. It's honestly quite impressive that such an old Mac can still run the latest macOS version without too much trouble.</p>
<p>So for now, that's all. At some point in the future (might be the next article, might not be) I'll continue this and will talk about my new(ish) MacBook Pro and the adventures I've had getting Big Sur running on that one.</p>
<p>Also, here's a fun fact: almost every article on this blog was written on that 2010 White MacBook!</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[So as a fun way to document my work on my MacBooks, I thought I'd make a blog article out of them. Blog articles that are actually about our software will be coming soon. Part 1: My First Macbook The first old Mac I had to work on was my parents old 2010 White Unibody MacBook (Model identifier MacBook7,2) with 4GB of RAM, a 500GB HDD and a 2.4GHz Core 2 Duo CPU. The title of this part has a double meaning of sorts. It was indeed the first MacBook I experimented with, but it was also the first MacBook I ever used (and also the first computer I really used) and is what really got me interested in computers, so it's pretty cool that I've now come back to it. When I first pulled it out, all I knew about was dosdude1's Mojave patcher, so my intention was just to install Mojave and then tinker with that. The installation was relatively uneventful, other than the minor stress I had from doing a BootROM update (since an interruption could brick your Mac!). I only had to do that update because this Mac was still running the macOS (or more accurately, Mac OS X) version that it came with, 10.6 Snow Leopard, and so it never got the APFS support update that I needed for Mojave updates to work, otherwise I would have avoided it. After a while, I wanted some programs (mostly just Xcode) that needed Catalina, so I decided to check the compatibility list for dosdude1's Catalina patcher... Lo and behold, my Mac was on the list! So I immediately went and downloaded the patcher and began preparing my USB, making sure to get a backup first (I learned my lesson after one of my laptops' HDD failed). Attempting to upgrade failed, but luckily one fresh install and a restore later and I had Catalina up and running with all my files, and that was enough for me.. For about a month. Mostly by chance, I went to check on the MacRumours macOS 11 Big Sur on Unsupported Macs thread, and discovered that someone going by ASentientBot had added Graphical Acceleration back to older, non-metal GPUs, and mine was one of the ones it supported! So, like before, I made a backup and got to work getting my USB all set up. This time I was using OpenCore Legacy Patcher instead of an OS patcher like dosdude1's, which allowed system updates without having to re-patch the system (possibly excluding the GPU Acceleration patches, I never got a chance to test that). This process was a lot more of a headache than for Mojave and Catalina. My biggest issue was that once I had Big Sur installed, it would lock up on boot when the progress bar was about 1/3 of the way across. I eventually figured out that the NVRAM needed to be reset, and since then that Mac has been running Big Sur about as smoothly (or likely more so) than you'd expect for an 11 year old Mac. It's honestly quite impressive that such an old Mac can still run the latest macOS version without too much trouble. So for now, that's all. At some point in the future (might be the next article, might not be) I'll continue this and will talk about my new(ish) MacBook Pro and the adventures I've had getting Big Sur running on that one. Also, here's a fun fact: almost every article on this blog was written on that 2010 White MacBook!]]></summary></entry><entry><title type="html">The History of theVaultC</title><link href="http://localhost:4000/2021/08/22/history-of-thevaultc.html" rel="alternate" type="text/html" title="The History of theVaultC" /><published>2021-08-22T00:00:00-04:00</published><updated>2021-08-22T00:00:00-04:00</updated><id>http://localhost:4000/2021/08/22/history-of-thevaultc</id><content type="html" xml:base="http://localhost:4000/2021/08/22/history-of-thevaultc.html"><![CDATA[<p>I've decided that it's probably a good idea for me to take a break from the rant-type articles and write something a little more fun. So here it is! The history of our project theVaultC, up through the day this article comes out.</p>
<h3>I. theVault (The C# One)</h3>
<p>Before theVaultC, my equivalent project was theVault, which was written in C#. The only projects it had were GuessMyNumber, GraphicStuff, and helloWorld. GuessMyNumber and GraphicStuff in theVault are almost identical to the theVaultC versions. HelloWorld was not remade because I didn't think there was any reason to remake that, as it was written when I was actually new to C# console apps, and was actually a test. By the time I started on theVaultC, I was already past that point with C.</p>
<p>I finally decided to abandon theVault when I decided to slow down (so that I could eventually stop) my work on C# programs. I archived it on March 19, which was the same day I had set up a workflow on the theVaultC repo, getting it to the point where it was practical to have it as a full replacement. The programs in it at that point were equal to the ones in theVault.</p>
<h3>II. theVaultC</h3>
<p>I decided to create theVaultC when I was learning C and wanted to create something to both test and show off my skill with C. I wanted to be able to replace theVault with it so I worked on creating versions of those programs in C. That is more or less all the history behind the program itself. In the next section I'm going to talk about the histories of each program in theVaultC.</p>
<h3>III. theVaultC's Programs</h3>
<p><b>GuessMyNumberC and GraphicStuffC</b></p>
<p>I'm grouping these two together because they have the same history. As I've already mentioned, these were recreations of the theVault programs.</p>
<p><b>PrintUnixTime</b></p>
<p>PrintUnixTime was originally a quick test that I made when I was learning how to seed random numbers using <code>time(0)</code>. After learning how it worked, I constructed it to print the number of seconds since Unix time "began" (also known as the Unix Epoch<sup>[1]</sup>) on 1 January 1970. I made this example program that just read the value from <code>time(0)</code> and printed it as a cool way to check how many seconds it's currently at, and then decided to add to theVaultC.</p>
<p><b>RNGTool</b></p>
<p>RNGTool (also known as the theVaultC program that has a name that is way too cool for what it is) is a program that generates random numbers. It also lets you enter a maximum and minimum number that you'd like be generated. I only created it because I had been working on random number generation when optimizing GuessMyNumberC, and wanted to use it in another program just for fun.</p>
<p><b>WordGenerator</b></p>
<p>WordGenerator is a (from the outside) simple-seeming program, that was actually the hardest to make by far out of all the theVaultC programs. I needed quite a bit of help from <a href="https://github.com/Garhoogin">Garhoogin</a> and <a href="https://github.com/Jonatan6">Jonatan6</a>, but in the end I got it done. It reads a list of words (conveniently located in a file named <code>words.txt</code>) and then picks a random selection of words from that list (the number of words it picks is random too!) and prints them. I don't quite remember when I first thought about this program, but it had been floating around for a while by the time that I finally got around to it.</p>
<p>I hope you found this little dive into the history of theVaultC interesting! Any questions? Feel free to <a href="mailto:github@ncxprogramming.com">shoot us an email!</a>
<hr>
<p><b>Sources</b></p>
<p>1. <a href="https://en.wikipedia.org/wiki/Unix_time">Unix time</a> Wikipedia, retrieved on August 22, 2021</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[I've decided that it's probably a good idea for me to take a break from the rant-type articles and write something a little more fun. So here it is! The history of our project theVaultC, up through the day this article comes out. I. theVault (The C# One) Before theVaultC, my equivalent project was theVault, which was written in C#. The only projects it had were GuessMyNumber, GraphicStuff, and helloWorld. GuessMyNumber and GraphicStuff in theVault are almost identical to the theVaultC versions. HelloWorld was not remade because I didn't think there was any reason to remake that, as it was written when I was actually new to C# console apps, and was actually a test. By the time I started on theVaultC, I was already past that point with C. I finally decided to abandon theVault when I decided to slow down (so that I could eventually stop) my work on C# programs. I archived it on March 19, which was the same day I had set up a workflow on the theVaultC repo, getting it to the point where it was practical to have it as a full replacement. The programs in it at that point were equal to the ones in theVault. II. theVaultC I decided to create theVaultC when I was learning C and wanted to create something to both test and show off my skill with C. I wanted to be able to replace theVault with it so I worked on creating versions of those programs in C. That is more or less all the history behind the program itself. In the next section I'm going to talk about the histories of each program in theVaultC. III. theVaultC's Programs GuessMyNumberC and GraphicStuffC I'm grouping these two together because they have the same history. As I've already mentioned, these were recreations of the theVault programs. PrintUnixTime PrintUnixTime was originally a quick test that I made when I was learning how to seed random numbers using time(0). After learning how it worked, I constructed it to print the number of seconds since Unix time "began" (also known as the Unix Epoch[1]) on 1 January 1970. I made this example program that just read the value from time(0) and printed it as a cool way to check how many seconds it's currently at, and then decided to add to theVaultC. RNGTool RNGTool (also known as the theVaultC program that has a name that is way too cool for what it is) is a program that generates random numbers. It also lets you enter a maximum and minimum number that you'd like be generated. I only created it because I had been working on random number generation when optimizing GuessMyNumberC, and wanted to use it in another program just for fun. WordGenerator WordGenerator is a (from the outside) simple-seeming program, that was actually the hardest to make by far out of all the theVaultC programs. I needed quite a bit of help from Garhoogin and Jonatan6, but in the end I got it done. It reads a list of words (conveniently located in a file named words.txt) and then picks a random selection of words from that list (the number of words it picks is random too!) and prints them. I don't quite remember when I first thought about this program, but it had been floating around for a while by the time that I finally got around to it. I hope you found this little dive into the history of theVaultC interesting! Any questions? Feel free to shoot us an email! Sources 1. Unix time Wikipedia, retrieved on August 22, 2021]]></summary></entry><entry><title type="html">The Problems With C On Windows</title><link href="http://localhost:4000/2021/08/16/c-on-windows.html" rel="alternate" type="text/html" title="The Problems With C On Windows" /><published>2021-08-16T00:00:00-04:00</published><updated>2021-08-16T00:00:00-04:00</updated><id>http://localhost:4000/2021/08/16/c-on-windows</id><content type="html" xml:base="http://localhost:4000/2021/08/16/c-on-windows.html"><![CDATA[<p><i>This will be a short article.</i></p>
<p>As much as I like using C, I have one big issue with it. And that problem is Windows.</p>
<p><b>1. Libraries</b></p>
<p>Compared to macOS and Linux, installing/obtaining libraries to use on Windows is difficult. If you're on a Debian or Arch system, you have <code>apt</code> or <code>pacman</code>, respectively. If you're on macOS, you have a few options, such as my package manager of choice, <code>brew</code>. But on Windows? You don't have those options. You have to find and download those libraries yourself in order to use them in your program. Now is this a huge deal? No, not really. It's just inconvenient, compared to macOS and Linux where you'll always be using the latest libraries, and they can be installed with one command.</p>
<p><b>2. POSIX Compliance</b></p>
<p>Windows is not POSIX Compliant.<sup>[1]</sup> Now what does this mean? <a href="https://en.wikipedia.org/wiki/POSIX">"The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems."</a><sup>[1]</sup> One particular POSIX standard that it doesn't meet is the C POSIX standard,<sup>[2]</sup> which is what causes me issues. Because Windows does not follow these standards, it doesn't include many of the standard C libraries, and instead forces you to use the proprietary Windows libraries. While this isn't inherently a bad thing, it does kill compatibility between Linux/macOS and Windows. This deters me from making Windows-compatible software because I need to rework a lot of code to do it. With macOS and Linux the changes I need to make are often either minor or nonexistent.</p>
<p><b>3. Compiler</b></p>
<p>Tying in with the previous section, Windows requires its own proprietary compiler because it needs to be able to include the Windows libraries.</p>
<p><b>Finishing Off</b></p>
<p>Overall, if you intend to only make Windows programs, there's no reason to not use C. However if, like me, you want to make programs that run on multiple operating systems, you'll have to write completely different versions for POSIX compliant and non-POSIX compliant systems.</p>
<hr>
<p><b>Sources</b></p>
<p>1. <a href="https://en.wikipedia.org/wiki/POSIX">POSIX</a> Wikipedia, retrieved on August 15, 2021.</p>
<p>2. <a href="https://en.wikipedia.org/wiki/C_POSIX_library">C POSIX library</a> Wikipedia, retrieved on August 16, 2021.</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[This will be a short article. As much as I like using C, I have one big issue with it. And that problem is Windows. 1. Libraries Compared to macOS and Linux, installing/obtaining libraries to use on Windows is difficult. If you're on a Debian or Arch system, you have apt or pacman, respectively. If you're on macOS, you have a few options, such as my package manager of choice, brew. But on Windows? You don't have those options. You have to find and download those libraries yourself in order to use them in your program. Now is this a huge deal? No, not really. It's just inconvenient, compared to macOS and Linux where you'll always be using the latest libraries, and they can be installed with one command. 2. POSIX Compliance Windows is not POSIX Compliant.[1] Now what does this mean? "The Portable Operating System Interface (POSIX) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems."[1] One particular POSIX standard that it doesn't meet is the C POSIX standard,[2] which is what causes me issues. Because Windows does not follow these standards, it doesn't include many of the standard C libraries, and instead forces you to use the proprietary Windows libraries. While this isn't inherently a bad thing, it does kill compatibility between Linux/macOS and Windows. This deters me from making Windows-compatible software because I need to rework a lot of code to do it. With macOS and Linux the changes I need to make are often either minor or nonexistent. 3. Compiler Tying in with the previous section, Windows requires its own proprietary compiler because it needs to be able to include the Windows libraries. Finishing Off Overall, if you intend to only make Windows programs, there's no reason to not use C. However if, like me, you want to make programs that run on multiple operating systems, you'll have to write completely different versions for POSIX compliant and non-POSIX compliant systems. Sources 1. POSIX Wikipedia, retrieved on August 15, 2021. 2. C POSIX library Wikipedia, retrieved on August 16, 2021.]]></summary></entry><entry><title type="html">Moving On</title><link href="http://localhost:4000/2021/08/14/moving-on.html" rel="alternate" type="text/html" title="Moving On" /><published>2021-08-14T00:00:00-04:00</published><updated>2021-08-14T00:00:00-04:00</updated><id>http://localhost:4000/2021/08/14/moving-on</id><content type="html" xml:base="http://localhost:4000/2021/08/14/moving-on.html"><![CDATA[<p>All good things must come to an end. And for me, that thing is my time working with C#. In this article I will outline my reasons for abandoning C# as well as what will happen with my C# programs.</p>
<h3>I. Why I'm Leaving It</h3>
<p><b>1. Free as in beer</b></p>
<p>One of my biggest issues with C# is the lack of open source. While all of my C# code is open, nothing about the language or its tools are. It's a proprietary language that uses proprietary tools and, if you're making a GUI app, only runs on a proprietary OS. So yes it may be free to use, but it offers no freedom.</p>
<p>With a language like C, there are options for what compiler you want to use because nothing about the language is proprietary. Or if, for example, let's say you'd like to make a GUI in C. You have several options, such as GTK+, which is an open source solution. When you're programming in C#, you have to use Microsoft's proprietary compiler and one of Microsoft's proprietary GUI frameworks, if you intend to make a GUI app.</p>
<p><b>2. Platforms</b></p>
<p>Another large issue I have is OS compatibility. C# desktop apps run only on Windows, and even then you have to install the .NET 5/Framework Desktop Runtime first. C# console apps can be run on Linux and macOS in addition to Windows, however you still need the .NET 5/Framework Runtime installed and you need launch the apps with the <code>dotnet run</code> command in the terminal.</p>
<p>On the other side, C code can be written to work on multiple platforms, and even if the same code won't you can (usually) make adjustments to let it run different code on different operating systems. (Of course Windows support can be a lot harder due to it not being POSIX compliant, read more about that <a href="/blog/pages/2021-08-16-c-on-windows">here</a>). C code also just runs on whatever OS it's compiled for, no need for any frameworks or runtimes, only the libraries for your program (and unless you're doing something crazy, a lot of common libraries you want to use might already be installed).</p>
<p><b>3. Abandoning Windows</b></p>
<p>My final reason for leaving C# behind is that I'd like to leave Windows behind, quite possibly for good. Since none of the GUI designer tools, <i>cough</i> Visual Studio <i>cough</i>, run on Linux or macOS (the 2 operating systems I will still have access to), then that leaves me with no way to continue developing my C# apps. And that brings me to the second part of this article:</p>
<h3>II. What will happen to my projects</h3>
<p><b>CSharpCollection</b></p>
<p>I'll keep this short. I have no intentions to continue developing CSharpCollection, or to pass it on to another developer. It is a test app and nothing more.</p>
<p><b>NCX-Core, XStore and NCX-News</b></p>
<p>While I, and by extension, NCX Programming, will still own the project, it is being passed on to <a href="https://github.com/rolfiee">Rolfie</a>, who will handle any future development or maintaining work. She will also be maintaining XStore. NCX-News will still be managed and updated by NCX Programming.</p>
<p><b>XWare</b></p>
<p>Like with NCX-Core, XWare will be passed on to <a href="https://github.com/rolfiee">Rolfie</a> as well.</p>
<h3>III. Closing words</h3>
<p>I'd like to wrap up this article by saying that this is by no means the end of any major NCX Programming projects. There will be more to come in the future, even if I don't know what they'll be now. That's all for now, and I'll be back next time with a fun Microsoft rant.</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[All good things must come to an end. And for me, that thing is my time working with C#. In this article I will outline my reasons for abandoning C# as well as what will happen with my C# programs. I. Why I'm Leaving It 1. Free as in beer One of my biggest issues with C# is the lack of open source. While all of my C# code is open, nothing about the language or its tools are. It's a proprietary language that uses proprietary tools and, if you're making a GUI app, only runs on a proprietary OS. So yes it may be free to use, but it offers no freedom. With a language like C, there are options for what compiler you want to use because nothing about the language is proprietary. Or if, for example, let's say you'd like to make a GUI in C. You have several options, such as GTK+, which is an open source solution. When you're programming in C#, you have to use Microsoft's proprietary compiler and one of Microsoft's proprietary GUI frameworks, if you intend to make a GUI app. 2. Platforms Another large issue I have is OS compatibility. C# desktop apps run only on Windows, and even then you have to install the .NET 5/Framework Desktop Runtime first. C# console apps can be run on Linux and macOS in addition to Windows, however you still need the .NET 5/Framework Runtime installed and you need launch the apps with the dotnet run command in the terminal. On the other side, C code can be written to work on multiple platforms, and even if the same code won't you can (usually) make adjustments to let it run different code on different operating systems. (Of course Windows support can be a lot harder due to it not being POSIX compliant, read more about that here). C code also just runs on whatever OS it's compiled for, no need for any frameworks or runtimes, only the libraries for your program (and unless you're doing something crazy, a lot of common libraries you want to use might already be installed). 3. Abandoning Windows My final reason for leaving C# behind is that I'd like to leave Windows behind, quite possibly for good. Since none of the GUI designer tools, cough Visual Studio cough, run on Linux or macOS (the 2 operating systems I will still have access to), then that leaves me with no way to continue developing my C# apps. And that brings me to the second part of this article: II. What will happen to my projects CSharpCollection I'll keep this short. I have no intentions to continue developing CSharpCollection, or to pass it on to another developer. It is a test app and nothing more. NCX-Core, XStore and NCX-News While I, and by extension, NCX Programming, will still own the project, it is being passed on to Rolfie, who will handle any future development or maintaining work. She will also be maintaining XStore. NCX-News will still be managed and updated by NCX Programming. XWare Like with NCX-Core, XWare will be passed on to Rolfie as well. III. Closing words I'd like to wrap up this article by saying that this is by no means the end of any major NCX Programming projects. There will be more to come in the future, even if I don't know what they'll be now. That's all for now, and I'll be back next time with a fun Microsoft rant.]]></summary></entry><entry><title type="html">Copyright Issues</title><link href="http://localhost:4000/2021/05/17/copyright-issues.html" rel="alternate" type="text/html" title="Copyright Issues" /><published>2021-05-17T00:00:00-04:00</published><updated>2021-05-17T00:00:00-04:00</updated><id>http://localhost:4000/2021/05/17/copyright-issues</id><content type="html" xml:base="http://localhost:4000/2021/05/17/copyright-issues.html"><![CDATA[<p><b>DISCLAIMER!</b> This article is about <i>my</i> experiences with false copyright claims. This is not a critique of the copyright system, only of the automatic copyright claim bots used on websites like YouTube or MediaFire.</p>
<p><b>Part I: The Claims</b></p>
<p>My first experience with a false-positive copyright claim was on YouTube when one of the pieces of music I made in GarageBand caused a video to get claimed. Twice in fact, once for each song I used. Now you would think that I could just appeal these claims with whatever proof they needed, right? Unfortunately this was not the case. (It should be noted that before submitting the appeal, I did my research and I am, in fact, allowed to use the loops provided by GarageBand for personal or commerical use.) Once I submitted the appeals, I was happy to see that the first was withdrawn, however that was short lived when a few days later I discovered that my second appeal had been <i>rejected.</i> (Thinking about it now, I wonder if I could have pursued that further since now a real person was saying that they owned something that they did not.) Another interesting fact about that claim is that I could not find the copyrighted music I supposedly used anywhere online, and believe me, I looked.</p>
<p>My second experience wasn't a claim but instead a takedown. I had been hosting downloads for the music that I made in GarageBand (same songs that caused trouble on YouTube) so I could link to the files on my website. I eventually discovered when linking to one of them that they had just been removed with 0 warning and could no longer be downloaded. Below is an image of what you get if you <a href="https://www.mediafire.com/file/rrjlp7nc3mowrji/Da_Song.m4a/file">visit the download page</a>.</p>
<img src="https://cdn.ncxprogramming.com/file/blog/2021-05-17/blog-copyright1.png" style="max-width: 100%;">
<p>If you're interested, <a href="https://cdn.ncxprogramming.com/file/blog/2021-05-17/blog-dasong.m4a">here's the song I uploaded.</a> Definitely not what it says it was.</p>
<p><b>Part II: Why These Claims Happen</b></p>
<p>Most of these sites, especially ones like YouTube and Twitch, use bots that check audio in your video against samples of copyrighted music. The biggest issue with this system is that if any other sound matches a sample, the video or stream will be claimed. Here's a <a href="https://screenrant.com/twitch-streamers-dmca-sound-effects/">ScreenRant article about it.</a> (Not endorsing ScreenRant or their content, it was just the first good article I found about the issue.) The reason these false claims make it through is that there's nobody checking them, as soon as the bots detect something it thinks should be a claim, it just goes through with that. Programs aren't perfect, but it sure seems like they expect them to be. Judging from which of my songs were claimed, the reason was most likely that they contained a loop that was present in the copyrighted music that was supposedly playing.</p>
<p><b>Part III: Fixing The System</b></p>
<p>So now we're at the part where I give my thoughts about how this issue could be fixed. Remember that these are <i>my opinions</i> about this could be done. The first and most obvious solution is to <u>have the claims verified by a real person.</u> I would imagine that a large number of these false claims would stop happening if there were people who could check these and notice that the claimed content sounds nothing like the music that supposedly is being used.</p>
<p>Another, albiet more difficult, solution would be to improve or change the way these bots compare the source content to the copyrighted content. Evidently the "sampling" method leaves too much of a margin of error. One of the most obvious issues with it is that there are plenty of loops that you can either buy once or just use for free and if they're used in a piece of copyrighted music, then any content uploaded that contains that same loop will be claimed, as I've experienced firsthand.</p>
<p>Now obviously I don't make copyright claim bots, so I don't understand everything about how they work. I'm just hoping that my thoughts (and the thoughts of many others too) won't fall on deaf ears.</p>
<p>And with that, we've come to the end of this article. I know that this article was less fun for exciting compared to the Wii DVD Icon adventures, but this is something that I've wanted, needed really, to talk about for a while. -NinjaCheetah</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[DISCLAIMER! This article is about my experiences with false copyright claims. This is not a critique of the copyright system, only of the automatic copyright claim bots used on websites like YouTube or MediaFire. Part I: The Claims My first experience with a false-positive copyright claim was on YouTube when one of the pieces of music I made in GarageBand caused a video to get claimed. Twice in fact, once for each song I used. Now you would think that I could just appeal these claims with whatever proof they needed, right? Unfortunately this was not the case. (It should be noted that before submitting the appeal, I did my research and I am, in fact, allowed to use the loops provided by GarageBand for personal or commerical use.) Once I submitted the appeals, I was happy to see that the first was withdrawn, however that was short lived when a few days later I discovered that my second appeal had been rejected. (Thinking about it now, I wonder if I could have pursued that further since now a real person was saying that they owned something that they did not.) Another interesting fact about that claim is that I could not find the copyrighted music I supposedly used anywhere online, and believe me, I looked. My second experience wasn't a claim but instead a takedown. I had been hosting downloads for the music that I made in GarageBand (same songs that caused trouble on YouTube) so I could link to the files on my website. I eventually discovered when linking to one of them that they had just been removed with 0 warning and could no longer be downloaded. Below is an image of what you get if you visit the download page. If you're interested, here's the song I uploaded. Definitely not what it says it was. Part II: Why These Claims Happen Most of these sites, especially ones like YouTube and Twitch, use bots that check audio in your video against samples of copyrighted music. The biggest issue with this system is that if any other sound matches a sample, the video or stream will be claimed. Here's a ScreenRant article about it. (Not endorsing ScreenRant or their content, it was just the first good article I found about the issue.) The reason these false claims make it through is that there's nobody checking them, as soon as the bots detect something it thinks should be a claim, it just goes through with that. Programs aren't perfect, but it sure seems like they expect them to be. Judging from which of my songs were claimed, the reason was most likely that they contained a loop that was present in the copyrighted music that was supposedly playing. Part III: Fixing The System So now we're at the part where I give my thoughts about how this issue could be fixed. Remember that these are my opinions about this could be done. The first and most obvious solution is to have the claims verified by a real person. I would imagine that a large number of these false claims would stop happening if there were people who could check these and notice that the claimed content sounds nothing like the music that supposedly is being used. Another, albiet more difficult, solution would be to improve or change the way these bots compare the source content to the copyrighted content. Evidently the "sampling" method leaves too much of a margin of error. One of the most obvious issues with it is that there are plenty of loops that you can either buy once or just use for free and if they're used in a piece of copyrighted music, then any content uploaded that contains that same loop will be claimed, as I've experienced firsthand. Now obviously I don't make copyright claim bots, so I don't understand everything about how they work. I'm just hoping that my thoughts (and the thoughts of many others too) won't fall on deaf ears. And with that, we've come to the end of this article. I know that this article was less fun for exciting compared to the Wii DVD Icon adventures, but this is something that I've wanted, needed really, to talk about for a while. -NinjaCheetah]]></summary></entry><entry><title type="html">Stylizing The Site</title><link href="http://localhost:4000/2021/05/15/stylizing-the-site.html" rel="alternate" type="text/html" title="Stylizing The Site" /><published>2021-05-15T00:00:00-04:00</published><updated>2021-05-15T00:00:00-04:00</updated><id>http://localhost:4000/2021/05/15/stylizing-the-site</id><content type="html" xml:base="http://localhost:4000/2021/05/15/stylizing-the-site.html"><![CDATA[<p>So as you've probably noticed if you got this far on the site, we've finally added CSS. For a while (from the start of the website on January 29th, actually) it became a joke of sorts that this site had absolutely no styling. That was mainly because of how annoying CSS can be, and also how bad <a href="https://ninjacheetah.github.io">my other site that uses CSS looks.</a> <sub>Editor's note: this article was written before NinjaCheetah overhauled his site in 2022.</sub></p>
<p>What started me off on making this site look better was some free time I had during school just yesterday. I decided to open GIMP and just see if I could create some sort of banner. It ended up coming out really good (in my opinion at least) so I added it to the website. From there, I decided to try and add the nav bar I used on my old site to this one, but this time actually make it look good. From there, I didn't like that the banner and nav bar used Sans-Serif but the body used Times New Roman, so more CSS it was! Eventually, with the help of <a href="/members/ianskinner1982">IanSkinner1982</a>, we managed to get the banner and nav bar to stretch to the edges of the screen which greatly improved how it looked. All I did after that was add the GitHub and Discord link icons, and it was done! (also for the record I have no idea if this is in chronological order)</p>
<p>I woke up this morning and had an idea: more banners! So I created banners for the <a href="/programs/">Programs page<a> and the <a href="/members/">Members page</a>, which both also came out pretty good (again, in my opinion at least). So for now, I think that just about wraps up our website "renovation". We will of course still add new things, but there shouldn't be any major changes coming soon.</p>
<p>Sorry for the short article, but I felt like it would be better to at least say something about it than nothing.</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[So as you've probably noticed if you got this far on the site, we've finally added CSS. For a while (from the start of the website on January 29th, actually) it became a joke of sorts that this site had absolutely no styling. That was mainly because of how annoying CSS can be, and also how bad my other site that uses CSS looks. Editor's note: this article was written before NinjaCheetah overhauled his site in 2022. What started me off on making this site look better was some free time I had during school just yesterday. I decided to open GIMP and just see if I could create some sort of banner. It ended up coming out really good (in my opinion at least) so I added it to the website. From there, I decided to try and add the nav bar I used on my old site to this one, but this time actually make it look good. From there, I didn't like that the banner and nav bar used Sans-Serif but the body used Times New Roman, so more CSS it was! Eventually, with the help of IanSkinner1982, we managed to get the banner and nav bar to stretch to the edges of the screen which greatly improved how it looked. All I did after that was add the GitHub and Discord link icons, and it was done! (also for the record I have no idea if this is in chronological order) I woke up this morning and had an idea: more banners! So I created banners for the Programs page and the Members page, which both also came out pretty good (again, in my opinion at least). So for now, I think that just about wraps up our website "renovation". We will of course still add new things, but there shouldn't be any major changes coming soon. Sorry for the short article, but I felt like it would be better to at least say something about it than nothing.]]></summary></entry><entry><title type="html">Cleaning Up CC64</title><link href="http://localhost:4000/2021/05/03/cleaning-cc64.html" rel="alternate" type="text/html" title="Cleaning Up CC64" /><published>2021-05-03T00:00:00-04:00</published><updated>2021-05-03T00:00:00-04:00</updated><id>http://localhost:4000/2021/05/03/cleaning-cc64</id><content type="html" xml:base="http://localhost:4000/2021/05/03/cleaning-cc64.html"><![CDATA[<style>
code {
font-family: Consolas,"courier new";
color: crimson;
background-color: #f1f1f1;
padding: 2px;
font-size: 70%;
}
pre {
background-color: #f1f1f1;
padding: 2px;
}
</style>
<p>This article is to explain how I made Cookie Clicker C64 item buying more efficient. This probably isn’t the most interesting article, but you may enjoy it nonetheless.
<br>
Here is the layout of a page in the store:
<br>
<br>
<code>1. Print a page in the store
<br>
2. Buy certain items depending on the pressed key (goes to sections 4-7)
<br>
3. Switch page if + or - is pressed
<br>
-------------------------
<br>
4. item 1 buying code
<br>
5. item 2 buying code
<br>
6. item 3 buying code
<br>
7. item 4 buying code
<br>
</code>
<br>
Now, this is for 1 page in a store. The store has over 5 pages… with 4 item buying routines each. Too much code, right? Well that's why I came up with an idea to make it better. First, let me explain how the store looks. You have 3 lines for each item. The setup is as follows:
<br>
<pre>
Item Name Amount Owned Ex. Cursors 69
Description of item Adds .1 cookies per second
Price of item 1000c
</pre>
<br>
I decided that I would put all the building info in a sequential and save it to a few arrays. (I'd have a name array, a price array, a description array and an amount array) It might not make sense why I did this, but you'll see why soon.
Instead of printing a whole page, I'd print the values in the array. So...
<br>
<br>
<code>
1. Select a range depending on the page selected. (0-3, 4-7, 8-12, etc)
<br>
2. Print the values in the range selected for each array
<br>
I will now add a for...next loop to handle all the menu printing. It will go through the range selected and print the desired values.
</code>
<br>
<br>
I have replaced all the page printing code with just 2 parts. (each page display would take 20 or so lines, meaning if I had 5 pages that would be 100 lines. With this new method, I need around 8-10 lines to load the array values, and 9 lines to print any selected page. With 5 pages, that is only 17-19 lines!) I can also add a whole new page just by adding one line of code.
<br>
Figuring out how to select an item with this new design was tough. I decided to assign a value to each item of the page. (x) If the input was within 1-4, then you will be sent to the buying routine.
<br>
<br>
<code>
1. Reset x and read keyboard input
<br>
2. Exit on a change of the current page or menu
<br>
3. Enter buying routine if an item was selected. (if x=1-4)
</code>
<br>
<br>
This ended up taking 18 lines instead of 50 lines for all the pages. Not a big improvement, but it is still good to clean stuff up.
<br>
As mentioned earlier, there are four blocks of code for buying items per page. Each bit of code was 6 lines. 6*4*5 is 120 lines. (still assuming I need 5 pages) Yeesh.
I have to chop that down.
Before, it was like this for each item:
<br>
<br>
<code>
1. Compare price and cookies
<br>
2. Subtract price
<br>
3. Add gain to gain.
<br>
4. Update amount owned.
<br>
5. Add 15% to price.
<br>
6. Update screen with new price and amount owned.
</code>
<br>
<br>
Now, once you have selected a item, it will do this:
<br>
<br>
<code>
1. Load the item number. (y=i+x-1) (i is the low number in the range)
<br>
2. Compare price(y) with your total cookies. (see if you can buy it)
<br>
3. Subtract price(y) from your cookies. Add the gain to gain(y). Multiply price(y) by 1.15. Add one to the amount owned
<br>
4. Update the price and amount owned on the screen. (this takes up a few more lines to determine where the item you want updated is)
<br>
<br>
(What is the gain? With Cookie Clicker, an idle game, the game is always adding something to your total amount of cookies. This is your CpS, or in this case, Gain. I made it so each item has its own gain. (in this case, gain(y)) All gains are added, and that is the total gain. The total gain is added to the amount of cookies you have.)
</code>
<br>
<br>
Now we have one routine shared by all items. So instead of 120 lines, we end up with 12 lines to handle all the items. If I were to add a thousand more items, it would still only be 12 lines.
<br>
<br>
In all, this took a week to figure out, and a few days to debug. In the end I got it to work, but I had to change a few things. All the ideas here still apply though.
<br>
Thanks for reading this extremely boring article!
</p>]]></content><author><name>IanSkinner1982</name></author><summary type="html"><![CDATA[This article is to explain how I made Cookie Clicker C64 item buying more efficient. This probably isn’t the most interesting article, but you may enjoy it nonetheless. Here is the layout of a page in the store: 1. Print a page in the store 2. Buy certain items depending on the pressed key (goes to sections 4-7) 3. Switch page if + or - is pressed ------------------------- 4. item 1 buying code 5. item 2 buying code 6. item 3 buying code 7. item 4 buying code Now, this is for 1 page in a store. The store has over 5 pages… with 4 item buying routines each. Too much code, right? Well that's why I came up with an idea to make it better. First, let me explain how the store looks. You have 3 lines for each item. The setup is as follows: Item Name Amount Owned Ex. Cursors 69 Description of item Adds .1 cookies per second Price of item 1000c I decided that I would put all the building info in a sequential and save it to a few arrays. (I'd have a name array, a price array, a description array and an amount array) It might not make sense why I did this, but you'll see why soon. Instead of printing a whole page, I'd print the values in the array. So... 1. Select a range depending on the page selected. (0-3, 4-7, 8-12, etc) 2. Print the values in the range selected for each array I will now add a for...next loop to handle all the menu printing. It will go through the range selected and print the desired values. I have replaced all the page printing code with just 2 parts. (each page display would take 20 or so lines, meaning if I had 5 pages that would be 100 lines. With this new method, I need around 8-10 lines to load the array values, and 9 lines to print any selected page. With 5 pages, that is only 17-19 lines!) I can also add a whole new page just by adding one line of code. Figuring out how to select an item with this new design was tough. I decided to assign a value to each item of the page. (x) If the input was within 1-4, then you will be sent to the buying routine. 1. Reset x and read keyboard input 2. Exit on a change of the current page or menu 3. Enter buying routine if an item was selected. (if x=1-4) This ended up taking 18 lines instead of 50 lines for all the pages. Not a big improvement, but it is still good to clean stuff up. As mentioned earlier, there are four blocks of code for buying items per page. Each bit of code was 6 lines. 6*4*5 is 120 lines. (still assuming I need 5 pages) Yeesh. I have to chop that down. Before, it was like this for each item: 1. Compare price and cookies 2. Subtract price 3. Add gain to gain. 4. Update amount owned. 5. Add 15% to price. 6. Update screen with new price and amount owned. Now, once you have selected a item, it will do this: 1. Load the item number. (y=i+x-1) (i is the low number in the range) 2. Compare price(y) with your total cookies. (see if you can buy it) 3. Subtract price(y) from your cookies. Add the gain to gain(y). Multiply price(y) by 1.15. Add one to the amount owned 4. Update the price and amount owned on the screen. (this takes up a few more lines to determine where the item you want updated is) (What is the gain? With Cookie Clicker, an idle game, the game is always adding something to your total amount of cookies. This is your CpS, or in this case, Gain. I made it so each item has its own gain. (in this case, gain(y)) All gains are added, and that is the total gain. The total gain is added to the amount of cookies you have.) Now we have one routine shared by all items. So instead of 120 lines, we end up with 12 lines to handle all the items. If I were to add a thousand more items, it would still only be 12 lines. In all, this took a week to figure out, and a few days to debug. In the end I got it to work, but I had to change a few things. All the ideas here still apply though. Thanks for reading this extremely boring article!]]></summary></entry><entry><title type="html">Under construction</title><link href="http://localhost:4000/2021/05/03/go-away.html" rel="alternate" type="text/html" title="Under construction" /><published>2021-05-03T00:00:00-04:00</published><updated>2021-05-03T00:00:00-04:00</updated><id>http://localhost:4000/2021/05/03/go-away</id><content type="html" xml:base="http://localhost:4000/2021/05/03/go-away.html"><![CDATA[I'm working on this stuff. Check back later please.]]></content><author><name>IanSkinner1982</name></author><summary type="html"><![CDATA[I'm working on this stuff. Check back later please.]]></summary></entry><entry><title type="html">Enabling the Hidden Wii DVD Icon Part 2</title><link href="http://localhost:4000/2021/04/08/wii-dvd-p2.html" rel="alternate" type="text/html" title="Enabling the Hidden Wii DVD Icon Part 2" /><published>2021-04-08T00:00:00-04:00</published><updated>2021-04-08T00:00:00-04:00</updated><id>http://localhost:4000/2021/04/08/wii-dvd-p2</id><content type="html" xml:base="http://localhost:4000/2021/04/08/wii-dvd-p2.html"><![CDATA[<p>Before I get anyone's hopes up, I should state that this <b>did not</b> work. If that disappointment isn't too much for you, I'd love it if you kept reading.</p>
<p>So now with that out of the way, I'm sure you're wondering, <b>what did I do differently this time?</b></p>
<p><b>1. A different method of obtaining the system files</b></p>
<p>The first major change I made, which fixed the biggest issue from last time, was the way I obtained the .app files within the Wii System Menu install WAD. Last time, I chose to just save the decrypted contents in NUS Downloader, however that ended up preventing me from packing the WAD at the end of the process. This time I didn't save the decrypted contents, but instead had NUS Downloader pack the WAD for me. Once I had the WAD, I unpacked it with Sharpii, which left me with <i>almost</i> the same files. The difference is that this time I had the ticket<sup>[Check]</sup> which allowed me to pack the WAD at the end.</p>
<p><b>2. Recompressing the archives</b></p>
<p>Note: Since this article was written long after I tried the things listed in it, accuracy is not guaranteed.</p>
<p>What I tried this time was enabling LZ77 compression on the .arc file, then compressing the .arc again into an .ash, rather than going directly to a .ash. Thanks to my new method of obtaining the Wii Menu files, I was able to pack the WAD no problem and install it. However, once I installed the WAD in Dolphin, problems arose. The initial setup went just fine, as it should have since I didn't mess with those files, however once I tried to select the Disc Channel, it all came crashing down, in a way more literal than I would have liked. Fatal exception. Unfortunately, my .ash recompression method had not worked properly. (For the sake of making sure the WAD itself wasn't the issue, I unpacked, repacked, and installed an unmodified version and it worked just fine.)</p>
<p><b>So where does this leave me?</b></p>
<p>When I originally started (and then lost) this article back when I did all this, it left me with no leads and nothing else to try, or at least nothing I could think of. Thankfully, a fellow nerd known as <a href=https://github.com/Garhoogin>Garhoogin</a> gave me some extremely valuable information. It turns out I wasn't understanding the Wii's file formats correctly (specfically the .arc and .ash formats). Only .ash files are compressed, whereas .arc files are just archives. That's why adding the LZ77 compression to the .arc didn't help; it's not a compressed file. So now my new plan is as follows:</p>
<ol>
<li>Do everything I did last time up the the recompression part</li>
<li>Pack diskBann/arc into diskBann.arc, <i>without</i> LZ77 compression</li>
<li>Compress diskBann.arc into diskbann.ash, <i>with</i> LZ77 compression</li>
<li>Put diskBann.ash at 00000001/layout/common/ and compress 00000001.app</li>
<li>Pack the WAD and install in Dolphin</li>
<li>Profit (in theory)</li>
</ol>
<p>So, for now I leave you here. Hopefully there will be an update soon, as I intend to follow the plan above in the next few days so that I can make an update to this faster than last time.]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[Before I get anyone's hopes up, I should state that this did not work. If that disappointment isn't too much for you, I'd love it if you kept reading. So now with that out of the way, I'm sure you're wondering, what did I do differently this time? 1. A different method of obtaining the system files The first major change I made, which fixed the biggest issue from last time, was the way I obtained the .app files within the Wii System Menu install WAD. Last time, I chose to just save the decrypted contents in NUS Downloader, however that ended up preventing me from packing the WAD at the end of the process. This time I didn't save the decrypted contents, but instead had NUS Downloader pack the WAD for me. Once I had the WAD, I unpacked it with Sharpii, which left me with almost the same files. The difference is that this time I had the ticket[Check] which allowed me to pack the WAD at the end. 2. Recompressing the archives Note: Since this article was written long after I tried the things listed in it, accuracy is not guaranteed. What I tried this time was enabling LZ77 compression on the .arc file, then compressing the .arc again into an .ash, rather than going directly to a .ash. Thanks to my new method of obtaining the Wii Menu files, I was able to pack the WAD no problem and install it. However, once I installed the WAD in Dolphin, problems arose. The initial setup went just fine, as it should have since I didn't mess with those files, however once I tried to select the Disc Channel, it all came crashing down, in a way more literal than I would have liked. Fatal exception. Unfortunately, my .ash recompression method had not worked properly. (For the sake of making sure the WAD itself wasn't the issue, I unpacked, repacked, and installed an unmodified version and it worked just fine.) So where does this leave me? When I originally started (and then lost) this article back when I did all this, it left me with no leads and nothing else to try, or at least nothing I could think of. Thankfully, a fellow nerd known as Garhoogin gave me some extremely valuable information. It turns out I wasn't understanding the Wii's file formats correctly (specfically the .arc and .ash formats). Only .ash files are compressed, whereas .arc files are just archives. That's why adding the LZ77 compression to the .arc didn't help; it's not a compressed file. So now my new plan is as follows: Do everything I did last time up the the recompression part Pack diskBann/arc into diskBann.arc, without LZ77 compression Compress diskBann.arc into diskbann.ash, with LZ77 compression Put diskBann.ash at 00000001/layout/common/ and compress 00000001.app Pack the WAD and install in Dolphin Profit (in theory) So, for now I leave you here. Hopefully there will be an update soon, as I intend to follow the plan above in the next few days so that I can make an update to this faster than last time.]]></summary></entry><entry><title type="html">Enabling the Hidden Wii DVD Icon Part 1</title><link href="http://localhost:4000/2021/01/30/wii-dvd-p1.html" rel="alternate" type="text/html" title="Enabling the Hidden Wii DVD Icon Part 1" /><published>2021-01-30T00:00:00-05:00</published><updated>2021-01-30T00:00:00-05:00</updated><id>http://localhost:4000/2021/01/30/wii-dvd-p1</id><content type="html" xml:base="http://localhost:4000/2021/01/30/wii-dvd-p1.html"><![CDATA[<p>NOTE: This article was originally written in OneNote and was not altered before being uploaded here. Please excuse formatting errors.</p>
<p>Unsurprisingly, this is more easily said than done. To do this, you need to modify the Disc Channel’s BRLYT file (“Binary Revolution Layout” file), which is contained in the diskBann.ash file, which can be found at</p>
<p> | 00000001/layout/common/diskBann.ash</p>
<p>and the BRLYT file is stored inside that at</p>
<p> | diskBann/arc/blyt/</p>
<p>Once you’re there and can write to the file, it’s just a matter of changing a 00 to a 01.</p>
<p><b>1. Obtaining the Necessary Files</b></p>
<p>The first thing I needed to do is get the Wii System Menu files (in this case I downloaded System Menu 2.0U), using a tool like NUS Downloader to get them right from Nintendo’s servers. I chose to not pack the WAD, and to keep only the decrypted contents. The only file I really needed from this download was 00000001.app, but I kept the rest so that I could pack the WAD later.</p>
<p><b>2. Extracting</b></p>
<p>Now that I had the file I needed, I had to open it. I ended up using Sharpii’s U8 extraction tool to extract 00000001.app into the directory 00000001. Once I had it extracted, I poked around to see if I could find what I needed to find. Fortunately, that was one of the easiest things I had to do. Once I located the diskBann.ash file that I needed to get into, I had to figure out how to get into it. Eventually I found a tool called Easy CSM, and used its command-line ASH extraction tool to extract diskBann.ash into diskBann.ash.arc (so just an ARC file). I then struggled to figure out what I had to do with that ARC file. I tried using ECSM, but it just crashed, probably because I didn’t understand how it wanted me to set it up. I eventually discovered that the U8 extraction tool that from Sharpii is compatible with ARC files. What luck! Once I understood that, I was able to extract it and look through its files to find what I was looking for.</p>
<p>Once I had the BRLYT file in my sights, I finally felt like things were going to work! …until I realized that, like before, I had no idea how to get into this file. I managed to find a guide on banner creation for the Wii, and it has a guide on how to convert a BRLYT file into an XMLYT file (using a tool called Benzin), which I could just open in Notepad. (Pretty sure an XMLYT file is just an XML file - it certainly looks like one.) Once I had it in an acceptable format, I just had to scroll through, find the flag I needed to change, change it, and get out of there.</p>
<p><b>3. Recompressing</b></p>
<p>I thought the hard part was over. It wasn’t. Now that I had changed what I needed, I needed to stick it all back together so I could use it. Luckily, Benzin could change XMLYT files back into BRLYT files, so that was easy enough. But then I had to figure out how to compress the diskBann folder back into an ASH file. I didn’t have anything that could do that. I was able to compress it into a file that said it was an ASH file using Sharpii, but it was the exact same size as the ARC (which was much larger than the ASH), so it seems to have just created a renamed ARC file. I decided that was probably good enough, since I knew some other files were also just renamed ARC files. The next step, compressing everything back into 00000001.app, wasn’t terrible once I figured out how the command worked. And this is where I hit the roadblock that stopped me. I needed to pack everything into a WAD so that I could actually use it. And the command failed every time. </p>
<p>So this is where things end for now. I <i>have</i> experimented more since this, and made more progress, so expect a follow up article at some point.</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[NOTE: This article was originally written in OneNote and was not altered before being uploaded here. Please excuse formatting errors. Unsurprisingly, this is more easily said than done. To do this, you need to modify the Disc Channel’s BRLYT file (“Binary Revolution Layout” file), which is contained in the diskBann.ash file, which can be found at | 00000001/layout/common/diskBann.ash and the BRLYT file is stored inside that at | diskBann/arc/blyt/ Once you’re there and can write to the file, it’s just a matter of changing a 00 to a 01. 1. Obtaining the Necessary Files The first thing I needed to do is get the Wii System Menu files (in this case I downloaded System Menu 2.0U), using a tool like NUS Downloader to get them right from Nintendo’s servers. I chose to not pack the WAD, and to keep only the decrypted contents. The only file I really needed from this download was 00000001.app, but I kept the rest so that I could pack the WAD later. 2. Extracting Now that I had the file I needed, I had to open it. I ended up using Sharpii’s U8 extraction tool to extract 00000001.app into the directory 00000001. Once I had it extracted, I poked around to see if I could find what I needed to find. Fortunately, that was one of the easiest things I had to do. Once I located the diskBann.ash file that I needed to get into, I had to figure out how to get into it. Eventually I found a tool called Easy CSM, and used its command-line ASH extraction tool to extract diskBann.ash into diskBann.ash.arc (so just an ARC file). I then struggled to figure out what I had to do with that ARC file. I tried using ECSM, but it just crashed, probably because I didn’t understand how it wanted me to set it up. I eventually discovered that the U8 extraction tool that from Sharpii is compatible with ARC files. What luck! Once I understood that, I was able to extract it and look through its files to find what I was looking for. Once I had the BRLYT file in my sights, I finally felt like things were going to work! …until I realized that, like before, I had no idea how to get into this file. I managed to find a guide on banner creation for the Wii, and it has a guide on how to convert a BRLYT file into an XMLYT file (using a tool called Benzin), which I could just open in Notepad. (Pretty sure an XMLYT file is just an XML file - it certainly looks like one.) Once I had it in an acceptable format, I just had to scroll through, find the flag I needed to change, change it, and get out of there. 3. Recompressing I thought the hard part was over. It wasn’t. Now that I had changed what I needed, I needed to stick it all back together so I could use it. Luckily, Benzin could change XMLYT files back into BRLYT files, so that was easy enough. But then I had to figure out how to compress the diskBann folder back into an ASH file. I didn’t have anything that could do that. I was able to compress it into a file that said it was an ASH file using Sharpii, but it was the exact same size as the ARC (which was much larger than the ASH), so it seems to have just created a renamed ARC file. I decided that was probably good enough, since I knew some other files were also just renamed ARC files. The next step, compressing everything back into 00000001.app, wasn’t terrible once I figured out how the command worked. And this is where I hit the roadblock that stopped me. I needed to pack everything into a WAD so that I could actually use it. And the command failed every time. So this is where things end for now. I have experimented more since this, and made more progress, so expect a follow up article at some point.]]></summary></entry><entry><title type="html">Welcome to the Blog</title><link href="http://localhost:4000/2021/01/29/hello-blog.html" rel="alternate" type="text/html" title="Welcome to the Blog" /><published>2021-01-29T00:00:00-05:00</published><updated>2021-01-29T00:00:00-05:00</updated><id>http://localhost:4000/2021/01/29/hello-blog</id><content type="html" xml:base="http://localhost:4000/2021/01/29/hello-blog.html"><![CDATA[<p>Hello, and welcome to the NCX Programming blog! We plan to write about all sorts of tech nonsense here. Stay tuned for the first article, which will be about the Wii!</p>
<p>For now, that's all I have to say. Our first articles should be coming out soon.</p>]]></content><author><name>NinjaCheetah</name></author><summary type="html"><![CDATA[Hello, and welcome to the NCX Programming blog! We plan to write about all sorts of tech nonsense here. Stay tuned for the first article, which will be about the Wii! For now, that's all I have to say. Our first articles should be coming out soon.]]></summary></entry></feed>
Reference in New Issue View Git Blame Copy Permalink