Find the VOD here: https://www.twitch.tv/videos/433606398, the question list here: https://gist.github.com/JTK222/1f59c90046e2a62cec5165e7b5407c1d or here: https://gist.github.com/cpw/b7d439f14289cec10f8704af462ca938
- Discord is offline so they use teamspeak, which leads to a bit of organisation mess
- $WELCOME
- Happy FAPing
- The FAP is actually annual
- Lex and CPW will update everyone on current affairs
- Attendants: Lex, cpw, mezz,
- in Chat: tterrag aka gerritt, asiekierka (Fabric guy¹), RainWarrior/fry, many other people
- FAP last year was June 16
- FAP anywhen in June is OK
- Lots of changes to how mods load were merged in since last FAP
- All of the big overhauls are in and stable, no further significant changes anticipated
- Except for one thing: Modules for mods and Forge itself in J9+
- But no huge API changes, just boxing
- Might enable the stuff on the list
- Forge targets the version MC targets, currently J8
- laughter
- CPW weng mad/senile and squirrels came out
- Metaphor for distraction
- They're adorable and cute and distracting
- They came about since CPW on stream was often distracted and the squirrels signify that
- All the photos on stream are either shot by cpw himself or he bought the rights
- Squirrel emotes are a thing in chat
- When 1.14 gets a recommended build
- Legacy support (managed by tterrag&mezz) will continue, probably for long
- 1.13 will be skipped
- Legacy mode means features will be proposed on the main branch and then backported
- Hardest part about a recommended build is writing the changelog
- 1.12 will get a recommended build before/as it's legacy-ed
- It will be left as is
- 1.13 is rather buggy and is not a good modding target
- This was known and is why it was chosen for the rework of Forge
- Especially the fluid system is unfinished in 1.13 and will only get properly frameworked in 1.14
- Still needs to be done but this will all continue on 1.14
- "Anyone developing for 1.13 had a mindset of it just being a way to get 90% job done in prep for 1.14" - s_m9 in chat
- 1.13 is a stepping stone for Forge as well as modders
- Get onto 1.14 as soon as it's there (shortly)
- Community often asks to skip MC versions so the modding scene can settle
- People™/the game/Modpacks might adapt to this cadence of 1 annual big update
- Forge will always update to new versions, there will always be a dev env
- Modpacks have already been following this 'skipping every other update' rythm
- Predicting the future is hard
Will the example project ever do anything meaningful? (Like register a block, or implement an entity)
- No
- It's supposed to just show how to get code running and the basic file structure
- Implementing the content is left to the reader
- Look at the test mods or all the open source mods
- Even though the test mods are not yet updated as they are low todo
- Some caching is already happening as deobfuscation now happens with the forge installer instead of having runtime deobf during game launch
- Caching more will be difficult but there are a few possibilities
- Like the texture atlas maybe
- Large part of loading is vanilla stuff loading textures/models which is up to mojang to cache
- Caching the in-memory representation is more expensive then loading the raw data
- Invalidation is a huge issue
- 1.13 already has been rewritten to make mod loading and loading in general way faster
- Huge modpacks might show us some more angles of attack for optimisations
- Wait for them to accuarately see loading times
- Forge adapts
- Everyone redid the RF API in capabilities so Lex got annoyed and wrote a common implementation
- Forge should exist at the intersection of many mods and do very common stuff
- 1 correct but forced implementation is better than 99 incorrect but independent
- Energy API was a one-time thing which is not to be expected to repeat
- Fluids are a different thing that forge has special support for since they are rather hard to do
- Forge does things correct, but other people aren't wrong. Their stuff will just be less compatible
- Forge's job is to provide a common API for stuff most people want to have and to be compatible
- That's what makes it so nice compared to the Bedrock API or other games
- Side question: how does Forge influence stuff like async entity modifications?
- That example would lead to unsafe behaviour (crashes, corruption..) and isn't recommended. But we can't stop you. We won't support you though.
- We aren't here to make Vanilla threadsafe or fix other 'misdesigns'
- (Black) Magic Classloader hax
- actually a lot of effort by Lex and co
- Minecraft is closed source, obfuscated (names are changed) -> we deobfuscate (try to figure out proper names) -> patch game stuff to support modding -> only distribute the changes (called patches) to not infringe on copyright -> reapply these patches and renamings when installing forge
- Some of that is provided by MCP
- Different parts (by order of loading):
- Modlauncher (by cpw): replaces LegacyLauncher; loads and provides a patching environment for Java compatible with the latest Java and having a nice API
- FML piece: Contains transformers, mod scanning and loading, language loader handler/provider
- Forge itself: technically is a mod which loads the game
- Several 'pulled-out' projects that are maintained seperately like EventBus, coremod JS framework, ...
- Searge made it and made the rules
- It's still his project even though Lex maintains it
- Mappings are released publically, but don't redistribute it.
- Having (even slightly) diverging after every update is a huge PitA because everything is incompatible
- Lex (and cpw) work to reapply all the patches to the MC code
- MCP mappings have to be updated
- For 1.14 the community was involved, which was slow but a start
- ForgeGradle (the tools that build Forge) needed updating for 1.13
- For the future: earlier community engagement please - because you'll still able to change things
- Class names need to be done early because everything depends on them
- If you think they suck make a vote issue here https://github.com/MinecraftForge/MCPConfig/issues and it may be included in the next major versions
- FernFlower (or it's fork ForgeFlower): actual decompiler adapted to Forge needs, HELP NEEDED HERE. Also shoutout to JDLogic.
- FernFlowers's code is not that great and things are often rewritten when they are patched for ForgeFower, but if you want to you can clean things up and resubmit patches to ForgeFlower into the upstream FernFlower
- A lot of the pulled-out projects have tests.
- Test mods are a thing, currently being rewritten, low priority.
- 'We try to test everything. Obviously we can't test everything.' - cpw
- Mezz and tterrag (gerritt)
- They have been a bit neglected recently, mezz apologizes
- New GitHub features will hopefully improve this so more people can manage PRs without full code access soon™
Will the major Forge rewrite be finished with 1.14 or can we expect more large changes in the future?
- Only change still on the horizon is Mojang updating to Java >8
- Will allow treating mods as modules, might allow mod hot reloading
- We maintain compatibility with J8 as long as mojang does
- Fluid system is to be done as it's brand new in 1.14, still needs to be adapted
- No huge engine changes anticipated except for likely graphics stuff (Blaze 3D), which are likely to be incremental
- Valhalla will have a huge effect but still far away
- The rewrite for 1.13 was to be future-proof, got rid of legacy stuff (which was 8 years old) which wouldn't be J8 compatible
- Game will still be around for the next 10 years, let's hope this rewrite lasts as long as the old one
- Microsoft has a vested interest in keeping Minecraft alive and isn't that against Forge
Will the fluid system be rewritten? Will it be possible to have a "waterlogged" state for multiple fluids?
- The vanilla system got a big overhaul/was redone, this question is about how Forge will adopt to it
- Yes
- Plans exists and will be done when things stabilize after the 1.14 update
- Supports waterlogged state for a variety of fluids
- We'll see how that's gonna be expanded, no concrete ideas yet
- It'll be discussed over the next couple of months
- What's wrong with it? - cpw
- 1.13 has changed things with dimensions and made it more confusing
- Dimension is tied to a world type but not the world itself
- New dimension API already exists but is not final, feel free to suggest changes / redesings if you're impactied
- It's fix up to design an API that noone is using
- Changes begun in 1.13 and continues to change a bit in 1.14
- 'Go crack it open and have a look for yourself' (cpw) if you want to see the actual changes
- If there's something missing talk to us
- New WorldGen engine apparently is pretty good and modifiable
- Is it async? - IDK
- Removal of metadata
- Makes a huge amount of stuff way simpler
- Mezz is happy about JEI
- Infinite blocks, per chunks and in general
- Register everything, ignore your footprint. Don't make it config dependent or something
- Because TileEntities came up in chat - please look into flattening your TileEntities into BlockStates (like flowerpots, rotations, ..) since the 16 limit now longer exist
- Since getActualState is gone, you're even more encouraged
- Or break up 1 TileEntity -> multiple Blocks
- Especially if it has a different inventory name
- This is just a recommendation, you're not forced if it woukd result in "petabytes of JSON"/blockstates
- No effect
- Not even the Forge Bucket™ is affected
- Actually it is since the Forge Bucket is dynamic by just putting an overlay on the vanilla bucket, so the mask will need to be updated
- Event code cleanup and organisation is needed
- Many events are just for ModLoader compatibility which is now no longer needed
- If you like writing documentation please help out documenting events and where they are fired
- Some events will die due to changes in the backend (like WorldGen)
- Forge did not create the block ID limit
- Now everything is unlimited in game
- Registries need a bit of work but Lex will surely deliver
- Everything related to IDs in a registry will be a VarInt that has a limit of 2 Billion and takes fewer bytes for small values
- Viruses have been distributed as Forge Mods, we can't do much about it
- Apparently there's a Remote Code Execution issue
- The entire MC community is run by amateurs who aren't really good at writing not exploitable bugs
- Forge can't monitor every mod. Be responsible, if you find bugs, open issues
- Don't be a dick
- Yes
- Or they soon will be
- It's up to optifine
- Optifine now has it's own entrypoint it can use
- Optifine is lower-level and was using LegacyLauncer as an entry instead of the way normal Forge mods work, but since that's replaced, ModLauncer needs to and has provided a new API
- Optifine guy¹ can now adapt to the new API, all hooks in Forge are there
- They exist
- A PR is in progress
- You might need to somewhat rewrite your models
- Is there someone who's good at rendering and wants to help out
- The last one got hired by Mojang so he's gone
- Likely won't come back
- NightConfig has annotation support
- That annotation parser might need changes
- Config UI needs some changes too but it's low priority
- If you want to help with making NightConfig compatible feel free
- Config annotation were a bodge since the old config system was trash
- Annotations are no longer needed to circumwent the crappy API
- New config is nice, annotations are 'magic' and unnessecary
- You can add maps so that allows every type imaginable
- Coming along
- The NightConfig guy¹ is cooperative, PR him if you want more/better type support if applicable
- Yell at gerritt as he's in charge
- Likely not
- Eventually maybe
- A lot of restructuring has made this come closer
- Vanilla itself has a lot of static references which are hard to pull apart and reload
- Restarting will become less painful hopefully so hotreloading won't be such an issue
- Coremods prevent this, but as MC becomes more data-driven, reloading the data is way easier
- CPW wants Mixins
- The Mixin maintainer (mumfrey) is less focused on it
- ModLauncer has a mixin api but it's unused
- mumfrey has local changes to make it work but hasn't pushed them since changes are still pending
- That includes a modlauncer change
- CPW looks forward to working together
- Mixim may one day become a first-class member of MC modding in Forge
- Read the coremod repo, talk to the team on discord
- Having a standart mechanism and a sandbox api would be nice even though/as coremods are bad
- Coremods should only do class byte transforms, the rest of the mod uses the coremods
- Do no mix them
- What even is a coremod: During the game loading, various actors want to change them. Forge does this to do all the forge stuff it does like adding events, hooks, buttons, ... Coremods (and mixins) plug into the same system and allow additional changes to the raw MC code.
- Coremods are now sandboxed and written in JavaScript so they only change class bytecode.
- Coremodding is very delicate and allows you to fuck things up hard. Keep your coremods small, precies, single-issue. Look at forge patches
- JarInJar allowed (in 1.12) to have multiple mods in a single jar so that coremods and mods can be seperate
- Since Coremods are now JS they are 'data' and are loaded seperately
- Coremods are visible-source, please don't use stupid obfuscators
- JarInJar is supposed to be in 1.13, it's being worked on
- Version resultion will also be there (somewhat)
- Mods in memory are kinda like maven from a version organisation point of view
- Since J11 removed the embedded JS engine (Nashorn), the JS engine might change
- It would be nice
- Will likely only include the JS stuff
- Coremods will exists but should be a last resort
- Documentation will make it 'hard' to use a coremod since it should be hard and done with care
- In the past we did
- One particular bug with stairs and slabs had impact on some resourcepacks so the bug was readded
- Forge rapid release cycle allows for bugfixes to be tested and then pulled into vanilla to be fixed there
- As long as bug fixing is minor it'll be done
- On a case by case basis, no large-scale changes.
- Forge often changed the lightning engine with mixed results
- FastCraft/Optifine/FoamFix are not added into Forge since they have side effects which Forge shouldn't have as it aims for vanilla compatibility
- Vanilla bugs belong onto the vanilla bug tracker
- Notch didn't write it that way originally
- They're kinda rewriting MC to make it mod friendlier since then
- A lot of code improvements and refactorings make it easier for forge as well
- Most breaking changes have been for the good, look back to 1.6 and how you had to fiddle with IDs to get mods to load
- They're not working against Forge's interest
- Registries were forge's best invention
- Nothing stops them, but they won't
- Mojang may include parts and take what they want
- Forge is way more difficult and out-of-scope. (Like performance improvement mods for forge)
- Vanilla Modding API is commandblock
- ModLauncer was supposed to replace LegacyLauncher in conversation with mojang who also use LegacyLauncer for beta/alpha/old versions of the game, but that is not going to happen
- Lex can moderate on the Vanilla bug tracker so he can promote bug tracks in there
- Nice, have fun with it
- There was a meeting between the Bedrock modding API people and Lex/CPW/Direwolf, the Forge team have high hopes them
- 'We aren't competitors'
- Having Bedrock mods load in Forge would be nice eventually at some point in time maybe
- Does more than just obfuscate, like removing testing&debug code
- Downsizes the jar
- The law requires them to guard their IP because otherwise they can't sue infringers
- Why is it a 'vs'
- No, that's fabric's job
- Will they coexist in a single name?
- Forge uses srg namings (see above)
- Fabric has it's own intermediary names
- Someone would need to write a LangLoader to translate bytecode from fabric to srg, then it'll be compatible
- Or even more simple a odLauncer transformer
- Other big compatibility issues would need to be adressed like different registries
- In summary: no technical difficulty, just API stuff
- asiekierka in chat: Fabric has its own launchwrapper replacement (Knot), but can in theory handle different naming schemes
- ModLauncer is flexible and able to adapt
- We all have dreams
- asiekierka wishes the best of luck, same from the forge people
- Lines of communication are open
- They got out while we were in a major refactor
- After 1.14 updating will soon get faster
- Fabric can update to snapshots so fast since Fabric has way less patches it carries around
- Lex can update forge to a snapshot in 2 hours he just doesn't publish it
- Forge for 1.14.3 when it eventually drops will be within days
- Forge will only ever target stable versions and full releases since prereleases often are too volatile and revert stuff weekly
- Forge has stable srg names which it requires to update to every update, Fabric is easier with that by having adaptive naming
- It all comes down to a philosophy difference (asiekierka):
- Forge is "what works: the mod loader", also big and covering a lot of cases
- Fabric is "what I believe in: the mod loader", also small and agile
- Fabric is young
- Back in the day the prereleases were more final so Forge updated to them, and was done before the main version dropped
- Lex has a lot of ideas about the updating that he can talk about if you buy him a beer
- Forge for 1.13 had 497 patches to the base game which take some time to update
- The update to 1.14 that just dropped took a week and will have a compiling version by tuesday (estimated by Lex)
- Blocks now define their own collision box which is also used for isSideSolid (ie can you place a torch on it)
- peterix (the MultiMC guy¹) will talk to cpw about how launching with ModLauncher works
- Lex has already talked to him, it'll be released when he has time
- cpw streams it, Lex doesn't like it
- private branches on public repos allow for better cooperating during MC updates because they can push MC code
- They won't stream documentation updates, just look at it
- Still somewhere in the pipeline
- Also tags exist now
- Which were stolen by mojang
- Pahimar wanted to do such a day
- ModJam was supposed to be included
- Noone's got time for it
Flocker store for Forge merch
- It's currently affected by the Google Could Error
- Also no AdFocus links on the forge download since patreon raised enough money
- Forge is Lex's main job, support him on patreon, he has bills to pay
- GitHub sponsors hopefully
- The way he got serviceloaders work nicely
- The lambda APIs
- Patching works by creating a supplier to patch stuff
- Mass patching has been moved to default interface methods (by mezz)
- Problem: no fields
1) I'll use guy when talking about the people behind projects, idk if they're actually male