Jump to content

Draco18s

Members
  • Posts

    16551
  • Joined

  • Last visited

  • Days Won

    155

Everything posted by Draco18s

  1. It also leads to everyone writing their own API addons that duplicate efforts and makes things incompatible with each other because everyone creates a patch that does what they need and only what they need. It also means that when Minecraft updates if you have a mod that relies on one of these additional specialized APIs, you have to wait on that author to update it, even though Fabric's main API is already current. Neither Waila nor JEI require additional source patches to work with Forge. They have their own APIs, yes, but that's not what I'm referring to when I say that Fabric requires modders create additional hooks inside vanilla code. Forge makes sure that every mod stays well out of vanilla code so that mods don't conflict with each other and crash the game. I'm referring to this: https://fabricmc.net/wiki/start#mixins_asm Fabric pushes modders towards ASM. ASM is dangerous, complex, and highly fragile. It can lead to code that crashes code that isn't your code with the resulting stack trace having no evidence as to which mod caused the issue! It can DO anything, but it doesn't do it safely.
  2. AH HAHAHAHAHA! 🤣 No seriously though, the two ecosystems are so wildly different that it wouldn't be so much a "port" as "rewritten from scratch." Forge: make everything compatible because no one touches vanilla code directly. If Forge doesn't make what you need possible, make a PR. Fabric: we can update to new versions quickly because we only have the basics. So if you need something special, you're going to have to patch the vanilla code yourself, have fun~!
  3. A Double (with a capital D) absolutely can be null, because it's an Object that boxes a double (lower case d).
  4. Nope, that class looks fine. Did you register the serializer? Did you add it to the forge/global_loot_modifiers.json list?
  5. You have an error on line 85 of CopperKilnGuiMenu
  6. BlockPos.GetAllInBox, or whatever mojang called it. It literally gives you an iterable that solves this.
  7. That only gets you LOGS and PLANKS, he doesn't want to know if the item is wood, he wants to know if it's made of wood. Example: jungle door. Jungle Door is made of wood, but is neither a log nor a plank. Doing it with tags, and not creating a new tag, you'd have to check: logs planks wooden_buttons wooden_doors wooden_fences wooden_pressure_plates wooden_slabs wooden_stairs wooden_trapdoors And possibly still have to check for other blocks like ladders. I'd even go so far as to say the tag mineable/axe would cover it, but it's more like "everything in mineable/axe except..."
  8. "Exit Code -1" is just the "application closed with an error" message, it is not itself the error. Post the whole log.
  9. Well. Yes. Blocks aren't meant to take up visual space outside their 1x1x1 cube. Two vanilla blocks have this issue as well. https://bugs.mojang.com/browse/MC-158827?filter=-2
  10. Kinda sorta. Don't catch fatal errors. Don't create boneheaded errors in the first place so you don't need to catch them. Exogenous you must catch, while vexing are...well, vexing: the product of unfortunate design decisions that may (or may not) have a Try alternative that doesn't throw an exception when there's a problem, but if not, the exception must be caught. https://ericlippert.com/2008/09/10/vexing-exceptions/
  11. Compare a stored worldtime to the last-checked world time. If different, you know it hasn't ticked any times, if it has, it's ticked at least once.
  12. My info* I looked at the code for it back in 2013, which was in the linked bug report. Warjort just rephrased it. That's what I thought, but I wasn't sure if you meant like carpets or like snow layers where you can make the block thicker, but still take up less than a full block.
  13. https://bugs.mojang.com/browse/MC-1127 Resolved as "working as intended" Clarification required.
  14. It's a logged bug that's existed since...basically forever. I'd get you a link, but the bug tracker is undergoing maintenance.
  15. https://docs.minecraftforge.net/en/1.19.x/concepts/events/#creating-an-event-handler
  16. Maybe set the Notify_Client flag? (which is 2, so you want to pass 3 here) Also, rather than using ints, use the proper enum object.
  17. https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/client/ProspectorParticle.java#L46 Mind, that's old code and there's almost certainly a vanilla class wrapper method that does the same thing. Note that this will cause the particle to always draw on top of blocks, even opaque ones. So you might want to clarify a bit. Right right. I know water does what you want, but its been a while since I looked at the fluid render code (as in, I fixed the issue you're having on Forge fluids back on like 1.6.4 or 1.7.10)
  18. You need the faces to be double sided. I'm not sure how this is done with the json format, however.
  19. Yeah, because the real gradient (that you want) isn't truly linear across the diagonal.* It's close though. The only way to get it to be smoother is to...break things into smaller triangles so you have more control points. But it also gets more complicated to set that up, as you have to compute the location and vertex color value yourself. *This is actually a color-space problem with respect to how our brain interprets color.
×
×
  • Create New...

Important Information

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