Search the Community

Showing results for tags 'sapien'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Site Bugs

Categories

  • News & Announcements

Categories

  • Tutorials and Guides
    • Blamite Game Engine
    • Website and Forums
    • Miscellaneous
  • Resources
    • Guidelines
    • Troubleshooting
    • History
    • Blamite Game Engine
    • Website and Forums

Categories

  • Products

Categories

  • Project: Infinity Issue Tracker

Categories

  • Blamite Game Engine Issue Tracker

Categories

  • Elaztek Launcher Issue Tracker

Categories

  • NTClient Version History

Categories

  • Suggestions Tracker [Legacy]

Categories

  • Introduction
  • Using the Engine
    • Configuration & Settings
    • Debugging
    • In-Engine Tools
  • Using the Editing Kit
    • Foundry
    • Guerilla
    • Sapien
    • Tool
    • Customization
  • Technical Information
    • File Formats

Categories

  • Blamite Game Engine Suggestions
    • Archive
  • Website/Forums Suggestions
    • Archive
  • Discord Suggestions
    • Archive
  • Other Suggestions
    • Archive

Categories

  • Volunteer Positions
  • Paid Positions
  • Submitted Applications

Forums

  • Community Hub
    • News & Announcements
    • Suggestions & Feedback
    • Staff Applications
  • Server Management
    • Support
    • Reports
    • Ban Appeals
  • Projects
    • Infinity
    • Blamite Game Engine
    • DonationStore
    • Sandbox
  • Server Discussion
    • Discord
  • Community Discussion
    • The Den
    • Computers & Tech
    • General Gaming
    • PC Gaming
    • Console Gaming
    • Tutorials & Guides
  • Area 51
    • Archive

Product Groups

  • Games
  • DLC/Downloadable Content
  • Software
  • Merchandise

Blogs

  • Update Notes
  • Raven Runner Game - Official Updates
  • Elaztek Launcher Update Notes
  • Blam Update Notes
  • Blamite Development Blog
  • Haloman30's Blog
  • Eon Blog
  • Galactiminer Update Notes
  • HealthAndMore
  • Hebe Medical Spa
  • Why Manual Testing Five Reasons
  • Breath of life
  • Employee time clock app
  • Sandbox Update Notes
  • test's Blog

Categories

  • Official Games/Projects
    • Blamite
    • Sandbox
    • Project: Infinity
    • Elaztek Launcher
    • Legacy
  • Community
    • Project: Infinity Mods
  • Blamite Game Engine
    • Tools and Utilities
    • Editor Themes

Calendars

  • Project: Blamite Game Engine
  • Project: Miscellaneous
  • Community Calendar

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Github


Minecraft Username


Steam


Gitlab


Xbox LIVE


Website URL


Discord


Skype


Gender


Location


Interests


About Me


CPU


Graphics Card (GPU)


Motherboard


Operating System


Memory (RAM)


Cooling Type


Storage


Other PC Info

Found 2 results

  1. 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.
  2. 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.