Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 12/18/18 in all areas

  1. Just venting off some thoughts i have after reading about the release of yet another modloader, Fabric, this time for 1.14 (snapshots) - just asked the same thing on FTB Reddit too... Wouldn't all that new modloaders (Rift for 1.13, Fabric for 1.14) fragmentate the modding community as time goes on? Not only on different software, but also in versions (one modloader per version, etc)... Forge is going through a challenging time by all those changes necessary for future updates, and its very solid and capable, plus this isnt the first time devs needed more time to work in an update. But this scenario (others trying to make alternative modloaders with such voracity) never happened before, at least what such strength (liteloader was a lonely happening in 1.6). Should i, as a modded player, be worried about all of this? From what i read in Fabric release on FTB reddit, they arent sure it will be compatible with Forge at all. And for the modders on the forum: did you think people will "return" to Forge as soon new builds came off? Anyway, thanks to open the space for us to talk about...
    1 point
  2. First of all NEVER EVER register things like this. If you have to access the registry directly then you are doing something VERY wrong. Use the appropriate RegistryEvent.Register<T> event and use the registry provided to you in that event. Second of all this is not enough information for the EntityEntry. You at the very least also need to provide the tracker data and the registry name/ID. Thirdly don't construct EntityEntries directly. Use EntityEntryBuilder. Your entity doesn't exist on the client because you didn't register it correctly.
    1 point
  3. Considering that you need to do this on client only the best course of action would be to set the value of GameSettings.keyBindDrop field to your custom implementation that returns false when needed in KeyBinding#isPressed.
    1 point
  4. Would need to see your code, but custom SoundEvent objects should be registered via a registry event, similar to custom Block or Item objects. As an example: https://github.com/TeamPneumatic/pnc-repressurized/blob/master/src/main/java/me/desht/pneumaticcraft/lib/Sounds.java (the RL() method in there is just a convenience method to get a ResourceLocation with the mod's domain). See also https://mcforge.readthedocs.io/en/latest/effects/sounds/. Note that SoundType and SoundEvent are not the same thing, but you seem to be conflating them a bit here.
    1 point
  5. The problem with most alternative mod loaders, is that they are created out of spite with "Fuck Forge" as their motivation. But then they use our tools, our data, and our work to make their system. That's the thing that pisses me off about things like Rift. I have not looked at Fabric so i can't comment on what they are doing, or if they are doing it correctly/legally. However, I would also advise against using any loader that "gives the hooks to the users", by "exposing" mixins and encouraging the average user to use it. Because that flat out won't work. The reason Forge has compatibility with so many mods is because we've cultivated all the internal hooks as clean changes that make it so modders DON'T have to break things in MC code to make their mods work. So you can get a couple nice mods yes, but it'll become difficult when you start trying to create modern mod packs. As for updating to snapshots. I update the mappings internally when I get time cuz I like seeing what has changed. I would LIKE to make those mappings public but it isn't worth doing as they are not the highest quality and we loose a lot of information. I am looking for people who are willing to help create open source versions of some of the internal tools I use {which I did not create and thus is not my place to release} as well as a better three way binary mapping generator.. If anyone actually wants to help out on that, hop on discord either Forge's or sponge's and we can talk... Anyways, using 3rd party smaller loaders just to explore the new vanilla code is fine. But do not expect stable or useful releases from those.
    1 point
  6. Thanks Cadiboo for the answers (dont know why the forum doesnt notificate me before)! After so much pain in replacing Bukkit i will not risk to rely on Rift mods in my modpack, so will stick on Forge 1.12.x until 1.13 comes and, just for sake of curiosity, i will test Fabric and ComputerCraft for 1.14 snapshots.
    1 point
  7. These small loaders give Modders and players the ability to preview and get a feel for the new versions, but their purpose is definitely not to replace Forge. At this point Forge is pretty much a proper API. Also, Rift has legal problems; and Fabric is recreating all of the MCP mappings to avoid some of those legal problems. Both loaders are encouraging Modders to use coremods (mostly Mixins) to add features, a thing Forge discourages. This isn’t necessarily a bad thing, with Modders (hopefully) gaining more knowledge about how java works and what their code does. However, obviously coremods have a bit of a tendency to blow up unexpectedly (especially those created by people new to coremodding), so a large amount of coremods being created for 1.13+ isn’t great. Also neither modloader provides an event based API (one of the best features of Forge IMO) though Rift has expressed interest in providing one. I know that my mods will definitely “return” to forge within very short period of its official 1.13 release
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.