Karlovsky120

I'm creating a chunk pre-generator and I'm running into trouble with "Already decorating" exception. I figured it was because I was calling the methods to populate and generate chunks too fast. To fix it, I put a delay before each call (about 250ms works for me). However, I don't want players having to decide how fast they would allow for terrain to generate. So my solution to this would be to have somkind of a fast benchmark which would be ran everytime before I try to generate, to see what their computers are capable of, and that use that info to set the appropriate delay. But I have no idea what method I could use or call that wouldn't really affect anything, and would be intensive enough to have a somewhat reliable results. On a related note, whenever I generate a chunk, I immediatley save it, drop it, and unload it (unloadQueuedChunks()) . Could it be im getting the error because I'm (in theory) having no adjacent chunks loaded? I know Minecraft loads chunks when decorating cross-chunks, but I'm just no that familiar with the mechanic. Help please?

Hi! I just wanted to ask something that's been bothering me for a while. A lot of forge problems arise due to the fact that two mods both have the same id for their own block/item/biome/etc. Why doesn't forge create an "ID dictionary"? Every mod would request a number of IDs for it's purposes and forge would grant it and move on to the next one. A record would be something like: [ingameID] [inmodID][modName](optional [iDType] if not using single dictionary per ID type) So if you have two mods that both use eg. ID 85 for an enchantment, you would end up with this: [45][85][mod1]([enc]) . . . [67][85][mod2]([enc]) It should be simple enough for modders to interconnect items/blocks/... across diferent mods using the dictionary, shouldn't it? How come there is no such system in use? BTW, I have zero knowledge of Forge's inner workings, which is why this post may seem very ignorant.