spawnerItem = new SlimeSpawnerItem(new EntitySlime(par2World))
par2World cannot be resolved to a variable. Please note that both these lines of code aren't in the same class... I don't know how I'll acess par2World
spawnerItem = new SlimeSpawnerItem(new EntitySlime(par2World))
par2World cannot be resolved to a variable. Please note that both these lines of code aren't in the same class... I don't know how I'll acess par2World
Make the variables public then access it from the class you want (I think)
Rollback Post to RevisionRollBack
If you thought something was missing in Minecraft, think again.
MoreMine is coming soon for Minecraft 1.7.10
Back to your original question -- yes you can have one class represent multiple different similar things. You just need to pass the differences in the constructor for the item, and then store them in local fields for that instance of the item.
In that tutorial, when I create the item instance to the constructor I pass a string for the name of the entity I want to spawn, and I pass the colors for the egg and spots.
So I only have one class, but can use it for multiple different entities.
Okay, I've officially came to the conclusion I need to learn java much more in-depth when I have more free time before I get into this stuff. Man, it's complicated. I can barely understand any of what you're saying Vic_.
If it were me I'd just use standard Java stuff instead of some runtime logic sorcery. Makes your code much neater, and it's faster (not by much, but still).
EDIT: Also you *need* to do subclasses in some things, TileEntities for example.
There was a time when wasting space in the id range was a bad thing and I still hold on to this practice even tho there aren't any ids left to be concerned of. Feel free to do it by instancing an Item type, It just doesn't feel right to me, I guess it's a style choice mostly.
Oh good point, more relevant before 1.7.x. I would prefer to subclass myself still, just easier to work with - but clearly a matter a taste. I can see how putting a bunch of items/blocks into one class keeping it compact has appeal, and I may very well do it one day.
Okay, I'll be honest with you, I didn't read the whole thread and all the comments. But here's what I would do:
First of all, create a new Item class.
package main;
public ItemEntitySpawn extends Item
{
}
Then for the constructor, you can have it like this.
private final Class<!--? extends EntityLivingBase--> clazz;
public ItemEntitySpawn(Class<!--? extends EntityLivingBase--> clazz)
{
//all the stuff you normally do for an Item.
this.clazz = clazz.
}
Then when you go to spawn the entity in the item use or right click function or wherever you spawn it. You can create the entity by using the class like so:
This will give you a new instance of whatever class of entity you put in.
Now to create the item, in your mod file (or wherever you create items) write:
Item pigSpawner = new ItemEntitySpawn(EntityPig.class);
Hopefully this will work. To setup the whole entity rotation and positioning to is doesn't spawn in the wall, look into the ItemMonsterSpawner class.
Thanks for reading!
Hope this helps! If not, let me know! I HAVE NOT TESTED THIS! It's just a way I would test it. If you already have something from this whole thread, and don't want to throw it away. Forget this comment and continue getting help on the other way you're doing it! Again, thanks for reading, Happy Modding!
You've given a great answer and it will work like gold, but I think he might want to just create tons of items, separately like:
Item item1 = new Item(...);
Item item2 = new Item(...);
Item item3 = new Item(...);
Mmm if it's a heck load of similar items then I don't see why you can't just have parameters to your constructor and use final class fields for the stuff that differs between each item. That's wise if all the items are functionally identical, but if they can have very different behaviors then it's more efficient to have a base class and extend it multiple times as needed. You could always do a combination of both too.
Mmm if it's a heck load of similar items then I don't see why you can't just have parameters to your constructor and use final class fields for the stuff that differs between each item. That's wise if all the items are functionally identical, but if they can have very different behaviors then it's more efficient to have a base class and extend it multiple times as needed. You could always do a combination of both too.
Yeah. It's not just for better performance, but it's just the right way to do things. If you have a variable that you only need to set once, make it final. Always make class fields final when possible, especially if they are read a lot. The Java JIT is stressed to heck by Minecraft, and these help a lot with it.
Another thing. If you access a non-final class field in a method more than a few times, it's technically better to assign that class field to a new local final variable. Reason is that a fetch from a local final variable is only one Java op, but a fetch from a class field is at least 2 ops. Assignment to a new local field is at least 2 ops. So say, if you've got a TileEntity or something that reads a class field 20+ times every tick (in onUpdate), *definitely* set it to a new local final variable at the top of onUpdate. Here's a technical discussion on this from StackOverflow if you want some more info.
Also, if you *assign* a class field immediately, it's good to make it static. E.g:
public class MyGui extends GuiScreen {
static final ResourceLocation MyGuiBackground = new ResourceLocation("mymod:textures/gui/mygui.png");
[...]
}
But I digress... a lot, again. Obviously, Java performance and convention are important to me - Modded Minecraft ain't getting any faster
To be honest, I don't care much about about assign performance (the difference here, one or two ops is like... nothing), there are more severe bottlenecks I have to fight, for example how to sync a circuit board without using a ridiculous amount of bandwidth, saving precious ram by using bitshifts, how to render a circuit board with 64 ^ 2 components and repetitive background without killing the performance or letting the ram usage explode... I wish I could care about one or two opcodes more or less!
I agree that when it comes to performance optimization, while it is good to keep it in mind during coding you shouldn't let it get in the way of proper coding style unless it is necessary -- and necessary means you have proven that it is actually causing performance problems.
Making unchanging class variables final is both proper programming and also better performance so is something definitely you should do as normal practice. However, the metadata strategy in Minecraft is an example where necessity (due to sheer number of blocks in the world) created a somewhat overly cryptic and limited approach -- default programming strategy would have used a much more readable and extensible way to store data per block, but they quickly realized that they needed a compact method like metadata.
I see a lot of people doing overly tricky things for "performance" on things that are not real performance issues -- things that are only done occasionally, etc. First principle of programming (in my humble opinion) is to create readable, simple, well structured code and only get tricky when pushed due to necessity.
because it gives the error "EntitySlime cannot be resolved to a variable" FFFFFFFF-
Here's the code for 'SlimeSpawnerItem':
Replace EntitySlime with
I'm working on an open-source mod called Craft++. Check it out!
par2World cannot be resolved to a variable. Please note that both these lines of code aren't in the same class... I don't know how I'll acess par2World
Make the variables public then access it from the class you want (I think)
If you thought something was missing in Minecraft, think again.
MoreMine is coming soon for Minecraft 1.7.10
If I helped you, hit that green arrow!
Look at ItemMonsterPlacer (mob eggs).
None taken, just trying to help. .-.
If you thought something was missing in Minecraft, think again.
MoreMine is coming soon for Minecraft 1.7.10
If I helped you, hit that green arrow!
You can check out my custom spawn egg tutorial here: http://jabelarminecraft.blogspot.com/p/minecraft-forge-1721710-creating-custom.html
In that tutorial, when I create the item instance to the constructor I pass a string for the name of the entity I want to spawn, and I pass the colors for the egg and spots.
So I only have one class, but can use it for multiple different entities.
EDIT: Also you *need* to do subclasses in some things, TileEntities for example.
Oh good point, more relevant before 1.7.x. I would prefer to subclass myself still, just easier to work with - but clearly a matter a taste. I can see how putting a bunch of items/blocks into one class keeping it compact has appeal, and I may very well do it one day.
But Java/Minecraft/CPU number of ops per cycle does :\
One improvement to the code would to replace: ArrayList spawndata = Lists.newArrayList();
With the generic version of ArrayList: ArrayList<EntitySpawData> spawndata = Lists.newArrayList();
This allows you to do: spawndata.get(I).id
Instead of ((EntitySpawData) spawndata.get(I)).id
[url=2482915-wip-arkcraft-survival-evolved-dinos-taming]
I was surprised how much you were able to do. I still haven't mastered putting more than one code segment in.
[url=2482915-wip-arkcraft-survival-evolved-dinos-taming]
Then for the constructor, you can have it like this.
Then when you go to spawn the entity in the item use or right click function or wherever you spawn it. You can create the entity by using the class like so:
This will give you a new instance of whatever class of entity you put in.
Now to create the item, in your mod file (or wherever you create items) write:
Hopefully this will work. To setup the whole entity rotation and positioning to is doesn't spawn in the wall, look into the ItemMonsterSpawner class.
Thanks for reading!
Hope this helps! If not, let me know! I HAVE NOT TESTED THIS! It's just a way I would test it. If you already have something from this whole thread, and don't want to throw it away. Forget this comment and continue getting help on the other way you're doing it! Again, thanks for reading, Happy Modding!
Hello!
Item item1 = new Item(...);
Item item2 = new Item(...);
Item item3 = new Item(...);
etc..
But great answers!
Hello!
I took Java in school, but that was awhile ago, so I just looked up why you would use a final class fields.
I found this tutorial that explains it well: http://javarevisited.blogspot.com/2011/12/final-variable-method-class-java.html
[url=2482915-wip-arkcraft-survival-evolved-dinos-taming]
Yeah. It's not just for better performance, but it's just the right way to do things. If you have a variable that you only need to set once, make it final. Always make class fields final when possible, especially if they are read a lot. The Java JIT is stressed to heck by Minecraft, and these help a lot with it.
Another thing. If you access a non-final class field in a method more than a few times, it's technically better to assign that class field to a new local final variable. Reason is that a fetch from a local final variable is only one Java op, but a fetch from a class field is at least 2 ops. Assignment to a new local field is at least 2 ops. So say, if you've got a TileEntity or something that reads a class field 20+ times every tick (in onUpdate), *definitely* set it to a new local final variable at the top of onUpdate. Here's a technical discussion on this from StackOverflow if you want some more info.
Also, if you *assign* a class field immediately, it's good to make it static. E.g:
But I digress... a lot, again. Obviously, Java performance and convention are important to me - Modded Minecraft ain't getting any faster
I agree that when it comes to performance optimization, while it is good to keep it in mind during coding you shouldn't let it get in the way of proper coding style unless it is necessary -- and necessary means you have proven that it is actually causing performance problems.
Making unchanging class variables final is both proper programming and also better performance so is something definitely you should do as normal practice. However, the metadata strategy in Minecraft is an example where necessity (due to sheer number of blocks in the world) created a somewhat overly cryptic and limited approach -- default programming strategy would have used a much more readable and extensible way to store data per block, but they quickly realized that they needed a compact method like metadata.
I see a lot of people doing overly tricky things for "performance" on things that are not real performance issues -- things that are only done occasionally, etc. First principle of programming (in my humble opinion) is to create readable, simple, well structured code and only get tricky when pushed due to necessity.