jabelar

I'm not at my computer with code so I can't confirm, but I'm pretty sure I put a setCreativeTabs() method in the block class constructor, or at least for items I do that.

Where exactly are you putting your code to change harvest level? Your statement is a bit ambiguous when you say you attempt to change it in the initTools() method. Do you mean you're editing the ForgeHooks' actual initTools() method by adding the code you wrote? Or did you try to do it in the main class of your mod? Or in the postInit() event? I'm assuming it is ultimately a matter of timing on when your code is run versus the ForgeHooks' static initializer that contains the initTools() command. Did you try doing it in postInit() event handler?

I depends on whether you're interested in likely scarcity (i.e. based on probability of it being generated) or whether you're interested in actual scarcity. For likely scarcity, like mentioned above just look at the code for the decorators and see what chance of generation is. For actual scarcity, I think you could pick a range and check all the blocks within the range for specified type. You wouldn't want to do this often, but could do it occasionally based on currenly position, or as each chunk is generated or something. There may be a good way to get a count of a specific block (I know you can get counts of specific entities) but you could implement that yourself by doing something like checking area within certain range of the player and use World method getTopSolidOrLiquidBlock() and then check each block with getBlockID() method and keep going downwards until you get to bedrock. If you're looking for multiple types of blocks, you can increment the count of each type during the scan of the blocks. So basically, create int counter variables to keep track of what you find, use for loops to loop through a range of x and z positions within a range, find the top solid or liquid block in each position, loop down to bedrock in that position incrementing the counter variables for each thing you find.

Does the /summon command also rely on global ID? I didn't have luck in having it summon my custom entity registered with modEntity registration, but works fine with globalID registration.

Most of the AI I've done have been pretty simple modfications (like making entities target different things than vanilla entities). However, I do suggest you use the AI tasks list method. Look at a class like EntityWolf to see how the list is created. Then you further want to create your own AI class that extends AIBase and then put that in the AI tasks list of your entity. In your AI class you'll have to put in whatever code you want to control your Entity, but if you want it to move you can have it check for a free path in the direction you want to go and then update the position over time accordingly. To get started, you can make a simple AI that will cause it to move upwards a few blocks from where it spawns. Basically you can just have a starting Y position saved in a variable of the Entity constructor and then in your task you can update the actual Y position until it is some number higher. That should get it off the ground at least.

But something is wrong because I don't see the modEntityID registrations ever show up in EntityList. I created a method to print out the EntityList after I registerEntities and it doesn't show any entries for my entities. Here is the EntityList after my registration (none of my entities are listed): And here is my code for the registration. Main class preInit(): And my commonProxy class: However, if I change the CommonProxy to use globalID then I get the following EntityList readout that shows my entities nicely registered: Where my CommonProxy was now: So I really don't see the modEntityID registration adding my entities to the EntityList. Or does it do it at some other range beyond id = 255?

This is totally correct. Also, while it doesn't give you a vanilla egg, it doesn't stop you from making one. The lazy step would be to register a global entity id and add it to the vanilla egg list. (but then the local id registration is far less interesting) Another solution is to create your own egg, like any item (see ItemMonsterPlacer, though you'll need to replace the global entity id lookup with either entity name or local id). Another solution is to use events and spawn the entity yourself. I've been experimenting and like you and CoolAlias said it seems that vanilla eggs definitely require a globalID. I like the idea of only worrying about mod-specific ID since it seems like better programming practice. But in addition to not having spawn eggs (I wouldn't mind making my own if that was only thing), it seems that the natural spawn registrations also use globalID. So you'd have to make new natural spawning methods too?

Thanks. That is in line with case #4 (use both but different ID numbers). I do know about the parameters (distance to render, frequency of updates, velocity updates). @Jacknoshima You didn't have to look at the link because I quoted the specific advice. Note that the advice was from CoolAlias who I greatly respect. The key difference is that the id is different in the two registrations. In particular this meshes with the explanation in the second link that indicates that the mod entity registry is meant to be unique id within your mod -- doesn't need to be globally unique. I think method 4 (CoolAlias' suggestion, and backed up by McArcane) is technically correct, but 3 happens to work because if your global id is unique then your mob entity id will be unique too so no real problem created. I can't quite ignore these because even though they are older they each have a registration method that is different, and now we're supposed to use both? I understand if there is a newer method that replaces an older one, but it seems strange to me that the new method would be to combine both older methods. Also, the explanation in the second link is quite interesting and makes sense to me -- that the mod id is meant to get away from the trouble of the mod programmer worrying about globally unique id. While there is a method to find a globally unique id, there is another limitation with the global entity list related to it being limited to 255 entities (due to a byte cast on the id in the packets). If I look at the related mob spawn packet methods in 1.7.2 there is still a byte cast, so seems like that limitation is still present. Lastly, the weird thing to me is that ALL these methods kinda work when I try them. I tried all the scenarios, and in every case the entities are created, spawn, act on their AI, have NBT and restore from saves, etc. I would understand it better if skipping either of the registries prevented the spawn, since then it would imply that you need them. Just strange that it is hard to notice any difference in behavior between the cases. I guess I'll do some experiments to figure out what behavior is explicitly enabled by each registry.

Okay, I'm getting confused between the use of the EntityRegistry.registerGlobalEntityID() and the EntityRegistry.registerModEntity() methods for entity registration because I looked at four tutorials that give conflicting advice... A tutorial here (http://www.minecraftforge.net/wiki/How_to_register_a_mob_entity#Registering_an_Entity) indicates to only use the registerGlobalEntityID(). It says: A tutorial here (http://www.minecraftforum.net/topic/1417041-mod-entity-problem/page__st__140#entry18822284) says to only use registerModEntity(). It says: At tutorial here (http://www.minecraftforum.net/topic/2389683-172-forge-add-new-block-item-entity-ai-creative-tab-language-localization-block-textures-side-textures/) says to use both methods, but to use the same entityID for both. It says: A message here (http://www.minecraftforum.net/topic/2564566-172spawning-my-entity-on-top-of-another-one-crashes-game/)indicates to use both methods, but use different ID in each: So which way is correct? The weird thing is they all kinda work -- I tried all three and can spawn the entities -- but I assume there is some invisible bad stuff going on if you do it the wrong way.

Thanks for the feedback. Yeah, there is usually a side effect when doing something unorthodox. I'll probably continue to hardcode until it becomes an issue. For now my mods are mostly just for personal use, but maybe if they start being used publicly I'll need to do the work to ensure compatibility.

I just try things and if they don't work then I have to understand since it means I must be missing something. In this case it is really interesting -- I tried overwriting the modmetadata with credits and description and it didn't work (in the launcher mod list it just complained about missing mod info file). So then I got worried about my understanding of Java because I thought it should work. After discussing with you I got confident that it should have worked after all, so I looked at it again... It turns out that there is another field called autogenerated which needs to be set to false in order for it to skip looking for mcmod.info file. Once I set that it worked!! So basically I didn't like having something that I thought should work not work, but I also admit that I find the mcmod.info file annoying. So for anyone that is interested (I'll post something else about this, maybe a tutorial), you CAN hardcode the mod info as long as you set the autogenerated to false. For example:

Thanks. I definitely understand it now. Seems like a dangerous sort of approach compared to some other programming languages where you would at least be explicit with pointers and such to distinguish whether you just want a copy versus access to the actual field in the other class. Okay, since it sounds like you CAN edit the private variables once they are passed in a return of a method, then what do you think of the idea of hard-coding the mod info as suggested in the web link at the top of this thread? I tried it briefly but didn't see it work ... but maybe I'll play around more with it.

Thanks. That is along the lines of my understanding of the pass-by-value idea of Java, except that the passing of a private variable still seems strange to me. So I think you're saying: If Class A has private variable privVar1 and if I pass it to a method in Class B, then Class B can modify the value in Class A if it wanted to. Similarly, if Class B had a private variable and returned it in a method called by Class A that Class A could then modify the value in Class B if it wanted to.

I saw a web page that claims you can directly hardcode the mod info rather than rely on an mcmod.info file. (http://minecraftforgetutorials.weebly.com/hardcoded-mod-metadata-aka-virtual-mcmodinfo-file.html) The idea is that the FMLPreInitializationEvent event actually has a mod container with such info in it and there are some methods that look like you can access them. Here is the vanilla code for that event: Now the web page claims than in your preInit method you can edit the mod info like However, this seems strange to me because the getModMetadata() method returns a value from a private variable in the event class. So I don't see how you can edit further attributes of what is returned -- basically I thought you need to have a set method in order to set private variables in a class. I guess I've dabbled in too many computer languages because I realize I'm not confident in my understanding of this. But can you really manipulate a private variable outside the class if it is returned from a method in the class? Also, the recommended method didn't work for me anyway, so I'm doubly suspicious of the recommendation ...

Actually you seem to be on to something with your question about any interaction between entities. I found that if I try to spawn my custom entity on top of one that already exists (even just clicking spawn egg one at a time) I get the same crash. I don't know that I have any special code related to this -- my entities are basically wolves but with tiger textures. But maybe I'll go through my AI bit by bit enabling/disabling to see if anything seems related. Anyway, thanks I think this gives me something to dig into.

Okay, I take it back -- it seems that the constructor is being called twice per spawn. I assume that it is on each of the Client and Server side, I'll put in some debug messages in a sec. Why do you say register in ClientProxy? Did you mean ServerProxy so it is only on server side?

How would I check? All I do is register the spawn in my CommonProxy. That seems to create a spawn egg in the Miscellaneous tab of the creative inventory. When my entities spawn I have a console print that indicates that the constructor was called. I only see it being called once, so I think it is only being called on one side. I guess I can add to the print to see what side it is being called on. Also, as I mentioned, I can spawn the entities one at a time with the spawn egg just fine. In particular, why are you asking about the server side: 1) should I only register the spawn on one side? 2) should the spawn happen on server or client? I'm assuming it should happen on the server, right, since the server keeps track of the game world?

Bump. Sorry for bumping, but I still need help on this one. The error unfortunately doesn't give me a lot of ideas on where the problem may lie. The thing is that at one point this worked, I could spawn lots of my EntityTiger including the baby ones, but now all my entities invariably crash the game when spawning multiples from the spawn egg.

I kinda figured that was what you were getting at -- distiguishing between where it is installed/compiled for versus run-time "happens to be called by". I think it is still kinda confusing to say "nothing to do with" because you made it sound like it wasn't even same client and server model or something. But I know what you mean now: there are common classes that can report where they are being run, and there are other classes which only exist on one side or the other. Okay, one last question. It seems that you prefer to use proxy for pretty much all the main class events, even if common (you put that in the commonProxy I assume). I kinda thought about going that route, however is it just a style preference or is there some other advantage to not putting the common code directly in the main class? For example, I do all my entity registering right in the main class, but for the renderers (which care about side) I register them through the proxy. While I understand there is some logical cleaness in putting all the common stuff in the commonProxy, it just seems like main class is pretty logical home for it too.

I agree with SanAndreasP -- a Block already has an isLadder() method. In your Block class you should just have something like: The code you quoted for isLivingOnLadder() method in your original post definitely checks the isLadder() method and returns true as long as the box isn't null, no matter which of the boundingbox code paths it takes. That should be all you need to do. In fact if you look at BlockLadder class, that is exactly what it does. If you don't trust that, then make your block an extends BlockLadder class to pick up the ladder behavior.

When I'm modding I usually try to find the vanilla code that does similar effect. It sounds like you want an effect maybe like same as if bonemeal was added to the plant above your block? I dug around a little bit. Note I'm using 1.7.2 -- you might have better luck with 1.6.4 since the code is less obfuscated there. The first thing that makes it a bit difficult to find is that bonemeal is also used sort of as a dye, so it looks like the code for applying bonemeal is actually in ItemDye class. There you will find an applyBoneMeal() method and you can see code where it is checking if the block applied implements IGrowable. The interesting part of the code seems to be: As you can see, unfortunately much of that code is obfuscated (you should look at it in Eclipse or your IDE to follow the various parameters. But it looks like the right place to start to me -- you can get the block above your grass (with additional code) then check to see if it is an instance of IGrowable and then update the growth.

Thanks, I like your tutorials. I don't understand your statement (in the linked tutorial) that the sided proxy "has NOTHING TO DO with the difference between client-side and server-side. That is something totally different." Can you explain the difference? It seems related to me -- for example subscribing a GUI event handler on the server proxy seems to give me trouble, similar to any other gui method running on the server elsewhere in the code. For example, what would be the difference between: a) putting my registerRenderers() in ClientProxy b) using no proxy and instead use @SideOnly in main class and have two preInit methods (preInitServer and preInitClient) where only the preInitClient registers renderers? c) using no proxy and instead use one preInit method in which you test FMLcommonHandler.instance().getEffectiveSide() and register renders if on client?

Okay, still learning about the client-server architecture. I'm registering event handlers in my mod and I thought that an event that was client side (like a gui related event) would simply never fire, but it seems that even subscribing it when running on Server will cause a crash. In other words, I guess you need to have different subscriptions depending on which side you're running. Is that true? To be clear, here is my event handler: And the RenderGameOverlayEvent seems to cause the problem. So is it best to do the event registration in the proxies according to the side, or should I use @SideOnly in the event handler to mask out anything not relevant to a side? This actually brings me to my real question about dealing with the client versus server: when do you put things in the proxy versus when do you put them in regular class with @SideOnly annotation?

Okay, solved. I just re-implemented my SidedProxy stuff. I will have to give some feedback to a couple tutorial authors to include this in their 1.7.2 conversion examples as I assumed the omission was purposeful (although I was suspicious at the time). @Darty, yeah I was just thinking that -- it is really the event type that is passed that controls the call, not the name of the method itself. But the proxy thing is the standard way for controlling what classes are used based on side, so I'll stick with that.

I guess some misleading tutorials! I had working 1.6.4 mods and then followed some tutorials for converting the mods to 1.7.2 and they didn't have the sided proxy stuff anymore so I figured it wasn't required (also because the @NetworkMod annotation wasn't needed I assumed it was related to proxy stuff). I'll go back and re-implement my sided proxy stuff now that I know it is in fact still required.