Jump to content

Draco18s

Members
  • Posts

    16559
  • Joined

  • Last visited

  • Days Won

    156

Posts posted by Draco18s

  1. 2 hours ago, Syric said:

    Does anyone know if there's a way to make a particle render after blocks do?

    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.

    2 hours ago, Syric said:

    but those new faces also render from outside the block, which really negates the whole HalfTransparentBlock business.

    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)

  2. 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.

    Color_Space.jpg

  3. The problem is that 3d graphics are all built with triangles, so you can't get a hue-tinted diagonal line when the end points are black and white.

    You need to construct the quad in such a way that the diagonal edge uses the other two corners (you should be able to do this simply by moving your first vert to be last, or vice versa).

    • Like 2
  4. 3 hours ago, CoddingDirtMC said:
        private void setup(final FMLCommonSetupEvent event)
        {
            // some preinit code
            LOGGER.info("HELLO FROM PREINIT");
            char[] ca = {'g', 'o', ' ', 'm', 'y'};
            String c = Character.toString(ca[0]).toUpperCase();
            System.out.println(c + " is c");
            char[] newc = c.toCharArray();
            ca[0] = newc[0];
            System.out.println(new String(ca));
            LOGGER.info("DIRT BLOCK >> {}", Blocks.DIRT.getRegistryName());
        }

    By the way, why do you have this?
    It does nothing useful.

  5. Forge has used official Mojang names since about 1.17 (I think late in the 1.16 cycle it switched).

    However, 1.8.x is no longer supported. Regardless, Mojang was not publishing a deobfuscation map back then, so only MCP names exist.

  6. Minecraft builtin recipes don't work this way.

    One option I can think of is to create an "uncooked jerky" item that only exists to be on the campfire and find a way for your beef strip item to place four of them into the campfire when used, rather than placing itself. You'll have to see how the campfire accepts items and find a way to inject a different item than the one you're holding (and then do it four times, rather than once). That uncooked item is then the one that gets cooked (and the only way to obtain it normally would be to pick it up off the campfire before it's done cooking / break the campfire). Of course this takes up all four cooking slots.

    Alternatively you could have an intermediary "cooked beef strip" item that when picked up or dropped turns itself into four beef jerky (there's hooks for both of these actions, I'm pretty sure--OnEntityUpdate is the one for it being dropped on the ground though its Mojang name might be different, not sure about picking it up, but there should be some kind of Item method or Forge event that would work).

    Or you treat the act of eating as durability loss rather than item consumption (but this effectively lowers max stack size to 4).

  7. 11 hours ago, diesieben07 said:

    No, LootTable#getRandomItems already does that.

    👍

    Haven't traced all the calls lately, as I haven't been doing any active modding.

    33 minutes ago, Sweetmimike said:

    And for the looting enchant ? It seems to not be considered

    I believe that is a separate context entry.

  8. TLDR, in order to generate loot from a loot table you need to pass in all of the relevant context for that kind of loot table, because "I just need cow loot" requires knowing if the cow was on fire. And if the player was holding a sword with the looting enchantment.

    Etc etc etc.

    So you need to specify where the loot is being dropped, who cause it to drop, what is being dropped, and so on. All of that it put into the loot context builder.

    Look for existing usages of LootContextParamSets

    (Oh and be sure to pass the result through ForgeHooks.modifyLoot)

    • Like 1
  9. Not sure, I haven't dug into the minecart code that much.

    The only problem I see is that this:
    Math.pow(targetVelocity, 2) - Math.pow(entryVelocity, 2)
    Is guaranteed to return a negative value, which when multiplied against entity motion would cause the entity to reverse direction.

×
×
  • Create New...

Important Information

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