jabelar

I just thought of another thing. It may be possible to generate the dungeon twice. I think with the same seed it should generate the same way. So why not just have your dungeon generator also run after the vanilla stuff? Of course your version doesn't have to place all the blocks, but should be able to find where the spawner would be. Even if it wasn't perfect due to randomness beyond the seed value, I think it could greatly narrow down the scanning you need to do as you'd know specific area that spawner should/could be.

Honestly, the best way in terms of performance and in terms of logical simplicity and correctness is to replace the structure generators with your own. It really isn't that hard, as you really just copy or extend the existing ones and replace the one line of code for the spawner. Many of the vanilla structure generators have public fields you can assign directly, and dungeons have the event where you can intercept and replace it. I know it sounds heavy-handed but I'm not sure that it is that bad. Secondly, if you continue with your scanning approach you seem really worried about remembering what has been changed and such. It isn't that hard to add a collection (list of spawners) that you have modified and add that to the world save data. Thirdly, another possibility is to predict where the structures will add the parts that go into the next chunks. Basically you would create a copy of the structure generator that takes the same seed and instead of actually generating the structure (remove that part) just note which additional chunks are affected and scan those. Lastly, while it would take a bit longer you can simply make a PR to add the hooks you need in Forge. For example, I think the current DungeonHooks implementation sort of sucks because it doesn't allow outright replacement of the spawner. So why don't you make a PR for a PlaceSpawnerEvent that gets information on location and which generator type produced it. If you're lucky (and for a simple and useful PR it is quite possible) it will take about a month to get your PR accepted and then you can return to this aspect of your mod.

The list of languages is: https://minecraft.gamepedia.com/Language#Available_languages As Draco18s mentioned, if your assets are format 3 then you need to use all lowercase. The table confirms that Dutch uses nl_nl.lang

Well, to debug it I would put more console statements in. For example, your dungeon event won't fire if the if statement before is true and it returns. So why not put a print statement there to see if it is returning before firing the event? Also, why not put a console statement in the constructor of the event so you can see when it fires? And so fortth... If you put console statements in every method/constructor as well as where each if statement is, you can very quickly determine what is going wrong.

You can still get a look vector. They just renamed the method to getLook(). You can figure this out yourself (i.e. when something changes between versions) but looking at the type hierarchy for the class and seeing of any of the methods have a name that suggest it is equivalent behavior.

If you want to contain the player in a single chunk, I would probably ignore the normal spawn location stuff and make your own by handling the EntityJoinWorld event, checking if the entity is instanceof EntityPlayer and setting the location directly yourself. There is also the setSpawnPoint() method which is in EntityPlayer and is public so you can use it to set the spawn point. That way you don't need the player to wake up in a bed before having spawn point set.

Hey, I just figured out a much easier way to do all this. There is already a class in Forge called DungeonHooks. It has a removeDungeonMob() and an addDungeonMob() method. Secondly, can't you tell that it is a dungeon by the type of spawner that is there? Like if it is a silverfish spawner then it must be a stronghold, etc. However, if you need more control -- like you only want to change it in certain situations -- then I think really the best way is to continue to handle the PopulateChunkEvent.Populate for EventType.DUNGEON and fully replace the dungeon generator. It is actually very EASY. You just need to copy the WorldGenDungeons code into your own class and change the spawner part. Then in your event handler you simply call the generation in your class and return Result.DENY to prevent the vanilla dungeon. Another method would be to handle all the EventTypes you're worried about and set boolean variable(s) to figure out if a dungeon generated in the chunk before you try to replace the spawners. For example, you could have fields like generatedStronghold, generatedDungeon, etc. and clear them in the Pre event and set them in each Populate event. Then in the Post event you could check what generated and decide whether you should replace the spawners.

I'm not exactly sure what you mean by identifying the dungeon. Once you have modified the spawner why do you need to identify it later? But if you do, there are a few ways I suppose. One would be for your mod to extend the world save data and you can record the positions of each modified dungeon (or spawner) as a list. What are you trying to do exactly?

ConcurrentAccessException are often encountered when iterating through Java Collections. Especially if you try to modify the list while iterating. In Minecraft it seems that entities, blocks and such are often being concurrently accessed (I guess for things like rendering and loading and such, although someone more knowledgeable should comment). So basically I'm saying it probably isn't just about loaded chunks but simply the fact that you're iterating and I guess modifying collections that are even being rendered or otherwise accessed elsewhere. Now, I expect Minecraft does some threadsafe locking in order to allow use of the lists (vanilla somehow is able to iterate through them) so maybe someone here can enlighten us on how that works.

Okay. So do you have a problem or something? What isn't working?

My example code goes further than just adding a piece. But I've been writing some tutorials on world generation and now have one for village stuff. See: http://jabelarminecraft.blogspot.com/p/minecraft-modding-custom-villages.html Note that one section on that page is specifically related to adding a piece to vanilla villages. Follow that part.

Okay, see you on the other thread shortly. I'm on a work call at the moment but will try...

By the way I just edited above post to show my console output -- shows that pre and post events are getting handled, but not populate. I just realized that Pre and Post are posted to the main event bus, but Populate is on terrain gen bus. Give me a second, but you can try too, I think that is the problem -- register on the terraingen bus.

Well it should be the terraingen bus that you register your handler too. However, I just tried it out and you are right. I can get the PopulateChunkEvent to fire (a lot) but can't get the PopulateChunkEvent.Populate to fire at all -- I tested this simply by printing out a console statement in each case. Weird. I think you can agree that the event is supposed to be fired according to the chunk generator code... If I simply handle the PopulateChunkEvent and print out the event (toString) I get Pre and Post but no populate: [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Pre@70579ed5 [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Post@3d9125df [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Pre@499013c9 [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Post@7bb934e4 [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Pre@37d4bc70 [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Post@3dfd888 [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Pre@4a989d61 [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Post@78b48ec2 [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Pre@6a119a98 [20:07:43] [Server thread/INFO] [STDOUT]: [com.blogspot.jabelarminecraft.examplemod.TerrainGenEventHandler:onEvent:30]: Populate Eventnet.minecraftforge.event.terraingen.PopulateChunkEvent$Post@177714ca

Maybe it's because I'm viewing this on the phone, but it is not clear what instance his "this" refers to. Jredfox can you post your whole code?

Event handler methods need to be static.

You should look at the ChunkGeneratorOverworld code. It will answer all your questions. There are a variety of generation-based events that fire and you can see exactly when, where and what parameters are accessible. In this specific case I think you'll find that the ANIMALS always fires. Note that this is for Overworld. If you're doing nether or end you'll have to look at those generators to see what is available. But I only recommended the ANIMALS because it is immediately after the dungeon generation. Instead, as Choonster mentions it is robably even better to use the Post event which will happen after everything and furthermore fires in all the vanilla chunk generators. Regarding generation versus loading, it shouldn't really matter. Whatever loads should be whatever was saved which should have been replaced during generation anyway. You do need to be a bit careful with performance though, so you might only want to check the chunk for spawners if you're confident there is dungeon or whatever present. Overall I know you're a bit scared about the implications of each approach, but you can confirm it all yourself by inspecting the chunk generator code. There are lots of forge hooks existing that probably get you close enough to do what you want, even if not totally elegant. Also, replacing the dungeon generator with your own isn't that big of a deal. It seems like a heavy hammer, but you can simply make yours an extension of the vanilla one and selectively @Override those methods and fields that you need to change the behavior. You can insert your custom generator either directly (the generator fields are public in the vanilla chunk generators) or by handling the PopulateChunkEvent and looking for EventType.DUNGEON.

You can also handle the PopulateChunkEvent. If you handle the one for type EventType.ANIMALS, it happens immediately after the dungeons are generated in the vanilla overworld chunk generator. So you can scan the chunk for any spawners at that point and replace them with your own.

Ultimately most Minecraft models are pretty simple, just a bunch of boxes with rotation points. I honestly have been very successful in making complex models just by drawing them on paper. If you are doing rotations then having a protractor and ruler help. But it really isn't hard, in fact may be easier than using a program, to simply sketch it out and use ruler to measure the coordinates.

Sorry I don't know much about the lighting or texture buffers. I do suspect you ran into trouble when you couldn't reference the static lightmap -- I have a feeling you can't just create your own instance since I expect it contains information from a bunch of previous lighting calculations. In terms of refactoring all the fields, I agree sometimes it is almost "impossible". In particular when they are randomizing in things like world generators it takes a lot of investigation to figure out why they're doing things. So don't worry about refactoring everything, but I just suggest always refactoring what you can as then you will understand more and it becomes more properly "your" code.

I am still suspicious that it is related to something with administrator rights (i.e. not having where needed). That type of error is specifically mentioned in other discussions (general gradle discussions) as being the culprit. I'm not sure what might have changed to make this start popping up more. However, the rest of your log has the line: C:\Users\jerem\.gradle\caches\minecraft\net\minecraftforge\forge\1.12.2-14.23.2.2611\userdev\dev.json could not be parsed . So have you looked more closely at that JSON file? Is it there? Is there a problem accessing it? Is it malformed? For the "honor the JVM" thing, it seems that there are various scenarios that cause it. But it is usually possible to figure out based on the rest of the error message. Some of it has to do with your java home evironmental variables. Some of it has to do with admin privileges. Some of it is other things. This is a gradle error though, so maybe there are gradle support available as well that can advise (even though it seems to be a Forge MDK file that is causing your problem).

Not sure. But there is a "clean dependencies" you can run with gradlew that might help.

That's pretty cool actually. One thing about red is that it is a primary display color so makes me think that somewhere that it should be white FFFFFF is somehow FF0000 through shifting or something. But I can't see anything there. I don't think it is a problem with finding the texture since the shapes of the snowflakes are correct. As far as I can think, it can be a blending issue (maybe even blending from before the renderer is called if the GLState has something left over, so look at that GL stuff at the top. Secondly, it could be direct color methods but your color() methods seem to be white. Lastly it could maybe be a lighting issue, although I'm not aware of lighting changing color, but you could look at how it get lighting. I'm most suspicious that the GLState is somehow blending red due to something left over in the state. However, the state is explicitly set to white with the GLStateManager.color() method call, so it is very curious as to how you're getting red. I do feel that it has something to do with blending though. Did you try to disable the blending? You can use GLStateManager.disableBlend() early on in your code (probably right after the enable call). Don't just comment out the enable call because it can possibly already be enabled and you need to make sure it is disabled. One other thing for debug, when I copy code with a lot of fields with obfuscated names like j1, f3, and such, I like to go through and figure out what they do and refactor the name to something meaningful. You might find a clue as you do that.

So to make your own crop generation you should make a StructureVillagePieces.Village subclass like the vanilla Field1 or Field2 class and add your crop. Then use the IVillageCreationHandler to add it to the generation. The IVillageCreationHandler is supposed to be registered to the village registry with VillageRegistry.instance().registerVillageCreationHandler() method. I'm not sure exactly when it should be registered, but I kinda feel it should be in init loading phase because you'd want it after your blocks are registered (in case you have custom blocks used in your village piece). You also need to register your structure component with MapGenStructureIO.registerStructureComponent() method. To make sure it is only in certain biome, I think in your the buildComponent() method of your IVillageCreationHandler you will get parameters for the mixX, minY and minZ (they call them p1, p2, and p3 in the interface declaration). You can use the position to query what biome you're in and check for desert. I'm not super familiar with the above, but based on inspecting the classes I think it should work. Note that you need to register your village with a "weight" that makes sense. You can learn about how that works here: https://minecraft.gamepedia.com/Village/Structures I have an example of a "cloud house" that uses my cloud blocks for walls here: https://github.com/jabelar/ExampleMod-1.12/blob/master/src/main/java/com/blogspot/jabelarminecraft/examplemod/worldgen/structures/villages/VillageHouseCloud.java

Cool. Definitely learn to look at console and log files when debugging. There is usually enough there to get some solid idea of what is wrong.