This prevents silent issues where a mod gets the value of the setting
before configs are loaded, which means the default value is always
returned.
As there may be situations where the getting the config setting before
configs are loaded is needed, and it is not preferable to hardcode the
default value, the original behavior is made available through #getRaw.
Implements and closes#7716
* Remove getRaw() method
This is effectively replaced with the expression `spec.isLoaded() ?
configValue.get() : configValue.getDefault()`.
* Remove forceSystemNanoTime config setting
As implemented, it never had any effect as any place where the config
value would be queried happens before the configs are loaded.
Previously, the suggestions used the string representation of the enum
through Enum#toString, which can differ from the name of the enum as
required by Enum#valueOf, causing invalid suggestions (both in gui and
through the error message).
* displayTest option in mods.toml
* "MATCH_VERSION" (or none) is existing match version string behaviour
* "IGNORE_SERVER_VERSION" accepts anything and sends special SERVERONLY string
* "IGNORE_ALL_VERSION" accepts anything and sends an empty string
* "NONE" allows the mod to supply their own displaytest using the IExtensionPoint mechanism.
* Update display test with feedback and added the mods.toml discussion in mdk.
* Bump pack.mcmeta formats
* 1.19 biome modifiers
* Mark ClientPlayerNetworkEvent.LoggedOutEvent's getters as nullable
* Add docs and package-info to client extension interfaces package
* Move RenderBlockOverlayEvent hooks to ForgeHooksClient
* Add package-infos to client events package
* Rename SoundLoadEvent to SoundEngineLoadEvent
This reduces confusion from consumers which may think the
name SoundLoadEvent refers to an individual sound being loaded rather
than the sound engine.
* Document and change SoundLoadEvent to fire on mod bus
Previously, it fired on both the mod bus and the Forge bus, which is
confusing for consumers.
* Delete SoundSetupEvent
Looking at its original implementation shows that there isn't an
appropriate place in the new sound code to reinsert the event, and the
place of 'sound engine/manager initialization event' is taken already by SoundLoadEvent.
* Perform some cleanup on client events
- Removed nullable annotations from ClientPlayerNetworkEvent
- Renamed #getPartialTicks methods to #getPartialTick, to be consistent
with vanilla's naming of the partial tick
- Cleanup documentation to remove line breaks, use the
spelling 'cancelled' over
'canceled', and improve docs on existing and
new methods.
* Remove EntityEvent.CanUpdate
ClosesMinecraftForge/MinecraftForge#6394
* Switch to Jetbrains nullability annotations
* New PlayLevelSoundEvent; replaces old PlaySoundAtEntityEvent
* Remove ForgeWorldPresetScreens
* Remove IForgeRegistryEntry
* Remove use of List<Throwable> in FML's CompletableFutures
* Add docs to mod loading stages, stages, and phases
* Gradle 7.4.2
* Use SLF4J in FMLLoader and other subprojects
* Switch dynamic versions in subprojects to pinned ones
* Switch ForgeRoot and MDK to FG plugin markers
* Configure Forge javadoc task
The task now uses a custom stylesheet with MCForge elements, and
configured to combine the generation from the four FML subprojects
(fmlloader, fmlcore, javafmllanguage, mclanguage) and the Forge project
into the javadoc output.
* Update docs/md files, for 1.19 update and the move away from IRC to Discord.
* Make "Potentially dangerous alternative prefix" a debug warning, not info.
Co-authored-by: Curle <curle@gemwire.uk>
Co-authored-by: sciwhiz12 <arnoldnunag12@gmail.com>
Signed-off-by: SizableShrimp <sizableshrimp@sizableshrimp.me>
Commands#fillUsableCommands does not handle redirect nodes properly. It
blindly pulls from the cached node map for a redirect node, which may
have no result because the target node of the redirect has not been
visited yet.
CommandHelper#mergeCommandNode is better in this regard, because it
visits the target node of the redirect instead of blindly pulling from
the node map.
Fixes#7551
Manually entering the names of dynamic registries work as expected. The
suggestions for registries didn't include dynamic registries because
they queried the static registries rather than querying all registries
from the server's `RegistryAccess` (which includes both static
registries and dynamic registries).
Marc Hermans