• 1

    posted a message on How can a "permanent" property be stored?

    Use WorldSavedData to store NBT information per-world (or per-dimension, depending on your needs).


    The readthedocs explain WorldSavedData here, and I have a (large) example here. Remember to call markDirty() any time you change a value that you want saved.


    Another way to do this would be writing a file to the world save folder, but trust me -- WorldSavedData is easier and more reliable.

    Posted in: Modification Development
  • 2

    posted a message on Thoughts on the future of modding.

    As a modder who started in 1.7.10 and has updated/built mods all the way to 1.10.2, here are my two cents:


    People who enter modding as a pasttime or a nice way to learn Java will often be discouraged. This was true for 1.7.10 would-be-modders and it is true of 1.10.2 would-be-modders.

    People who love coding and modding, on the other hand, will not be stopped, no matter how complex it becomes to make a "simple" mod. Personally, I enjoy the challenge of writing working code (and then transforming it into good working code) and work with whatever changes are made simply because I like trying.


    Was I excited by the JSON system and many rendering changes? No -- until I discovered the power of special models without a TESR or complicated vertex code. Was I excited by BlockPos and the need to change every single method signature in my block classes? No -- until I discovered the helper methods and convenience of such a container class. Was I excited by IProperty and IBlockState requiring several bridges just to get block metadata? No -- until I discovered how much easier it was to remember a property name than the significance of each bit in stair or door metadata (structure generation got a lot easier with that change). There are still some changes that I am not excited about, but I look at those as changes of which I have not learned the true power yet.


    What I'm saying here is that the people who sincerely enjoy coding and modding will find a way to use every change to their benefit. At the very least they will accept the need to work with changes instead of against them. The learning curve may be steeper than it once was, but for people who love learning and trying, that steepness makes no difference.

    Posted in: Modification Development
  • 1

    posted a message on Potion effect not spreading to players

    Side note: you can use player.getEntityBoundingBox().expand(int x, int y, int z) or player.getEntityBoundingBox().expandXyz(int) to easily get a resized bounding box.

    Posted in: Modification Development
  • 1

    posted a message on Potion effect not spreading to players

    If this is hard-coded to only support players, why aren't you using PlayerTickEvent ?


    It seems a little redundant (and possibly unreliable) to fire this for every EntityLivingBase when you only support players.

    Posted in: Modification Development
  • 1

    posted a message on Can I create and set variables for the server?

    If you want to avoid reading/writing files directly, you can add to the WorldSavedData and use the world's NBT data to save a boolean. I have one here.


    Make a class that extends WorldSavedData. You can use a helper method to get the current instance (like I do on lines 34-44), then call methods on that instance to set variables of any sort. You must call markDirty() every time you change a variable or it will not be saved. Override writeToNBT and readFromNBT to store and retrieve those variables, and you're all set :D

    Posted in: Modification Development
  • 1

    posted a message on Why 1.7.10?

    The main reasons anybody would mod for an older version include:

    1) There are many large mods that have not updated, but the modder wants both their mod and the old mod at the same time. This is especially common in large, popular modpacks, which may refuse to update until all those mods have updated... fat chance :P

    2) The modder is just starting and thinks 1.7.10 may be easier to code for (especially if they skimmed through the many anti-JSON posts about 1.8). Saying "1.7.10 is easier" is not entirely wrong, but not entirely right either. There are pros and cons, but I don't have time to address that argument.

    3) The modder thinks that Mojang's rapid-release of 1.9 and 1.10 means those versions are 'unstable' and constantly supporting the newest version would take too much work

    3) Like Bright_Spark said, they simply don't like newer versions of Minecraft


    That's all that came to my mind. My personal recommendation is this: if you fully plan on supporting 1.7.10, for whatever reason, start the mod in that version. Backporting is much harder than updating. However, if you are kind of thinking it'd be nice to have the mod in 1.7.10 but you want to support other versions too, start the mod in 1.9.4 or 1.10. (for anyone reading this after September 2016, those versions may be unsupported too)

    Posted in: Modification Development
  • 1

    posted a message on [SOLVED] Entity dropping exp orbs

    Custom damage type is a possibility. Make a static DamageSource, just like you would for other items, and apply that damage using your magic spell. To spawn XP orbs, handle the LivingDeathEvent, check if they died to that damage source, and spawn the xp.

    Posted in: Modification Development
  • 1

    posted a message on Hi, I'm pretty new to using packets and I've been getting a certain error a lot.
    @Override
    public void fromBytes(ByteBuf buf) {
        this.B = buf.readInt();
    }
    @Override
    public void toBytes(ByteBuf buf) {
        buf.writeByte(this.B);
    }

    This is your error. You're writing a byte but reading an int, and they are very different when every binary bit counts.

    Since this.B is of type int, you should use ByteBufUtils.writeVarInt(buf, this.B, 5) and ByteBufUtils.readVarInt(buf, 5) . The last parameter (5 in my example) represents how many bits (and thus the max size) you can write, and you might be safe passing 3 or 4, depending on how large you expect the int to be. Just make sure that both read and write use the same number.


    Read more about packets here.


    Edit: also, your packet registration is very inefficient. The whole point of using variableName++ is so you only need one variable and it is guaranteed to be different each time.

    Remove all but one of the packetIdXX and use just that one for every packet (using the ++ of course)

    One more note: if all your packets are very similar, why do you need more than one? At the very least you could use a base class for the variables and read/write, then just have different handlers...

    Posted in: Modification Development
  • 1

    posted a message on trying to make a packet that handels an entity it gets from UUID but keep getting EntityItem cannot be cast to EntityLivingBase

    Motion (and possibly position?) is actually mostly a client-side thing. It's possible that the values ARE being set correctly, but only server-side, and so your client doesn't show any difference.


    I suggest adding printouts after you send that message (both on client and server) so you know more about what's going on.

    Posted in: Modification Development
  • 1

    posted a message on trying to make a packet that handels an entity it gets from UUID but keep getting EntityItem cannot be cast to EntityLivingBase

    Use Entity#getEntityId() and World#getEntityByID(int) instead of looking them up by UUID. For one, UUIDs may not even be synced between the server and client, but the entity ID is. Jabelar has an example/tutorial here.


    Second, assign itr.next() to a value before using or checking it at all. Calling it twice does NOT return the same value each time! You check if itr.next() is instanceof EntityLivingBase, then cast the NEXT entity in the list to EntityLivingBase. See the problem?

    Posted in: Modification Development
  • To post a comment, please .