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.

Simply put, you cannot call Minecraft.XXXXX on server side, or any code that is even seen on the server -- you need to route it through a proxy class. The only safe place to use Minecraft.XXXXX functions are in purely client-side code (mostly just GUIs as far as I know...can't even use it in containers). This happens because ALL imports/etc are resolved when a class is loaded, not 'just the ones that would be used in that code path'. (i.e. even though the if(remote) stuff would never execute, the imports are still in the class definition) (Others might be able to clear this up a bit better.....) However, there is an easy solution -- the real method to spawn particles is safe, as it is located in the World class, and should be callable on any world object. Excerpt from EntityArrow code (the part that handles crit hit particles) if (this.getIsCritical()) { for (i = 0; i < 4; ++i) { this.worldObj.spawnParticle("crit", this.posX + this.motionX * (double)i / 4.0D, this.posY + this.motionY * (double)i / 4.0D, this.posZ + this.motionZ * (double)i / 4.0D, -this.motionX, -this.motionY + 0.2D, -this.motionZ); } }

In your For Each loop, you are never setting the newly created instance into the array -- so yes, it will be null. While you _are_ iterating over the null instances that exist, changing the reference of 'screen' while in the loop does not change the assignment for that reference in the array. Hopefully someone else can explain this in a more understandable manner. add something like: screens [ i ] = screen; to the bottom of your for-each loop ( BEFORE you increment i ), and you should be good. Not MC related, basic Java / reference stuff.

Your problem is you are checking the stacks ITEM for null, not the stack itself change it to if (gear.getStackInSlot(20)!=null && gear.getStackInSlot(20).getItem()!=null){...} and you should be fine

Further edit: Doors are probably the trickiest to get correct, because they come in two halves that must BOTH be set properly, AND be set using the right method. Check out the static method of ItemDoor.placeDoorBlock -- should be able to feed it one of 4 values(for each closed door orientation, 0-3). It will properly set both the top and bottom of the door. From there you only need to figure out what orientation number is correct for the doors in your structure (+rotation if generating your structure with multiple rotations).

For the pistons/torches/chests/furnaces/other metadata blocks -- to alleviate the problem that delpi is describing, you can also just re-set the meta after setting it the first time. E.G. world.setBlock(x,y,z,block,meta,flag);//initial assignment, meta is often overriden by blocks' onPlaced methods world.setBlockMetadataWithNotify(x, y, z, meta);//force-set the meta to your desired meta, this one should stick world.markBlockForUpdate(x,y,z);//make sure clients will receive the new/updated metadata, generally optional during world-gen as the entire chunk will be sent when client goes in range Another way that I found works well (and better performance) is to manipulate the data directly in the chunks. This bypasses many of the world/block methods..so you have to be careful on what/where you do things, but will allow you to manually set the block / metadata / tile entity without worrying about the vanilla methods overriding them. I actually do this during my structure generation stuff so that I can generate redstone contraptions with full state-data -- normally the wire/etc would get a neighbor update when placing the next block, and revert its power state / etc -- going through the chunk bypassed the vanilla 'update neighbor blocks on change' code, and allowed me to generate fully active redstone contraptions with the precise state they were scanned in as.

Is the lack of GUI a necessity...e.g. do you want the player to be able to move-around? The easiest solution that I could think of (if an immobile player was okay) would be to actually use a GUI -- as that provides a central place to intercept key events...and if you don't have slots in your container, then no slot-selection/item moving will happen. And you don't -have- to draw anything in the GUI, so it could be transparent...the player just wouldn't be able to move while it were open, and would have a mouse cursor on their screen. Getting the local client has always been as easy as calling Mincraft.getMinecraft.thePlayer Keep in mind, that needs to be called from behind a client-side proxy (like other input handling), or things will crash when deployed on server

That particular GUI can only be opened via using an item -- so there shouldn't be any other GUIs open. Apparently for the affected users it effects most/all of the GUIs. I am investigating having them try with no other mods installed to see if it is a mod-conflict or something else. Either way, I will probably need to find a solution I can implement in my code. Could be a z-level thing -- I don't mess with z-level during gui rendering at all, so it is left at whatever the previous renderer(mod) had set. Hard for me to test solutions though, as I have been unable to duplicate the problem (gotta love those issues....)

Hi all, Some of my users are reporting some strange GUI rendering problems that I cannot seem to track down on my end: Here is how the GUI displays for me in dev and multi-mc instances, and for most users: https://dl.dropboxusercontent.com/u/95935735/AW%20Dev%20Shots/2014-06-24-res_gui.png[/img] And here is how it is displaying for a couple of users. The background is rendering as black instead of gray. The details are all there (can still see slots rendered in some other guis), but the main background layer is black/extremely dark. They are each running different mod-packs (but probably have a few in common, so could be a common cause). (holy crap thats a big SS.....) Any ideas what the cause could be? I already tried putting code in place to reset openGL state for lighting, textures, disabling 2nd texture unit (lightmap texture?), lots of other stuff. The strange part is that the scrollable composite areas render properly -- and I don't do any lighting stuff inside their render code, only bind the texture. Most relevant source: https://github.com/shadowmage45/AncientWarfare2/blob/master/src/main/java/net/shadowmage/ancientwarfare/core/gui/GuiContainerBase.java https://github.com/shadowmage45/AncientWarfare2/blob/master/src/main/java/net/shadowmage/ancientwarfare/core/gui/elements/CompositeScrolled.java

Just a stab/guess -- but it is probably related to cpw's recent security manager additions that... 'catch' when you exit Minecraft. I'd wager that there is still some work to do on the system. Looks like it was added in @ version 1029. I would say test to see that it happens with just forge/no mods installed, and submit a ticket with FML on the problem.

the integer param represents the operation type 0==additive 1==additive multiplicative 2==direct multiplicative orignal value = x; modifier value = y; modified value = z; additive: z = x+y; additive multiplicative: z = x + x*y; direct multiplicative z= x * (1+y) -- http://minecraft.gamepedia.com/Attribute