haloman30

Hey, everyone! Not much to actually write here, but we've just uploaded a YouTube video going over the current state of the Blamite Game Engine. We plan to create more of these as time goes along and the engine continues to grow and evolve. We can't say how often they'll be produced, but we want to start showing off new features as they get developed. Sometimes they'll just be simpler stuff without too much visual flare, other times it might be something a bit more exciting. This first video was uploaded yesterday and was recorded by yours truly. It's a fairly in-depth one as I was both somewhat sleep-deprived, as well as the video being entirely unscripted. So, if you want to check it out, bundle up, grab some popcorn, and give it a watch.

Howdy, folks! You may have noticed that the forums were offline for a bit today. That's because today was the day of... The Big Move™. And by that, I mean that today was the day we migrated away from InMotion Hosting. But why? Why the sudden webhost migration? Well, if you've been active on the Discord - you'll know this wasn't sudden at all. This has been the plan since earlier this year. It just took until fairly recently for it to become feasible - or at least, seemingly feasible. Why We Moved As great as InMotion has been considering how much we paid for it, they've become increasingly frustrating to work with. On more than one occasion, I would get an email in my inbox telling me to remove a handful of .zip files. You see, according to their ToS, you aren't allowed to use the webhost for anything other than a website and email. Hosting files or other content that isn't explicitly part of a website doesn't fall into that category. I was at first unaware of this - because let's be real, nobody reads the ToS. Luckily, they don't just instantly shut your account off if they detect zip files. You get 48 hours to remove the files and only if you fail to do so afterwards are you at any risk of account termination. At first, this was still a pretty fair thing. It wasn't every single zip file, rather it was just a handful of larger ones - usually world archives. By the time this started to come up, I'd already had a subscription to OpenDrive, which gives me unlimited cloud storage for a mere $100 a year. So - I just moved everything over there, and while it took a while (especially to upload), it was done and things were good. But of course, if that's where it ended, we wouldn't be putting up a topic saying we'd moved away from them, would we? No - this continued to become more and more of a problem. What started as requests to remove 20-50GB archives later turned into 100-300MB archives, and later did in fact turn into every single .zip archive on the entire host. The last email I got about excessive "backup content" was one listing 196 different files, many of which were only a few megabytes in size. A select few were larger - but some of them were so small that they were even less than 1MB. This wasn't the only issue I'd had with them. Additionally, performance had become a recurring problem. Now in fairness - this is undoubtedly in part due to poor optimizations on my part. There's likely stuff I could do to improve things. For a while, the banner images you'd see on most pages were at 4k resolution, and in PNG format. Many of those were later downscaled to 1080p JPEGs, which somewhat helped. However, one of the biggest factors with the performance of the host happened to not be large images used in various places - but rather, resource limitations on the host itself. Not disk or storage limits, mind you - one of the best things about InMotion was the unlimited everything. Turns out, the CPU usage even during a single page load was being maxed out. The poor response times were a result of the machine itself being stressed and strained. Now, you might be wondering - why not just make a ticket? I could've theoretically made a ticket with them, because it's entirely possible the CPU usage had little to do with my own site. And this comes into the other issues with InMotion - it was a shared host. For smaller or simpler websites, there's absolutely nothing wrong with shared hosting. All the hard management stuff is taken care for you out of sight - all you worry about is the content itself and that's it. Things just work - and that's the beauty of it. It worked for us for a while too, and it perhaps could've continued to do so going forward. However, when running under shared hosting, if someone else is hitting the CPU hard for whatever reason, that'll start to affect you, too. It's all under the same machine - hence the term, "shared" hosting. You can get dedicated hosting to work around this, but this tends to be much more costly. The common thread interleaved between these issues all center around one thing - ownership and control. And that's precisely what this move was designed to fix. Our New Home So, where did we move? What hosting company did we go with? If you're active on Discord you already know the answer, but if not... nobody. We aren't hosted with any 3rd party company. For the first time in CU's history since 2015, one of our services is running off of owned hardware. That's to say, hardware that is itself entirely under ownership and control of CU. I've upgraded my home internet to a business plan with faster speeds (at virtually no increased cost), rebuilt my old AMD FX-8370 desktop, hooked it up to my TV, and went out and bought a single-user cPanel/WHM license and got everything set up. The only stipulation with that single-user license is that it runs in a virtual environment - which it does. However, I am in full control of this virtual environment and it's got plenty of breathing room to work with - so any performance/latency losses from virtualization should be negligible. The system is setup to have automated backups, and I'll be getting it setup to periodically upload them to OpenDrive as well for added peace of mind, as the website is one of those things that we've been negligent to back up regularly. Along with that, it's got two 2TB hard drives that are mirrored - so it's also safe from any potential hard drive failures as well. Now - full disclosure, this is partially an experiment in a way. It took a lot of tinkering and many days of slamming my face into my desk to work out some of the kinks with the whole setup - but things should be running smoothly now. Even so, I fully expect bugs to crop up just because of the fairly different system being run. Along with that, I'm also in the middle of sorting out stability issues with the FX board itself. But don't panic - I've got a backup board/CPU if it turns out that the FX (or the board it's on) are faulty. The issue at this time appears to be a faulty RAM stick - which has since been removed and the server has been stable ever since, but we won't know for sure for another week or so. If the site does happen to go offline, I can assure you it'll come right back online as soon as possible. And, in the worst case scenario - if running this stuff off of local hardware turns out to be completely infeasible and just isn't working out, I'll be holding onto the InMotion host for a while still - so that if we ever have to move back over, we can. But, as of now - everything seems solid. DNS works, Email works, the forums and website both work, everything seems to finally just work. If you find something that goes against that - don't hesitate to report it on the bug tracker. If the site happens to go offline for an extended period of time, ping me or DM me on Discord and I'll get it back online once I see it (likely after doing some hardware maintenance if it turns out the machine froze again). Oh, and be sure to let us know if the site is any faster than before. It should be a little faster, but there's still one more hardware upgrade that the machine needs - so it won't be running at full speed until then. Otherwise, if no issues arise - that's it. We're moved onto what will hopefully be the new home of the Chaotic United, Elaztek, and any other websites for the foreseeable future. And this time, there's nobody to tell us what content we can or can't have on the site. No arbitrary rules on zip files or having too large of files. The only one who has any say in what we do with the CU website, is us. And damn does that feel good. Just as a sidenote, I'm not intending to throw any shade at InMotion. They gave us pretty decent hosting for 13 bucks a month. Unlimited disk space, addon domains, email accounts, and so on. The performance wasn't great - but even then, when it's that cheap, it's hard to argue with it too much. If you happen to be wanting to host a site of your own, don't let my words against shared hosting scare you off of it. For simpler stuff or for people just getting started, shared hosting is affordable and relatively easy to use. It served ourselves, Nuclear District, and the old CU well for many years - we've just decided we want to take things into our own hands now. Anywho, that's all we've got for this one folks! Apologies for the downtime - though to be honest, it didn't last nearly as long as I was expecting. Overall, the migration went about as smooth as I could've asked for. Be sure to let us know if you run into any issues on the site.

Hey, everyone! It's been a little bit, and we've got some news to share! Gitlab Migration First off: we've once again migrated the Gitlab, except this time we didn't break LFS data. The new and updated Gitlab can be found at the Gitlab's original URL: https://gitlab.elaztek.com. As a result, if you have any repositories cloned you will need to update the origin push/pull URL's to point to gitlab.elaztek.com instead of newgitlab.elaztek.com. Since all the old data (accounts, repositories, etc.) is still present, no other adjustments should need to be made to those URL's. You may need to log-in again if you use a GUI application for interacting with Git, and if your repositories utilize webhooks those may need to be adjusted as well (though this depends on the hooks themselves typically). The old URL (ironically named https://newgitlab.elaztek.com) has been set to redirect automatically to the new URL. As a sidenote, the Gitlab has not exchanged hands during this migration. Seeing as internally I've mentioned moving things to my own hosting a few times (and I suppose it's possible that such information may have slipped out potentially), I figure its worth mentioning. The main purpose behind this migration is to reduce the sheer number of servers that have been in use by Errite (the studio that hosts Gitlab as well as assists with other server-management-stuffs with Elaztek and CU), as it became more costly than made sense. Blamite Game Engine You didn't think we've been sitting alone doing nothing the past few months, have you? If you did think that - you'd be entirely justified because there's been a lot of that before. But today, we've got some goods to show off. For most of you, it'll be more boring stuff - but while it isn't much on the surface, it's actually a much bigger deal under the hood - and I'll try to make that clear as best as I can. Engine Architecture Changes The game engine has, up until now, been a standalone executable. No libraries or anything crazy like that, just a simple blam.exe and that's it. However, as time went on it became clear that this wasn't gonna work out long-term. The engine's core has to be used outside of just the game - Sapien will need to use it, our UI editing tool that has yet to be named needs to use it, and our planned unified editor for Blamite will of course need to use it as well. So, we had to perform some adjustments to migrate the engine from being a standalone application to a DLL, or Dynamic Link Library. In layman's terms, this means the engine can be utilized by other applications without having to bake the engine's runtime into each and every development tool by hand. We aren't done with that migration, as the migration has revealed a couple real issues - namely that the engine doesn't have a very clean startup and shutdown routine. There's a lot of data that "persists" through restarts erroneously, that was previously given no thought since that data would just be lost on exit. However, this mainly refers to trying to do things like stop/start the engine from those external tools - initial startup works just fine. Documentation Along with this, we've started to build up a documentation website for Blamite. Or, rather, a "Guides" section. We have automated source documentation built via Doxygen, but this is presently kept behind lock and key - as it includes many of the source code files for the engine. What isn't being kept behind lock and key is this new Guides section, which is derived from the Blamite repository's Wiki section. The new documentation is crisp, clean, and much easier to use than Gitlab's built-in Wiki (especially for what we're using it for). Keep in mind - absolutely nothing on these guides should be relied upon for any amount of real guidance at the moment. Since the engine is only in its infancy at the moment, a lot of things are undocumented. What is documented are, in many cases, old feature plans by 16-year-old-me back when I had no real clue how to do anything with a game engine, or even C++ for that matter. You will see a few pages marked with a notice like this: Usually it will contain a message about me harshly criticizing my past self and stating that the page exists for archival purposes only. Most of these pages are kept in the 'Deprecated' category. Other pages are either out of date, incomplete, or in some cases may actually be complete if you're lucky. Don't expect anything too exciting on the guides for a while, though you may periodically get a glimpse under the hood in between announcements. The new guides section can be found at https://hub.elaztek.com/guides/latest. Tags - The backbone of all Blamite content For those of you at all familiar with Halo's game engine, you've surely heard of Tags before. In Bungie's engine, tags are used for the vast majority of all game content. And as of now, Blamite has full support for creating new tags and tag classes. Cache files (.map files) aren't implemented yet, and there are a few other things that need to be accounted for, but the bulk of the engine's tag/tagclass system is functional. Along with that, we've made a couple minor but, in my opinion, very key changes that will prove to be invaluable later on. Each tag file stores the version under which it was created within its file. And while this may not seem like a huge deal, it means that we'll be able to actually know what exact version each tag was built with. This can be used for a number of things, particularly with backwards compatibility. We could either let the engine be aware of all previous tag formats - though this could prove to become very unwieldy, very fast. A more realistic implementation is having Guerilla facilitate tag upgrading. We could even make it so Guerilla can automatically download the appropriate plugin files for that tag and help the user migrate their tags forward. No tag classes have actually been solidified yet. In fact, Guerilla hasn't even been upgraded to be able to handle proper tag files. But it's something that'll be happening sooner rather than later. Screenshots So, I've talked about a number of things in this post - but so far, I've not shown anything in the way of photos. Let's fix that. Below you can find some screenshots of the various engine tools. Each image will have a brief explanation below it. Sapien Guerilla Blamite Engine Unfortunately folks, that's all we've got - for now. Progress is always being made - and while not all of it is worth showing off, be rest assured we're always inching closer to having a fully functional engine on our hands. 3D rendering isn't being worked on yet - but we're very close to being there. Until then, we'll see you all next time.