jabelar

Just use a regular BiomeProvider.

what have you tried so far?

The event is probably technically working, but I suspect that most rendering code overwrites whatever you do there. The rendering events are good for ADDING something else to be rendered, or fully replacing what is rendered, but not really good for changing what is rendered. It is actually usually good practice for any rendering code to sort of "reset" some of the GL stuff to a known state, exactly so other code running before it can't mess it up. Now Minecraft code is quite inconsistent so you might get lucky and find some places where a judiciously placed alpha change will affect the next thing rendered but it would be hard to count on it, as you found out. If you're really good at GL, you might be able to push/pop a matrix to apply the alpha but you'd have to take care to handle the events symmetrically so that you don't end up overflowing the matrix stack. If you're ambitious you can replace all the renderers for the vanilla entities with ones how you want, but doing it for other mobs would be tough. Sorry, maybe someone has a clever idea to do what you're looking for. Otherwise, I'd trace through the various rendering code to see if there is a place to surgically insert an alpha change.

Your IDE should allow you to see all fields and methods for a class. In Eclipse it is called the Type Hierarchy. Just right-click on the class in the project hierarchy pane and select Type Hierarchy. There are a couple of "buttons" that affect the filtering of the view, I like to show everything including the inherited methods. That is a better way to scan for available methods than simply scrolling through class files themselves. In modding it is especially useful to look at the Type Hierarchy because you can actually get a lot of ideas for modding after you see some of the available methods, and at least get a really good feel for how the interfaces are organized.

Yes it is a common problem in client-server games. Ideally all "game truth" is enforced by the server but in order to get smooth movement and minimize network traffic the client usually processes the immediate movement with the server just sampling it to check the validity. But the problem then is how much "tolerance" the server has in this verification. The server can and does rule out impossible movement but what about the fringes of what is possible? As an ethical mod maker you can add a barrier to using it for cheating yourself by making your mod require that it also be loaded on the server. Of course a hacker type person could still figure out a work around I'm sure, but at least you know that you have done as much as the vanilla game itself does to protect against it.

Well, the ScorePlayerTeam class has the getAllowFriendlyFire() method.

The entity bounding boxes need to have the same length and width (i.e. square base). I believe this is to simplify path-finding. Similarly note that the bounding box never rotates even when the model does, so it wouldn't be that helpful even if you could specify different values. EDIT: Also the setEntityBoundingBox() method set's the actual box in the world meaning the values of the box would be related to the entity position. If the size was 2.0 wide and the entity is at x position of 300 then the bounding box would go from 299 to 301. You shouldn't ever use the setEntityBoundingBox() method as it is meant for updating the position of the bounding box based on the size and position.

I don't think your code will move them in a circle. It might spawn them in a circle, although the code for that looks a little weird for that too. Let's go through you update() method in the hastebin link. The first important thing is -- where is this update code? If you want to move the particles it would need to be in the particle class, but I kind of suspect you have it somewhere else like in an entity. So your first mistake is that your code isn't moving the particles, it is just spawning them constantly. It might also be possible to used particles in fixed positions and "animate" them by killing and spawning them quickly but I don't think it would work well visually. So I think you need your particle class to remember the center of the circle and the angle, and then in the update method for the particle you would add some angle and adjust the position (not respawn) accordingly. Additionally, I think your math is still suspicious. Your code to use trigonometry to adjust the X and Z positions looks like: double angle = Math.toRadians(degrees); double vx = (pos.getX() + 0.3) * Math.cos(angle) - pos.getZ() * Math.sin(angle); double vz = pos.getX() * Math.sin(angle) + pos.getZ() * Math.cos(angle); I'm pretty sure the math is wrong here. The X and Z positions are the values in the world, so they can be numbers like 600 or 0 or -600. Instead I think you should be multiplying by a radius for the circle as the vx and vz fields presumably indicate the difference in position relative to the center. Also, you're mixing up the two dimensions. Sin and Cos functions already take and angle and separate it into the two dimensional components, so I think it should be something more like: double angle = Math.toRadians(degrees); double radius = 2.0D; double vx = radius * Math.cos(angle); double vz = radius * Math.sin(angle); Then instead spawning the particles again, you should just move them. Also, you shouldn't move them based on current position, but recalculate from the center of the circle. So the new positions would be something like (this is pseudo code because you need to put the code into the right place with a field for the center: this.setPos(particleCenterX + vx, this.getPosY(), particleCenterZ + vz); Summary Putting it all together: The movement code needs to be in the update for the particle class which runs on the client side. You can't just keep spawning particles. I would have the particle "remember" where the center of the circle should be. You need to have a sense of "radius" for the circle. You simply update the particle position with very simple trigonometry such as center + radius * cos(angle)

how did you try to play it?

The issue is that the term "entity" usually implies a number of things (such as registration) and functionality (like AI) that is expected to also be run on the server. ESPECIALLY note that if you want to do the following then the server MUST be involved: Syncing across multiple clients so that all players can see the entity. Saving so that the entity persists across saves. There are cases though where it can make sense for an entity that exists only for each play on the client side. In that case I think your best bet for client-side "entity" behavior is to create your own system. All an entity really is is a loop of code that runs along with some rendering. So you can simply have a tick handler running the AI and some rendering that hooks into the normal rendering process. But it is somewhat of an advanced approach that would require decent programming skills and fairly high modding experience.

Well you set the default state to have the check decay and decayable as false.

I have some tutorial information on custom villagers, which also discusses trades a bit. http://jabelarminecraft.blogspot.com/p/minecraft-forge-modding-villagers.html

For your original question, yes the approach of having a simple "queue" for scheduling things should work. The actual mechanics of the queue can be coded in different ways depending on how many things and how far in time you want to queue things. Unless there is a performance concern due to having a huge number of scheduled events, almost any sort of collection can be used that you cycle through. One detail is that if you're doing this for worlds that might be saved, you'll probably want the time to continue when the world is loaded again. In that case, you should also save the queue to world save data or maybe the player data depending on what sort of things you're scheduling.

I think so. I think maybe you can maybe you can handle the RenderHandEvent or the RenderSpecificHandEvent. You might also want to rotate the original model. Note that it (in order to be more gun-like) may be more important to control the rotation of the whole hand.

Okay, that makes more sense. I'm wondering if there is a more efficient way to do the "rebuilding" then. Let me see what that is doing -- if it could be targeted to just the light map updating part that shouldn't really bog things down.