jhogan42

I'll give you a hint -- the bug is in this line :-) if (ConfigurationHandler.enableGeneration = true)

I tried this earlier tonight after our discussion, and had partial luck. I was able to point CCC to the gradle cache dir above, and it found some of the needed files there (like packaged.srg), but others (like methods.csv, and joined.srg one I forget) are not there. My actual MCP/conf directory (i.e. from an actual MCP download/build) is the other way around -- contains joined.srg and methods.csv, but not packaged.srg.

Thanks for the heads-up on the thread safety issues. Given Draco's suggestions I don't actually think I even need a Hashtable anymore. Instead of tracking which chunks have been completed in my own data structure, I can just read/store that in each chunk's NBT metadata during the load event. It appears the asynchronous phase of chunk loading is completed by the time the ChunkDataEvent fires, so I think that should be safe.

I see. Yeah, that is probably pretty safe. tterrag tells me on IRC that events are synchronous, so it sounds like storing the metadata during the ChunkDataSave event will work! Thanks for the tip... that'll be much cleaner. Thanks -- good to have this as an alternate strategy!

Right, I saw that :-) What I am wondering is if adding my own data to that would violate underlying assumptions in the vanilla code and break things... or if those extra NBT values would just be happily ignored by the vanilla code. Another question on this approach -- are Forge events synchronous or asynchronous? If they're asynchronous, then even if I did modify the chunk payload in the ChunkDataSave event, there's no guarantee my modification would complete before the save executed.

Thanks Draco. I know I can use those events to find out when the server is going to save/load a chunk... what I'm wondering is if/how I can edit the payload of what's being saved. For example, can I add my own arbitrary fields to the chunk's NBTTagCompound when I'm handling the Save event? Will that screw anything else up in the vanilla code if I do that?

Hi! I'm writing a mod that implements new ore. Rather than just have the ore get generated in new chunks, I'd like servers to be able to use it on their existing maps, as well. Here's the pseudocode for the approach I'm thinking of -- looking for critique / flaws! I'm particularly wondering about methods for storing data to disk -- is there a mechanism in the vanilla code to store mod-related metadata along with the rest of the world state? COMPONENT 1: Keep track of which chunks have the new ore: preInitialization() { HashTable<ChunkCoordIntPair> chunksWithNewOre; chunksWithNewOre = modSpecificRepository.readFromDisk(); } COMPONENT 2: Modify standard ore generator (registered with GameRegistry.registerWorldGenerator()) to keep track as well: generateNewOre( chunk ) { typical_ore_generation( chunk ); chunksWithNewOre.put( chunk.chunkPos ); modSpecificRepository.writeToDisk( chunksWithNewOre ); } COMPONENT 3: Generate ore in all existing chunks as they load: @EventHandler newChunkLoaded( ChunkLoadEvent ) { // if this chunk has NOT had its terrain populated already, that means it's a brand new chunk being generated // (as opposed to loaded from disk). http://minecraft.gamepedia.com/Chunk_format if( !event.chunkData.TerrainPopulated ) brand_new_chunk = true; // If this IS a new chunk being generated, regular terrain/ore generation mechanisms will kick in, so we don't need to do anything special if( brand_new_chunk ) return; // Additionally, if we've *already* put the new ore in this chunk, there's nothing to do either if( completedChunks.get(event.chunkData.pos) ) return; // this is a previously-existing chunk which has not yet had the new ore added! generateNewOre( chunk ); }

Thanks for the feedback... the obfuscation / deobfuscation bit makes sense here after more research... Is there any general documentation about the Forge/Gradle environment that I have missed that would tell me things like this? Or is this a standard convention in the Java world I just am not aware of? I have no idea where y'all learn these things... is it just from digging around in the source code for years?

Haha, not that much more experience actually. I'm new to Minecraft modding, but just happened to spend yesterday evening writing ore generation code right before I saw your post :-) Glad it worked!!

Hi all, I'm developing mod M, and want to run tests while simultaneously running mod M and a testing mod T in my dev environment. When I attempt to install T, by placing it in my dev client's "mods" directory (same directory tree where the client logfiles go, etc.) -- it only partly works. I see on the title screen that it loaded, but none of the other functionality is present. T works fine on my normal (non-development) Minecraft client. Can anyone help me understand what I'm doing wrong? I've read some claims that code obfuscation might be related, but I don't understand why that would affect the client software reading a pre-compiled .jar at runtime. If it matters, I am using IntelliJ, and the testing mod in question an x-ray mod (linked below) -- I'm using it to test ore generation code. Thanks in advance http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/1292688-xray-mod-1-6-4-1-8-3-vanilla-optifine-forge

The X,Z coordinates which Forge passes to generate() are in units of chunks, whereas the X,Z coordinates which WorldGenMinable takes in are in units of blocks. Your code isn't doing the translation, so odds are that the ore is getting generated, but somewhere else in the world far away. Inside your for loop, try to multiply your blockXPos and blockZPos by 16, see if that fixes it. A couple other minor longshots: 1. As Brickfix said, try registering your WorldGenerator from the main Init event; that's where I have mine (currently working in 1.. 2. For the "priority" of the generator submitted when registering it, all the code examples I've run across use 1, and I notice you have 0. 0 probably still works, but who knows, maybe try 1 just in case. good luck!

Progress! It looks like net.minecraft.network.play.server.S21PacketChunkData.func_179756_a() is where the server does the raw data assembly for sending chunks to the client. Passing in an optional hash table of block-id translations (e.g. "newOre->stone") would make it a fairly straightforward code change to present "stone" to the player instead of "newOre". There are a number of other circumstances under which a similar translation would need to be made (block placements, itemblock spawns, opening inventory / containers which might have the affected block inside) but it looks like net.minecraft.network.play.server has nicely compartmentalized points to address most of these -- maybe all. One area I'm uncertain about is performance. The loop in question (for sending chunks to players) obviously gets called a lot, and is quite optimized, down to bit manipulation. Presumably this was done to minimize CPU load. I don't know if Notch was just being prudent, or if this is loop is a crucial part of server load. I'm hoping the former, since chunk loading isn't done *that* often (compared to, say, tick processing). Of course I don't know anything about injecting Java code so now I need to go look into that and hope I don't run into any critical roadblocks. Suggestions, or pointing out pitfalls I am missing, would be appreciated!

Well, I know any vanilla code modification would be an undertaking. My hope is that the changes might be relatively small and self-contained -- minor in scope compared to projects like Forge/FML. I don't think other mods would need to adapt to this -- all of the altered behavior could be contingent upon a mod explicitly opting in. No change for current mods.

Sounds like the requirement there would be to create two parallel data structures before the data is compressed -- one "real" and one with the "hallucinations". Then in the loop which sends it to the clients, send the corresponding compressed data structure. In the grand scheme of things that doesn't sound that bad.

Hi all, I'm trying to figure out whether there's a way to create a server-side mod that offers new content to modded clients, but will still allow unmodded clients to connect and have a mostly-intact experience (without the new content, of course). The motivation is to encourage server-side mod adoption by minimizing the impact to non-participating players. The general idea is for the server to induce vanilla-based "hallucinations" in the unmodded client that are as close to the "reality" of the modded server as possible. For example, consider a server-side mod that implemented a new ore block. When an unmodded client encountered the ore block, it might appear to them as stone. If they break it, the dropped ItemBlock might be invisible and un-gettable to them. Because this assumes an unmodded client, this translation would have to happen server side. For example, the server would need to tell the modded clients "block x,y,z is NewOre!" while telling the unmodded clients "block x/y/z is just stone." I don't think there's any generalized solution to this problem -- the approach & implementation would need to be custom-tailored for each use case. And it does have its limits. Hallucinating stone instead of ore will not be terribly disconcerting for a player, but bouncing 100 feet in the air because the "grass" they walked on is actually a super-trampoline starts to get a little weird. Nonetheless I think for many situations this approach would work fine. So my questions are: 1) Does the above approach seem theoretically possible? Is there something I'm missing? 2) If so, how difficult would it be in practice to implement the "stone for ore" example? I'm sure it's not easy, and I figure it would probably require hooking directly into the core source, but I don't have much of an intuition beyond that. I don't have much experience with Minecraft modding, but do have software dev experience more & a lot of time on my hands right now, so may actually decide to tackle this if it's feasible