-
Notifications
You must be signed in to change notification settings - Fork 193
Configuration File
Lithium makes use of the TOML language for its configuration file. If the configuration file does not exist during game start-up, a blank file with a comment to this page will be created.
This configuration file defines overrides for options in Lithium, and as such, a blank file is perfectly normal! It simply means that you'd like to use all the default values.
Each category below includes a list of options which can be changed by the user. Due to the nature of the mod, configuration options require a game restart to take effect.
All configuration options in Lithium exist under a category name. In order to override a configuration option, you will need to specify the option under the table header for its category. If you have not already created the category's header, start with doing so:
[ai]Then add whichever options you want to modify in that category below it, like so:
use_fast_goal_selection = true
eat_bagels_rapidly = trueThe remarks after the # are comments and exist for your own book-keeping. As such, you don't need to include them, but you might want to include a note as to why you're modifying a default value.
Optimizations for entity AI.
(boolean, default: true)
If true, a faster implementation of the goal selector for entity AI will be used. This will generally provide a decent improvement to server tick rates in nearly all cases and is generally safe to enable.
(boolean, default: true)
If true, a number of AI goals which query for nearby entities in the world every tick will be changed to use an event-based system for tracking nearby entities. In other words, instead of entities constantly polling to see if other entities are nearby, they will instead be notified only occasionally when such an entity enters their range. This significantly reduces the amount of CPU overhead added by these goals and should be safe to enable.
Optimizations for collision detection and resolution.
(boolean, default: true)
If true, a more precise algorithm will be used for determining which blocks an entity is going to collide with given a motion vector on each tick. This completely eliminates an expensive step requiring blocks to be tested for intersection and can significantly reduce the number of blocks which need to be checked against by only marking those the entity's bounding box will actually intersect.
In situations where entities are trying to move very quickly (such as in a mob farm where an entity is being pushed by many others), this algorithm will reduce the number of blocks being tested by an order of magnitude and greatly improve performance.
(boolean, default: true)
If true, shape comparison and collision resolution will use much simpler and faster algorithms when trivial block shapes are encountered. This allows for much faster collision resolution against shapes which only contain one normal cube and will provide a significant boost in performance.
(boolean, default: true)
If true, the algorithm for checking whether or not an entity is within the world border will be replaced with a much faster axis-aligned bounding box check. Even if the world border has not been changed or entities are not near it, this patch will improve performance.
(boolean, default: true)
If true, a simpler (and much faster) collision testing algorithm will be used to test if an entity is inside of blocks. Additionally, the world border will not be included in a collision test if the player will not collide with it in a given physics step.
Optimizations for entity ticking.
(boolean, default: true)
If true, an optimized map implementation will be used for entity data tracking which avoids integer boxing and a map lookup by using a simple array.
(boolean, default: true)
If true, the data tracker for entities will not perform locking. This works by making additional patches to some network packet classes, requiring them to copy their data on the main-thread (which will later be serialized off-thread.) This could, however unlikely, cause issues if mods are installed which try to access the data tracker on the wrong thread.
(boolean, default: true)
If true, entities will cache nearby chunks to avoid more expensive calls to the world object. This will provide a small improvement even when the world object would otherwise have the chunks cached itself, and a much greater improvement when the chunks would not have been cached. This is generally safe to enable and provides a good performance boost in some situations.
(boolean, default: true)
If true, entities will be selected for collision using an optimized function which avoids functional stream-heavy code. This will generally provide a boost when entities are heavily crowded.
(boolean, default: true)
If true, living entities will cache which block is at their feet to improve performance in situations where it is repeatedly checked, such as when entities are heavily crowded and colliding with many blocks.
Client-sided optimizations.
(boolean, default: true)
If true, the client's time function (glfwGetTime()) will be replaced with standard Java calls. This can improve performance when multiple threads (i.e. the client and server) are both accessing the timer, which is usually almost always the case in single-player.
(boolean, default: true)
If true, the loading screen will be patched to reduce the CPU overhead required to render it by an order of magnitude. This is primarily achieved through batching all the tiles to be drawn into a single draw-call and through optimizing the color lookup for a tile.
Optimizations for chunks and block data containers.
(boolean, default: true)
If true, additional conditional logic for checking if a world is of the debug type will be removed. This may slightly improve performance in some situations, but will make it impossible to use the debug world type. It's very likely that you didn't know that was a feature or will ever need to use it, so this option is generally worthwhile.
(boolean, default: true)
If true, the vanilla hash palette (which maps a small range of integers from chunk data into blocks) will be replaced with an optimized variant.
(boolean, default: true)
If true, an optimized method for compacting a chunk's palette upon serialization will be used. This is greatly faster the vanilla implementation and should be safe to use, providing a boost when the server is saving many chunks.
(boolean, default: false)
If true, checks which see if a chunk is being concurrently modified will be removed. This may slightly improve performance in some situations, but comes with the dangerous side effect that these kinds of threading issues will not be detected and could go on to create serious problems. This option does not make it valid to access chunks from multiple threads, and if the vanilla game or another mod attempts to do so, it will create problems.
Disabled by default until further testing in vanilla is performed and alternatives are looked into.
General optimizations which apply to many sections of the game.
(boolean, default: true)
If true, the expensive check to see if a TypeFilterableList can be filtered by a specific class will only be made when a new list for that type needs to be created.
(boolean, default: true)
If true, the tick scheduler will be replaced with an optimized variant which allows for significantly reduced CPU usage with many scheduled ticks and much faster checking of in-progress ticks. In real world terms, this means that the tick settling which occurs right after generating chunks will take much less time, and redstone ticking will be slightly faster. This implementation has been tested extensively, but some issues might still lurk.
(boolean, default: true)
If true, a handful of small patches will be made to avoid unnecessary memory allocations throughout the game.
(boolean, default: true)
If true, a handful of small patches will be made to avoid unnecessary hashcode recalculation throughout the game.
(boolean, default: true)
If true, some math utility classes will be patched with various optimizations in order to reduce the general overhead in operations such as switching/rotating axis's or shifting block positions. This does not make any optimizations to trigonometric functions or the like of them!
Redstone optimizations.
(boolean, default: false)
If true, Redstone dust will use an optimized update system which avoids unnecessary block updates (fixing MC-81098). Additionally, the update order of redstone dust is made deterministic (fixing MC-11193).
These patches will provide a huge improvement when updating dust, but might affect contraptions which rely on the non-deterministic update order of dust (known as "locational contraptions").
This is unfortunate and goes against the strongest belief of the mod (being that we don't change vanilla behaviours) but it is impossible to maintain behaviour which is non-deterministic. Even though this behaviour is often said to be consistent given the same location in a world, this is only a happy coincidence. The implementation of Set (which is the type responsible for ordering these updates) makes no guarantees about its order, meaning that a simple update to Java or the usage of another JVM could result in the order being changed.
This is disabled by default as it is an INCUBATING feature. This will likely conflict with any other mods which make similar patches.
Region file format optimizations.
(boolean, default: true)
If true, the world's session lock will only be checked one before saving all pending chunks versus once for every chunk saved. This provides a small boost in performance when handing off chunks to be saved from the main server thread.
Miscellaneous optimizations.
(boolean, default: true)
If true, tags with very few entries (<=5) will use array scanning instead of a hash table, which might slightly improve performance when checking to see if a block/fluid is contained within a tag.
Options for people wishing to hack on the code or debug issues. These are all disabled by default.
(boolean, default: false)
If true, the client will be patched to allow the visualization of "tracers" used for debugging.
(boolean, default: false)
If true, swept entity bounding box collisions will be traced. This adds a non-trivial amount of overhead and may destroy performance!