Subscribe
Badlion Client Developer Blog #1: The new position & scaling system in BLC 3.2
Posted on 19 June 2021 - 07:09 PM
Literally cannot see realms anymore on 1.16.5, sad. Fix this.Last edited on 20 June 2021 - 02:28 AM by lafour01
flakex wrote
Literally cannot see realms anymore on 1.16.5, sad. Fix this.
available in 1.17 and if you dont see it switch the main menu to the alternative main menu and restart the client if still no realm submit a bug report at the bottom of the launcher explaining the issue
Posted on 21 June 2021 - 06:16 AM
flakex wrote
Literally cannot see realms anymore on 1.16.5, sad. Fix this.
We dynamically check the same way Mojang does it to verify the version supports Realms.
Since 1.17 is out, it's most likely possible Realms is now only supported on 1.17 and no longer on 1.16.5.
Posted on 04 July 2021 - 03:14 PM
GyllieGyllie wrote

Hello everyone,
Welcome to the first Badlion Client Developer Blog! In these blog posts we'll be giving you all an insight how some of our Badlion Client features work and explain how we have come to these designs. In this first post we'll be discussing the new Mod positioning & scaling system we've implemented in the BLC 3.2 release. This system is used by mods we call Render Mods as they render something on the UI and includes mods like CPS, FPS, Player Counter, etc.
This new mod system will increase stability of your mod profiles, prevent them from bugging out, and create an overall game play experience for all of you. Most of you won't even notice any new changes, because the system just works and will keep your mods the way they were before the changes.
Previous System and its issues
The base of the old system was started in the very early days of the development process for the client. Over the past 3 years this system was adapted, expanded and built upon based on the needs of new mods we were adding at that point in time. Of course during this process we always had to make sure we didn't break how existing mods already work and how their information was already stored in the profile from our users. Here is a quick brief explanation how this information used to be stored in the old system.
First of all we divided the screen in 32 boxes horizontally & 32 boxes vertically. Using these boxes we stored the box it is in and a relative percentage compared to the top left of position of the box.
Using this for every render mod we stored 3 positions:
- Top Left Corner
- Middle Point
- Bottom Right Corner
Using these 3 positions we calculated the size of the mod & it's position. Along with this we also stored what mods were locked or snapped against it and on what side.
Now the main issues with this system is that the stored values were constantly being updated when you were resizing the screen, going in/out fullscreen, adapting a mod setting… Basically it was updating your profile way too many times what often resulted in profiles breaking completely, causing new mods to be hard to add or adding new functionality into existing mods on this "old" system.
Coming up with a solution
A couple weeks ago we decided it was time to think about a new solution and design. During this process we first listed everything the system requires to work for the current mods and also keep in mind flexibility for future plans. Multiple solutions came up during the discussions but at that point we also accounted for all the issues we've had in the past trying to add new features, issues our users have when using the old system and a system possible to be migrated to without resetting everyone's setup.
After discussing everything needed we came with a solution we call the Box System.
The new solution
The Box System is in short words an abstract piece of software that is designed to work completely on its own, even outside of Minecraft and our mod code. It's only purpose is to handle "boxes" that have a certain place & size on the screen and update them when the screen resizes. Here is a quick video of how it works in a prototype version before we dive more into how it works.
As mentioned above this system is build around boxes. Right now we only have 3 type of boxes:
- A normal simple box which is just completely on its own. Has its own position and size information stored
- A grouped box which also has its own position and size but also has a list of sub-boxes linked to it
- A sub box which is part of a grouped box and holds relative position & size compared to its grouped box
In the video above you can see examples of each type as well as 1 box (top middle) which showcases a box which changes size during the rendering process since some of our mods have to become wider/smaller based on what they are displaying. These boxes stored their default size and just adapt the position on the moment of rendering.
So now you briefly know what kind of boxes exist lets talk about positioning. As you know positioning in the old system was one of the main issues so we totally went for a different approach here. First of all the screen is now divided in 9 quadrants in a 3x3 format where the height/width is each times 1/3 of the respective screen size. Each box will store in which quadrant its center point is.
Along with what quadrant a box is in, the box will also store the respective point compared to the quadrant. This means a box in the top left will store the top left corner position, a box in the middle center quadrant will store the center position. The image below demonstrates how the center point (red) decides the quadrant and which point will be stored (purple). The position points are stored using a percentage relative to the top left corner of the quadrant it is in.

The final piece of information we store is the size of the box, which is simply stored in pixel size. This is one big difference from the old system where the mods became bigger/smaller if you resized the screen, they will now remain the same to avoid all the issues we had scaling wise in the past.
With all this information the box system can do its job and calculate the actual positions for the box when we want to render them. So what happens now if you change the screen size? Basically the system will keep it's stored positions the same relative position to it's quadrant, no matter the screen size. But since width/height doesn't scale it will be pushed away from the stored point. You can easily see this in the example video above with the grouped box on the right being pushed both up/down to keep the center right point in the exact middle of it's quadrant.
Another big important reason we designed the system as a standalone piece of software is that we have automated tests running every time we do code changes to assure no developer breaks the system by accident. One thing we definitely learned is that you can't test every single piece of code in our massive code base. So these kind of automated tests will be added more and more to help us test.
Finally this update is the first new feature also using a new mod profile versioning system we implemented in BLC 3.1. This versioning system will help us avoid breaking profiles if we add new features but not lose backwards compatibility. It also gives us the ability to write migration scripts which we used here to convert the old stored positions to the new system.
Conclusion
BLC 3.2 brings a complete newly designed mod positioning & scaling system. This system will behave a bit different from the old logic but should be a lot smoother & easier to use. The system is also more abstract and testable in order to avoid your profiles from glitching out randomly. We also did some extensive testing on this new system with our test team to make sure your current setups don't break. Of course we'll continue improving this system as well as add new features now the system has had a good cleanup.
Posted on 04 July 2021 - 03:15 PM
i dont understand but i support, keep up, i think youre doing great, and the client its verry good