strumshot

That, specifically, I can't really say from experience. I was trying to answer this question:

AKA this:

I would say that this can be temperamental, and should be named by the same protocol that packages should. Try "infiniteDiamonds" and then make sure that your directory in the resources folder matches this exactly!

So I've cloned vanilla hoppers to a new format (unique logic to the automation process - I've added 3 slots that determine the "filter" of allowed items so as to remove the need for redstone in sorting. I am calling it a "filter." Novel name, right?) and I am curious: considering all I've done is a simple cloning and Hoppers don't use traditional stand-alone renderers, what would be the simplest way to say... change the color? Is there some simple access to render-time and a hue modifier or something to that effect? I honestly don't feel that trying to port the rendering method(s) tucked away in the Block renderer to an ISBRH is worth it, so if there's not a superficial hack this thing is staying grey! I'm actually open to suggestions because all I need the modification for is to be able to visually discern which are hoppers and which are filters.

Probably this code...

Maybe you can override a little more of the process and just manually add a bucket to the players inventory as a workaround?

Yeah, you're definitely bypassing the handler... and using the base container... From the video - which is deceptive - I would guess its maybe a combination of syncing and slot locations? I had a similar issue once when the client was drawing a different screen (gui vs slot locations) than the server had. Is there a way to see all the code in one place, like a Git or something?

Good call. In that case, although it would be a bit long-winded, I would ignore the cables and find any within a radius, and then work backward to try to find a cable path that leads back. You would want to make a List<> of already scanned cables, but treat tees specially. That would actually be some fun logic, and would work similar to AI pathing. That's all I've got! lol

Maybe debug it like this: @SubscribeEvent public void onRenderInvList(RenderGameOverlayEvent.Post e) { if(e.type != ElementType.EXPERIENCE) { return; } FontRenderer fr = mc.fontRenderer; String name = mc.thePlayer.getCommandSenderName(); if(e.world.IsRemote) System.out.println("Server: " + name); else System.out.println("Client: " + name); int xPos = e.resolution.getScaledWidth / 2; int yPos = 10; fr.drawString("" + name + "", xPos, yPos, 16777215); } I'm sure e.world isn't the right world reference, but you see where I'm going with it... edit: on second thought, I can only imagine "onRenderInvList(RenderGameOverlayEvent.Post e)" is on the client, so yeah, I've gotta leave this to those better than me.

I'm just spitballing here, but does drawstring have a SideOnly Client, and the event is subscribed on the server? edit: DrawString is definitely only executed on the client, I just don't know 100% that events are subscribed only on the server, but I feel that must be the case. As annoying as it is, I think you have to do this through packets. Its one of those times where on the surface it looks like magic is happening in that code, but we have to remember that unless otherwise specified, a lot of code gets executed twice! (server & client) Instead of assigning the variable in the subscribed event, I would send a packet to the client and assign it in the handler. I don't know, it still doesn't sound right, but either you are pasting code you aren't actually using or its something like this.

That's what "modal" means - the screen is on top and must be dismissed before play continues - and although I haven't done it myself and there are others here who would know more specifically... what about the HUD? It is a screen GUI I believe and game operates normally with it up. edit: if nothing else, this is where I would look to find your answer. Do what the HUD does.

Because when you say you have an issue you don't post the code, and then when you do post the code its not in a code tag, and because you still have an issue. Post your custom item, your registration in the main file, and a screenshot of your file structure, and then I can tell you if you have done what I, dies, and the tutorial have suggested...

I hate to be that guy, but I would suggest reading the tutorial, not just copying the code. And I would suggest posting your code and maybe even telling us where you put your texture. However I would assume if you can't follow a tutorial then you can't follow a forum post. This forum is for helping point people to a solution, not for getting a mod written for you. I feel you have more than enough information to solve this issue.

http://www.wuppy29.com/minecraft/modding-tutorials/wuppys-minecraft-forge-modding-tutorials-for-1-7-item-textures-and-names/#sthash.AnlA7m49.dpbs

Its similar to your first approach, but I feel you are overcomplicating it. Do it all from the trigger block with classic logic/iteration. I'll write some shorthand code... Coordinate scan(coordinate){ scans your 6 sides and returns the coordinates of a found cable or null } Coordiante start = trigger block coord; Coordinate temp = start; Coordinate find = null; Coordiate ignore = null; find = Scan(start); if find != null{ if find is emitter, yippee! else ignore = temp, temp = find, find = scan(temp); rinse/repeat Then when you find an emitter, determine the distance of emitter from start, and derive your power or whatever from there...

In general some code would help... but I'm guessing this is in a GUI and its not in sync with the server. You will have to override your update packet or manually write a packet to get the info from the server.

This is pretty basic stuff, there's tutorials everywhere... setTextureName(MODID + ":pulseRifle"); Then put your graphic in the right folder... Again, I don't feel like writing a tutorial that's been written 1000 times, but that's the jist. Google is your friend!

I have to be honest and say tl;dr, so if I'm way off forgive me... But what I would do is make a method within your class that can determine distance from any coordinate, and derive your power rating from that. Ie: 0,59,0 is 59 from 0,0,0; power = 59 - distance, aka 1. Then do a typical block search starting at your trigger block, which returns success when it finds an emitter (which will then enact the distance/power method), and terminates when no cable can be found. Click block... begin loop check all six sides found cable east... (ignore west, check 5 sides)... found cable south... (ignore north, check 5 sides)... found emitter south... determine distance (3)... determine power (57)... end Has this not been suggested/will it not work for your issue?

Can you post the rest of the code related to this? TileEntity, GuiHandler, etc?

Why don't you just make a gui screen that is not modal, etc, and draw it there? Maybe there's something I don't know about guis but wouldn't that work?

In the end you can clone the base files... BlockChest and TileEntityChest, and you will need your own renderer. tutorial should help.

You can't send the same packet back to the client. What you want to do is simplify your packets as much as possible. For example, make a button that increases a value. This will send an empty pack to the server (and is registered to be handled by the server) called, lets say, InrcreaseValuePacket(). The server sees this packet, and increases the value. You can make as many buttons and packets as you like! Then each of those will have a relative packet, say RespondWithIncreasePacket(), that is registered on the client. If you send packet A to the server - where its registered to be handled - you cant send packet A back to the client, it won't ever hit the handler. You would make packet B and register is to be handled on the client. You can make unlimited packets, just make sure you register the handlers on the right side, and also you can minimize the information stored within. It looks like you are sending an UpdateEveryValueEver() packet to the server, and trying to send the UpdateEveryValueEver() packet right back to client (sometimes.) One possible example of flow could/should be like this: Player activates block which opens gui on the client only Gui sends update request to server(packet A) server responds with data the gui needs to display(packet B) player clicks button to adjust a value gui sends packet to adjust specific value to server(packet C) server receives packet and changes value, responds with either total update (packet B) or value specific update (packet D) Packets A and C would be registered to be handled on the server and would most likely hold 0 specific data whatsoever. the server would know what to do just based on the packet type. Packets B and D would be registered to be handled on the client, and packet D would have the advantage of not carrying much data. ...I sure hope that makes sense/helps!

That makes sense, yes. Why I keep reading it as "if(we are not the server) send packet to server" is what doesn't make sense to me, aside from obvious dyslexia on my part - which I have resigned to, because I trust you. lol!

No. No no no. isRemote is true for client worlds only and false for server worlds (including worlds from the integrated server) only. So you can detect the logical side with isRemote. @SideOnly completely removes a method, field or class (as if it just did not exist in the java code) from the specified Jar-file. So @SideOnly(Side.SERVER) means that the method will only exist in the minecraft-server.jar. So even the Integrated Server will not have it. Also @SideOnly does not care about any compile errors that might occur from this. It just strips the method/field/class completely no matter what. Conclusion: @SideOnly is almost never the right choice. Okay, good, that's what I've thought, and that makes me feel better! You scared me for a second. I guess I was looking at my logical check wrong, but I found a better solution by sending the gui update packet from within the gui itself, so problem solved/averted anyway. As usual, big thanks! Although the fact that this didn't work still perplexes me, but I think this thread is officially dead! I don't want to know!