neoforged / documentation Goto Github PK

In sub-section Textuers, it says this:

Textures are drawn through blitting, hence the method name #blit, which, for this purpose, copies the bits of an image and draws them directly to the screen. These are drawn through a position texture shader. While there are many different #blit overloads, we will only discuss two static #blits.
The first static #blit takes in six integers and assumes the texture being rendered is on a 256 x 256 PNG file. It takes in the left x and top y screen coordinate, the left x and top y coordinate within the PNG, and the width and height of the image to render.

There isn't static method in GuiScreen. and method it refers to seems to have this signature now: public void blit(ResourceLocation pAtlasLocation, int pX, int pY, int pUOffset, int pVOffset, int pUWidth, int pVHeight)
Because it is the only method with 256 constant

Packet handler is no longer passed a Supplier<NetworkEvent.Context> it is passed the NetworkEvent.Context directly.

public static void handle(MyMessage msg, Supplier<NetworkEvent.Context> ctx) {
  ctx.get().enqueueWork(() -> {
    // Work that needs to be thread-safe (most work)
    ServerPlayer sender = ctx.get().getSender(); // the client that sent this packet
    // Do stuff
  });
  ctx.get().setPacketHandled(true);
}

becomes

public static void handle(MyMessage msg, NetworkEvent.Context ctx) {
  ctx.enqueueWork(() -> {
    // Work that needs to be thread-safe (most work)
    ServerPlayer sender = ctx.getSender(); // the client that sent this packet
    // Do stuff
  });
  ctx.setPacketHandled(true);
}

Unsure if anything else there needs updating.

The 1.19 versions of the docs were removed in the move to Docasaurus [8dbb7fe], but the versions dropdown menu still contains the 1.19 link and it now leads to a Docasaurus quick-start tutorial.

The "Access Transformers" topic page doesn't reflect the changes made in NeoForge 20.2. This page should be updated to reflect the new support for multiple AT files and the added mods.toml configuration.

ITagManager

Forge wrapped registries provide an additional helper for creating and managing tags through ITagManager which can be obtained via IForgeRegistry#tags. Tags can be created using using #createTagKey or #createOptionalTagKey. Tags or registry objects can also be checked for either or using #getTag or #getReverseTag respectively.

Forge no longer wraps registries and ITagManager does not exist.

Step 4 under "From Zero to Modding" contains outdated information for run configs. genIntellijRuns and genEclipseRuns no longer exist. This issue was already reported on the MDK repository in this pull request a few weeks ago.

Many documents still use RegistryObject and ForgeRegistries. These should be updated.

In section about armor and ArmorMaterial:

// Optionally, you can also override #getArmorTexture here. This method returns a ResourceLocation

// that determines where the armor location is stored, in case you want to store it in a non-default location.
// See the default implementation in Tier for an example.

#getArmorTexture is not defined in both ArmorMaterial and Tier. Instead it's method from IItemExtension which is for 3d model. It's mentioned later in same section:

Besides the usual resources, armors also need a worn armor texture that will be rendered over the player model when the armor is equipped. This texture must be located at src/main/resources/assets/<mod_id>/textures/models/armor/<material>_layer_1.png for the helmet, chestplate and boots textures, and in the same directory at <material>_layer_2.png for the leggings.

The contributing guidelines have recently been established, so every page needs to be updated to support the new guidelines. To that end, every page will be reviewed and rewritten/reformatted as required. The changes will target the 20.2 version of NeoForge when released.

I have assigned myself since I will eventually redo all the pages, but anyone is welcome to help contribute.

• Getting Started with Neo #28
  • Mod Files #28
  • Structuring Your Mod #28
  • Versioning #28
• Advanced Topics
  • Access Transformers
• Block Entities
  • BlockEntityRenderer
• Blocks #21
  • Block States #21
• Concepts
  • Events #48
  • Internationalization and Localization #62
  • Mod Lifecycle #48 (merged into Events)
  • Registries #48
  • Resources #48 (moved to Miscellaneous/Resource Locations)
  • Sides in Minecraft #48 (renamed to Sides)
• Data Generators
  • Client
    • Language Generation
    • Model Generation
    • Sound Definition Generation
  • Server
    • Advancement Generation
    • Datapack Registry Object Generation #48 (merged into Concepts/Registries)
    • Global Loot Modifier Generation
    • Loot Table Generation
    • Recipe Generation
    • Tag Generation
• Data Storage
  • The Capability System #34
  • Codecs
  • Saved Data
• Game Effects #62
  • Particles #62
  • Sounds #62
• GUIs
  • Menus
  • Screens
• Items #39
  • BlockEntityWithoutLevelRenderer
• Legacy
  • Porting to Minecraft 1.20
• Miscellaneous
  • Text Components #62
  • Configuration
  • Debug Profiler
  • Game Tests
  • Key Mappings
  • Forge Update Checker
• Networking #42
  • Entities #42
  • SimpleImpl #42
• Rendering #62
  • Model Extensions #62
    • Face Data #62
    • Render Types #62
    • Root Transforms #62
    • Part Visibility #62
  • Custom Model Loaders #62
    • BakedModel #62
    • ItemOverrides #62
    • Transform #62
• Resources
  • Resource Packs #62
    • Models #62
      • Item Properties #62
      • Coloring Textures #62
  • Datapacks
    • Advancements #45
    • Conditionally-Loaded Data
    • Global Loot Modifiers
    • Loot Tables
    • Recipes
      • Custom Recipes
      • Non-Datapack Recipes
      • Ingredients
    • Tags

something like RegistryObject still in it...

https://github.com/neoforged/Documentation/blame/main/docs/datastorage/saveddata.md#L21

DimensionDataStorage#computeIfAbsent takes in three arguments: a function to load NBT data into a SD and return it, a supplier to construct a new instance of the SD, and the name of the .dat file stored within the data folder for the implemented level.

On 1.20.2, it takes in 2 arguments instead. The first argument is a record instead of function. The record in which takes in default constructor for the Saved Data, NBT deserializer, and nullable DFU Type.

So, I'm starting in minecraft modding, and found it very unclear when trying to change the name of my mod. As it reads on the document, on the section "Customizing Your Mod Information"

"Many of the basic properties of your mod can be changed in the gradle.properties file. This includes basic things like the mod name or the mod version."

Further by investigating, you stumble across mod files and find the definition of the property "mod_id"

"The id of your mod. This should be something unique and memorable, as having two mods with the same id will prevent the game from loading. The mod id shows up in a lot of places, for example as the namespace for all your registered things, or as the namespace for your resource and data packs."

One starting would think that in order to change the mod name you would only need to change this variable, but it turns out that there are more elements that interfere when building the mod and are related to the name, so if you only changed that property, it would cause trouble for mods to properly build.

Might be redundant for some but wouldn't it be more clear to say or suggest in the for example that in order to change the name of the mod, there are other properties that need to be changed properly?
For example, in the definition of "mod_id":

"Note that this is not the only property related to the mod name, only changing this variable can create issues".

Regardless of that issue, thanks in advance for the support.

In FancyModLoader DistExecutor is marked deprecated and will be removed. so we should now stop directing users to it.
https://github.com/neoforged/Documentation/blob/main/docs/concepts/sides.md?plain=1#L31-L66
This section should be rewritten to demonstrate other ways of checking physical sides without class loading issue.

Description: I want the team to consider moving the current docs to use Starlight rather than Docusaurus 2.

As much as both documentation builders are great, in my opinon, I think starlight provides a more organised and faster approach to documentation with alot of features packed in. Since Starlight is built on top of Astro, you can use Astro's features inside Starlight to have more functionality with the docs.

I know I have mentioned 'alot of features' and you may be wondering what features does it have that makes is better than Docusaurus. Well, I can name a few but not all for example: Astro / Starlight is more faster and lightweight compared to Docusaurus. This means that it will take less time to build and load the pages up. The docs are very customisable and flexible, this means that the docs can be customised with plugins or add extra language support if needed. Extra language support means that markdown can be extended to support extra features outside of the markdown scheme. Finally, the looks and feel of Starlight, in my opinion, are so much better. I know that the last point is personal preference, but I truely believe that Starlight looks and performs much better than Docusaurus.

Now to the downsides of Astro / Starlight, luckily there is only one which is versioning support. Versioning support can really help organise your docs into seperate versions like the NeoForge docs have now (1.20.x and 1.19.x). In Starlight, there is no way to setup versioning for your docs however, this feature is being discussed and worked on here. I am not sure if NeoForged needs versioning desperately since NeoForge only has 1.20.x support, I know it will probably be needed for 1.21 for when that releases. That won't release for a couple of months so, the feature should be out by then.

Overall, I am sorry if this issue feels like I am in love with Starlight. This issue is mainly to try and convince the team to consider and maybe switch to using Astro / Starlight. Also, I am happy to help out the migration to Starlight if this issue gets accepted.