jabelar

Yes, why not? Your item NBT can just store the registry name of each block in the area. If the block is something special (like having a TileEntity) you can store further information. What exactly is your concern?

I think the gui open event should work. The gui that is passed in can be tested to see if it is a GuiMerchant and if so then you should be able to cast it as GuiMerchant and then get the container since the inventorySlots field is public.

Yeah, I think that should work except that if other mods set their priority to highest then you you're not guaranteed to have yours go before theirs (I assume the order is based on mod loading or modID alphabetical) and if other mods set their priority to lowest then you're not guaranteed to have yours go after thiers. In fact, one or the other will not fully work because if you're first in order for the highest then you'll be first in order for the lowest, and vice versa. But at least you can say you tried. And it should work for mods where they leave the priority at default (normal).

Do you want a GUI where player puts these items into slots, or do you want to be able to just "drop" or throw items near it? It seems that you are trying to do the latter... If you don't want a GUI, then you're on the right track. Doesn't look like you need much help. I think you just need to take the EntityItems that you find and check if you have everything needed for the recipe and if that is true then "kill" the ingredient EntityItems and spawn the result EntityItem. If you do want a GUI then basically you're making a crafting table and you can check out tutorials and other mods' for such things. But the main thing is it is recommended in that case to use the Container and GuiHandler system to help sync things up.

The first thing is to decide why you want to split it up. Is because some people only want part of the mod's functionality? If so, actually the easiest way is to have one mod with good configuration settings. You can let people select which parts they want and it doesn't add that much complication to your coding (usually). If you do want to split it up, the next question is whether some of it can simply be a fully separate mod. Like have GammaS' Cool Mobs Mod and GammaS' Extra Potions Mod and so forth. Now if you want big parts to be both optional but also when enabled you want them closely working together then you have to think more carefully. For example, is the "core mod" always required in which case it will be a dependency for the other mods (you can google how to work with mod dependencies). Furthermore to make a really good dependency you might want to formalize the API part of the core mod meaning coding some proper encapsulation (look it up) and maybe using things like the @API annotation. And maybe you want each of the add-ons to also work together -- like if you have one that adds entities and another that adds potions maybe you want to change the drops of the entities to include the new potions. In that case you might need to have APIs between them but since you won't be guaranteed they're there you might need to look into things like the @Optional annotation. To be honest it can be hard to break up a mod that wasn't originally programmed with breaking it up in mind. It is much easier to organize if you start out that way -- making effective APIs and building on top of those. Look at how other mods that are broken up do it -- many of them have open source code on github you can inspect. If you already have a large complicated mod that you want users to be able to control which parts they use, I suggest it is probably easiest to add the configuration options I suggested at the beginning.

Okay, that makes sense. It is okay to modify other people's code but you need to understand what it is doing, so you should think carefully about how the logic works. Your new edits are changing it the wrong way. Your original way was close, you checked for the cooldown okay before the problem was you were also setting it in the loop. All you needed to do was to move the cooldown setting line to the outside of the loop -- but after the loop not before it. They way you're doing it now has lots of problems -- you're reducing the cooldown in a loop all within a single tick, and also attacking the same entity over and over again in that same tick. Please think through the logic very carefully. Remember this loop will be run through the whole loop in a single tick. So if you want something like a cooldown that works over multiple ticks you need to only reduce the cooldown by one each time the code executes. So the loop should be going through the list of entities like it was before, not going through all the possible cooldown values.

There is a class that extends GuiButton called GuiButtonImage. You can see how it is used for example in the GuiInventory#initGui() method where the recipe button is created that way.

You need to post the whole class code. Hard to tell what is going on with just a bit of it. Is this your code? The general code is quite complex and shows a fairly high degree of coding ability, but your questions show very little understanding of how to code. So it seems that you've copied code from somewhere else and are trying to modify it a bit. It is okay if you are doing that, but we need to know because otherwise we don't know how to help you -- do you need quick tips or do you need detailed step-by-step help?

Well, I'm sure there are ways of sort of spacing out chunk loading and such, but it would be very advanced modding technique. Optifine is extremely advanced and does a lot of low-level performance tweaks. I think you're probably talking about the chunk pre-loading thing. But even that is a bit of a trade-off. You can get smoother play but at the expense of occasionally extreme lag. In the end you need the same number of chunks loaded and it is just a matter of how the loading is spaced out. You can either have a bunch of smaller lags or occasional bigger lag. But the average overall load on the CPU will be about the same. In other words, you can make the lag possibly smoother, but can't really get rid of the overall lag (unless you do other things I mentioned). Also note that Optifine also provides a lot of other tweaks in the areas I already mentioned and similar like reducing render distance, enabling advanced OpenGL features, looking at things like fog, turning of the sky, clouds, and so on. It is a lot of coding work to do this sort of stuff, and you need to know what you're doing. Honestly, I would suggest just getting a better computer, or if you're using a desktop then get a better GPU card. They get so much better each year that even a $150 spent every couple years will great improve your graphics.

I think your problem is that while you're going through the list you check the cooldown value to be less than 0 but then you set it to value of 20 (or 50 if you're level 5). So the loop will only run once since the next time it loops the cooldown will always be greater than 0.

Okay, so most personal computers have two types of processing going on -- the CPU which does logic and the GPU which does the graphics. These run "in parallel" and have their own loops that run at their own rates. For Minecraft the CPU is looping through the game logic at 20 FPS, and the GPU is looping through the rendering at whatever refresh rate your display is probably 60 FPS. If your computer is having trouble with lagging during single player (integrated server) mode, it can be either the CPU or GPU (or both) that is having performance issues. The GPU will have trouble if the scene is "complex". That is partly related to how many blocks are visible (due to render distance), but also to things like the resolution and color depth of the display mode, whether the blocks are transparent, whether the textures are animated, what quality the edges have (like anti-aliasing). So if you're having graphics performance issues I would firstly reduce the resolution, color and quality settings for your graphics (like go to your graphics or display options on your computer), secondly I would reduce the render distance in the Minecraft video settings. After that, there isn't much you can do except get a new graphics card or computer (if you have integrated graphics like in a laptop). The CPU will also have trouble if the scene is complex, but in this case complexity is related to the amount of things it has to do. For example, if the blocks are all simple and don't have random ticks (like leaves), scheduled ticks (like redstone), or tickable (like tile entities), then it would be simple logic. But if you've loaded up on redstone and command blocks or use a mod with complex systems such as energy distribution it will be complex. I don't think there is much you can do if you're having performance issues with your CPU, except get a better computer. However, if you have lots of other mods installed you should check to see if removing them helps -- it is very easy for a mod to cause performance problems if it does a lot of additional work every tick. But the important thing to understand is that for the game to run it needs to do the logic and needs to keep the display refreshed. So you can't just generally "slow" it down because you would still experience that as lag. In fact, lag is what happens when it slows down. So slowing it down more wouldn't help you.

Yeah, I've been meaning to update that page. Will do so in the next few weeks, plus adding more information on custom textures.

That doesn't really help because the total performance needed is the same -- everything you want to be rendered needs to be rendered. If you have a PC with bad graphics performance you should just make the render distance smaller so you can't see as far. You can do that in the video options in the settings.

If you just want the sky to move slower, that works pretty much like you just suggested -- basically you can affect the time of day direcly with World#setWorldTime() and it mostly just affects the celestial angle. However, as mentioned above you will then get out of sync with other functionality like sleep cycles (which will force the time to advance expecting vanilla day duration) and the "calendar" system. And if you try to fix everything it will get complicated because then you need also change the totalWorldTime and that is used by a lot of things.

Another point. The world info contains two "time" fields. There is totalTime and worldTime. The latter only cycles through the 24000 of the day cycle and is used for things like celestial angle. The totalTime is the time since the world started. There is the corresponding World#setTime() and World#setWorldTotalTime() methods. The total time is used for a lot of stuff. If you look at the call hierarchy it is used for things like armor stand rendering applyRotations() method, used to "pace" some updates from happening too , quickly (like it waits every 600 ticks to update the "calendar date"), used in animations of items and TESR, checking for redstone torches to burn out, and many other things. In other words, if you slow down the "day / night" cycle by affect the rate of tick counters like totalTime you will likely slow down many other things. So it wouldn't just be a langer day, some things would also happen slower and some things might happen multiple times like command block triggers. Now that might be what you want to have happen -- if the day is longer maybe you would want some things to be slower. But just wanted to point that out.

Rendering is done in separate thread (I think) which updates every screen refresh (like 60Hz or even 120Hz depending on display). The main game logic loops in "ticks" which are 20 per second (unless lagging). Since the rendering and main loop are not really synced up specifically, there is concept of "partial ticks" used to help smooth out some animations. So if you did something like simply changing the world tick count, it wouldn't directly affect rendering. However, it could affect other things. For example, I think the the sleep cycle uses it (like in WorldServer#tick() metho), and world difficulty uses world tick count for the increasing difficulty, I think the map spinning might use it, And some mods might use it for timing things. So there might be some side effects. But it would be fun to try. Just use a tick handler and use the World#setWorldTime() method as you wish and see what happens.

What do you mean? That loop should only create as many buttons as are in your loop index which should be equal to this.tileEnchantFab.knownEnchants.size(). If it is looping more than that you should debug -- either put a print statement or two to watch it in the console or set a breakpoint and use debug mode. Basically I don't think your loop is the problem. I think it is your this.tileEnchantFab.knownEnchants. It probably has a bunch of duplicate entries in it or something weird. I'd print it out before the loop to see what it contains.

Exactly, I'm not sure why he thinks it will cause memory problems. To the original poster, can you explain more about your concern related to memory issues?

There are a fair number of tutorials and threads about this topic already. Have you tried those? Once you have please share your code so we can help with whatever part you're stuck on.

Did you search the forums? There are lots of lengthy discussions on this topic which don't need to be repeated here. Basically, to do it properly is complicated because you have handle things like the time command, sleep cycles, and some mod compatibilities such as sky animations. And yes generally it requires a replacement world provider. However, if you want a really crude way of doing it you can add or subtract ticks to the world tick counter -- basically like a "leap second" sort of approach but there are dangers to that as discussed at length in previous threads.

I think he's saying he already did this but is worried about the memory it takes. So that leads to the question -- why are so many of these structures and entities in the structures getting spawned in the first place? To cause an actual memory problem I'd assume you'd need thousands of these to have been spawned... Those entities enable persistence. You can check that by following the call hierarchy for things like the Vindcator you'll see that right after they are constructed the enablePersistence() method is called on them. The end city and woodland mansions are rare structures so there is no problem with too many of them. So the main question is: why do you have so many structures with so many entities that this is a problem? What are you actually trying to do?

Tip: I highly recommend that when implementing tag functionality, especially if you're not highly familiar with it, that you print out the compounds to the console/logger throughout your code that reads and writes it. It can much more quickly get you a sense of what is going on. NBT is technically very simple, but I think it can be confusing (for beginners) because you can "nest" them in different ways. You can have compounds of mixed types, lists of compounds, compounds of lists, and so forth. Furthermore, the reading and writing need to be perfectly "reciprocal" which a lot of people mess up. So seeing the compounds in print statements I find is extremely helpful to track what is going on.

The problem started with cpw actually recommending this ("common" proxy) in the comments for the @SidedProxy annotation. Here's what it actually says: /** * Sided proxies are loaded based on the specific environment they find themselves loaded into. * They are used to ensure that client-specific code (such as GUIs) is only loaded into the game * on the client side. * It is applied to static fields of a class, anywhere in your mod code. FML will scan * and load any classes with this annotation at mod construction time. * * <p> * This example will load a CommonProxy on the server side, and a ClientProxy on the client side. * * <pre>{@code * public class MySidedProxyHolder { * {@literal @}SidedProxy(modId="MyModId",clientSide="mymod.ClientProxy", serverSide="mymod.CommonProxy") * public static CommonProxy proxy; * } * * public class CommonProxy { * // Common or server stuff here that needs to be overridden on the client * } * * public class ClientProxy extends CommonProxy { * // Override common stuff with client specific stuff here * } * } * </pre> * @author cpw * */ I know it "hurts" the brains for those people who have strict semantic thinking (and most coders should be strictly semantic), but it does work and lots of people used it that way for years. But yeah it felt good to finally convert my mods over to a more semantically correct implementation.

Why? And what exactly do you mean by "load slowly"? You mean that the overall loading process slows down so that the individual blocks are placed more slowly, or do you mean that the decision to load an entire chunk is delayed? In either case I think it would be quite difficult/advanced. The whole concept of chunk loading is an optimized part of game. Also, a chunk is considered either loaded or unloaded -- I don't think there is a "partially loaded" state (although I'm not an expert in this).

Yeah, that example is good. It actually avoids having to send the custom packet because it handles the case where the grass block has been clicked on on the server side and then checks if there is an entity in that space as well.