jabelar

Okay, it is a lot easier for us to help you now that we know what you're actually trying to accomplish. I think the best way is to refresh from your lock block. Does that have a tile entity? In that block you would have fields with the position of the associated chest. You would also have a int field for the counter. Then, when the lock state changes you can check to see if enough time has passed, and if it has then you could manipulate the tile entity inventory for the associated chest.

Hold on guys. I think the original poster was hoping to add to existing (i.e. vanilla) chests. theCorvid -- are you trying to make your own custom chest, or to alter the behavior of vanilla chests? For your own custom chests, most of the advice above is correct -- you just make your tile entity process code in its update method. You could scan through the inventory and if it was empty (or had small amount of items) you could add some. For existing chests, you'd basically have to scan through the chests occasionally and process them, maybe from some other tick event. However, another alternative is to just update the inventory contents at the time the player opens the chest. You could handle the gui opening and check the inventory then.

If the other mods are making their HUD also in the RenderGameOverlayEvent, then it is a matter of the event priority and cancellation. I explain a bit about this in my events tutorial: http://jabelarminecraft.blogspot.com/p/minecraft-forge-172-event-handling.html You control priority with the annotation to the event handling method. You cancel the event (if it is cancelable with the setCanceled() method). If event handlers from different mods have same priority level I think that they'll fire based on the order the mods loaded. You can also receive events that have been canceled and uncancel them. So putting it all together, if you make your method have priority = HIGHEST and also set to receive canceled events, then you can do what you want then cancel the event, and in vast majority of cases it will cancel the events for those other mods. Ideally though, for compatibility with other mods you have discussion with the other mod's authors to work out agreement on how to handle it. Note that there is a difference of opinion on receiving canceled events. I'm of the opinion that you should always receive canceled and if you care you can handle those cases where you are canceled carefully. Other people think that if another mod cancels it then they probably have a good reason to do so and you should honor it.

It's cool what you're trying to do and the approach seems sound, but it is hard to get interested enough to crawl through it to look for logical errors. I think you should just perform standard debug practice -- put console statements at all the critical points in the code to confirm its operating as expected. Alternatively, use a debug mode of your IDE to watch the values of the fields. I'm sure you'll quickly see the problem if you just trace the execution.

Again you need to be meticulous in your debugging. You should put a console statement to confirm that the gui constructor is called, that the init is called, etc. For example, maybe you'll find that you copied the GUI class to work on it and you're never actually constructing this one but an older copy of it. Sometimes I have multiple workspaces open and think I'm working in one project but actually working in another. Most bugs are dumb mistakes or typos, the rest are logic bugs. In either case when debugging you should trust nothing so need to very every step of logic to get to the result you want.

I believe the major tick events PlayerTickEvent, ServerTickEvent, ClientTickEvent and WorldTickEvent all get called twice (at start of tick and again at end of tick) and you can tell which is firing by the phase field which is in the event parameter passed into the handling method. I'm not sure the order of the tick events (like whether player tick is called before server tick) though, but you can look at when each one is posted to the bus.

I think a custom config GUi is better than the built-in one, so long as you're willing to put in the time to make a good one. However the built-in one is convenient because it auto-formats based changes in the Configuration -- in other words you don't have to change code of the GUI when you change the Configuration. However, you also don't have control over things like the order, and generally it looks boring. I do use the built-in one though -- here is my tutorial on doing that: http://jabelarminecraft.blogspot.com/p/minecraft-modding-configuration-guis.html

A quick scan over the code and it looks correct. Like Ernio says, you should definitely enable @Override verification in your IDE to ensure your methods are the right ones, but they do look correct as well. You should put a console statement in every method to see which ones are being called. Especially the initGui(). The one thing I wonder about is that you've made it a GuiContainer but haven't added any inventory slots. I don't know that that would cause a problem, but it might. What happens if you make it extend GuiScreen instead? I realize you'll want it to be GuiContainer when your finished, but it might be instructive to see if it works as a GuiScreen.

There is nothing special about a counter. All you need is an int field that you increase (or decrease) each game tick and then check if it made it to a certain value you desire. In Minecraft the tick happens 20 times per second, you need to count up or down to 20. What class do you want this timer in? If it is your own custom entity or something, there may be update methods that are called once per tick and you can put the code in there. Otherwise, like Ernio suggests, you can use a tick event like ServerTickEvent.

As mentioned, using F3 ingame you can inspect the state of the tripwire, the hook and the dispenser. The dispenser is "triggered", the hooks are "attached" as are all the parts to the trip wire itself. However, interestingly if I placed the blocks using the metadata in my schematic, every other piece of trip wire would either show "powered" or not powered. If I place the blocks using default state (this is 1.8 ) then they all show "powered" but the behavior is the same. If I break all the wire and place new wire down, the trap works perfectly fine. Anyway, there is still something strange about it in 1.8. The circuit is sort of supposed to be self-correcting as far as I know -- I mean each piece detects whether it's attached, triggered, etc. And the setBlock function calls onBlockAdded() method for the trip wire which does a notifyTriggers() call. Still looking for ideas...

You know how to code, but your recent posts show you're missing a consistent approach to debugging. Based on the faith that computers are completely logical and exact, you can solve most bugs by tracing the logic. You should either use your IDE debug mode to watch the values of the fields of interest, or I personally tend to just add console statements (System.out.println()) all over the place. I put a console statement at the beginning of every method to confirm that the method is being called, I put a console statement inside every if statement to confirm whether the condition was met, and I put a console statement after every major change in field value. So I personally would put console statements in your correctValues() and fixValues() methods after every line to output what the previous line actually did. I guarantee you that the problem will be obvious if you have good tracing through this method. Once you learn this technique of tracing the logic, you won't every have to come to forums again for a null pointer exception problem.

I'm finding a weird difference in behavior between 1.8 and 1.7.10 that maybe someone can explain. I have a schematic (basically my own which is just text file with lots blocks, metadata and position) that I read and place. This has worked well for me for a long time and previous versions. In one schematic I have a trap with arrow dispenser with trip wire hook and trip wire to make an arrow trap. Because trip wire kinda self-configures based on what is around it, I place it last in my structure generation, after all other blocks are placed. It works great in 1.7.10. Walk back and forth across the trip wire and it will keep shooting arrows each time until the dispenser runs out. However, in 1.8 walking across the trip wire will not fire an arrow. However if I press F3 and hover over the string, trip wire hook and the dispenser, they all show that they are actively set as a trap. Even weirder though is that if I break the trip wire and place new string, it will shoot once even if I'm not on the trip wire and will not fire again unless I break the trip wire and place new string again. Anyone have any ideas on why this is happening? I'm not aware of any mode where simply placing the trip wire without standing on it would trigger the dispenser, and I'm not aware of why it would say that the trap is set but won't activate when walking across it.

There are not 50 slots in the player inventory. There is 27 inventory slots plus 9 hotbar slots = 36. You need to look at why your index is getting up to 50.

It says it is crashing due to GuiShopTravellerOver.updateScreen() method. Can you post what the code for GuiShopTravellerOver looks like now?

No, that is not a "coding style" issue, it is a coding error: you are trying to assign something at a time when the assignment is either bad or at least unpredictable. That is a logical mistake and therefore wrong no matter what your coding style is. Now it is understandable to make such a mistake -- when modding, the nuanced behavior of the Minecraft implementation is not always obvious. It reminds me of someone who was trying to use the entity position in the constructor. Similarly, the position is not asssigned at that point, so using it would be wrong.

You can use debugging mode in Eclipse to see what is going on. Or add a check for null with a console statement.

In Eclipse, in your Run Configuration in the Arguments tab you just put --username=yourUserNameHere --password=yourPasswordHere. I don't think you need port forwarding if you're on the local network. I put in the IP address of the server directly to connect from the client machines. You can run server and client on the same computer. In the client, just do a direct connection and put in "localhost" for the IP address.

I don't think you need the IGuiHandler at all if you are just opening a GuiScreen. I think that is just for GuiContainers as it helps you match the Container (i.e. the server element) with the GuiContainer (i.e. the client element). Just make a GuiScreen class and open it like (on client side): Minecraft.getMinecraft().displayGuiScreen(new MyCustomGui()); or if you have the player you can use EntityPlayerSP#displayGui(). Note this is NOT the openGui() method, that one is for the container guis that need the IGuiHandler.. or if you have the FMLClientHandler you can use FMLClientHandler#displayGui(). That's it!

Interesting. Yeah the separate thread for networking in 1.8 has created a few gotchas. For example, the timing of packets can sometimes be different that expected which affected the way I was constructing some custom entities with sync packets. Thanks for pointing this out.

Why do you say that? At least I haven't had problems with changing height, and in fact things like fences do it that way. Changing X and Z I'm not so sure.

The block class has fields that define the bounding box: minX, maxX, minY, maxY, minZ, maxZ. If you wanted to make block bounding box 1.5 blocks high you would make maxY = 1.5D.

You're right about multiplayer, it would have to be an map field or something. So I guess it isn't that simple. Are you sure the field wouldn't be available on the server though? I think it would but that the problem would be that a single boolean couldn't cover all the players..

Okay, first of all you should clean up all those missing texture errors. Anyway, the actual crash says exactly what is wrong -- you're trying to access slot 50 when it thinks there are only 45 slots. You need to look through the math to see how that is happening. For how to implement the IGuiHandler, you might want to read my tutorial on container blocks: http://jabelarminecraft.blogspot.com/p/minecraft-modding-containers.html

Since the sprinting status is temporary (no need to save whether player is sprinting) and because it is not tied specifically to an item, I would simply create a static field in my main mod class and use that.

Are you also implementing an IGuiHandler class? That is what syncs the container across client and server.