Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

MFMods

Members
  • Posts

    139
  • Joined

  • Days Won

    2

Everything posted by MFMods

  1. that is not the log you are looking for.
  2. remove the condition part of the recipe. does it then work in game?
  3. if you want recipes to reference other mod's item (other mod being optional and recipe not crashing the game), use forge's mod_loaded condition. look inside the jar file of "create" mod, for example in smelting recipes directory - you'll find smelting recipes that give players lead ingots even though the mod doesn't include lead ingots. if you want the recipe dependent on a switch in your config file, make a condition class.... ...and then in the main class (mod class), in FMLCommonSetupEvent do CraftingHelper.register(new OptionalRecipeCondition.Serializer(new ResourceLocation(YourThing.MODID, "optional"))); this last string ("optional" in example above) is the type that is stated in recipe json.
  4. we can't help you. if BOP's generator only uses BOP biomes and vanilla biomes, there's nothing to do. just don't use it. don't set world type to BOP.
  5. ok, new plan - start over. unpack MDK zip into a new folder and get example mod to start. just import the build.gradle file, that'll make a new project, run genIntellijRuns (you can do it from IDE) and then runClient. do not edit ExampleMod source or anything else until you can start it. only set java version where it's wrong. after you can start it for the first time, you'll make edits to build.gradle, mods.toml and you'll delete a few files (txt, etc.). now it is very important that once you make those changes and confirm that they work, you turn those changes into a command line script (or a shell script). that way, for the next mod, you'll be able to initialize build.gradle and mods.toml in a second and be sure you didn't break anything.
  6. it is okay for other mods to access your capabilities - assuming both developers know what they're doing. i don't feel like looking at source code of either mod, but i can tell you that authors of cold sweat mod had the same issue with half a dozen other mods, including the exile-whatever mod. they changed something two months ago and cut the list of incompatible mods by half. maybe you could ask them about it on their discord?
  7. run genIntellijRuns task (i assume you did). in configuration of the runClient task is a java version dropdown; pick 17. main class box in my ide (2 rows below 17) says "cpw.mods.bootstraplauncher.BootstrapLauncher" without "main". module box (to the right of 17) says main.
  8. the crashlog doesn't say which mod is at fault, sorry. remove 8 mods, retry, then next 8...
  9. because you didn't read the technicalities, you just copied the event handler. make that method static and put the EventBusSubscriber annotation on the containing class. there is a second option and it looks like you tried to follow that one, but just go with the option one (above).
  10. 2 ores, 5 stone types. the easiest way to find out about those things is to go through mods config.
  11. first of all, you know you can look at vanilla recipe json files? find the stone sword recipe and a pumpkin pie recipe, you shouldn't have problems making simple recipes based on those. ...or, there a few recipe generators online. drag and drop a few items and download a json file. (now serious modder wouldn't want to be seen using that, but don't worry about that)
  12. do you have a connection between the player and the villager (one knowing of other withing your mods logic)? if so, try subscribing to player clone event. when the player is cloned (new entity for new dimension, old one is one that entered the portal), have the villager following the old player entity make note of new player entity. and when the new player enters the world (in other dimension), you can try to make a clone of the old villager a few blocks from the portal. just make sure that the dimension change is the reason for cloning.
  13. why don't you make an invisible floating zombie and just give it armor as equipment? that way you render a trivial entity (invisible one), game takes care of armor with support for any armor. you don't need a second entity, just use existing armor stand and have your ghost remember its "home" stand. when the player destroys the armor stand (handle usual event), kill the ghost or assign it to another armor stand, whatever. good thing to note is that you can precisely control which armor parts equipped creature drops and with which chances. when passive, set its location and rotation to that of the armor stand. have it attack and go back. change hitbox (size) to make it an actual ghost.
  14. update from 1.16 to 1.18: instructions above work line-for-line, with no semantic changes. the dialect has changed however. in addition to common changes (level instead of world, etc.), here's a list of things you need to change that are related to making and registering a simple entity: instead of Biome.Category.SWAMP write Biome.BiomeCategory.SWAMP instead of EntityClassification.CREATURE write MobCategory.CREATURE instead of MobSpawnInfo.Spawners write MobSpawnSettings.SpawnerData instead of EntityPredicate use TargetingConditions instead of DataParameter/EntityDataManager/DataSerializers write EntityDataAccessor/SynchedEntityData/EntityDataSerializers instead of IParticleData write ParticleOptions instead of AttributeModifierMap.MutableAttribute write AttributeSupplier.Builder instead of SpawnReason write MobSpawnType instead of ILivingEntityData write SpawnGroupData instead of MovementController write MoveControl instead of WorldEntitySpawner write NaturalSpawner instead of EntitySpawnPlacementRegistry.PlacementType write SpawnPlacements.Type instead of RenderingRegistry.registerEntityRenderingHandler write EntityRenderers.register
  15. to clarify a bit - block (example: crops) can have random ticks enabled. they tick about once a minute. so for example if you want your block to change/grow/mature after five minutes, just skip four ticks (change state each time) and replace block on the fifth tick (or just have a different model for this sixth state. the other kind of ticks happens 20 times each second (hopefully) - please do not use them unless you really, really have to.
  16. no, not mine. hold on, i'll port a test mod to 1.18...
  17. peek into the ClientChatEvent class. i think it's f3 in eclipse and ctrl+b in idea.
  18. you may want to break that up into a few threads, yes. i'll handle the immediate practical problem. yes, you need the obfuscated name. option 1) i think there is a discord bot that you just ask but i never used it. don't ask me. option 2) minecraft developement plugin for idea ide - right click and say copy AT entry to clipboard. option 3) find forge-VERSION_HERE-decomp.jar in .gradle directory inside your home folder. it contains game code with SRG names. compare the same class from that jar with the class with mapped names and copy the field name. for method names you need to specify proper signature (param types and return type). in any case always put a mapped name one row above (comments start with #) so that you know what the row below is.
  19. "entity joins world" event - make your extended villager, copy data from original (if you care to), spawn your villager into the world instead of the original ok, but refreshBrain is public - override it. either let the inherited code do its thing and re-add your stuff, or rewrite the method completely. and it looks like you'll need ATs sooner or later - no worries, they are not a big problem.
  20. you would have one property that controls rotation and one that controls texture (and right-click behavior). look into AbstractFurnaceBlock. it has one property for direction and one for functionality. (you may want to extend HorizontalBlock). look at furnace blockstate json and furnace model json.
  21. 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).
  22. 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.
  23. 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.
  24. 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?
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.