# NAP 2025 Team notes

# History

## Did you have a good nap before NAPping?
- **IHH** - I figured this as an opener would make sense
- **Orion** - Obviously not, that is why we are here.
- **TG** - I really dont do naps. Get all my sleep done at night.

## Where did the idea of creating Neoforge come from? I remember reading something about some problems with LexManos, but who proposed this idea?
* **Orion** - It was a team efford, and was always in the air.
* **TG** - defer to Orion
* **maty** - (internal note for those speaking) ||I would be careful with what ""team"" is meant to be mean, the reality is that most of the team had no knowledge of it - only me, sci, orion, curle, cpw and shrimp did as part of the planning server (+team members that were in FC and read the special channel, but they only had vague ideas). This did create complaints from other team members at the time - moderators specifically, which were suddenly tasked with moderating many channels flooded with ""what is neoforge"" when they themselves had no idea what it was - when we made the quick change to the Discord server as they had no idea what to expect and what was going to happen next (frankly, we didn't too). That's not to say the idea wasn't welcomed, it was mostly welcomed (with a specific exception in mind) as everyone was already painfully aware of lex's behaviour, but it still wasn't as meticulously planned as it should've been||

## How did the name "NeoForge" come to be? I know it's a better fork of Forge, but why "Neo" on it? (also why is the fox the icon)?
* **Orion** - Neo is a variant of New that fit. So NeoForge it was :D
* **TG** - defer to Orion
* **maty** - worth noting that other initial name ideas were ""X(F)Orge"", ""deforged"" or ""forgereborn""
* **Rogue** (internal note/question) - ||Wasn't NeoForge a temp name, and then shit got rushed so it stayed?||

## If you were to pick just one (1) of the features Neo introduced, reworked, or otherwise edited to be the most representative of the work done by the Neo team over this past two (2) years, what would you pick?
* **Orion** - NG and MDG/NFRT for Tooling. Removal of Obfuscation for useability and debugging. Registry Rework for features
* **TG** - To be honest, there isn't any one thing. NeoForge is a culmination of many new features and improvements and that's why we hope people enjoy using it. And so, I cannot pick a favorite feature. Especially when each improvement and feature was made by different people. A team effort.
* **maty** - I think the new Gradle tooling has been received quite well by the vast majority of the community with its speed improvements and usability improvements. On the PR management side, I think the PR publishing system has been extremely helpful to modders that wanted to port early or test new reworks
* **Champ** - Overall, the gradle tooling. If not that, I would say either extensible enums or feature flag support.
* **Rata** - I'm a big fan of the registry rework.

# Versioning
## How do you plan to handle Mojang versioning in the future? Since 1.22 now became 1.21.6, will you always chase the latest version? How do you decide on LTS versions?
* **Orion** - Yes we do. This was discussed early on. LTS is determined by community engagement
* **TG** - We will always target latest as main version. The idea of LTS is not a thing as NeoForge will accept backports of non-breaking PRs to any past version minus 1.20.1. So in essence, we support all versions.
* **maty** - NeoForge does not have LTS versions and we will accept backports to any ""real"" (not 1.20.1) past NeoForge version, and we will try our best to make sure that we can build these versions indefinitely, with recent tooling as much as possible. We also have a bot that can seamlessly create automated backport PRs to previous versions and we use it frequently, even to backport to 1.21.3 or 1.20.6!

## At some point a few months ago, there was an announcement recommending that gameplay stays on 1.21.1 and recommending that we port to future versions as stepping stones (for ease of porting), and not publish vigilantly. (not exact quote). I absolutely approved of that announcement. I do not want to port for each version. Even if there is little or no work, just loading projects and testing takes many hours. Question: can we expect such recommendations in the future? Sure, we all agree that there are various factors that made some earlier versions "a thing", but non-binding recommendations can't hurt.
* **Orion** - Yes.
* **TG** - That announcement caused a bit of a stir among maintainers. It's not in NeoForge's place to state what versions modders should stay on to be honest. Instead, this is something that modders, players, and packmakers should naturally decide on. As modders keep porting, they hit a Minecraft breaking change wall. Pack makers then go make modpacks for that version before the massive breaking change. Next modders and players then consolidate on that version because modpacks were made for it which leads to more mods and more modpacks to be made for that version. I say, keep porting your mods until you hit a massive Minecraft breaking change and that should be a good signal that the version before that is going to become popular.
* **maty** - personally, the announcement was not the best decision. While I agree that ""1.21.1"" was and still is a huge modding version, focusing on it exclusively limits the chances for modders to port to new versions, try out new features and give us feedback. It also creates the false sense of an LTS version which we do not have as we actively backport to most versions, even ones that are barely used.

## What's the biggest thing coming down the pipeline come 1.21.6 that modders should be preparing for? For example, Item Components caught me completely off-guard, and were a pain to initially migrate to, but are so powerful that I can't imagine going back.
* **Orion** - Rendering.........
* **Monica** - Rendering. Specifically, not relying on OpenGL being present as an implementation detail.
* **TG** - I got a straitjacket for myself with these rendering changes. I rather pay someone to port my mod for me to deal with the rendering hell.
* **Champ** - Assuming that you're starting from 21.1, there are a ridiculous number. For the average modder, I would say
* 21.2) entity render states and general consumables,
* 21.4) client items,
* 21.5) game tests and saved data, and
* 21.6) some minor gui changes. But overall, it would have to be the entire rendering rework. It's something we don't have well documented aside from what we already had.
* **Rogue** - Echoing rendering again. The complete rework of B3D changes how Mojang uses OpenGL massively, and also opens the door for mods to do things through it that previously required direct use of OpenGL. Mojang has directly said they are (currently) not actively persuing moving to VK, but mods should be prepared for that being the future as the B3D API has many things that mirror VK and is quite clearly keeping that door open [Cinnabar was running in under 24h].

# Features
## What are some more featues (like QoL, things made simpler) that might get added in the future?
* **Orion** - I don't have a glass ball
* **Monica** - Logging improvements. This has been on the backburner a bit but sorting out the tragedy that is logging is something that should help all modders and mod-users alike.
* **TG** - There is work in toolchain to not need to do classnode parsing for all classes to improve dev workspace speeds. We do need someone to go and overhaul the FluidType system that is problematic and buggy. More documentation of course.
* **maty** - in response to TG above, that's not really correct. We have no plans to remove the @Mod annotation which is the primary user of the annotation scanning system. You probably meant removing class node parsing for all classes which we indeed are actively working towards right now
* **Champ** - In general, that's hard to pin down. My recommendation would be to just look at the pull requests as to what people are currently working on or the threads on discord. Also, I see you TG with your sneaky FluidType mention!
* **Rogue** - The new B3D is a massive step by mojang, but its far from complete for all modding purposes. Quartz and Flywheel both use MDI (multi-draw indirect), theres only a couple texture formats which is limiting for what UTBs can be defined, SSBOs aren't supported at all, Compute shaders aren't supported (nor is transform feedback to fake them), attempting to make an array texture has its own error in the default GL backend. If features to cover these mods get added and they use them, hopefully GL state machine mishaps (which suck to debug...) can be avoided in the future. [Also API intercompatability with VK, without the mod needing to really care]

## Will cached loaded states ever be a thing? / something like dashloader but in neo so everyone supports it :P
* **Orion** - Not planned right now. Lets focus on FML, and not throw ourselves in a knot there. Before looking forward to that
* **embeddedt** - Caching is a bandaid and often has pitfalls, except in certain simple situations. Better returns are usually possible by just optimizing the loading logic in the first place, or deferring it
* **TG** - It is better to see if we can optimize the poor performing parts of code first. Then add caching when no further improvements can be made. That will need more research and investigation so no promises right now about this. Continue to use the mod form.
* **maty** - Caching the mod loading state and transformed class state is a slippery slope that has the potential to introduce several bugs. We can definitely cache other data like annotation data first, but it's always worth seeing what are the real slow code paths that cause slowdowns.

## When you try to add a second layer with the neoforge:item_layers model loader, it cause z-fighting. Is this a NeoForge or Minecraft issue? Is there any way to fix it?
* **Orion** - Open a bug report / issue on github.
* **TG** - This is a question better suited for the NeoForge repository so we can investigate it and fix it.

## Is there any way, any way at all, that some kind of SimpleCodecBuilder\<T> gets added to NF to pare the enormity that is Codec \<T> down to the actually useful bits? I'm far too smooth-brained to fully understand Codec\<T>, let alone StreamCodec\<T> :sob:
* **Orion** - No not really. Codec and StreamCodec serve two entirely different purposes.
* **Monica** - This is where docs/examples would really shine, as well as explaining the difference between MapCodec/Codec. Of course, any specific questions can be asked in our Discord and we'll do our best to help
* **TG** - Welcome to codec hell. Anyway, we hope to have more documentation on Codecs in future. For now, please ask in the NeoForge discord and someone should be able to help teach and walk you through codecs.
* **maty** - To answer the question, there's little you can do to make codecs ""simpler"" without defeating their extreme type safety, which is why they exist. Sure, the lambdas might be confusing but we cannot do much about that nor can we do more to help with the generic errors when you mess up writing a codec. What is true however is that the error reporting of codecs is far from ideal but again, DFU contains codecs and it is an external Mojang library that we cannot patch. It is open source however, so anyone can actually contribute to Mojang's repository directly - https://github.com/Mojang/DataFixerUpper

## What is your opinion on approaches for unification? Will there ever be a native unification system in Neoforge or do you encourage the use of mods like Almost Unified or KubeJS?
* **Orion** - Maybe.
* **IHH** - There's talks about it here and there in #brainstorming, and I'm currently doing a first step for that.
* **TG** - There is talk about it in brainstorming thread but seems a bit died down as people are busy with other stuff. It could get revived. Issue with it is there is a lot of potential edge cases and pitfalls. For example, if Mod A and Mob B both provide a resource, whose resource should ""win"" and take priority? Will mods be fighting each other to be dominant by default?

## Will the transfer rework ever get merged into official neoforge? Whats stopping the team right now?
* **Orion** - Yes. Very much Yes. The size of the PR is currently a problem for Github, we are working with Soaryn and Adrian to handle that currently
* **TG** - It will get merged after it addresses all the reviews and stuff. The PR is MASSIVE and we had to split it up to make reviewing more easier and to help force the PR to continue moving along instead of stagnating.
* **maty** - The PR is massive and hard to track, which is why we opted to split it up in multiple smaller PRs. In the end, as with all features, refactors and PRs we cannot promise they will ever be merged, but if our reviews are addressed promptly and we reach a satisfactory state and maintainer consensous it has high chances of being merged.

## A question regarding the recent transaction PR that clash with maintainer/ outside contributor. What is the team members take on this and the steps is taken to reduce future chances?
* **Orion** - We dealt with it internally. Everybody rose to the occasion to achieve something great and we continue working on the PR and getting it reviewed.
* **TG** - The PR is unique in how incredibly massive it was which made it very difficult to review and pain points We are trying a solution of splitting up the PR into slices to review easier. Overwhelming majority of maintainers were in favor of this. In future, if we have another ridicously big PR, we might employ this strategy from the start but these kinds of PRs are very very rare.
* **maty** - While we can take steps to ensure we communicate changes more effectively, we cannot reasonably expect clashes between contributors and other team members or between team members to not exist in the future. Every person has a different view on a matter and in the end it is the job of each maintainer to make sure that contributions they review raise to their standards and those of the project. What is important however is that these discussions remain civil and that we do not talk past each other as these discussions are NEEDED and when correctly managed are constructive

# Documentation
## Which guides or tutorials would you recommend for beginners that want to learn modding? This is probably an answer somewhere, but where would a first timer trying to get into making mod go to learn how to use NeoForge to make mods. Thank you for the incredible work you do. (I'll have to watch the video for the answer).
* **IHH** - Our docs! For those who prefer videos, Kaupenjoe or McJty are usually what is recommended.
* **TG** - The NeoForge Docs is a good spot to start. We also have the NeoForge Discord that can help if you get stuck. Just keep in mind that knowing Java at a intermediate level will go a huge way to making modding much easier.
* **maty** - I think it's important to also learn how to ask questions in our servers and other servers dedicated to developer support so you can be helped effectively when you inevitably get stuck - you need to avoid XY fallacies, provide clear descriptions of why you want to do something - NOT how - and provide the people that help you with any other useful information they ask for like logs. And don't be scared to ask, obviously!
* **Champ** - Text-based, NeoForge docs and the primers. Interaction? NeoForged discord. Video? Not sure. McJty hasn't done a video for 1.21 iirc and Kaupenjoe has mainly been focusing on 21.1 and only providing brief updates for the later versions.

## Is it possible to have a real documentation for NeoForge mods development? I know that's a lot of work but it could help us a lot. Thank you so much for your work!
* **Orion** - Unsure what docs they are looking fort here
* **Monica** - Does the FCW still exist? That had a bunch of useful documentation.
* **TG** - Did you mean the NeoForge documentation? *show site* This contains info for how to get started and info about various topics. The mod generator site also comes with comments to help get your feet wet into modding.
* **IHH** - To add to TG's: If you feel like docs for something are missing, please open an issue on the docs site or - even better - contribute them yourself! We are glad about every contribution
* **Champ** - Like more tutorial style or what? Assuming tutorial style, I'm not against adding it to the docs, but we would probably want an actual code repo and a general agreement. There are other solutions as well, but each one will require time and work to implement.

## What is the actual difference between NeoGradle and ModDevGradle? Which tool do you recommend for beginners? I am pretty helpless where to start.
* **Orion** - They both achieve the same thing, just have a different philosophy.
> NG tries to adapt to what ever you need, being useable for complete new commers and extremely advanced scenarios. But that adaptability and flexibility comes at the cost of some setup speed.

> Where MDG is an amazing tool for the not absolute newcommer, but the modder that knows gradle at least a little bit, it uses a more direct DSL, is a bit faster due to a different setup chosen, but also restricts you more when it comes to your choices and how it integrates with the IDE, and Gradle itself. One amazing feature is the Legacy module MDG has, allowing you to use it on older MC versions that NG does not support.

In the end the choice is yours, and either one is perfectly fine if you have worked with gradle before.

* **TG** - Defer to Orion. Though MDG seems fine for beginners too.
* **maty** - This is a charged topic, but I don't think MDG being ""restricted"" is a bad thing, it just requires you to rethink the setup in such a way that it works correctly with all IDEs natively and with Gradle. MDG is definitely fine for beginners.
* **Champ** - Generally recommend MDG for most use cases.

## Can you please increase documentation for working with Energy, Items and Fluids in a BlockEntity? The only information there is explanation of Capabilities.
* **Monica** - There is documentation in the pipeline as part of the transfer rework, as well as samples/templates which you can use for common scenarios. More to come in time, though
* **TG** - Trafers PR int he works will change a lot for this. Afterwards, we should have more documentation on this. You can ask in the NeoForge Discord and someone can help walk you through the current system today.
* **Champ** - Are you talking about an example to hook block entities into caps on the docs? That's fine, but as always, leaving issues on the docs is the best way to let us know what to improve.

## Will there be a docs/explanation for NeoForged internals working such as ModLauncher, FancyModLoader and similar for future maintainers
* **shartte** - currently no plans, but maybe?
* **IHH** - I want to do it eventually, but I have only so much time. If someone else wants to take the lead, they're welcome to
* **TG** - Issue with this is someone has to find time to do internal documenting and our list of things to do is looooooong lol. Maybe someone will do so at some point but more documentation priority is focused on the modder facing APIs and Minecraft features as those will be more immediately helpful for modders.
* **maty** - While the idea of documenting is certainly appealing, documentation on FML's loading process does not prove itself as useful to random modders as it might. Obviously documentation is good, but at the same time those actually interested in grasping how FML works should have the ability to follow its code and figure it out because with the recent refactors a big goal is to simplify and comment (with Javadocs too for the API) the codebase, in hopes of making it more maintainable
* **Champ** - As all things are, eventually. Just not a priority at all.

## Any plans on fully documenting the Minecraft and NeoForge Source Code and publish it to the documentation page? It would save me so much time reading the source code and understanding the logic behind. For example: understanding how the enchanting system works.
* **Orion** - Eventually maybe. Currently no plans
* **embeddedt** - something important to keep in mind is that Minecraft's internals change frequently (especially nowadays), so even if such documentation were written, it would fall out of date very quickly
* **TG** - Like NeoForge adding comments, javadoc, and docs on every single Minecraft inner workings? Not a chance of happening. The workload to do this and maintain it far exceeds any team and Minecraft changes incredibly frequently. Learning to read Minecraft's source code is a skill modders have to pick up and it's always going to be that way. For NeoForge, we document all our public facing APIs as well as we can. If there is missing documentation for a specific NeoForge API, please make an issue report so we can be aware of it.
* **maty** - The idea of documenting Minecraft fully is frankly a misguided pipe dream. The code changes extremely often and time is much better spent on working with the code than trying to document it to then realise now there's no time left to actually use it before Mojang changes that code again. It would also be extremely labourious.
Neo code should have Javadocs generally and the documenation page should provide rough overviews of Minecraft and Neo features, but, as goes with modding for all reverse engineered games, modders have to be able to decipher some code themselves - and it's a useful skill in general. Now regarding a Javadocs page, there are some legal concerns regarding publishing Javadocs containing all the names present in Mojang's official mappings, but it should be doable. But in general I don't find Javadoc websites useful because they don't contain the crucial part - the code
* **Champ** - We have some general inner workings in the docs for modders, but if you want javadocs or parameters, Parchment! Use Parchment! Or help contribute to Parchment.

## Are there any plans for improving the website? The Neoforge website seems pretty decoupled from the Neoforge Docs. The links to each other are pretty hidden as well.
* **Orion** - Yes. We are looking for some experts :D
* **TG** - We need expert web devs/designers. The site does need an overhaul.
* **maty** - There are no plans to merge the documentation website into the main website - they serve different concerns and will always end up using different frameworks. This is not at all an exception, you will find that a huge amount of projects have a separate documentation website - this is because it can be changed independently (which is needed as docs are updated more frequently) and because documentation websites generally use a different framework designed specifically for documentation - in our case, Docusaurus
* **Champ** - We welcome any and all contributions there. Our webstack is very different for each: main page uses hugo, project listing uses vue, docs uses docusaurus... it would be nice to have a general web-dev framework for each to keep the design consistent.

# Loader
## Is “NeoForge as a mod”, so the separation of loader and api still planned?
* **shartte** - at this point I'd say it'd be disingenuous to claim it was, if it comes in a year or two, cool, but I don't see us currently actively working on this
* **TG** - I have not heard of movement on this.
* **maty** - There has been no movement on this, and as much as it is a cool idea there are different issues regarding how this separation would actually play out in practice and the required maintenance costs. So this is not in the plans for the near future - it might come in years.What we have plans on however is to decouple installation data from the installer executable and have a universal installer that can install any Neo version - this should also allow other launchers to improve their NeoForge installation technique and make it more stable, and allow us to make more visual improvements to the installer GUI

## There was some discussion post-forking of killing BSL/legacy classpath. Is this being worked on?
* **shartte** - yes
* **TG** - Repeat Shartte's ""yes""

## When can modders start using JPMS infrastructure in mods such as able to declare module-info.class and have actual runtime enforcement with some leeway for interoperability?
* **shartte** - the majority of maintainers is (was? vote was a while ago) against closing down mods against other mods
* **Orion** - Maintainers don't really want to support this. But if the community voices a different opinion we can reopen the discussion. Right now we consider the ability for modders to patch/mixin/reflect into broken mods to be more important. If we can come up with a mechanic that allows for that while JPMS is in place, then we can reconsider it
* **TG** - I personally don't think this will be a net benefit at all and comes with a lot of downsides and will shotgun the community down the road. Maintainers voted majority in favor of NOT adding a system to lock down mods.
* **maty** - To me, restricting access to a mod's code is a hard no. The whole modding community is built on modifying closed source code - Mojang's own - and it would be unproductive to allow mods to deny any runtime modifications to their code

## Is there work being done on making NeoForge load times a bit more, eh, bearable? Lazying, parallelization, anything? or is it just flat out impossible without major backwards-incompatible changes at this point?
* **shartte** - work is being done, but progress is admittedly slow and will also bring some pain to modders (see removal of OnlyIn for modders being one such case)
* **embeddedt** - the majority of loading time nowadays is caused by inefficiencies in mods, rather than the modloader itself. We sometimes add optimizations in the modloader where the impact might be significant, but it is hard to fix slow code that we don't control
* **XFactHD** - very prevalent example of the above is the creation of VoxelShapes for blocks. The helpers provided by vanilla for joining shapes have major pitfalls, making it easy to write extremely inefficient shape composition, to such a degree that a single mod can take several seconds in total to compute all its block shapes
* **Monica** - Another major source of ""lag"" is through logging. Inappropriate uses of logging means that we're spending a lot of time in disk I/O and in logging infrastructure (e.g. filtering log messages) when we shouldn't.
* **TG** - The long load times is mainly due to modder's own code.You should try seeing if you can profile or test your modpack and find which mods are a significantly increasing the load times and report to those modders. On the modloader side, we already parallelized registration/loading even though that comes at some quirks modders have to be aware of. We can't do much about code outside of our control in mods that are increasing the load times.
* **maty** - While load times are not as fast as others might except, it is worth noting that improvements to loading times have been already made and will continue to be made (albeit they will not be that noticeable, as as mentioned above most slowdown comes from the huge amount of content in NeoForge modpacks and the code of mods) and loading times are already much better than in older versions

# Kotlin
## When will the FML rework start? There are so many issues with it currently, specifically with kotlin and libraries that depend on kotlin, you have to make so many workarounds. Why are you against supporting Kotlin for modding? Kotlin has a huge fan base and ecosystem and bundling it's standard libraries in every mod or depending on third party is a huge road block.
* **shartte** - has already started in more incremental steps with actually integrating those steps into NeoForge. First step was integration of ML/BSL/SJH into FML and has continued with removal of RuntimeDistCleaner
* **TG** - FML is being reworked slowly. I do not know how it will affect Kotlin. (Personal opinion and take, I think Kotlin mods make it harder for other people to help contribute or read your code or help you. So using Kotlin for modding is fine but comes with some downsides and I personally would recommend sticking with Java, especially for new modders joining)

## Do you plan to support Kotlin first party in the future? Have there been any discussions about maybe making Kotlin a first class citizen in terms of Language Loader and stdlib?
* **shartte** - no, shipping the Kotlin libraries is pretty massive (6.2MB) and once we ship Kotlin, fans of Scala will ask for their libraries to also be included again
* **Orion** - The know how on Kotlin in the team is to low - Additionally this would lead to expectations we simply could not full fill, especially in the area of surrounding tooling.
* **TG** - We will not ship Kotlin for it is a large library, would lead for other languages to be added, our team does not have enough Kotlin-knowing maintainers, and Kotlin does not have majority dominance in the modding community. Java remains the standard and recommendation for both ease of reading each other's code and easier assisting each other along with most documentation and examples being in Java.
* **maty** - Java is and will remain the recommended language mods should be written in - after all, Mojang uses Java. We will not ship Kotlin's massive libraries to all users (Forge has already made this mistake in the past with Scala) but we might consider a 1st party language loader for Kotlin. Importantly, this would be a mod users would download through CurseForge or Modrinth and that modders will depend on. It will not be bundled into default NeoForge installations.

## Would you consider adding a switcher to the Docs site to change Java code to Kotlin code?
* **Orion** - No. Kotlin is not an officially supported language.
* **IHH** - Besides not being supported, atm we also simply do not have enough people (I couldn't think of anyone?) that have sufficient Kotlin knowledge for this
* **TG** - We do not have any Kotlin-knowing maintainer/documentator. Furthermore, this will significantly increase the workload on our documentation team for what is really, a tiny subset of users. If you choose to write in Kotlin, knowing how to convert Kotlin code into Java code is a must. This is the tradeoff you choose when picking to mod in Kotlin. The burden should not be pushed to the ModLoader team as we can't write examples in every language one could use for modding. We do not have the manpower or time.
* **Champ** - I did this at one point for FCW (including Scala and Groovy) and even for other mod loaders, and basically, it was just removed in the end since no one wanted to maintain it. So no.

# Ecosystem
## What would it take for one universal modloader to break the split between neo and fabric?
* **Orion** - The sun moon and earth to be in the exact same spot
* **shartte** - Sinytra Connector? :-P
* **Monica** - Nothing could ever overcome this. Modloaders are like Marmite, or football teams: some people love them and will support them feverishly, and some people hate them and would rather see them gone.
* **TG** - I think having Fabric separate is fine. Different loaders have different niches they try to fill. NeoForge aims to be a more comprehensive and API heavy modloader. Fabric aims to be more lightweight and hands-off. There are reasons for both approaches and use cases. For example, if I recall, the speed running community prefers to use a minimal subset of Fabric to ensure the game's base behavior was not changed while Forge and NeoForge is avoid due to all the patches and possible changes we done.
* **Champ** - Ah yes, NeoForge: the new Fabric API mod /s

## Just a confusion in mod loaders. What mod loader you would recommend for what purposes? Like, as people say - fabric for lightweight modpacks, forge for heavyweight, and neoforge for what..? The same goes on with other mod loaders. Do you plan on making Neoforge universal for all kinds of modpacks?
* **Schurli** - Neoforge is a replacement for forge and I would personally never recommend content mods/packs for fabric
* **shartte** - Neoforge is suitable from the largest to the smallest pack, really. Just use whatever loader has the mods you wanna play. As a developer, look where packs are located you might wanna be in
* **TG** - NeoForge aims to be a modloader for all major use cases that modders and packmakers want. Fabric aims to be a more hands-off modloader to the modders themselves. But for advice of what to use, find the mods you want to play with and see which loader has the majority of those mods. That's the modloader to play. Really it boils down to mod choices when advising players of what modloader to play.
* **maty** - To add to what shartte said, also look at the features each loader providers and what features your mod might use.

## Can you make a loader or mod, that let's you use any mod, any version, any loader, be it neoforge, forge, quilt or fabric?
* **Orion** - Not without libraries
* **embeddedt** - This is incredibly difficult to achieve from a technical perspective, and even if it was possible, probably wouldn't have the desired effect (mods' gameplay design is usually tailored to the MC version they were made for)
* **TG** - Like Sinytra Connector but more insane? Sure someone could probably figure that out but the effort going into that would be incredibly insane, like not-in-our-lifetime insane.

## Is there a possibility (or maybe even internal plans?? :o) for integrated multiloader support a-la Architectury in the future, or is that too far outside NF's scope?
* **Orion** - Too far out of scope.
* **Monica** - This is more of a question for build tooling compatibility. Abstracting over multiple mod loaders like NeoForge and Fabric (in order to have a ""write-once run-anywhere"" codebase) would be akin to writing a new mod loader (XKCD standards propogation), and isn't worth our time.
* **TG** - NeoForge is a modloader for NeoForge mods. There's not multiloader support to add here. Unless you are talking about tooling, then in terms of MDG and NG, no Architectury is not something that would go into those toolings.

## Do you think there will ever be a point at which datapacks are as powerful as mods are? If so, will ModLoaders like NeoForge still get developed after this point, or even be as necessary as they are today?
* **Schurli** - datapacks will never be able to 100% replace mods but they will definitely be replacing some parts of modding
* **TG** - Datapacks will not be able to fully replace mods because mods wwill always have more power and flexibility as they can manipulate the very code itself. Instead, as more content becomes datapackable, modders will make use of them in the mods to ease developement to focus on the more complex parts of modding. In theory.
* **Champ** - I would say no. To make datapacks as powerful as mods are, the datapack would essentially be injecting compiled code at runtime, which just sounds like a nightmare.

## How did you feel when Sodium made an official NeoForge version? Did you happen to help its developer with something?
* **Orion** - as a team we are happy to have any mod on our platform and we are welcome to everybody
* **TG** - Sodium choosing to port to NeoForge was their decision. Many other modders made that decision as well. We seen quite a few modders switch from Fabric to NeoForge so this is not that strange from my point of view.

## Do you like CurseForge or Modrinth?
* **Orion** - As a team we do not have any preference for either platform. As long as it makes you as a modder happy, use what ever you prefer.
* **TG** - We have no favorites of one over the other. In fact, we encourage usage of CurseForge and Modrinth the most for downloading mods. Other sites are a bit iffy or sketchy. When uploading mods, you should stick to either CurseForge or Modrinth or both.

# Moderation
## What measures is the NeoForge team planning to take to tackle the constantly recurring issues of misinformation and propaganda being freely spread on the discord server?
* **Orion** - We address each on a case by case basis. We are aware that some other platforms do not allow talks about other platforms themselves, however we had a bad experience with that in the past. So for now we keep this an open area where we are still drawing lines
* **TG** - gonna say this is a case-by-case basis like Orion said. Please use modmail in our Discord server to report problematic conversations. This can be done by right clicking the message and clicking Apps and then Modmail option. Mobile requires long press on the message.

## How are you going to address the neoforge moderation team, as well as several other users engaging in activities propagating regimes that aim to suppress the rights and freedoms of individuals or that promote racial, ethnic or religious hatred?
* **Orion / SC** - We address each on a case by case basis. However there are internal discussions to apply stricter rules which would ban some off-topic discusisions. If you have any particular concern, please open a modmail message to us, and we will address it immediatly. Additionally if you think a particular conversation requires immediat attention of moderators then please ping them directly.
* **TG** - What Orion said
* **maty** - As a moderator, my opinion is that people should be allowed to discuss political topics so long as they remain civil and non discriminatory. Politics involve every single aspect of our lives and it is important that people have a safe space to discuss and express their opinions to avoid polarisation, which is especially present on more traditional social media websites. As always, if you feel like anyone crossed a line feel free to report the message to moderators through a ping or Modmail, or if you would like to keep the report anonymous, report it to an individual moderator or steering council member and ask them to not share the source of the report with other team members.

# Misc/Off-Topic
## When I use "What Am I Forging Up (WAIFU)" to find mods that use a particular class, I'm keep getting clouldflare timeout in the Method in "WAIFU Classes". Does the search has timeout enforced and how to overcome this?
* **maty** - Unfortunately, some queries can be very expensive if they involve highly-used classes, which may cause a timeout. You can keep trying until it works, or try using the API (which has a hard timeout, but can limit the amount of entries returned so you can paginate). If you still can't get the data you need, ask in the channel
* **TG** - What maty said

## How hard does the love/hate relationship with gradle lean towards either side?
* **Orion** - It is a tool. Nothing more. It is good in some areas, the worst in others. Some of the problems we have are not even caused by it, but by the IDEs.
* **TG** - Be me, avoid touching Gradle and cry when I do.
* **Champ** - I like Schrödinger's Elephant. Sometimes it works, sometimes it doesn't. Best to just nuke everything every once in a while.

## When will Neoforge use frog as the mascot ? Neofroge >>>>> Neofox
* **Schurli** - we will never replace our beloved fox
* **TG** - The fox is cemented as the logo for NeoForge and is permanent.
* **maty** - changing our branding after over 2 years is not a good idea, we've already built an association of the fox logo to our project. It is here to stay, probably forever
* **Champ** - Doesn't our fox go on holiday on April 1st? Though I think it's just replaced with Fox AI

## What's your favourite planet from Factorio: Space Age
* **IHH** - Vulcanus
* **Monica** - Aquilo is clearly the best, followed by Gleba. Everyone else is simply wrong :^)
* **Champ** - Fulgora, but mainly because it's the most unique imo
* **Rogue** - Not Gleba......

## On a scale of 1-10, what's everyone's favorite color of the alphabet? (Wrong answers only)
* **Orion** - Drölf
* **Monica** - 400nm
* **TG** - There's an alphabet?
* **Champ** - Popcorn
* **Rata** - Water
* **Nano** - Q

## When do we get complimentary breadstick
* **Orion** - When I get a complimentary Maß of beer on the October fest.
* **TG** - I can only offer imaginary ones.
* **Champ** - In exchange for a complimentary breadstick
* **Nano** - Regular, Garlic, Cheese-filled?

## Pineapple on pizza?
* **Schurli** - Is a crime
* **Orion** - against the pineapple
* **TG** - Nah plain for me.
* **maty** - The place of pineapple 🍍 is on pizza and I will die on this hill.
* **Champ** - Anything edible on pizza tastes good
* **Rata** - No...
* **Nano** - If you're going for a sweet pizza, pineapple is great. Now, the people that do stuff like peas or mayo, you crazy. (I recommend [Huggbees' video, "No One Can Decide What Pizza Is"](https://www.youtube.com/watch?v=eRPnkoRPwHo))