Jump to content

(1.16) When updating environment variables (PATH) is needed


Recommended Posts

Posted

I'm trying to write some tutorial/advice articles for Minecraft modding for 1.16. I'm a technical writer and have a few of my own mods under my belt. I've seen some older tutorials that tell you to add the path of your Java JDK installation to your environment variables. I don't recall having to do that when I started modding, and my general understanding is that the environment variables are mostly a convenience so you don't have to use the full path of an exe on the command line. So I was wondering if you really need to do anything with environment variables for modding and if so what situations it might be needed. Does it depend on your OS, JDK version, IDE, or what? TIA.

Posted
16 hours ago, Daeruin said:

So I was wondering if you really need to do anything with environment variables for modding and if so what situations it might be needed.

Not really. If you set up your JDK with no modifications, it will still point to the JDK. The path variable is pretty much just a list to which the first entry that matches the requirements will be chosen. If I had two JDKs for two different versions on the path, whichever one is at the highest priority or the top of the list will be chosen. On the other hand, I can force a specific JDK to be chosen using the JAVA_HOME environment variable which tells the program exactly where to look for the JDK. If at least one of these two are set, you should be able to mod with no issues. There is no real dependency on any underlying system for modding, just the JDK you are using (which should be 8 as that is what is shipped with vanilla).

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • @Tsuk1 Also, new note, you can use blockbench to make the custom item model for when it is not on the head.   EDIT: Funny story, I am making a mod similar to yours! Mine is called NorseMC.
    • @Nood_dev Could you send a screenshot of your weapon code? Here is the one I made (for a dagger): The specific UUID does not matter, just that it is the same every time, which is why UUID#randomUUID does not work public class DaggerItem extends TieredItem implements Vanishable { protected static final double REACH_MODIFIER = -1.5D; protected final Multimap<Attribute, AttributeModifier> defaultModifiers; protected final UUID BASE_ATTACK_REACH_UUID = UUID.fromString("6fe75b5c-9d1b-4e83-9eea-a1d5a94e8dd5") public DaggerItem(Tier pTier, int pAttackDamageModifier, float pAttackSpeedModifier, Properties pProperties) { super(pTier, pAttackDamageModifier, pAttackSpeedModifier, pProperties); this.attackDamage = (float) pAttackDamageModifier + pTier.getAttackDamageBonus(); ImmutableMultimap.Builder<Attribute, AttributeModifier> builder = ImmutableMultimap.builder(); builder.put(Attributes.ATTACK_DAMAGE, new AttributeModifier(BASE_ATTACK_DAMAGE_UUID, "Weapon modifier", this.attackDamage, AttributeModifier.Operation.ADDITION)); builder.put(Attributes.ATTACK_SPEED, new AttributeModifier(BASE_ATTACK_SPEED_UUID, "Weapon modifier", pAttackSpeedModifier, AttributeModifier.Operation.ADDITION)); // THE ONE YOU WANT: builder.put(ForgeMod.ENTITY_REACH.get(), new AttributeModifier(BASE_ATTACK_REACH_UUID, "Weapon modifier", REACH_MODIFIER, AttributeModifier.Operation.ADDITION)); this.defaultModifiers = builder.build(); } @Override public Multimap<Attribute, AttributeModifier> getDefaultAttributeModifiers(EquipmentSlot pEquipmentSlot) { return pEquipmentSlot == EquipmentSlot.MAINHAND ? this.defaultModifiers : super.getDefaultAttributeModifiers(pEquipmentSlot); } }
    • https://images.app.goo.gl/1PxFKdxByTgkxvSu6
    • That's what we'll try out. I could never figure out how to recreate the crash, so I'll just have to wait and see.
    • Ok, I updated to the latest version and now the models are visible, the problem now is that the glowing eyes are not rendered nor any texture I render there when using shaders, even using the default Minecraft eyes RenderType, I use entityTranslucent and entityCutout, but it still won't render. Something I noticed when using shaders is that a texture, instead of appearing at the world position, would appear somewhere on the screen, following a curved path, it was strange, I haven't been able to reproduce it again. I thought it could be that since I render the texture in the AFTER ENTITIES stage which is posted after the batches used for entity rendering are finished, maybe that was the reason why the render types were not being drawn correctly, so I tried injecting code before finishing the batches but it still didn't work, plus the model was invisible when using shaders, there was a bug where if I look at the model from above it is visible but if I look at it from below it is invisible. So in summary, models are now visible but glowing eyes and textures are not rendered, that hasn't changed.
  • Topics

×
×
  • Create New...

Important Information

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