MFMods
Members-
Posts
370 -
Joined
-
Days Won
13
Everything posted by MFMods
-
hold on. do not do both 1 and 2. do variant 2. annotation on class, annotation on event handler method, make method static. you do not want events to trigger twice.
-
there are two ways that method would be called for that event: variant 1 - manual: you called addListener. see ExampleMod.java for example. variant 2 - automagic: if a class is annotated with @Mod.EventBusSubscriber and the event is made static and annotated with @SubscribeEvent, forge will handle everything. use variant 2, but not in main class.
-
i was reading through https://forge.gemwire.uk/wiki/Capabilities and one thing caught my eye - question: is there - finally - a nice and elegant way to make simple capabilities for internal use? i need to attach two integers to a player. no inter-mod interaction perceived. earlier, when i needed stuff like that, i would just add my field or two into existing nbt tags of an entity and was happy about it. i refuse and will forever refuse to make two interfaces and four classes to attach a long int to a cow to know when it was last milked. back in 1.10 or 1.12 days, i made one or two implementations of IExtendedEntityProperties. i liked IExtendedEntityProperties - it gives me what i need - a few fields stored in a nice and clean manner. but then capabilities came along. and here on the forum nice-new-guy would ask how do i store something in player/itemstack and nice-experienced-guy would say "use capabilities" while an invisible chorus chants "aaaahh" in reverence. to clarify, i have nothing against capabilities in a "fancy machine" scenario. makes total sense. but for a cow scenario (3 rows above)? no sense at all. so what's with the wiki page calling parts of this system optional?
-
not really. wiki is here: https://forge.gemwire.uk/wiki/ but, yes, it is quite general.
- 1 reply
-
- 1
-
so instead of typing "i have a multiblock and want to temporarily remove the boring outer shell to show some fancy-shmancy animation" you decided to go with "here's a bunch of code, work it out"? if the shell block are your blocks, you can set aside one block state for invisible mode (model with zero cubes). if they are vanilla blocks, either memorize them and remove for a while, or, when the multiblock is formed, replace shell blocks with block entities that hold their data and emulate their look.
-
what do you really want to do (what is your scenario)?
-
How to play vanilla sound when spawning an item on right click
MFMods replied to StUnTmAKEr's topic in Modder Support
try this: if first three conditions { if not clientside drop pebble else play sound } i can't fire up the ide now but something like this should work. -
How to change custom block model offset? [1.19.2] [SOLVED]
MFMods replied to RInventor7's topic in Modder Support
look inside the model json file. move all cubes upward. -
Getting support for older minecraft versions
MFMods replied to gwoonryan's topic in General Discussion
not here. but... tutorials were better and more numerous at those days. start with gray ghost's https://github.com/TheGreyGhost/MinecraftByExample/tree/1-8-9final there is plenty more tutorials, so i know you did not search. (do not go to youtube). alternatively, is there someone else's 1.8 mod that does what you need? find it on github. -
you should not register blocks conditionally. i used to disagree with that policy long ago, but i got on board. you should access your option fields from worldgen code (if the block is terrain generated) and recipe conditions (if the block can be crafted). if you are a perfectionist, make a jei plugin that hides blocks that should be inaccessible.
-
make a class EmblemRecipe that extends SpecialRecipe. in method "matches" confirm that the player provided a chestplate (maybe you'll allow adding things in steps?) and things you accept. in "assemble" method you make a recipe result - vanilla chestplate with nbt or your own item with nbt, that's up to you. use SimpleRecipeSerializer as a recipe serializer. register it in RegistryEvent.Register<IRecipeSerializer<?>> event. make a json file like this: { "type": "your_mod_id:recipe_name" } where recipe_name is name you give to the serializer. basically this is the recipe class: public class YourRecipe extends SpecialRecipe { public static IRecipeSerializer<YourRecipe> StupidSerializer = (IRecipeSerializer<YourRecipe>) (new SimpleRecipeSerializer<YourRecipe>(YourRecipe::new).setRegistryName(YourMod.MODID, "recipe_name")); public YourRecipe(ResourceLocation resourceLocation) { super(resourceLocation); } @Override public boolean matches(CraftingInventory inventory, World world) { return true if items are acceptable; } @Override public ItemStack assemble(CraftingInventory inventory) { return nice new itemstack with nbt; } @Override public IRecipeSerializer<?> getSerializer() { return StupidSerializer; } }
-
Issue with creating model for a modded minecraft entity
MFMods replied to IJustExist's topic in Modder Support
do you have a model part called "body"? -
Yep, that was it. Thank you.
-
Literally identical to CraftingMenu (one used by crafting table). Copy and paste. I'll trim it and change it to what I need once we get the window to stay on screen instead of just flashing.
-
yes, you can use tags (nbt tags within the item, not the new "item tags"). you need a custom recipe that takes a chestplate and some items and returns a chestplate with some data in nbt tags. and you need to render your stuff when you render your armor item. if you are going to use the crafting table (you don't have to, it can be your own block), in assemble method of the recipe call startingChestPlate.copy() to get the itemstack to return. then, result.getOrCreateTag() returns the root tag. it's best to make a CompoundTag for your mod, fill it using putString calls and then append your compound tag under the root using the put method.
-
I'm making my first gui window for a block entity. Really, I would have been surprised if things just worked on the first try... what i have: DeferredRegister<MenuType<?>> in registration class and... RegistryObject<MenuType<my thing Menu>> below with a register call. (i assume these two are okay because this menu type is used in inherited constructor of my Container/Menu) event.enqueueWork(() -> MenuScreens.register inside the FMLClientSetupEvent in client setup class. the handler is called, i checked. overridden getMenuProvider in my block class. returns a SimpleMenuProvider which just creates an instance of my menu/container class. overridden use in my block class that calls player.openMenu(state.getMenuProvider(level, pos)); that part is the same as vanilla crafting table and should work. The gui window does open when i right click the block, but it closes instantly. Any ideas?
-
i can't tell from the log. it looks like one of the global loot modifiers for end chests loops infinitely, but i can't say which mod is the problem. try removing one or two mods adding loot to the end (or just related to end) and see of the problem persists. when you find the mod that causes your problem, tell the mod author and play without it for a few days (or get an older version, that sometimes helps).
-
i know you have reasons. and i get that you like flying/gliding. but trust me - modding is rarely smooth sailing. some days it is, but often - especially when you're first time in some terrain - there will be bumps. huge, horrible bumps. you've played minecraft - have you not wished there was some quality of life block or item at any point? have you not thought of some other small detail you might add? just trust me and start with one or two super-small mods. it couldn't never find time to implement everything from my lists of ideas. i refuse to believe you have nothing. anyway, consider yourself forewarned.
-
well, that would give me auto-magical support for any plank type in the game. did anyone have any experience with it?
-
ok. how about second question? can i use block entity renderer to render a json model, but change a resourcelocation of one texture?