jabelar

I'm using 1.7.2 though and thought I could get away without the proxies (I did use these before in 1.6.4). I actually did think about having two preInits, one for each side, but when I tried using @SideOnly to distinguish them Eclipse complained about having two methods with the same name. Although maybe I can ignore that warning since I guess only the one for the proper side will be loaded? I'll play around with this more. Can someone using 1.7.2 share their code for registering renderer such that it only gets registered if on client side? I must be missing something simple.

Okay, so I have an entity (a tiger) that spawns naturally fine and also has a spawn egg that works if I use it singly. I mean if I right-click it spawns a tiger, and if I right-click again it spawns another tiger, but if I hold right-click (for multiple spawns) the game crashes (seems to be right after first tiger spawned, although I'm not certain). It must be some code I modified recently because previously it worked (it would spawn a bunch of tigers including baby tigers). The NetHandlerPlayClient seems to be having trouble, but I swear I haven't modified any code related to the networking. Here is the console error: I can post more code, but not sure what would be related. I suppose that it may be trying to create a baby tiger and that is failing? Here is the only code I think I have that is related to baby tigers -- in the model class render method it checks for isChild and scales the body accordingly: Here is where I register the spawn egg in case that matters:

Okay, so assuming that I should only register my renderers on client side, how do I check for client side in the main class of my mod? It doesn't seem like world.isRemote() is available there, also the @SideOnly doesn't seem too happy if I try it within my code. And I don't think Minecraft.getMinecraft() works for this, especially since I'm not sure it exists even on client during the preInit stage. What is safest way to check for whether you're on a server during preInit? Or should renderers be registered later?

Okay, I understand that rendering is supposed to happen on client side only, but I thought I was handling that by making my whole render class only client side, as follows: However, when run with server run config from Eclipse I get following error: So my question is really: besides making the render class client side only, what else do I have to make rendering client side only? I'm suspecting that the render registry entries in my main class should only be registered when on client side (I'm not doing this now)? Do I have to do anything with the actual render methods in my entities?

Sort of. I think it does a multiply blend (see http://en.wikipedia.org/wiki/Blend_modes#Multiply). Your example of 500 x 20 isn't really a good way to think about it because the colors are multiplied in hexadecimal RGB notation (I think). So the actual effect is actually sort of useful -- for example you can colorize black-and-white pictures by multiplying in color. You might want to play with a multiply layer effect in Photoshop or GIMP to really understand it.

With entity AI, computers are so much faster than humans that you need to purposely limit their decisions to be less frequent. You don't want to use onLivingUpdate() because I think that gets updated every tick (20 times per second). Instead, if you think how entities in Minecraft act, they change their behavior only every couple seconds or so. It is actually pretty easy to use the AIBase class and use an AI tasks list. I suggest you just look at other vanilla entities like Wolf and Bat to see how they do it. Basically you create a list of tasks that are done in certain order every once and a while and it will call your custom AI class.

Yeah, I figured would be hard to intercept this vanilla code if it didn't have the hooks. Also, yeah it is wierd that sleeping case does have a hook. Do think there is any hacky way to intercept the sleeping case? Like what if you set the player as "sleeping" even though they weren't and then took control of the camera? I do have to say that that guy is a real programmer -- does some sophisticated stuff and apparently is pretty confident doing it. I noticed that in his ModelMorph() class he has a render() method in which he has this one line (line #202) that looks related to maybe what you're trying to do:

I haven't tried before, but I'm pretty sure that you can use standard Java text file methods for reading files. Just look those up. Your .json file would help map the right file for the purpose (based on the block you want info about and the language you want the text in). In terms of referring to your file there is some FML hooks such as: After that you should be able to do other file-based methods. I'm not Java expert, but I think something like: Since you're catching the errors with the code above, you can control it such that it doesn't spam console if that's what you want. Then you can come up with a text format that best suits your needs. For example maybe you want some markup to enable formatting or something.

Well, are you only doing this for the player? The player model should be ModelBiped. Generally, I expect the render registry probably can be queried. The loadEntityRenderers() method in RenderingRegistry class looks like maybe it does something like that. However, now that I think about it, it may be tricky to have an entity fully copy the player because you'd also want their armor and maybe any items and effects. So I think instead you'll want to somehow actually invoke the regular Player (or other entity) render a second time but with an offset and maybe some transparency. Again, I'm not certain but I think you could maybe listen for the render event and then invoke it again (but you'd have to have a flag that lets you know whether you've rendered or not already to avoid an infinite loop of renders). Not sure you know what I mean, but I think doing this as a render rather than as a copied entity may be easier.

I think most EntityFX are rendered in a model-less way, using render effect method and texture. I think you should just use regular entity for this (yes with a player model associated). In terms of when the entity is created and when the skin texture is "grabbed" can be done in many ways, and sort of depends on how common this effect will be. If it is an effect of a rare item, I would probably just create the entity instance at the time of use and it could "die" as it fades away. If all the players in a multiplayer game are going to be doing this frequently, maybe it would make sense to have permanent entities already ready to go.

But isn't moving the camera pretty much what he's hoping to do? Just move it to where the eyes are supposed to be, right? If you can move it "to the looking direction" you should be able to figure out how to move it elsewhere. In particular, if you look at the orientCamera() method of the EntityRenderer class, the description of the method says "sets up player's eye (or camera in third person mode)". In fact the code for orientCamera() method includes changing camera for debug camera mode, for sleeping in bed, third person, etc. So why isn't the OP's desire to move camera to different "eye height" pretty much the same as having a debug camera that is just at same level as the model's eye? Here is the code from the orientCamera() class. It seems to have a lot of examples of controlling the camera:

Note that I'm not sure that removing the vanilla AI tasks is that easy unless you know the instance of the actual AI task. If you look at the removetask method you'll see that it needs the actual AI instance (not just it's general class). In my own custom mobs, I usually record the instance of each AI class I add so I can easily remove it later (or in subclasses). I think there may be a couple workarounds though. I think the AI tasks ultimately are just some sort of list structure, so you can clear it. Also, I haven't fully got an understanding of the "priority" parameter in the task list. It may be that adding an AI task with same priority may overwrite the original -- in other words, maybe it is just an array index not actually an array.

That is what "extends" means in Java. If a class extends another class it gets all of its methods unless you purposefully override them. As a modder it is a good idea to check out the methods in all the parent classes for whatever you're modding.

I'm not at a computer with Minecraft source on it right now, but have you looked at the code for when you change the viewpoint in vanilla Minecraft when you press F5? If that can move the camera to behind / in front / or "in" your player while retaining all other gameplay, it seems that has got to give you some sort of clue.

I do that with some code, but a lot of it is part of a sort of physics engine; if I slowed that down, it would be extremely noticeable. Yeah, I understand some things do need real-time. However, even with some things like physics I have been successful with just scaling the physics itself to keep up with pace of updates. For example something can be processed with twice the velocity every other tick, etc. You of course have to be careful with collisions as you don't want things passing through each other without detecting a collision. In terms of users noticing I think it really depends on how near it is and whether it is within their field of view. For example, if a cog in a machine is not turning smoothly but is behind the player it may not matter. Anyway, I was just putting it out there because sometimes you're already fairly optimized but still have a perf problem -- at that point you need to break down the processing into manageble, less frequent, activity.

This is a cool discussion. The only thing I have to add though is sometimes a simple, brute force approach works sufficiently that you don't need to do all the work of a trickier, over-finessed approach. One thing I've taken advantage of in the past was the difference between human perception and computer execution speed. For example, if you process only half of the instances in your code every other tick, or one third every three ticks, etc. It is usually simple to implement and the human users often don't notice, especially if you're slightly smart about it (like maybe things behind the player or otherwise out of view (or farther) get updated less often. There are some situations where you need to process everything in same tick for some synchronization purpose, but I've seen a lot more cases where selective, less frequent updates give big perf boost withough much coding pain. I especially recommend this in the case (perhaps like here) where you know a certain activity is taking a majority of the processing time but you feel that any further true optimization is tough / impossible to squeeze out.

Do you think the look vector, or whatever the server thinks you're looking at needs to be modified? The render stuff you're doing presumably is client side, but at some point you have to translate what you're looking at into server side and maybe that is getting mucked up? Although I'm not sure why that would actually crash though, you think it would just think you're looking at the wrong thing and process as a proper left-click on whatever it thought you were looking at. I don't have Minecraft on this computer, but can't you look up that error message in the code and maybe figure out where it is going wrong based on the location of that message?

While it is nice to use elegant coding, or impressive to use tricky coding, sometimes I think it is best to just do something simple and "brute force". Why not just do use a random int to pick from a case statement and just list out all the items you want to have possible. Sure it will be fairly long list (although not really that long), but it will work very simply and should perform well too. The nice thing is that it is gives full control and won't have any weird occasional issues where you pick some unusable item out of the gameregistry.

Okay this is the crux of your confusion -- of course you can get variables from other objects! Once you know the tile entity instance you can just use it's variables (assuming they're public variables). That's the point of object-oriented programming. The trick then is simply finding the tile entity instance to refer to. Like CoolAlias advises, instead of searching for the tile entities every tick, for performance reasons it is better to record them when they are added (and also update when blocks are deleted!). So you'll just do a search when the block is added and update the entity with variables of type TileEntityCog for cogToNorth, cogToSouth, etc. and also gearboxToNorth, etc. Then, in the code where you update the direction of the rotation you would simply check each direction and if it isn't null then pick up the rotation accordingly. For example: In that example, you can see how you can refer to the clockwise variable in the neighboring tile entities and the result in this case is that the last non-null neighbor would control the rotation, gearboxes would override regular cogs, and it would be set to be opposite that neighbor. So hopefully you're getting the idea -- make sure the variables in your entity are public so they can be queried from other classes. So what I think (double check with more experienced modders) you could do for your mod: 1) create block for cogs that extends ITileEntityProvider 2) create tile entity associated with the cogs 3) in the tile entity create public variables for boolean clockwise, boolean active, int rotatedByDegrees, tileEntityCog cogToNorth, etc. (note that tile entities should automatically get x, y, z variables, world object variable, etc) 4) in the tile entity's constructor (more experienced programmers can advise if this is the right place) you make sure to add the tile entity to your mod's array of cogs, also search surroundings (you can just have each tile entity “look around itself” for other tile entities using TileEntityCog tile = (TileEntityCog) world.getBlockTileEntity(i, j, k); and put in the position you want to check) for neighbors and set the cogToNorth, etc. to the found instances. 5) in the render method you would update either the model or the texture depending on how you're visually planning to implement the cog according to the entity's active, clockwise and the rotatedByDegrees variables. 6) make sure you put in code in the block destroy event to update neighboring cogs such that they no longer consider the destroyed block a neighbor. 7) add in similar stuff for the gearboxes don't forget to registers all your stuff, update lang file, texture assets, etc. (I'm using 1.7.2, so maybe different if you're on 1.6.4) Anyway, hopefully you're getting an idea of a proposed approach: - extend your blocks with tile entities to keep track of variables - implement variables in the tile entity that track its state and also instances of any neighbors - refer to variables in those instances to figure out how neighbors should affect each instance - render the effect of cog turning

Perfect, this makes the requirements very clear. Okay, so first of all the cogs (and gearbox) should be tile entities, not standard blocks (although I guess you could use standard block with metadata if you really wanted). With tile entities, you can make some proper variables to hold information about the state of the instance. For example, you could have variables like a boolean clockwise variable to indicate direction of rotation, a boolean driven variable to indicate whether it is being driven by a gearbox or chain of cogs, and an int or float rotated_by variable to keep track of the amount of rotation. Then regularly (perhaps every tick, although if perf is concern maybe less frequently) you would scan the neighboring locations and implement the logic you described -- if there was a gearbox attached you'd pick up the boolean clockwise variable and set the opposite (since every cog would go in opposite rotation), and if there was no gearbox you'd look for other cogs starting in the order you specified "left to right". Hopefully you get the idea, and after you code it up please share and we can further give pointers if you need them.

Well, that's why I was being "strict" and asking him to at least post his code, which he did. But yeah, at some point if you don't understand how a nested loop works, you shouldn't really be modding. @Fergoman, we're not being mean but just being practical -- if you don't have confidence in programming a loop, it is going to be really frustrating modding when you get to more complicated aspects. I suggest you can have plenty of fun "modifying" Minecraft by creating texture packs, skins, maps, tricky things with command blocks, etc. without the frustration of working in actual Java programming.

Yes, but before we can help we need to understand a bit more about the logic you're trying to implement. For example, some questions: - if you put one cog block down will it turn? How do you start it turning and how do you want to set the direction? - if you place a second cog block down next to a cog block that is already turning, I think you want it to automatically figure out which way to turn? But what if you then try to control the second block direction manually, are you saying you'd want to then have the first cog react to that change? - what about the scenario I mentioned above: what if you have two cogs already spinning in opposite directions with space in between and you place a new cog between them? How will it figure out which way to turn if there are two neighboring blocks that are trying to force the direction? To be honest, it would be fairly easy to help you make code that searches around your cog block for other cog blocks and to get their directions, but after that it isn't clear how you would resolve the weird cases of multiple neighbors. If you describe how you want the behavior to happen in the cases I listed above, it would better direct how to write the code. Basically good coding "handles" all the logical cases. For example, it might be fun to have a cog break if its neighbors are trying to force it to turn in opposite directions. In any case, you need to have your code check for and respond to every possible case. So list out your cases and how you want it to behave, then we can help code it.

If you have a totally different question, you should create a new thread post just for it. Back to your original question, my first concern is that you need to figure out how to identify which blocks are the master that control the direction and which are the ones that react to the blocks. You also have to consider how to handle case where there are blocks on either side both trying to force it in opposite directions. For example imagine you made first placed two cog blocks spinning in opposite directions with a space in between then added a third cog block in between them. It is best to fully think through the logic of how you want to handle these type of situations before you start coding, otherwise it can get tricky to understand why it isn't working later.

@Fergoman Your current code breaks a 3x3x3 cube of blocks, but sounds like you only want to break one vertical layer in a 3x3 area? Like CoolAlias says, you don't need three loops in your code then, you just want to loop in the two dimensions you want the break to occur.

@Fergoman, instead of asking other people to write all your code for you, you'll only learn modding by trying things. People here then will be happy to help you out. But you need to show what you've tried. If you want to make a special hammer, can you show your code so far? Even if the hammer doesn't do the 3x3 block damage yet, show what you have and what you've tried. Some of the things you'll need to do before getting to the breaking part: - create and register your hammer item class, either as an extension of vanilla hammer or depending on how much different you want it to be an extension of a generic tool class. - make sure it works as a regular hammer -- is it registered, breaking blocks normally, does it show up in the creative tab you want, does it have the right model and texture you want, does it have the right sounds you want? - create and register the crafting recipe to make it. - make sure the crafting recipe works Have you done all that already? Only after all the above works, should you be trying to make it do special stuff like the 3x3 destruction. And usually, if you have all the above working, it will be pretty obvious what needs to be modified (i.e. find the method activated when you break blocks normally and then modify that) -- in this case the onBlockDestroyed() method looks promising as indicated by Busti. So can you post your code you've got so far (even if it only works like vanilla hammer so far) so we can better help you?