1
I mean correct me if I'm wrong but i think sky is trying to say you need to loop through the players inventory to find an instance of redstone(an itemstack) then use that to remove one item every whatever seconds.
Just cause you know the item is there doesn't mean you have an actual itemstack for that item.
1
Inside the preInit method of your main class , after you register your mob, place this line:
EntityRegistry.addSpawn(LDEntityInfected.class, [spawn frequency, try 10], [min spawn at once], [max spawn at once], [creature type], [biome to spawn in]);
The min and max spawn at once represent how many of your mob will spawn in a group.
Creature type can be any of EnumCreatureType, such as EnumCreatureType.monster, which gives it attributes like a monster, such as spawning only at night.
The biome to spawn in is one of BiomeGenBase biomes, such as BiomeGenBase.plains (You can find a list in net.minecraft.world.biome)
If you want to spawn the mob in all biomes, use this instead
for (int i = 0; i < BiomeGenBase.getBiomeGenArray().length; i++)
{
if (BiomeGenBase.getBiomeGenArray()[i] != null)
{
EntityRegistry.addSpawn(LDEntityInfected.class, [spawn frequency, try 10], [min spawn at once], [max spawn at once], [creature type], BiomeGenBase.getBiomeGenArray()[i]);
}
}
1
Personally I've moved on from 1.7.10 long ago. The new updates mainly brought the new combat mechanics, which have changed the way you fight quite a bit. But I think it's that which is why so many stuck with 1.7.10. They think the new combat mechanic is bad and they don't like it so they stay in the version before it was added. However, remember when the bows shooting was changed ages ago? That was an awesome change, yet nobody complains anymore. If anything, it was pretty OP before, but now it's much more balanced - and that's what the new combat mechanics bring.
I only see reason to move on from 1.7.10 - modding in the later versions is much easier and better... so I don't see why anyone would want to continue modding in that version. I'd strongly advise anyone still in that version to move up to 1.10.2.
1
Check in the entity's onImpact method if it has hit a block of tall grass.
2
2
It's pretty easy.
Firstly you need an item with a max damage of 4, and set its max stack size to 1.
You'll then want to override onItemRightClick so that you can make things happen when you right click the item.
So to damage your item, you can use ItemStack#damageItem.
To heal the player, you can use EntityLivingBase#heal.
The item stack and player are given as parameters to the method.
1
Another way of finding the items would be to use an item you right click at where the item entities are. You can then use that to ray trace to the hit block, find the items around it and do something like what Choonster has suggested above to check for all items you want being there to then craft. Having some sort of trigger is the most efficient way of doing this, as checking ALL entities in the world is very processing intensive. So an item or a block (like suggested by Alpvax) used to trigger the crafting would be one of the best, and probably easiest methods.
2
Bloody stop with "I want to make trains". If you don't even know how to make a decent ore generation mod (which is the most basic thing), you won't be able to make a train mod that needs REAL coding.
Just stick to the other train mods. Modding is something more than just clicking buttons.
1
No worries! Was hoping you'd catch on to that. Programming is a skill that comes with time, just like anything else - it might feel like you're getting in over your head, but just keep practicing like this and you'll start to catch on to newbie mistakes like that.
2
Returning a random textures from Render#getEntityTexture would cause the mob to choose a random texture each frame.
Instead, store the variant/texture index in the entity's DataWatcher (1.8.9 and earlier) or EntityDataManager (1.9+), set it to a random value in EntityLiving#onInitialSpawn, read it from/write it to NBT and use it in Render#getEntityTexture to determine the texture to use.
Horses, rabbits and sheep use this technique to select a random breed/colour when spawned.
In future, please specify the Minecraft version you're using in your title.
1
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.
2
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.
1
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.
1
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.
1
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
1
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
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)
1
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.
1
@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...
1
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.
1
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?