Fix game test structure rotations being inconsistent (#10391)
Fix redstone update order not matching vanilla. (#10392)
Fix redstone updates for comparators going up/down incorrectly. Related: #9973
Make block pos assertions in GameTestHelper behave like in 1.21.3, thus fixing rotated tests functionality.
This can be disabled in the Forge config if you have old tests that this breaks. Tho it is recommended you update your tests.
---------
Co-authored-by: LexManos <[email protected]>
Full Changelog: https://gist.github.com/Jonathing/c3ad28b2a048ac839a7baba5417ee870
The key features are:
- ES6 language support
- Thoroughly updated ASMAPI, with full documentation
- Bug fixes (some optional for backwards-compatibility)
- Partial internal code cleanup
- Request CoreMods to not apply fix for ASMAPI.findFirstInstructionBefore by default
New PayloadChannel that uses the vanilla payload Type for packet distinction
Implement the minecraft:register/unregister channels using the new PayloadChannel
New generic channel builder function allowing people to implement channels however they want.
Rework networking so that RegistryFriendlyByteBuf is useable for modders
Simple support for StreamCodec in SimpleChannel
Codecify all Forge packets
Make simpler builder pattern for SimpleChannel. Will eventually deprecate the old MessageBuilder as it's verbose and poorly written.
Co-authored-by: MrCrayfish <[email protected]>
Co-authored-by: Paint_Ninja <[email protected]>
Makes it easier to identify broken mods, as it moves the crash to when the broken mod in question registers the tier, rather than when any mod tries getting the tier.
Updated to use newer libraries that reduce the command line arguments needed to run the game.
Fix issues in the SecureModule's classloader that caused resources to not be seen when they are on parent module layers.
Cleanup some of the build.gradle
Start work on restructuring test mods. They are now treated as their own jars, as well as having their mods.toml auto-generated. No more mods.toml conflicts!
Add pattern matching support to Data run modlist.
This spawn packet needs to be re-designed, it is effectively only there to hook into creating the new entity instance. This will be re-evaluated during the cleanup in 1.21+
Kept newly added methods for binary compatibility but deprecated them all for removal.
The entire pose/eye/size system needs to be reevaluated and address some of Mojang's changes.
However this should fix any bugs that pulling that PR may of caused.
* Try and be a bit nicer about handling bad [feature] definitions - they're single square bracket defined and require strings for feature bound values.
* Some more tweaks to the feature system to output useful and well formatted error messages when bounds fail. Requires SPI 7.0.1 and the language string "fml.modloading.feature.missing" has changed.
* Use immutable lists where possible and generally tidy things a bit
Gradle 8 is stupid and doesn't (easily) allow in-place tasks, so a temporary fix has been made in ForgeGradle 6
Signed-off-by: SizableShrimp <[email protected]>
- Creative mode tabs are now a registry; the `BuildContents` event was renamed to `BuildCreativeModeTabContentsEvent` and moved it to its own class
- The pack format is now 15 for both resource packs and data packs
- `ScreenUtils` was deprecated in favor of a `GuiGraphics` extension
- Forge and the MDK were updated to Gradle 8 and FG6
- The Forge common config file was removed (it only contained the deprecated old fields for resource caching, which was removed in 1.19.3)
- Registry dummy entries were removed
- `RemappingVertexPipeline` was fixed to forward the `endVertex()` call
- Forge tool tags were removed in favor of vanilla ones
Co-authored-by: ChampionAsh5357 <[email protected]>
Co-authored-by: coehlrich <[email protected]>
Co-authored-by: Dennis C <[email protected]>
Co-authored-by: Matyrobbrt <[email protected]>
Added Unit tests for MutableHashLinkedMap
Added support for removing using the iterator
Added concurrent modification detection to the iterator
Added default constructor with basic hashing strategy.
Closes#9426
Because of the incorrect variable, the check to stop sprinting (and stop
swimming) never fired correctly.
1.19.3's `flag5` variable was renamed to `flag7` in 1.19.4; however,
this was not caught during patching because of the fuzzy patcher.
Fixes#9399
The `flag1` variable is ultimately controlled by whether the armor slot
being rendered is for the leggings, which explains this bug where the
leggings always had the enchantment glint but not any other armor piece.
Fixes#9394
Created a CreativeModeTabEvent to register creative mode tabs and populate entries per tab
Moved datapack registries to DataPackRegistryEvent.NewRegistry event instead of tying them to ForgeRegistry
Made it easier for mods to datagen datapack builtin entries with DatapackBuiltinEntriesProvider
Provided access to lookupProvider for datagen
Updated dependencies to match versions used by vanilla and update JarJar to 0.3.18
Added a test mod for the new CreativeModeTabEvent
Throws better error message for Forge registries in tag datagen
Deleted ForgeRegistryTagsProvider
Updated ClientChatReceivedEvent and ServerChatEvent for Mojang changes
Added patches for both sign related methods in ModelLayers
Changed RegisterShadersEvent to use ResourceProvider
Migrated old Mojang math types to JOML
Co-authored-by: Marc Hermans <[email protected]>
Co-authored-by: LexManos <[email protected]>
Co-authored-by: sciwhiz12 <[email protected]>
Co-authored-by: coehlrich <[email protected]>
In some situations, such as execution of a function by an advancement as
part of its reward, a command source stack may have a backing source of
a ServerPlayer which may lack the entity selector permission and have an
explicit permission level that should allow the use of entity selectors,
through CommandSourceStack#withPermission.
We now check if the permission level of the command source stack is
sufficient for entity selectors _before_ checking if the source is a
player and if they have the requisite permission.
This means that an operator permission level of 2 will always override
the Forge entity selector permission.
Fixes#9137
This means that exceptions occurring during the dispatch of the registry
events, such as those from the suppliers of RegistryObjects, properly
cause a crash rather than merely being logged and allowing the game to
reach the main menu.
Fixes#8720
This allows greater flexibility for configuring servers with
operator-like permissions to user groups through the permissions API and
their permissions handler of choice without needing to grant the
vanilla operator permission to any player.
The new permission is "forge:use_entity_selectors", which is granted by
default to players with permission level 2 (GAMEMASTERS) and above.
The hook falls back to checking the permission level if the source of
the command is not a ServerPlayer, such as for command blocks and
functions.
Load natives from classpath
Make command argument types a forge registry
Add `EntityMobGriefingEvent` to `Allay#wantsToPickUp`
Overhaul `ServerChatEvent` to use `ChatDecorator` system
Remove `ClientChatEvent#setMessage` for now
Gradle 7.5
Signed-off-by: SizableShrimp <[email protected]>
Fix weighted baked models not respecting children render types
Allow fluid container model to use base texture as particle
Fix inverted behavior in composite model building. Fixes#8871
* Add getter for the component names in an unbaked geometry
* Fix render type hint not being copied in BlockGeometryBakingContext
* Ensure BlockRenderDispatches's renderSingleBlock uses the correct buffer
* Make ShulkerBoxBlockEntity#canPlaceItemThroughFace delegate to Item#canFitInsideContainerItems.
* Switch to using Or and add comment.
* Switch Or to And.
* Fix door datagenerator
Fix datagenerator for door blocks. Successor to #8687, addresses comments made there about statement complexity.
* Fix extra space around parameter
Fix extra space before comma around a parameter.
* dimension specific tag fix
* remove forge:is_beach cause vanilla has it already
* remove forge tags for new 1.19 vanilla tags (savanna, beach, overworld, end)
Co-authored-by: Flemmli97 <[email protected]>
* convert GLM serializer class to codec
* cleanup
* GLM list needs to be sorted
* datagen
* simplify serialization
* fix test mods (oops)
* properly use suppliers for codec as they are registry obj
* Add an easy way to get the NamedGuiOverlay from a vanilla overlay
* Fix static member ordering crash in UnitTextureAtlasSprite
* Allow boss bar rendering to be cancelled
* Make fluid container datagen use the new name
* Add a classpath transformer discoverer to load custom transformation services from the classpath
* Update ClasspathTransformerDiscoverer to 1.18
* Update license year
* Update license header
* Fix the other license headers
* Update ClasspathTransformerDiscoverer to 1.19
* Handle modded packets on the network thread
- On the server we simply need to remove the call to
ensureRunningOnSameThread.
- On the client side, we now handle the packet at the very start of the
call. We make sure we're running from a network thread to prevent
calling the handling code twice.
While this does mean we no longer call .release(), in practice this
doesn't cause any leaks as ClientboundCustomPayloadPacket releases
for us.
* Clarify behaviour a little in the documentation
* Javadoc formatting
* Add a helper method for handling packets on the main thread
Also rename the network thread one. Should make it clearer the expected
behaviour of the two, and make it clearer there's a potentially breaking
change.
* Add back consumer() methods
Also document EventNetworkChannel, to clarify the thread behaviour
there.
* Add since = "1.19" to deprecated annotations
* Make the resource lookups cached.
* Include configurability and handle patch cleanup.
* Document and comment the cache manager.
* Make thread selection configurable.
* Implement a configurable loading mechanic that falls back to default behaviour when the config is not bound yet.
* Use boolean supplier and fix wildcard import.
* Clean up the VPR since this is more elegant.
* Clean up the VPR since this is more elegant.
* Address review comments.
* Address more review comments.
* Fix formatting on `getSource`
* Address comments by ichtt
* Adapt to pups requests.
* Stupid idea.
* Attempt this again with a copy on write list.
* Fix a concurrency and loading issue.
* Fix#8813
Checks if the paths are valid resource paths.
* Move the new methods on vanilla Patch.
* Revert "Allow safely registering RenderType predicates at any time (#8685)"
This reverts commit be7275443f.
* Renderable API refactors
- Rename "render values" to "context"
- Rename SimpleRenderable to CompositeRenderable to better reflect its use
- Remove IMultipartRenderValues since it doesn't have any real use
- Add extensive customization options to BakedModelRenderable
* ClientRegistry and MinecraftForgeClient refactors
- Add sprite loader manager and registration event
- Add spectator shader manager and registration event
- Add client tooltip factory manager and registration event
- Add recipe book manager and registration event
- Add key mapping registration event
- Remove ClientRegistry, as everything has been moved out of it
- Remove registration methods from MinecraftForgeClient, as they have dedicated events now
* Dimension special effects refactors
- Fold handlers into an extension class and remove public mutable fields
- Add dimension special effects manager and registration event
* HUD overlay refactors
- Rename to IGuiOverlay match vanilla (instead of Ingame)
- Add overlay manager and registration event
- Move vanilla overlays to a standalone enum
* Model loader refactors
- Rename IModelLoader to IGeometryLoader
- Add loader manager and registration event
- Fold all model events into one
- Move registration of additionally loaded models to an event
- Remove ForgeModelBakery and related classes as they served no purpose anymore
* Render properties refactors
- Rename all render properties to client extensions and relocate accordingly
- Move lookups to the respective interfaces
* Model data refactors
- Convert model data to a final class backed by an immutable map and document mutability requirements. This addresses several thread-safety issues in the current implementation which could result in race conditions
- Transfer ownership of the data manager to the client level. This addresses several issues that arise when multiple levels are used at once
* GUI and widget refactors
- Move all widgets to the correct package
- Rename GuiUtils and children to match vanilla naming
* New vertex pipeline API
- Move to vanilla's VertexConsumer
- Roll back recent PR making VertexConsumer format-aware. This is the opposite of what vanilla does, and should not be relevant with the updated lighting pipeline
* Lighting pipeline refactors
- Move to dedicated lighting package
- Separate flat and smooth lighters
- Convert from a vertex pipeline transformer to a pure vertex source (input is baked quads)
* Model geometry API refactors
- Rename IModelGeometry to IUnbakedGeometry
- Rename IModelConfiguration to IGeometryBakingContext
- Rename other elements to match vanilla naming
- Remove current changes to ModelState, as they do not belong there. Transforms should be specified through vanilla's system. ModelState is intended to transfer state from the blockstate JSON
- Remove multipart geometries and geometry parts. After some discussion, these should not be exposed. Instead, geometries should be baked with only the necessary parts enabled
* Make render types a first-class citizen in baked models
- Add named render types (block + entity + fabulous entity)
- Add named render type manager + registration event
- Make BakedModel aware of render types and transfer control over which ones are used to it instead of ItemBlockRenderTypes (fallback)
- (additional) Add concatenated list view. A wrapper for multiple lists that iterates through them in order without the cost of merging them. Useful for merging lists of baked quads
* General event refactors
- Several renames to either match vanilla or improve clarity
- Relocate client chat event dispatching out of common code
* Forge model type refactors
- Rename SeparatePerspectiveModel to SeparateTransformsModel
- Rename ItemModelMesherForge to ForgeItemModelShaper
- Rename DynamicBucketModel to DynamicFluidContainerModel
- Prefix all OBJ-related classes with "Obj" and decouple parsing from construction
- Extract ElementsModel from model loader registry
- Add EmptyModel (baked, unbaked and loader)
- Refactor CompositeModel to take over ItemMultiLayerBakedModel
- Remove FluidModel as it's not used and isn't compatible with the new fluid rendering in modern versions
- Move model loader registration to a proper event handler
- Update names of several JSON fields (backwards-compatible)
- Update datagens to match
* Miscellaneous changes and overlapping patches
- Dispatch all new registration events
- Convert ExtendedServerListData to a record
- Add/remove hooks from ForgeHooksClient as necessary
* Update test mods
* Fix VertexConsumerWrapper returning parent instead of itself
* Additional event cleanup pass
As discussed on Discord:
- Remove "@hidden" and "@see <callsite>" javadoc annotations from all client events and replace them with @ApiStatus.Internal annotation
- Make all events that shouldn't be fired directly into abstract classes with protected constructors
- Another styling pass, just in case (caught some missed classes)
* Add proper deprecation javadocs and de-dupe some vertex consumer code
* Replace sets of chunk render types with a faster BitSet-backed collection
This largely addresses potential performance concerns that using a plain HashSet might involve by making lookups and iteration as linear as they can likely be (aside from using a plain byte/int/long for bit storage). Further performance concerns related to the implementation may be addressed separately, as all the implementation details are hidden from the end user
* Requested changes
- Remove MinecraftForgeClient and move members to Minecraft, IForgeMinecraft and StencilManager
- Allow non-default elements to be passed into VertexConsumer and add support to derived classes
- Move array instantiation out of quad processing in lighting pipeline
- Fix flipped fluid container model
- Set default UV1 to the correct values in the remapping pipeline
- Minor documentation changes
* Add/update EXC entries and fix AT comment
* Add test mod as per Orion's request
* Additional requested changes
* Allow custom model types to request the particle texture to be loaded
* Even more requested changes
* Improve generics in ConcatenatedListView and add missing fallbacks
* Fix fluid render types being bound to the fluid and not its holder
* Remove non-contractual nullability in ChunkRenderTypeSet and add isEmpty
Additionally, introduce chunk render type checks in ItemBlockRenderTypes
Co-authored-by: Dennis C <[email protected]>
* Add "send to mods in order" method to ModList and use it in RegistryEvents and DataGen..
* Also preserve order in runAll
* Do better comparator thanks @pupnewfster
* postEvent as well.
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).
* Implement a simple feature system for Forge. Allows mods to demand certain features are available in the loading system. An example for java_version is provided, but not expected to be used widely. This is more targeted to properties of the display, such as GL version and glsl profile.
Requires https://github.com/MinecraftForge/ForgeSPI/pull/13 to be merged first in ForgeSPI, and the SPI to be updated appropriately in build.gradle files.
* rebase onto 1.19 and add in SPI update
* 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 <[email protected]>
Co-authored-by: sciwhiz12 <[email protected]>
Signed-off-by: SizableShrimp <[email protected]>
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).
Note to modded server devs:
Please, please, please implement full compatibility with [Brigadier](https://github.com/Mojang/Brigadier) instead of hacking around it.
Pass-through unknown structure IDs with "unknown." prefix
This avoids the fixer throwing an exception due to the unknown
structure, which causes the chunk data to be dropped (and freshly
regenerated later). The deserializer logs and ignores the unknown
structure ID, avoiding full chunk data loss.
After internal discussion, it was decided that we need to include
"contributors" to the license header. This avoids claiming that the
Java source files are under the exclusive copyright ownership of Forge
LLC, which excludes contributors that still hold copyright ownership
over their contributions (but is licensed under the LGPLv2.1 as stated
in the Forge CLA).
isSimple should only return true if the ingredient is any more sensitive then JUST itemA == itemB
It used to take metadata and damage into account, but that was removed in the flattening.
Also prevents fetching tag values too early, as tags are not ready during the ingredient constructor
The original correct method is getPath, but the patch uses getLocation.
The former is the actual resource path to the sound OGG file, while the
latter is the sound's location.
Fixes#8531
Tag-enabled registries must now be registered to vanilla's root registry. See RegistryBuilder#hasTags.
Modded tag-enabled registries have to use the format `data/<namespace>/tags/<registrynamespace>/<registryname>/<tag>.json`
This format is to prevent conflicts for registries with the same path but different namespaces
EX: Registry name `examplemod:shoe`, tag name `blue_shoes` would be `data/<namespace>/tags/examplemod/shoe/blue_shoes.json`
RegistryEvent.NewRegistry has been moved and renamed to NewRegistryEvent.
RegistryBuilder#create has been made private. See NewRegistryEvent#create
Created new ITagManager system for looking up Forge tags. See IForgeRegistry#tags.
Add lookup methods for Holders from forge registries. See IForgeRegistry#getHolder.
This event allows forcing the rendering of the potion indicators in the
inventory screen to either compact mode (icons only) or classic mode
(full width with potion effect name).
Core game mods are mods which are required to exist in the environment
during mod loading. These may be specially provided mods (for example,
the `minecraft` mod), or mods which are vital to the framework which
FML is connected to (for example, Forge and the `forge` mod).
These core game mods are used as the only existing mods in the mod list
if mod sorting or dependency verification fails. This allows later
steps in the which use resources from these mod files to work correctly
(up to when the error screen is shown and the game exits).
This is a redesign of a discarded section of my initial model system rewrite, back in 1.14.
In order to use it with the OBJ loader, you can use OBJLoader.INSTANCE.loadModel to get the OBJModel, and then call OBJModel#bakeRenderable() to get a SimpleRenderable object to render with.
The SimpleRenderable support animation, by providing different transformation matrices for each part in the MultipartTransforms.
Additionally, a BakedRenderable helper exists to turn an arbitrary BakedModel into a renderable.
After trying to get the B3D loader to work, I decided it wasn't worth the trouble and marked it for removal instead.
* Remove the normalized branch names also from the filter.
* Add the additional publishing arguments to get the crowdin information.
* TeamCity change in 'MinecraftForge / MinecraftForge' project: project parameters were changed
* Fix the configuration.
* Remove the required patch and use the base script.
* Make a note about the reference.
Co-authored-by: cpw <[email protected]>
* Add a setup task and publish the correct versions.
* Reconfigure build task and disable the normal build and test cycle on everything but pull requests, run an assemble there.
* Fix the derp in the build configuration.
* Setup the build.gradle
* Setup the teamcity toolchain.
* Revert the usage of the local build of GU.
* Automatically add it now, it will always exist and is added to maven automatically by GU.
* Implement the branch filter and move the constant for the minimal changelog tag to a constant in the extension.
* Adding the JDK and Gradle version to the build script.
Fix example mod
Fix obf issue with records. Closes#8228
Fix dependencies beingg out of sync from vanilla. Closes#8227
Disable mixin due to module incompatibility.
To retain compatibility with existing mods, the vanilla methods redirect
to the extension methods for now.
Users should now use and override the vanilla methods as directed in
the javadocs of the now-deprecated methods, as the extension methods
will be removed in the future.
Fixes#8201
This will also allow other mods which need to calculate small normalised vectors to be able to use the default classes without needing to write their own, while not effecting any side effects created by how the base game uses this function.
#8184 reverted some LootTable patches, including the types of fields `f_79023_` and `f_79024_`. However, `ForgeLootTableProvider` still expects a list, however the type of the fields is an array now.
This PR changes the expected type in `ForgeLootTableProvider` to an array as well.
* Fix another crash with new tooltip events
* Add ItemStack context to ghost recipe tooltip events
* Expand Tooltip Event test mod to add a screen to test all tooltip render methods
Deprecate helper functions related to ModFile/Metadata.
Mark ModFileFactory as to be removed from our usage.
It may be useful for other loaders, but introduces a weird level of indirection that makes things a pain.
If there are consumers of this API please leave feedback before the next major mc version so we can be sure to provide something useful.
Redesigns the tooltip events, and adds a feature where mods can register factories for ClientTooltipComponents, which are used for custom rendering in tooltips. The old events are maintained for binary compatibility.
You can now use `mc.pushGuiLayer` and `mc.popGuiLayer` to manage the layers.
mc.setScreen behaves such that if called with a non-null screen it replaces the entire stack, and if called with null it closes the entire stack.
Added AddPackFindersEvent which lets you add additional resource/data pack sources to the game.
Added PathResourcePack as a utility to allow easy providing of a subfolder in a mod as a resource pack.
The sprite used for the block particles needs updating after the constructor otherwise it defaults to the texture sprite returned from passing ModelData.INSTANCE to get IForgeBakedModel#getParticleIcon. Calling updateSprite fetches the real IModelData instance for that blockstate/pos and sets the texture to the desired one
When running under data-generation, the Minecraft singleton is unavailable
even though the operating env is under the CLIENT dist. Adding this check
prevents crashes from devs unaware of this, as most uses of
IItemRenderProperties (usually for a custom BEWLR) make use of the
Minecraft singleton and therefore will cause NPEs if not guarded against.
A similar thing happens in MobEffect and Block.
The patch accidentally replaces the minimum build height (set by the
dimension via e.g. datapacks) with 0, causing falling blocks placed
below Y level 0 to never fall.
Fixes#8091
Because IEventBus#post returns true on cancellation and the patched-in
hooks inverts the return of the ForgeHooks method, if the player
whose permission level is being changed is online and the event is not
cancelled, the permission change _is_ cancelled.
The fix is inverting the patched-in hooks and the default return value
of the ForgeHooks method, so that the permission change is cancelled
only if the player is online, the event is fired, and the event is cancelled.
Fixes#8088
Fixes#7396, where if a translated string with balanced pairs of single
quote characters passes through ForgeI18n, the quotes are stripped
because of ExtendedMessageFormat. This is most notable in languages
where `'` is used frequently, like Canadian French from the bug report.
Note that unbalanced pairs cause an IllegalArgumentException in
ExtendedMessageFormat, which means the message is not affected.
Changed:
- ToolType is replaced with ToolAction, which can selectively represent which actions are supported by an item.
- Added a canPerformAction method to query ToolActions.
- Renamed canHarvestBlock to isCorrectToolForDrops to match vanilla.
- Added TierSortingRegistry, which can be used to add custom tiers and supports sorting between vanilla or with other mods.
How to use:
For the breaking system there's 2 methods:
- getDestroySpeed decides if an item *can* mine the block fast. Override if you have multiple tags or your item isn't a DiggerItem.
- isCorrectToolForDrops decides if an item will get drops. Returning false will also slow down mining, regardless of getDestroySpeed. Override if you have type-dependant tiers or your item isn't a DiggerItem.
For the tier system mods can just call `TierSortingRegistry.registerTier(tier, "name", List.of(lesser tiers), List.of(better tiers));` to register their tiers.
There's helper methods to query tiers such as TierSortingRegsitry.isCorrectTierForDrops.
The ToolActions solve 2 problems:
1. distinguishing which kind of digger an item can be
2. querying if the item can perform specific secondary actions.
Any item can override `canPerformAction` to customize which actions it performs.
Fix ShaderInstance to allow resourcelocations with namespaces as input.
Fix shader parsing to respect resource domains.
Fix ForgeRenderTypes to use the right shader in each situation.
Add custom forge shader for unlit translucent entity rendering, equivalent to the vanilla entity translucent shader.
Added new entity rendering events.
- EntityRenderersEvent.RegisterLayerDefinitions: Used to register layer definitions for entity models.
- EntityRenderersEvent.RegisterRenderers: Used to register entity renderers.
- EntityRenderersEvent.AddLayers: Called during resource reload after all renderers have been constructed and it's safe to add layers.
Removed RenderingRegistry, which is now not necessary.
Removed a few unused things.
Fixes#7920
In 1.17, all of the inner classes of `RenderStateShard` (`RenderStateShard.OverlayStateShard`, `RenderStateShard.WriteMaskStateShard`, etc.) have been changed to protected. These classes are needed however to create new `RenderType.CompositeRenderType`'s using `RenderType.CompositeState.CompositeStateBuilder`.
Since these are protected inner classes, their constructors also can't be directly be obtained using `ObfuscationReflectionHelper`.
Currently, any mod using custom `RenderType`'s will have to either:
- add their own access transformer for the inner classes, or
- extend `RenderStateShard` to access `RenderStateShard`'s inner classes, and extend `RenderType` to access `RenderType.CompositeRenderType`
This PR changes the visibility of `RenderStateShard`'s inner classes to public in Forge's `accesstransformer.cfg`.
Update to Official classnames
Patchwork
Make the game compile and run
Merge in the new HUD overlay API
Merge in the new render properties API
PEEL
Use Gradle 7.2 snapshot to fix eclipse integration bug in 7.1, Would use 7.0 but FG needs 7.1 for some reason.
New FML installer
Update to 1.17.1
Co-authored-by: LexManos <[email protected]>
Co-authored-by: SizableShrimp <[email protected]>
Co-authored-by: cpw <[email protected]>
Co-authored-by: Curle <[email protected]>
Co-authored-by: Unnoen <[email protected]>
Co-authored-by: covers1624 <[email protected]>
Co-authored-by: DaemonUmbra <[email protected]>
Co-authored-by: gigaherz <[email protected]>
Signed-off-by: SizableShrimp <[email protected]>
Patch minecraft to fix MC-227255 and MC-134110, which are block
rotation and mirroring issues. I noticed this from problems with
Structurize, but this probably affects any other mods that allow
rotating or mirroring structures (as well as vanilla structure blocks).
Adds a system for mods to specify custom texture loaders which can be requested by the resource pack through a metadata section in the .mcmeta file. Due to technical reasons, png file is still required for MC to identify a texture as existing, even if the loader doesn't use it.
If an optional dependency is present, but it does not conform to the version range,
it will now error out in the same fashion as missing required dependencies, instead
of a more cryptic error down the line due to a missing method/class/field/etc.
Implements and closes#7696
Convert Forge to use Official mappings.
Mojang released their obfuscation mappings but we have not used them up until now due to wanting to get their license to be more explicitly permissive.
It is clear that their intent is to allow us to use their names for developing mods like this.
See the full wording, and our interpretation here: https://github.com/MinecraftForge/MCPConfig/blob/master/Mojang.md
Cleanup javadocs references slightly, fix a couple spots not using the proper forge hooks, and remove a couple unneeded patches
Update deprecation comment on isAir
This allows custom IBakedModel implementations to use the IModelData provided by their IBakedModel.getModelData() when used in the context of a multipart model.
* Mods can now register world types via a new forge registry, and optionally register a settings screen to tweak them.
* The default world type for dedicated servers and singleplayer world creation is configurable via forge's common config.
If a FakePlayer is constructed with the same UUID/GameProfile as a
currently active player, the player object within PlayerAdvancement is
set to the fake player.
As fake players cannot receive advancements (see grantCriterion), this
prevents the actual player from receiving any advancements until they
change dimension/relog.
Tweak MDK to automatically populate recommended values for things like forge version, loader version and minecraft version.
Signed-off-by: cpw <[email protected]>
Switch to a handler-based approach per packet class, simplify patch, add some docs
Add license header and docs
Switch to a network handler based approach
Switch to a network handler based approach
revert build gradle change
Simplify Packet patch
Add license header to IForgePacket
Revert ForgeHooks changes
Less hacky and more generic way to filter packets for vanilla connections
_Actually_ Order SAS.
It's early
Order SAS
simplify vanilla connection check
Remove unneeded import change
* Fix Lazy.Concurrent using a global lock, thus preventing multiple threads from resolving independent Lazy's at the same time
* Use Lazy with an added null check to implement NonNullLazy
Added automatic generation of conditional advancements from the criteria in the conditional recipe entries.
Added advancement name calculation from the recipe ID.
Add a UUID into crashreport that is also logged in all channels at crash report generation time. This will allow to associate crash reports and the logs.
Signed-off-by: cpw <[email protected]>
Closes#7293 (to reproduce issue easily, modify Util.func_240979_a_ and change the values in the MathHelper.clamp call). I've verified that 3 and below for "max" cause the problem. (I didn't test a whole range of values, just sufficient to reproduce problem and verify fix). Note that setting it to zero (and using the "direct executor" that's inaccessible in normal operation) works as well with this fix.
Signed-off-by: cpw <[email protected]>
For consistency, this meant making a few changes:
- Renamed the existing lazy mapping method to lazyMap, to indicate that it doesn't run the mapping immediately.
- Added a new implementation of map(), which returns Optional<T>, and resolves the value in the process.
- Changed filter() to return Optional, since there's no way to filter lazily.
- Added a new method resolve(), which helps convert the custom LazyOptional class into a standard Optional, for use
with library methods that expect Optional<T>.
* Update License headers.
Freeze the ModelLoaderRegistry right after this event happens, just before model loading actually begins.
This means ModelRegistryEvent is now the correct place to register loaders, as it was intended.
This is a slight breaking change, but any mod that used FMLClientSetupEvent before will need to be updated regardless due to the existing race condition.
This prevents other mods from throwing errors and being blamed for initial cause.
This is a temporary hack until cpw re-writes the mod event dispatcher.
Introduced IModBusEvent as a marker interface for events on the ModBus. Expect exceptions if you use
the modbus for events not listened there.
Signed-off-by: cpw <[email protected]>
Fix patched in method using srg name. Closes#6965
Fix capabilities not being collected for ClientWorld. Closes#6966
Fix TagEmptyCondition using client side copy of tags instead of server. Closes#6949
Fix ExtendedButton using narrator text. Closes#6958, Closes#6959
Fix misaligned patch in RepairContainer. Closes#6950, Closes#6953
Fix LivingJumpEvent not being fired for players jumping horses. Closes#6929
Remove extra getToughness method in ArmorItem. Closes#6970
Remove GetCollisionBoxesEvent. Closes#6921
* Add simple patch checker and cleanup patches
* Address comments
* move task implementation
* genPatches is now finalized by checkPatches
* the S2S artifacts are automatically removed
* added class and method access checking
- Port some things I did in 1.14 which I couldn't do in 1.15 due to breaking changes.
- Fix multi-layer block models not working (1.16 RenderType doesn't override toString the same way anymore)
- Implement multi-layer item rendering.
- Improve CompositeModel submodel data passing.
Code for customizing the server instance should be moved to the ServerAboutToStartEvent or similar, where the server instance
is available.
This reorganization means that mods will load fully before the server is even constructed, or the server properties loaded. We also move the EULA right to the front so we don't have to wait for bootstrap.
This should fix the problems with mods which customize world data and other things.
Signed-off-by: cpw <[email protected]>
Fix BreakSpeedEvent having null position. Closes#6844
Add MatrixStack to BackgroundDrawnEvent. Closes#6843
Fix some patches that should of been ATs. Closes#6839
Add getter to ServerPlayer to access client's language calue if sent. Closes#6829
Some patch cleanup.
* Retarget Block.Properties patch to the new AbstractBlock, reintroduces the harvestLevel and harvestTool fields.
* Slight adjustment to fix the lootTableSupplier.
Closes#6753
Moving the fadeOutStart setter above the callback invocation prevents re-entry into the block (which would result in an infinite loop and a StackOverflowException) if the callback causes a render tick (which creating a new ConnectionScreen does).
Add support for specifying which layers are fullbright.
Fix improper generation of model edge. - Thanks to iChun and KnightMiner for the fix suggestions.
Useful For Forge's test mods mainly.
Standardized data gen cache file's folder separators.
Added ItemModelProvider to BlockStateProvider for cleaner datagen code.
Added .gitattributes to fix datagen json's line endings correct on windows.
In general, use sided lambdas safely by embedding them in a separately loaded class. There's a whole twitch stream
dedicated to investigating this problem. See link in DistExecutor if you're interested.
Signed-off-by: cpw <[email protected]>
- Add "origin" key to determine what origin to use. This will default to the existing (broken) behaviour to avoid breaking changes.
- Fix interaction of transforms with variant transforms (transformation ordering).
- Fix OBJ loader ignoring "diffuseLighting" attribute from the json.
This attribute will continue not being used if "ambientToFullbright" is on (default) to avoid breaking changes.
It seems to be fully equivalent in testing, but there may be corner cases, so there is a config to disable, though disabling
may break servers, especially those chunkloading fake players.
Signed-off-by: cpw <[email protected]>
* Add "type" field to global loot modifier jsons and fix tests.
To avoid binary breaking, "type" defaults to be the same as the filename.
* Fix license headers.
Remove a lot of light value convolution by using 0..1 for nearly everything
Fix a lot of TODOs that are needed for the lighting pipeline to function
Potential fix for #6425
Fix vanilla bug that caused the byte order of the buffer from getNextBuffer to be incorrect
Fix missing modification to nextElementBytes in putBulkData
Also fixed a silly log message from the login handler.
This change introduces a mechanism to direct certain packets to only process on one side or another. Invalid sidedness will result in the connection being terminated.
Signed-off-by: cpw <[email protected]>
returnmatches.toSorted(Comparator.<String>naturalOrder())?:{thrownewRuntimeException('Failed to find any targets, please ensure that method names and descriptors are correct.')}()
// Make sure out manifests get written before compiling the code, IDEA calls this task if you tell it to use the gradle build.
tasks.withType(JavaCompile).configureEach{
dependsOn'generateResources'
dependsOn'processResources'// Needed because we merge the output of this with the output of the compile task. And gradle detects downstream tasks using the output without a hard dep
options.encoding='UTF-8'// Use the UTF-8 charset for Java compilation
options.warnings=false// Shutup deprecated for removal warnings
options.forkOptions.jvmArgs+='-Xmx3G'// Needed to make compiling faster, and not run out of heap space in some cases.
}
// Merge the resources and classes into the same directory. We'll need to split them at runtime because
// Minecraft and Forge are in the same sourceSet as they are inter dependent.. for now..
1) Keep patches to Minecraft classes minimal. If you need a lot of things done, you may either add to relevant forge classes or make a new class.
1) Keep patches to Minecraft classes together. If you need a lot of things done, you may either add to relevant forge classes or make a new class. Try not to spread out your patches across multiple disjoint lines, as this makes maintenance of your patches difficult.
2) An example mod must be provided for all PRs adding events/hooks to Forge. Whether it's a full mod using your proposed hooks, or just a pastebin containing a simple example, an example mod is required. Please also explain in detail what your new hook does.
2) TODO: Test Mods
3) Follow Forge coding guidelines (braces on newlines, spaces instead of tabs, etc)
3) Follow the code style of the class you're working in (braces on newlines & spaces instead of tabs in Forge classes, inline brackets in patches, etc).
For more information, refer to [the wiki](https://github.com/MinecraftForge/MinecraftForge/wiki/If-you-want-to-contribute-to-Forge)
For more information, refer to [the wiki][Wiki].
Contributor License Agreement
@@ -15,8 +15,6 @@ Contributor License Agreement
- You grant Forge a license to use your code contributed to the primary codebase (everything **not** under patches) in Forge, under the LGPLv2.1 license.
- You assign copyright ownership of your contributions to the patches codebase (everything under patches) to Forge, where it will be licensed under the LGPLv2.1 license.
Additionally, while 1.9.4 is being maintained, you will be asked to acknowledge these two additional clauses.
- You grant Forge a license to use your code contributed to the primary codebase (everything **not** under patches) in Forge, under the MinecraftForge license.
- You grant assign copyright ownership of your contributions to the patches codebase (everything under patches) to Forge, where it will be licensed under the MinecraftForge license.
"Forge" is Forge Development LLC, a legally incorporated entity in Oregon, USA.
# On the Contribution of an RF-lite Energy System: "Energy"
Forge has acquired an Energy system, after many years of debate on the topic. The prevalence of the RF API has warranted the inclusion of a similar (but simpler) implementation to forge for 1.10.2 and onwards.
Those who wish to use an RF like API, feel free to use it. If you don't want to think about Energy, but know you need it, you can use it *if you wish*. If you want to interoperate with other energy systems, feel free to use this to broker with them.
# On Diversity in Energy Systems
Forge has always supported diversity in energy-like systems. If you have a burning desire to simulate electricity flow in all it's glory, we fully support you and look forward to playing your mod. If you wish to have pneumatic power, we have no objections, and would love to see your wonderful creations. If you have a power system of your own devising that is simply beyond our imagination, please, blow us away.
# On Modder Obligations
As a modder, you are under *no* obligation to use or support the forge Energy system. If anyone, user, mod-pack maker or even us, tells you otherwise, refer them to this statement. The Forge energy system is not intended to supplant diversity in energy systems. It is not intended to be one-size-fits-all. The choice to support it, is the choice of the modder.
-- Check all libraries are present: ```accesstransformer```, ```coremod```, ```deobfuscator```
-- Check versions are suitable: ```modlauncher```, ```accesstransformer```, ```coremod```, ```deobfuscator```
- Find deobfuscated and patched MC
-- If not found, trigger job to generate that (loaded later at FMLLaunchProvider.launch)
Injected arguments:
- ```mods``` : CSV list of mod files to load
- ```modlist``` : JSON formatted list of mod files in a maven-like repository format
Entrypoint : ```FMLServiceProvider.initializer```
- Setup paths
-- ```mods``` folder
-- ```config``` folder
- FML config file read (JSON?)
- Trigger initial loading
Entrypoint : ```FMLLaunchProvider.launch```
- Launches the patched and deobfuscated game
- - If that wasn't found it'll be generated from the vanilla jar and patch/deobf files (see above)
- Possible we'll use an alternative launch for the development environment
(A goal is that we pre-generate this JAR during forge installation or modpack installation)
## Loading
- First we discover all mods
- - IModLocator instances present in system are found and queried to compile a master list of all mod artifacts of the three types
- LANGPROVIDERs are added to the supported language system : IModLanguageProvider
- The MODS from the list have their META-INF/mods.json file queried for mod instances to load
- - MODS are cross-referenced for their language being available
- - MODS are cross-referenced for their libraries being available
- - MODS are cross-referenced for their MOD dependencies being available
- - MODS with META-INF/coremods.json specification are loaded into the COREMOD system
- - MODS with META-INF/accesstransformer.json are loaded into the ACCESSTRANSFORMER system
- - MODS are enqueued to the background loading system
- FMLLaunchProvider will be triggered from the ModLauncher to start the game
## Game loading
- Events triggered from loadGame will launch various phases of modloading as before
-- Deprecation of old "FML" events in favour of Forge events
-- If a mod hasn't completed scanning there might be a pause waiting for it to complete before loading (testing indicates this should be a very rare occurrence and isn't worse than existing status quo where all scanning and loading is on-thread)
### ```IModLocator```
Finds mods from various sources of various types
manifest is queried for type: FMLModType
- MOD : this file will be scanned as a mod. This is default if nothing is present
- LIBRARY : this file will be added to the classpath and no further processing is done
- LANGPROVIDER : this file will be loaded as a language provider
#### ```ModsFolderLocator```
- scans for jar files from mods folder
-- able to load all types
-- loads in all environments
-- maybe able to do runtime name transformation for dev time?
Standard mechanism to find and load mods
#### ```ExplodedDirectoryLocator```
- loads a directory as a mod
-- only able to load mods
-- should only load in dev env
Intended as a mechanism to allow development of mods easily by pointing at a compiled output directory
#### ```ArgumentModsLocator``` : NYI
- loads mods from the arguments on the command line
-- able to load all types
-- loads in all environments
### ```IModLanguageProvider```
Provides mod and language provider services
- Provides a means to transform a Mod File (from the IModLocator) into a list of modcontainer objects based on mods.json
- Scanning work will be done in background threads
- Language providers can be provided as JARs via the modlocator for ease of distribution
#### ```FMLModLanguageProvider```
This is the standard Java @Mod implementation provider
- provided by default (always supported)
- All scanning for @Mod will be done in the background thread
#### ```ScalaModLanguageProvider```
This is the scala language provider. It'll be provided separately as a JAR mod download.
- API contract will need definition
Other languages? Kotlin? Alternative Scala versions? Javascript?
## Coremods
Coremods are now forcefully separated into _injection_ and _runtime_ phases.
### Injection
Injection is the act of intercepting the loading of a class and modifying the inbound class with alterations such as additions, replacements and deletions
Injections will be written using Javascript. Two functions are required: a function providing the list of injection sites, and the function to transform the injection site.
All injection sites will need to be pre-specified by the coremod in their metadata. Lookup services should be provided in the Javascript API.
Javascript API for common coremod injection tasks needs to be developed, to allow common best-practice tooling for these complex tasks.
Runtime coremod code (code that has been injected) is Java as usual.
## Background loading thread
Early in loading, a background thread is triggered which will perform scanning tasks for common resources, such as @Mod instances and other annotations. This thread will also be responsible for loading any cached resources, either those defined at build time or pre-computed from previous runs. It may also be tasked with writing those precomputed resources.
There will be a IPreLoaderJobProvider that will allow extension of the scope of these tasks
Forge is a free, open-source modding API all of your favourite mods use!
| Version | Support |
|------------- | -------------|
| 1.14.x | Active |
| 1.12.x | Legacy |
| Version | Support |
|--------------|-----------------------------|
| All versions | [Supported][Support-Policy] |
* [Download]
* [Forum]
* [Discord]
* [Documentation]
#### Notes:
- Introduced in 1.13 was a new FML, information found [here](NewFML.md).
# Installing Forge
Go to [the Forge website](https://files.minecraftforge.net)
Go to [the Forge website][Download]
and select the Minecraft version you wish to get Forge for from the list.
You can download the installer for the *Recommended Build* or the
@@ -32,37 +28,68 @@ You can download the installer for the *Recommended Build* or the
into your vanilla launcher environment, where you can then create a new
profile using that version and play the game!
For support and questions, visit [the Support Forum](https://www.minecraftforge.net/forum/forum/18-support-bug-reports/).
For support and questions, visit [the Support Forum][Support-Forum] or [the Forge Discord server][Discord].
[Here is a short video from Rorax showing how to install and setup Forge.](https://www.youtube.com/watch?v=lB3ArN_-3Oc)
## Required Java Versions
We require the version of Java that Minecraft requires, which is currently:
| Minecraft | Java |
|---------------|-------------------|
| 1.20.6+ | [21][Adoptium-21] |
| 1.18 - 1.20.4 | [17][Adoptium-17] |
| 1.17.1 | [16][Adoptium-16] |
| 1.16.5- | [8][Adoptium-8] |
**If you are on Windows and have difficulty using Java to launch JAR files, consider using [Jarfix by Johann Löfflmann][Jarfix].**
# Creating Mods
[See the "Getting Started" section in the Forge Documentation](https://mcforge.readthedocs.io/en/latest/gettingstarted/).
[See the "Getting Started" section in the Forge Documentation][Getting-Started].
# Contribute to Forge
If you wish to actually inspect Forge, submit PRs or otherwise work
with Forge itself, you're in the right place!
[See the guide to setting up a Forge workspace](http://mcforge.readthedocs.io/en/latest/forgedev/).
[See the guide to setting up a Forge workspace][ForgeDev].
### Pull requests
[See the "Making Changes and Pull Requests" section in the Forge documentation](https://mcforge.readthedocs.io/en/latest/forgedev/#making-changes-and-pull-requests).
[See the "Making Changes and Pull Requests" section in the Forge documentation][Pull-Requests].
Please read the contributing guidelines found [here](CONTRIBUTING.md) before making a pull request.
Please read the contributing guidelines found [here][Contributing] before making a pull request.
### Contributor License Agreement
We require all contributors to acknowledge the [Forge Contributor
License Agreement](https://cla-assistant.io/MinecraftForge/MinecraftForge). Please ensure you have a valid email address
associated with your GitHub account to do this. If you have previously
We require all contributors to acknowledge the [Forge Contributor License Agreement][CLA].
Please ensure you have a valid email address associated with your GitHub account to do this. If you have previously
signed it, you should be OK.
#### Donate
*Forge is a large project with many collaborators working on it around the clock. Forge is and will always remain free to use and modify. However, it costs money to run such a large project as this, so please consider [becoming a patron](https://www.patreon.com/LexManos) or buying some [cool merch](https://forgedev.flocker.tv/).*
*Forge is a large project with many collaborators working on it around the clock. Forge is and will always remain free
to use and modify. However, it costs money to run such a large project as this, so please consider
**If you do not want to read the following wall of text, no matter its relevance for helping get your issue resolved quickly, please refer to the [Forge Forums](http://www.minecraftforge.net/forum/forum/18-support-bug-reports/) for support.**
**If you do not want to read the following wall of text, no matter its relevance for helping get your issue resolved quickly, please refer to the [Forge Forums][Bug-Reports] for support.**
Before reporting an issue on this repository's bug tracker, please carefully read this document. There are various resources that are more likely to be able to help you with certain kinds of issues. This document provides instructions on how to determine which place best to report to.
@@ -44,7 +44,7 @@ You can generally tell pretty quickly what caused the error at the head of your
1. If you can find the name of a mod in the trace, that mod most likely is the culprit.
- Be aware that you may find multiple mods as participants of a crash. In that case, you can either report to both or try to reason (using the names in the stacktrace) about which mod is at fault.
2. If you can only find Forge (usually starting with `net.minecraftforge`) alongside Vanilla (usually starting with `net.minecraft`) references, chances are that you have found a bug in Forge. In this case, use one of the various [support channels](#forge-support) listed below.
- The occurence of a single call to Forge somewhere in the stacktrace *does not* warrant a report to Forge if there are mods present in the crash report.
- The occurrence of a single call to Forge somewhere in the stacktrace *does not* warrant a report to Forge if there are mods present in the crash report.
3. If there's no mention of Forge or a mod, but any Vanilla class, you might have found a Vanilla bug. You should probably still report it via the Forge channels first, however, due the nature of modded environments and the rarity of Vanilla crash bugs.
4. Always check whether there's a mention of coremods at the beginning of a crash report. If there is and you can't find any clear culprit, consider reporting to these coremods first, since they are free to change any of the code executed in your environment.
@@ -74,17 +74,18 @@ Please note that this list has to be considered incomplete as there is a large n
If you're certain you've found an issue that is directly caused by Forge, you have the following three platforms available for dealing with it, with decreasing relevance for end-users:
1.**Forge Forums:** There's a dedicated [Support & Bug Report](http://www.minecraftforge.net/forum/forum/18-support-bug-reports/) section on the Forge forums, which is led by team of moderators and volunteers who will try to deal with your reports as quickly as possible. *As a player you should probably report here first.*
- For modders, there also is a separate [Modder Support](http://www.minecraftforge.net/forum/forum/70-modder-support/) section where you can ask all your development-related questions. *You should prefer this section for coding help.*
2.**Forge IRC Channel:** You can find a lot of help on the official [`#minecraftforge`](irc://irc.esper.net:6667/minecraftforge) channel on EsperNet. Especially smaller issues that you quickly need help with could be reported there. *Be aware that the channel is more suited towards development questions, so while you may get support there as a player, you should almost always prefer the forums.*
3.**Forge Issue Tracker:** If you're absolutely certain that you've found an issue in the Forge codebase (e.g. you're a modder yourself and have analyzed the stacktrace and relevant code), don't refrain from reporting it on this repository's [issue tracker](https://github.com/MinecraftForge/MinecraftForge/issues). *Please do not use the issues as a means of getting coding help. For developers, the IRC and the [official documentation](https://mcforge.readthedocs.io) are the best sources of information.*
1.**Forge Forums:** There's a dedicated [Support & Bug Report][Bug-Reports] section on the Forge forums, which is led by team of moderators and volunteers who will try to deal with your reports as quickly as possible. *As a player you should probably report here first.*
- For modders, there also is a separate [Modder Support][Modder-Support] section where you can ask all your development-related questions. *You should prefer this section for coding help.*
2.**Forge Discord Server:** You can find a lot of help on the official [Discord Server][Discord], especially smaller issues that you quickly need help with. *Be aware that the channel is more suited towards development questions, so while you may get support there as a player, you should almost always prefer the forums.*
3.**Forge Issue Tracker:** If you're absolutely certain that you've found an issue in the Forge codebase (e.g. you're a modder yourself and have analyzed the stacktrace and relevant code), don't refrain from reporting it on this repository's [issue tracker](https://github.com/MinecraftForge/MinecraftForge/issues). *Please do not use the issues as a means of getting coding help. For developers, the IRC and the [official documentation][Documentation] are the best sources of information.*
### Mod Support
A lot of mods also use GitHub or other source management systems and their integrated issue trackers. The following options will give you the best chances of reporting your issue in the right place:
- **CurseForge:** Many mods are hosted on the [CurseForge platform](https://minecraft.curseforge.com) nowadays. Chances are you already downloaded them from there or as a part of a modpack hosted there. Projects may specify an issue reporting link on their own page, so simply look for it on the mod's project page and you should be directed to the preferred means of error reporting.
- **Searching for a repository directly:** You may need to try and find a repository directly on source control sites. The most common ones are [GitHub](https://github.com) and [BitBucket](https://bitbucket.org). Both come with search capabilities, so simply try to search for the mod's name.
- **Modrinth:** Some modders use [Modrinth](https://modrinth.com/mods) to host their mods, but be mindful that not all mods on this platform are for the Forge modloader.
- **Searching for a repository directly:** You may need to try and find a repository directly on source control sites. The most common ones are [GitHub](https://github.com), [GitLab](https://gitlab.com), and [BitBucket](https://bitbucket.org). Both come with search capabilities, so simply try to search for the mod's name.
### Vanilla Support
@@ -98,7 +99,7 @@ Now that you've identified the source of your issue and decided on the correct s
### Preventing Duplicates and Unnecessary Reports
Use the target issue tracker's search functionality to look for issues which have descriptions similar to yours, but make sure to also search for already closed issues. If you can find one, verify it is in fact the same (or a very similar issue) and simply comment on it if you have anything else to contribute to the discussion, such as other steps to reproduce it. *Do not create duplicates of an existing issue, since it only puts extra effort on maintainers to recognize and close/mark them.*
Additionally, always check the *latest* changelogs of Forge and participating mods to find out if the bug was already noticed and fixed by the developer. Often the maintainer may only support newer versions of the game, so also check the changelogs for versions of Minecraft you don't actually actively play. If the issue was adressed already, *do not report it*, even if the fix only exists for a newer version of the game, since the developer probably had a good reason to do so. If your issue only exists with versions of a mod that are for very old versions of the game, also refrain from reporting them, considering most modders only support the two latest versions of Minecraft, if at all.
Additionally, always check the *latest* changelogs of Forge and participating mods to find out if the bug was already noticed and fixed by the developer. Often the maintainer may only support newer versions of the game, so also check the changelogs for versions of Minecraft you don't actually actively play. If the issue was addressed already, *do not report it*, even if the fix only exists for a newer version of the game, since the developer probably had a good reason to do so. If your issue only exists with versions of a mod that are for very old versions of the game, also refrain from reporting them, considering most modders only support the two latest versions of Minecraft, if at all.
### Required Information
If you're certain that your issue went unnoticed up until now, you can get to actually writing up the report. Below you can find a list of the *required* information any bug report should contain:
@@ -143,4 +144,11 @@ After you have written your bug report, it is time to *wait*. Please be *patient
Every project has a different way of dealing with issues, so don't wonder if there's no comment on it, but somebody "labels" it with certain markers. This helps developers to more easily keep track of bugs and priorities. When any further input from you is required, you will be asked specifically. Do not bug anyone through other channels about resolving your issue.
Once your issue is closed, you will know whether it was valid or turned out to be irreproducible. If you included all of the data from above in your report, chances are that the latter won't be the case.
Once your issue is closed, you will know whether it was valid or turned out to be unreproducible. If you included all of the data from above in your report, chances are that the latter won't be the case.
.filter(modFileInfo->modFileInfo.getMods().stream().noneMatch(this.erroredModInfos::contains))//Ignore files where any other mod already encountered an error
returnactiveContainer==null?ModList.get().getModContainerById("minecraft").orElseThrow(()->newRuntimeException("Where is minecraft???!")):activeContainer;
}
/**
* @deprecated Going to be moved to ForgeHooks for Internal use.
LOGGER.error(CONFIG,"Detected config file conflict {} between {} and {}",config.getFileName(),this.fileMap.get(config.getFileName()).getModId(),config.getModId());
Loaded 100 of 4657 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
berkay8987
