Reika

I know normally the server does not send data about "other" worlds to a client. However, I find myself in need of this and with no way around it that I can forsee. DimensionManager only works serverside (it returns null clientside), so that is not a solution. Basically, I need the ability, clientside, to have the ability to do something like world.getBlock() where world is, say, the Nether while the client player is in the overworld. Perhaps Packet#MapChunk is involved, but I have no idea how to use it for this. No, rewriting the system to just send the checks to the server and back is not possible because of how complex and dynamic it is, as well as the fact that "delayed response" is not acceptable for my application.

World unloading and loading events are not fired clientside, which leads one to think chunks behave the same.

That was indeed it. I find it odd, though, that the method gets called clientside, where chunkloading is not really a "thing". ...Also, how do I "give thanks"?

I am trying to write a block-based chunkloader, and I am doing it the same way as systems that work - such as the BC quarry - but my chunkloader does not work. I call forceChunk (once) for the chunks I wish to keep loaded, and have a handler set up to manage the tickets. However, two problems arise. One, I sometimes get the "invalid ticket" error. Breaking the machine and clearing the manager's cache fixes this. Two, even when the "invalid ticket" error is not printed, the chunk appears not to be forced. I stepped through the forceChunk function line by line, and everything seems to work, creating the new entry for the given chunk and adding it to ForgeChunkManager's cache. However, as soon as I leave the area, the chunk unloads, because my TileEntity's onChunkUnload() gets called. My two classes are here: https://github.com/ReikaKalseki/DragonAPI/blob/master/Auxiliary/ChunkManager.java#L31 https://github.com/ReikaKalseki/RotaryCraft/blob/master/TileEntities/TileEntityChunkLoader.java#L22

Not really. Barring a MC version change or another mod's conflicting ASM edit, there is no way for this to error out. Also, you seem to be implying, based on your wording of "ASM into vanilla classes" that using ASM is not necessarily dangerous, but using it on vanilla classes is. What else would you normally use it on? You could of course theoretically ASM Forge or other mods, but that is far more dangerous and will generate a huge amount of drama.

As it happens, yes, these will be going in a custom dimension which allows me control over the ChunkProviders, but this does not help me actually figure out how the system works; there seems to be an internal automatic algorithm Minecraft uses to generate structures like these.

I actually found a way to safely extend it to 255 (and theoretically higher), but it required ASM into the PotionEffect packet and NBT methods to remove the byte casts.

http://lmgtfy.com/?q=java+static

I have several questions related to procedural structure generation (piece-wise multi-chunk structures like Strongholds, Nether Fortresses, and many Twilight Forest structures, not single-pass isolated structures like dungeons, jungle temples, and anything generated in an IWorldGenerator). How do I go about adding my own kind? I assume I extend MapGenStructure, but how do I register it? ChunkProvider classes seem to hardcode what generators they use, with no obvious Forge hooks aside from a PopulateChunkEvent.Pre, but that seems not to be the intended process, and some of the parameters, like the coordinates, seem off. Also, how does the structure generator work? I see that structures have pieces and a StructureStart, but what are the requirements on those pieces, such as dimensions (for example, must each piece be a 16x16 (or other size) square?), and how do I get pieces to plug into each other properly?

As of Forge 1208, addSubstitutionAlias is gone and the only public method that accesses the alias system for mod use is deprecated with the javadoc "DANGEROUS! EVIL! DO NOT USE!". GameRegistry also has an addAlias function, but it is a no-op.

You should probably mark this thread as [sOLVED] now, not unsolved.

I have a similar problem, trying to add ItemBlocks for vanilla blocks which do not have them (and thus would crash if you tried to render them in the inventory as an item). Manually creating the ItemBlocks is trivial, as is adding them to the game, but the problem is that the FML namespace registry automatically and forcibly prepends your mod name on the item, resulting in a Frankenstein mess of "DragonAPI:minecraft:unlit_redstone_torch" which causes FML to freak out: Granted, this could be avoided with careful use of reflection, but I strongly suspect that would be a very strongly criticized decision - maybe even deliberately broken by Forge - and one I would like to avoid.

I have noticed a new, hopefully unintended behavior in 1.7.10 Forge regarding the @SideOnly annotation, present in both recommended 1180 and newest 1208. Basically, many of my classes, when initialized, cause the loader to throw a NoClassDefFound error because somewhere there is a method referencing a clientside class. However, in previous versions of Forge, I used to be able to mark the method @SideOnly(Side.CLIENT) and it would load fine, as the clientside code was ignored on the server. This is no longer the case. Whenever I have a serverside class with such a method (such as a block referencing Minecraft.class in the getRenderColor() function, or a custom class on which I call registerIcons(IIconRegister)), it immediately crashes upon initializing that class. This is especially frustrating as it only happens outside the developer environment; the eclipse-based debug server runs perfectly fine. This inconsistency, combined with the absurdity of not being able to reference clientside code in clientside methods, leads me to think this is a bug. Is it actually a bug, or am I literally supposed to move half my methods' content to the proxy, which works but is hideously ugly and scattered code?

Fetching the TileEntity will likely give you additional data, but that would require special casing every one.

That is why you make the IDs configurable, and then the problem only arises with inept pack makers or if vMC decides to add 200 new packet types. No, the ultimate parent class must be Packet.