MFMods

now's the time for behavior, details like hitbox (hitbox is in registration manager), etc. ... 19a) if you want natural spawning, part one: in main mod class, in FMLCommonSetupEvent handler, try something like this: event.enqueueWork(()-> EntitySpawnPlacementRegistry.register(RegistrationManager.WHATEVER.get(), EntitySpawnPlacementRegistry.PlacementType.ON_GROUND, Heightmap.Type.MOTION_BLOCKING_NO_LEAVES, YourEntity::checkYourEntitySpawnRules)); 19b) if you want natural spawning, part two: in another class (i have a dedicated one for this) subscribe to BiomeLoadingEvent. sample code: remember to pick a proper classification. note that we stated the classification in two places, make sure they match. 19c) when seeing whether spawning works, don't be afraid to temporarily subscribe to "entity joins world" event and plop a block of glowstone at x,y+20,z. your time matters. also remember the locate biome command; it can teleport you. 20) for new/unique models, try blockbench. minor changes to existing models can be done in ide (extend model class).

it's true there isn't much - i struggled a lot too recently. but lack of documentation isn't your first problem, it's the order of things. i assume you're making the armor stand mimic as mentioned in the other thread? ok, order of things first... 1) stop writing behavior code until you have your creature on screen. start from scratch. 2) make a class extending zombie entity (for now). i'd even stick with it - zombies can wear armor, have two arms and legs (you'll make them thinner), have walk animation... 3) make a renderer class. if you're retexturing a zombie, you override getTextureLocation and done. or you can use it to replace the model and support the new one. 4) make a spawn egg. do not postpone this, you need to see the thingy on screen. see ForgeSpawnEgg class. (it doesn't exist in 1.16, make a manual/fake spawn egg, you need it asap) 5) you need some registration code. i'll just dump some, it's not something i can explain. (code is for 1.16 but should be ok in 1.18) i hold all of this in one class, you don't have to... 6) make a class for client-only initialization. subscribe to FMLClientSetupEvent and in the handler register your renderer: RenderingRegistry.registerEntityRenderingHandler(RegistrationManager.YOURTHINGY.get(), YourThingyRenderer::new); 6b) in 1.16 you may want to also subscribe to ColorHandlerEvent.Item event and color your spawn egg, if you created it manually. 6c) if Mod.EventBusSubscriber annotation has side parameter, (maybe it's called value), set it to client. otherwise (may depend on game version, not sure) make a new class that has a method that registers class from #6 to a given IEventBus; call that through DistExecutor.safeRunWhenOn in the constructor of your main mod class. 7) almost there... in the constructor of your main mod class activate the stuff from #5. 8] in your main mod class handle EntityAttributeCreationEvent. i may be doing it wrongly - feels wrong to me - but just do as i did because i lost a lot of time until i figured it... if i'm totally wrong about implementing this part, i apologize to whoever was sneezing because of the foul language i was tossing his way. event handler contents: event.put(RegistrationManager.YOUR_THINGY.get(), YourThingyEntity.createAttributes().build()); make createAttributes method in your entity class, copy from most similar vanilla entity (find method with that name). ok, stop and don't proceed until you have a working spawn egg and entity that shows up when you use the egg.

block state has getValue and setValue methods. use them to make a new state and then call world.setBlock. but why do you have two blocks? if it's not more complicated than what you described, you have a block similar to crop or a berry bush. it can be the same block with one more state property. then, when your item is "harvested" from a block, you'd just say world.setBlock(state.setValue(AGE, 0)) and you don't worry about the rotation - it just stays the same.

try opening eclipse normally (just run its exe), then right click the white area in the tree on the left side, click "import project" or "import existing project" and locate the example mod directory. anything different?

that output was for you, not us. i wanted you to assert two things: 1) serializer creates a condition with value true when config file says true 2) serializer creates a condition with value false when config file says false (after you exit the game, change config, start the game) can you confirm that you have that?

if you did any model registration in code, delete that. just register the block itself. in /resources/assets/your_mod_id/blockstates directory should be a file your_block_as_named_in_code.json . in /resources/assets/your_mod_id/models/block directory should be a file your_model_as_named_in_above_file.json . see vanilla oak saplings in minecraft jar.

i assume it's the same block (as far as registration is concerned)? same modid:blockname? if the block was changed too much, i'd consider having two blocks: legacy block and new block. make legacy block tick every minute (like crops) and on tick, replace with the new one. nice and clean.

react to "entity joins world" event. if the entity is a villager, remove goal g1 and add goal my_g1. (if you didn't find g1, you have a conflicting mod.)

yes. yes, there would be. put a log command (output a line into log or a console) in serializer.read, serializer.write and condition.test. write the value they return into console (along with the method name). run the game and look into the console.

remove all mods. it the game crashes, give us the log. then add two mods. then two more. then two more...

start with an empty collection, then add your trades. it is pretty simple. instead you pasted wandering trader code which takes 5 (iirc) trades from one list and adds a 6th one from a second list and you plugged your list into that. as a result - you wasted hours trying to find out why this thing doesn't work, but you did initially save 2 minutes by not reading what the pasted code does. nice job.

one thing you can try is make your own category. is your entity based on a vanilla hostile entity? probably not, but if it is, you need to override something that makes them despawn if they are too far.

can you run a 1.16 example mod on that setup? for 1.17 (which you are trying to start), you will need a parallel setup with java 16.

item model (youritem.json) should be in /src/main/resources/assets/MODID/models/item texture is in good location.

try editing the runClient configuration, setting the module (there is a dropdown) and running it again...

that is one weird stack trace. seems to me that just enough resources is going through loot tables, finds a bad loot table json and spins in a circle. but we can't tell which one is a problem. (problem is possibly in a loot function) so - binary search. remove mods and return them until you find out which mod is the problem. then you can tell the mod developer or find out which loot table is the problem by removing those.

I have a functional creature-entity (I can get it when i use the spawn egg). That was too frustrating but I'll try not to vent. Now i need those things to spawn in swamps. What i have: 1) in FMLCommonSetupEvent i have just one line: EntitySpawnPlacementRegistry.register(RegistrationManager.TESTSLIME.get(), EntitySpawnPlacementRegistry.PlacementType.ON_GROUND, Heightmap.Type.MOTION_BLOCKING_NO_LEAVES, TestSlimeEntity::checkTestSlimeSpawnRules); event fires, but checkTestSlimeSpawnRules is never called. i don't know why. 2) in BiomeLoadingEvent just this: if (event.getCategory() == Biome.Category.SWAMP) { event.getSpawns().getSpawner(EntityClassification.CREATURE).add(new MobSpawnInfo.Spawners(RegistrationManager.TESTSLIME.get(), 8, 1, 4)); } event fires a couple of times (swamp i'm in is likely composed of few small biomes; it is cut up by other biomes). 3) in entity registration, it is classified as EntityClassification.CREATURE. any idea why they won't spawn?

for tooltip, override appendHoverText in your item class. override, don't call.

i don't see the problem. please try without 30 silly resourcepacks; then later - after things start working, put a few of them back.

it depends on damage type somewhat, but event.getPlayer().getMainHandItem() should give you a sword, if you want to check enchantments or whatever.

mc version? forge version? and we need the log.

tile entity may not be needed at all.

ok, i'm not surprised i was wrong about the player, i've only ever sent in opposite direction. getSender is there and i should have checked instead of posting blindly... but how would he know the block location without including it in the message?

you could re-invent the wheel and do exactly what you said.... or you could use world saved data (link). using it makes a dat file in saves/YourWorldName/data directory.

your message class should have two fields: player uuid and button name (and two methods: encode and decode). make an instance of this message class and send it. edit: also include block position in the message.