Tags
Creators
Details
Licensed LGPL-3.0-only
Published last year
Updated 3 months ago
All versions
0.6.0
Beta
Velthoric 0.6.0 for NeoForge 1.21.19 months ago 204
Compatibility
Minecraft: Java Edition
1.21.1
Platform
NeoForge
Supported environments
Client and server
Required content
Any compatible version
Changes
Changelog โ Version 0.6.0
Features
- Implemented extended region file format to remove chunk size limits and enable automatic data pruning
- Added hot-map persistence architecture for instant body registration and lookup
- Introduced persistence flags for physics bodies and constraints
- Implemented Jolt-based modular powertrain system with transmission logic
- Added directional fluid flow vectors for advanced buoyancy simulation
- Added new
VxKeyMappingsystem with fallback display names for unbound keys - Added client-side callbacks for body registration lifecycle events
- Enabled automatic creation and deletion of empty region files
- Added CurseForge environment metadata support
Fixes
- Fixed multiple persistence race conditions causing missing or empty physics data
- Prevented native crashes by validating body existence before buoyancy locking
- Resolved Linux physics instability by replacing batch locking with sequential access
- Ensured inactive and non-dirty bodies persist correctly during chunk save and shutdown
- Fixed gravity desync in native buoyancy implementation
- Fixed terrain velocity prediction causing excessive chunk loading
- Corrected array bounds during body store reallocation
- Ensured synchronous snapshot creation to prevent data loss on shutdown
- Fixed file locking issues by introducing sequential I/O processor
- Fixed multiple edge cases in async persistence flush logic
Performance
- Overhauled network dispatcher with chunk-centric broadcasting and raw data streams
- Optimized physics update loop by removing integer autoboxing and map lookups
- Migrated terrain system to zero-allocation SoA snapshots with linear memory access
- Replaced map-based body stores with direct array indexing
- Implemented ThreadLocal pooling for network dispatch and physics updates
- Optimized buoyancy broad-phase using low-allocation flow sampling
- Optimized quaternion slerp by removing per-call object allocations
- Eliminated allocation churn in terrain tracker by reusing collections
- Optimized body state packet serialization to avoid temporary arrays
- Integrated native Jolt buoyancy implementation for near-zero GC overhead
Refactors
- Complete overhaul of physics persistence system for reliability and scalability
- Reworked persistence lifecycle to align with EntityStorage architecture
- Removed VxPhysicsConfig and hardcoded simulation constants for determinism
- Restructured and optimized native library loading mechanism
- Overhauled vehicle architecture with modular component-based design
- Migrated vehicle synchronization to unified
VxVehicleStatemodel - Reorganized Java package structure to match modern conventions
- Removed obsolete batching limits from network configuration
- Removed redundant and unused persistence and storage fields
- Removed issue templates to keep repository minimalist
Build & Dependencies
- Updated Jolt JNI to version 3.5.2
- Moved native extraction to processResources in vx-native
- Simplified build pipeline and removed obsolete mixins
- Cleaned up platform-specific build logic
- Improved resource packaging and extraction stability
Documentation
- Updated and standardized Javadoc across physics and vehicle systems
- Added license attribution headers to source files
- Improved naming consistency and code-level documentation
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:i2yo1LYg:N2SufnRo"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:i2yo1LYg:N2SufnRo"
}

