BejaClient - a Lunar Alternative?
The BejaClient is a highly customized, modern Minecraft client and launcher ecosystem designed to deliver optimized performance, advanced mod management, and a seamless user experience. Built using a split architecture, it bridges the gap between low-level Java game modifications and a high-performance, modern web-tech desktop frontend.
- Architectural Overview & Split System
The BejaClient is divided into two distinct components to maximize stability, ease of updates, and security:
The Desktop Launcher Frontend: Built using Electron, Vue 3 (Composition API with <script setup lang="ts">**)**, and Vite. This interface handles user authentication, profile management, mod discovery, and game launching configurations.
The In-Game Mod Core (BejaClient.jar): A heavy, feature-packed Java modification designed specifically for modern Minecraft versions (such as 1.21.1). It utilizes modern modding frameworks, Mixins, custom event-bus systems, and persistent WebSocket connections to communicate back and forth with the backend infrastructure. - Version Support & Vanilla Nostalgie Fallback
One of the standout architectural highlights of the BejaClient launcher is its elegant version handling:
Modern Versions (1.21.1+): The launcher injects the fully-featured BejaClient.jar, activating custom network hooks, modern rendering engines, and client-side modules.
Legacy/Nostalgia Versions (Minecraft 1.0.0): Because code written for 2026/2021 Minecraft relies on Mixins and Java structures that did not exist in 2011, trying to force the BejaClient.jar into Minecraft 1.0.0 would result in an immediate, catastrophic crash. To counter this, the launcher intelligently detects legacy version selections and seamlessly drops back to launching a pure, stable Vanilla 1.0.0 environment. Unlike restrictive competitors (such as Lunar or Badlion), BejaClient acts as a highly flexible launcher that doubles as a generic vanilla launcher when users want to play legacy versions without crashing. - Backend Infrastructure & Live Network Metrics
The BejaClient backend handles live lobby synchronization, global chat networks, cosmetic data delivery (such as custom capes), shop configurations, and user profile validation.
Recent network data reveals an incredibly lightweight, well-optimized backend ecosystem:
Network Inbound: 29.03 MiB
Network Outbound: 50.86 MiB
The traffic ratio is highly optimal. Eingehender Traffic (Inbound) consists of lightweight player requests, heartbeat pings, and WebSocket packets. Ausgehender Traffic (Outbound) is naturally higher because the server serves larger data chunks back to the clients, such as rendering data, asset paths, and global state updates. Over extended runtimes, these metrics prove the backend is highly efficient and capable of scaling cleanly. - Source Control, Repository Strategy, and Code Signing
To secure a professional user experience without exposing proprietary backend structures, a strict open-source versus private repository strategy is evaluated:
The Code Signing Dilemma: Acquiring a trusted Windows SmartScreen Code Signing Certificate (via platforms like SignPath or Certum) often relies on open-source community programs. Keeping the repository public builds rapid SmartScreen reputation through community downloads, eliminating the harsh "Windows protected your PC" warning.
The Hybrid Solution: To protect core assets while keeping developer certificates valid, the recommended path is a hybrid structure:
Keep the Launcher Frontend Open-Source: The Electron/Vue code contains no sensitive keys or backend exploits and can safely remain public to satisfy open-source certificate requirements.
Keep Core Elements Private: The Java bootstrap layers, proprietary network engines, and server backends reside in entirely separate, private repositories away from public view. - High-End In-Game UI Philosophy: Shaders & Fabric
Advanced design methodologies for the client emphasize pushing the absolute limits of the Fabric Mod-Loader platform:
"Pulling the Fabric Dev Skill": Utilizing Fabric’s lightweight, deeply injectible hook system to implement advanced UI/UX layers.
GPU-Accelerated Shaders for GUIs: Moving away from traditional, flat, pixelated Minecraft texturing methods. By utilizing custom GLSL shaders directly on the graphics card, the in-game menus can render high-end visual effects smoothly. This includes dynamic background blur (Gaussian blur interfaces), perfectly rounded vector corners, real-time color gradients, and physics-based menu animations. - Performance Mod Consolidation (Dependency Embedding)
To provide an unrivaled out-of-the-box performance boost without forcing players to hunt down performance patches manually, the client natively integrates the holy trinity of optimization mods:
Sodium: For revolutionary rendering engine rewrites and massive FPS gains.
Lithium: For deep physics, chunk-loading, and local server-side calculation optimization.
FerriteCore: For extreme reduction in RAM usage and memory footprint.
Rather than illegally copying and pasting raw source code (which breaks GPL/LGPL licensing boundaries and creates an unmaintainable nightmare whenever upstream updates release), BejaClient utilizes Jar-in-Jar (JiJ) Dependency Embedding via Gradle. By adding these mods as include configurations in the build script, Fabric automatically un-packages, compatibility-checks, and launches them smoothly alongside the core client jar. - Deep Code Review: HUD Rendering Fixes & Fragile Heuristics
A deep code analysis identified three critical vulnerabilities within the legacy in-game HUD rendering systems (HudRender.java) that required immediate remediation: - The Reflection Overload: The pack-icon rendering was held together by highly unstable reflection hacks instead of using the native Minecraft API. It reflectively scanned for internal methods (open/createResourcePack) to read pack.png files and bypasses safety restrictions using setAccessible(true) on private constructors instead of calling clean factory paths like Identifier.of(namespace, path). Most dangerously, it would loop over every method named drawTexture in DrawContext, blindly guessing integer and float slot parameters under a massive catch-all Throwable block. This "spray and pray" approach leads to silent failures, misplaced icons, or corrupted rendering states.
- String Truncation Error: The HUD name-display system was fundamentally flawed by stripping everything following the last dot (lastIndexOf('.')), operating under the false assumption that resource pack names always end in file extensions like .zip. Because getDisplayName() pulls the localized title directly out of pack.mcmeta, a pack named "Faithful 1.2" would be incorrectly rendered on the HUD as "Faithful 1".
- Fragile String Filtering: The filter method findActivePack() utilized a primitive heuristic that skipped any pack containing the substring "mod". While intended to hide internal mod-provided asset packs, it completely blocked legitimate user texture packs that happened to have "mod" in the name (e.g., "Modern HD").
- Latest Major UI/UX Overhaul (The Recent Pull Request)
The most recent engineering push brought a massive, highly professional visual and technical upgrade to the launcher's frontend interface. It transitions the old, basic mod-listing tab into a fully functional, highly interactive Mod Dashboard.
Visual & Layout Changes
New Controls Row (.controls-row): A beautifully structured layout zone sits above the main content panel to host global action components.
Modern Search Bar (.search-bar): A sleek, dark input box (background: #111) with an integrated SVG magnifying glass icon. It features crisp 6px border-radii and an elegant transition animation that changes the border color smoothly when focused (&:focus-within).
Action Button Suite: Two brand-new, clean, flat-design buttons accented with minimalist vector icons are introduced: "BROWSE CONTENT" and "UPLOAD FILES".
Empty State Management: When zero mods match a user’s search parameters, the list smoothly swaps out for a clean, centered layout block (.empty-state) displaying an "Icon Not Found" graphic and an explicit "No mods match..." notification text.
Inline Action Cells (.mod-actions-cell): Each row in the mod list now features a modern control hub on the right-hand side. It houses an active Switch-Toggle (sliding checkbox) to enable or disable the mod instantly, along with a dedicated Trash Icon Button to wipe unneeded mods from the disk directly through the UI.
Context Menu Integration: A new, perfectly aligned option row (.ctx-item) has been injected into the drop-down action menus for instant navigation.
Architecture & Code Quality Improvements
Sass Modularization: Outdated, deprecated @import statements inside global.scss were entirely replaced by the modern @use module system, safeguarding the project against future compilation failures.
Sass Color Function Upgrades: The deprecated legacy function darken() was eliminated from hover styles in favor of the modern @use "sass:color" and color.adjust() modules.
Vite Configuration Realignment: The vite.config.ts file was rewritten to properly inject global variables via additionalData, ensuring styles load seamlessly across all single-file Vue components.
Reactive Search Logic: Built entirely with Vue 3 computed properties, the filteredMods logic processes user input in real-time. It transforms inputs to lowercase (toLowerCase()) and evaluates matching criteria instantly without blocking the main UI thread.
Lifecycle Hook Enhancements: The addition of the onActivated(() => { loadMods() }) hook ensures that whenever a user navigates between profile panels or switches back to the launcher window, the mod list automatically refreshes itself in the background, matching any changes made directly in the OS file explorer.
Electron Native Bridge Calls: The "Open Folder" button hooks straight into the secure Electron layer (window.api.mods.openFolder), mapping the user's local profile path and immediately spawning a native Windows Explorer or macOS Finder window over the launcher interface. - Release & Deployment Pipeline
Once these comprehensive updates are approved and merged on GitHub into the primary branch, they enter the delivery cycle: - The Compilation Step: The code is pulled locally (git pull) and bundled via Vite and Electron Builder.
- The Deployment Model: Because BejaClient operates as a standalone local desktop application, these extensive UI modifications, search features, and optimization systems are compiled into the binary payload of the next official launcher release executable (e.g., updating from v1.0.0 to v1.1.0), instantly landing the new dashboard experience in the hands of the entire player community upon auto-update.
u/B3JA — 4 hours ago