shadowmage4513

try a bitwise OR operation ( | operator) e.g. color | (alpha << 24) Although for this use (with colors being bit-aligned), there should not be a functional difference. Unfortunately, I have not tried playing around with transparent font-rendering, so could not give you a 100% for sure solution =\.

player.inventory.getItemStack() e.g. PlayerInventory class has a method called getItemStack(), that returns the singlular item-stack that is on the cursor, or null for none.

A generic tick handler. Every tick it can check and decrement timers for any 'delayed explosion entries'. Any that are supposed to explode can then be made to explode. Or, if you have a block, you can schedule a block event/callback. Or, if you have a tile-entity you can use internal varialbes/onUpdate code. Or, if you have an entity you can decrement a variable in the entity/onUpdate code. There is not necessarily a thread-lock, however there are multiple issues with trying to manipulate data across threads (cache coherency, stale data, yadda, etc... multiple books can and have been written on the subject). You can't just jump in and muck about with another threads data.

I haven't watched the video, so merely speculating. Also, it generally helps people if you post what you have tried. My proposed method: Tickhandler. Call the pathfinder for the player to get a path. Every tick use your tickhandler to call the player-navigator to move him along said path. It might be easier than that... you -might- be able to just set him a path and let him go (as he shares most of the code with EntityLiving/etc). But I'm guessing because of the player-controlled aspect you will have some additional handling to do (i.e. through the tick-handler).

Last I checked you don't need a fakeplayer to make mobs drop their rare-drops. There is (was) an int field you can set in the entity that denotes a timer since it was last hit by a player. If this timer>0 when it dies, it drops rare/player only loot. Simply set the timer to 1, and do whatever to kill the entity (I generally call entity.attackEntityFrom(genericSource, entityHealth). Upon further investigation, the field is still there, in EntityLivingBase. protected int recentlyHit; Use reflection / AT to set this to a value >0. Viola, the mob now drops 'rare' loot.

Unfortunately validate() cannot be relied upon, as it can be called before the chunk is loaded entirely (e.g. it gets called for each tile entity when that tile is loaded, not for all tiles in a chunk after the chunk loads completely). This causes issues when 'examinig the world' as most of the nearby world will not exist/not be loaded. As suggested, a simple boolean flag works, check/set it your updateEntity() method. UpdateEntity is only called after the entire chunk is loaded, ensuring the world is ready to be queried. My personal method was lazy cache lookup -- I don't build a neighbor tile cache until something tries to access it. As the access can only occur from a tiles updateEntity method (in my case anyhow), this ensures that the world is loaded before the cache is ever built.

Solution A: Do -not- render the tooltip while rendering the item-stacks. Iterate over your stacks a -second- time after the initial rendering, only rendering the tooltip for the mouse-over stack the second pass. Solution B: Implement a deferred tooltip render. Again instead of rendering the tooltip immediately with the stack, setup a deferred rendering. I do this in my GUIs by grabing a reference to the item-stack and the x,y position the tooltip is supposed to render at (this is setup while doing the initial stack rendering). After stack rendering I quickly grab my deferred tooltip data and render that. If the mouse is over a stack in the stack rendering, set the tooltip stack reference to that stack and set the x,y position, render the tooltip after the stacks, and set the tooltip stack back to null -- that way you know if the tooltip stack is -not- null that you have a tooltip to render.

I believe the reason is because it is (on average) the most performant and most widely supported. Relying upon any specific Garbage Collection VM setting for your mod is a -bad idea-. You have no guarantees that your users would have that GC type enabled.

There -is- a packet-size limit for anything sent between client and server. Not sure off the top of my head what it is, but it should be at least 2MB. My guess is that MC is exceeding that limit when it sends the initial container contents from server-> client on GUI opening. Initial inventory contents are synched to client by container.addCraftingToCrafters(ICrafting), which ends up calling icrafting.sendontainerAndContentsToPlayer(Container, List<ItemStack>). This wraps up the entire inventory contents (including 'null'/empty slots) and sends them to the client. It is likely here that you are encountering the packet-size limit.

Still unsolved. Have not been able to implement the desired features because of it. Moved on to other things =\ There have been a couple of pull-requests for forge/FML to add such an event, but I haven't seen any of them get actually pulled/merged. Would do a PR of my own, but no much use if the two existing ones are just sitting there =\

Try calling super.onLivingUpdate() in your override of onLivingUpdate() I can't recall precicely, but I know the AI and movement states are updated from one of the living-entity update methods -- and you have overridden it without calling the super-class method, which means those AI updates likely are not occurring at all. Also...use the @Override annotation where appropriate (such as on that onLivingUpdate() method) -- will remind you of times where super() should be called, and even give errors when the MC code changes between updates / method names change.

You can't pass the entity, true. BUT -- GUIHandler gives you 3 ints to work with (x, y, z). This data is sent intact to the client when the gui-open packet is sent. Most would use this data to send a block-position for the gui (chests/machines/etc) -- but with an entity you do not need the block-position. The normal procedure for accessing entities client-side for GUIS is to send the entities entityID via one of those int parameters. You can then read this param client-side and retrieve the entity from the world via world.getEntityByID() (or w/e it is called in the current obfuscation),.

There are some -very- basic GUI widgets included in vanilla -- buttons, text-boxes, sliders. However, compared to normal GUI libraries they are quite backwards and difficult to use without much manual integration into your gui. I believe most people develop their own GUI widgets / classes. I did for my mod, I know chickenbones did for NEI, pretty sure the BC team has custom GUI stuff for BC as well. There is/was a 'minecraft GUI's' API/mod at one point that was meant to work as a shared GUI library, but I never looked into it too much -- it might still be available, can probably google for it (minecraft GUI API or similar).

Look into Math.atan2(y, x) -- it will return an angle given a vector from origin. Calculate the vector by the difference between player position and the position of the target looked at (use a ray-trace for getting that position). A good article explaining many of the basic geometric concepts related to angles/positions: http://www.helixsoft.nl/articles/circle/sincos.htm

https://raw.githubusercontent.com/coolAlias/Forge_Tutorials/master/ModdingWithAPIs.java ^^ The above guide helped me figure out how to implement BC compatibility in my mod (I did not write it, please give credit to coolAlias ) (https://github.com/shadowmage45/AncientWarfare2) Edit: Would like to add that this seems like the 'proper' way to do mod-api dependencies. Using the @Optional annotations makes your code design and packaging so much cleaner and easier to deal with in the long run. It can mostly do away with all of the proxy classes and reflection that used to be necessary even for simple dependencies.