Updating
Move between InputBooster versions, keep or reset your settings, and roll back safely when a new build misbehaves.
Updating is a file swap. The only thing that needs care is the config schema version and the fact that a bad alpha can stop the client from starting.
The update procedure
Not just the world — the whole client. The mod writes its config on shutdown, and a jar swap while the game is running corrupts the next save.
Remove every InputBooster jar from mods. Do not keep the old one as a
backup inside the folder; the client loads every jar it finds.
Exactly one jar, matching your loader and Minecraft version. See the jar matrix.
The mod logs the schema version it loaded and whether it migrated anything.
Open the settings screen and confirm the values survived.
Schema versions
The config carries a config_version. The current schema is 305.
| Schema | Introduced in | Meaning |
|---|---|---|
| 305 | 4.1.0-alpha | Current. Adds the nine 4.1 engine and overlay keys. |
| 303 and earlier | 3.x | Older schema, migrated on load. |
When the mod loads a file with a lower version, it logs a migration line and renames three legacy keys:
| Old key | New key |
|---|---|
auto_sprint_key | auto_sprint |
watap | wtap_assist |
pollrate | poll_rate_hz |
What is preserved across an update
Your config file is read on launch and written on shutdown. A version change does not touch it unless the schema version changed.
Preserved: every key present in your file, as long as it parses and stays inside its range.
Reset to defaults: keys that were missing from the file, keys with an unparsable value, and keys whose value falls outside the allowed range.
Not preserved: the settings window's size and position. Those are session state by design and are never written to disk.
Rolling back
A rollback is the same procedure in reverse: delete the new jar, put the old one back.
The risk is a config the new version wrote that the old version does not know. Because the loader starts from the documented defaults and only applies keys that are present in the file, an unknown key is simply ignored by the older build. Rolling back does not break the config.
Downgrading past the schema
If you move from 4.1 back to a 3.x build, the schema version in your file will
be higher than that build understands. Older builds read config_version but
do not have a migration path, so they simply use the keys they recognise.
Nothing crashes; the newer keys are ignored.
After every update
Run through this short list:
Ready!appears in the log.- The Overview tab shows the poll thread running.
- The engine mode is the one you expect.
- Your poll rate and CPS cap are the values you set.
If the poll rate or cap came back as a default, the file was reset on load.
The reason is in the log line that starts with Config entries reset to defaults. The log reference explains it.