-
Posts
141 -
Joined
-
Last visited
Everything posted by Koward
-
Unfortunately it just mess up the block movement every tick, it's not the effect I'm looking for at all. I would basically like items to stay, in water, at the height I throw them. Avoid them to sink. Here the standard behavior happens between each triggering of the event so it sinks a bit, then goes back up a bit, etc and in the end the sinking wins.
-
Hello. I'd like to change the motionX, Y, Z of an Entity (NOT a LivingEntity) to 0 (or whatever value) when it's in Water. There's no simple "EntityUpdate" event so I wondered what was the best way to do it.
-
Forcing my own lightmap texture so ? I think it does handle sky exposure, maybe phases.. I'm not sure how that would work out... You already did it yourself in the past ?
-
I would like to differentiate the lightmap updating between dimensions by editing EntityRenderer.updateLightmap(), change the perceived brightness (lighter/darker) according to moon phases or random days I decided.
-
Now add a simple test() method with let's say, a println, and call it. ((SpecialEntityRenderer) Minecraft.getMinecraft().entityRenderer).test(). Boom, crash. Because this is not an instance of SpecialEntityRenderer, so you're calling something the object don't have. When existing methods are called, it's the EntityRenderer behavior that will be chosen, not the Special one.
-
In the client proxy, yes. Anyone can try for himself. Do a class that extends EntityRenderer (no need to edit anything, just do a useless class) and add the code I posted in OP in ClientProxy.preInit(), the crash will happen, it's easy to reproduce. I do not know exactly what happens between startGame() and the triggering of preInit(), maybe doing the swap earlier (than preInit()) could do the trick.. which is assuming the rest of startGame() after the instanciation does not modify entityRenderer which is a big assumption since it has already been registered and can by that point be called by absolutely everything in the mean time. Given prompts that appear sometimes, I'm f*cking up something with FML too, so my hope is decreasing.
-
Hi. I would like to edit what EntityRender does. I first tried the naive way : extend it, and replace the (already public) field Minecraft.entityRenderer, at preInit. assert(Minecraft.getMinecraft().entityRenderer != null); Minecraft.getMinecraft().entityRenderer = new ModdedEntityRenderer(Minecraft.getMinecraft(), Minecraft.getMinecraft().getResourceManager()); ((IReloadableResourceManager) Minecraft.getMinecraft().getResourceManager()).registerReloadListener(Minecraft.getMinecraft().entityRenderer); As expected, Crash report : http://hastebin.com/uzumikujim.txt The original renderer is instanciated at startGame() and probably holds data I loose when overriding the field with a fresh instance, hence the crash I suppose. Could I do it any other way than byte code patching or is it really too deep for more.. conventional modding ?
-
[1.10.2] [SOLVED] Increase/Decrease walkspeed without FOV change
Koward replied to Koward's topic in Modder Support
Both. At the moment I call changeSpeed(), which does attribute*modifier , the new FOV is calculated by AbstractClientPlayer and then a FOVUpdateEvent is triggered. I disregard the new FOV and instead I recalculate it with the value it had before my changes, attribute/modifier. /** * Edit the speed of an entity. * * @param entity * @param speedModifierUUID * Unique UUID for modification * @param name * Unique name for easier debugging * @param modifier * The speed will be multiplied by this number */ public static void changeSpeed(EntityLivingBase entity, UUID speedModifierUUID, String name, double modifier) { AttributeModifier speedModifier = (new AttributeModifier( speedModifierUUID, name, modifier - 1, 2)); IAttributeInstance attributeinstance = entity .getEntityAttribute(SharedMonsterAttributes.MOVEMENT_SPEED); if (attributeinstance.getModifier(speedModifierUUID) != null) { attributeinstance.removeModifier(speedModifier); } attributeinstance.applyModifier(speedModifier); } /** * Cancel the FOV decrease caused by the decreasing speed due to player penalties. * Original FOV value given by the event is never used, we start from scratch 1.0F value. * Edited from AbstractClientPlayer.getFovModifier() * @param event */ @SubscribeEvent public void onFOVUpdate(FOVUpdateEvent event) { EntityPlayer player = event.getEntity(); float modifier = PenaltyManager.getHealthAndExhaustionModifier(player); float f = 1.0F; if (player.capabilities.isFlying) { f *= 1.1F; } IAttributeInstance iattributeinstance = player.getEntityAttribute(SharedMonsterAttributes.MOVEMENT_SPEED); double oldAttributeValue = iattributeinstance.getAttributeValue() / modifier; f = (float)((double)f * ((oldAttributeValue / (double)player.capabilities.getWalkSpeed() + 1.0D) / 2.0D)); if (player.capabilities.getWalkSpeed() == 0.0F || Float.isNaN(f) || Float.isInfinite(f)) { f = 1.0F; } if (player.isHandActive() && player.getActiveItemStack() != null && player.getActiveItemStack().getItem() == Items.BOW) { int i = player.getItemInUseMaxCount(); float f1 = (float)i / 20.0F; if (f1 > 1.0F) { f1 = 1.0F; } else { f1 = f1 * f1; } f *= 1.0F - f1 * 0.15F; } event.setNewfov(f); } There is still a small zoom in&zoom out effect for a brief time each time there's a change, but I guess it's the best we can achieve without coremod. -
[1.10.2] [SOLVED] Increase/Decrease walkspeed without FOV change
Koward replied to Koward's topic in Modder Support
Done. Works well, thank you, I just divided the attribute value by the modifier (that I multiplied before) to get the old attribute value the fov was previously computed with. -
[1.10.2] [SOLVED] Increase/Decrease walkspeed without FOV change
Koward replied to Koward's topic in Modder Support
fovSetting does not vary with sprint & other effects. That would make everything look constant. I want only my changes to not be affected by FoV change. -
Hi. I have an old problem I can never find a good fix for. I simply want to change the player's speed by a given float modifier. The field of view is however linked to the SharedMonsterAttribute.MOVEMENT_SPEED. Changing this attributes generates horrible zooms, and editing the FOVUpdateEvent is buggy because I don't want to cancel all FOV changes, I just want my speed variations to not trigger it. At the moment, it looks like this : /** * Edit the speed of an entity. * * @param entity * @param speedModifierUUID * Unique UUID for modification * @param name * Unique name for easier debugging * @param modifier * The speed will be multiplied by this number */ public static void changeSpeed(EntityLivingBase entity, UUID speedModifierUUID, String name, double modifier) { AttributeModifier speedModifier = (new AttributeModifier( speedModifierUUID, name, modifier - 1, 2)); IAttributeInstance attributeinstance = entity .getEntityAttribute(SharedMonsterAttributes.MOVEMENT_SPEED); if (attributeinstance.getModifier(speedModifierUUID) != null) { attributeinstance.removeModifier(speedModifier); } attributeinstance.applyModifier(speedModifier); } Note my method takes a simple EntityLivingBase because I could, but all I need is something for EntityPlayer. I tried to apply a negative player.moveEntityWithHeading, it did not work (stuck effect). Any idea ?
-
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
I am using a simple new ItemBlock(block).setRegistryName(block.getRegistryName()), so I guess you're right, it probably does not take in account that and always return 0. Good news, ItemMultiTexture works, thanks. The constructor take two Block objects, I have no idea why, I put twice the same Block to test (I thought I would get some relevant error to help me) and it worked, which is surprising. Thank you. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
Models do show up now, thanks. My last problem is that, with one of my new types of stone, while the item is ok in inventory/hand, the block spawned is always the default state. Blocks added during World generation are okay, so both item&block exist but the item does not seem linked to it. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
Yes but it tries to find a bark.json, which does not exist. It's weird because I never pointed to just "bark" in the ModelLoader method. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
Here is some code. ItemBark.java : package koward.stratification.item; import java.util.List; import com.google.common.base.Predicate; import net.minecraft.block.BlockPlanks; import net.minecraft.block.properties.PropertyEnum; import net.minecraft.block.state.IBlockState; import net.minecraft.creativetab.CreativeTabs; import net.minecraft.item.Item; import net.minecraft.item.ItemStack; import net.minecraftforge.fml.relauncher.Side; import net.minecraftforge.fml.relauncher.SideOnly; public class ItemBark extends Item { public static final PropertyEnum VARIANT = PropertyEnum.create("variant", BlockPlanks.EnumType.class, new Predicate() { public boolean apply(BlockPlanks.EnumType type) { return type.getMetadata() >= 4; } public boolean apply(Object p_apply_1_) { return this.apply((BlockPlanks.EnumType) p_apply_1_); } }); public ItemBark() { setHasSubtypes(true); setUnlocalizedName("bark"); setCreativeTab(CreativeTabs.MATERIALS); setRegistryName("bark"); } public String getUnlocalizedName(ItemStack stack) { String variantName; int meta = stack.getMetadata(); switch (meta){ case 0: variantName = "oak"; break; case 1: variantName = "spruce"; break; case 2: variantName = "birch"; break; case 3: variantName = "jungle"; break; case 4: variantName = "acacia"; break; case 5: variantName = "dark_oak"; break; default: variantName = "error_meta_" + Integer.toString(meta); break; } return super.getUnlocalizedName() + "." + variantName; } @SideOnly(Side.CLIENT) public void getSubItems(Item itemIn, CreativeTabs tab, List list) { list.add(new ItemStack(itemIn, 1, BlockPlanks.EnumType.OAK .getMetadata())); list.add(new ItemStack(itemIn, 1, BlockPlanks.EnumType.SPRUCE .getMetadata())); list.add(new ItemStack(itemIn, 1, BlockPlanks.EnumType.BIRCH .getMetadata())); list.add(new ItemStack(itemIn, 1, BlockPlanks.EnumType.JUNGLE .getMetadata())); list.add(new ItemStack(itemIn, 1, BlockPlanks.EnumType.ACACIA .getMetadata())); list.add(new ItemStack(itemIn, 1, BlockPlanks.EnumType.DARK_OAK .getMetadata())); } } ModItems.java (methods to register and link models) package koward.stratification.item; import koward.stratification.Stratification; import net.minecraft.client.renderer.block.model.ModelResourceLocation; import net.minecraft.creativetab.CreativeTabs; import net.minecraft.item.Item; import net.minecraftforge.client.model.ModelLoader; import net.minecraftforge.fml.common.registry.GameRegistry; public final class ModItems { public static final Item BARK = new ItemBark(); private ModItems(){} public static void register(){ GameRegistry.register(BARK); } public static void linkModels() { setModelLocation(ModItems.BARK, 0, "bark_oak"); setModelLocation(ModItems.BARK, 1, "bark_spruce"); setModelLocation(ModItems.BARK, 2, "bark_birch"); setModelLocation(ModItems.BARK, 3, "bark_jungle"); setModelLocation(ModItems.BARK, 4, "bark_acacia"); setModelLocation(ModItems.BARK, 5, "bark_dark_oak"); } public static void setModelLocation(Item item, int meta, String file) { ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(Stratification.MODID + ":" + file, "inventory")); } } register() is called in my CommonProxy class at preInit() and linkModels() is called in ClientProxy at init(). bark_oak.json (others are identical besides of course the texture) { "parent":"builtin/generated", "textures": { "layer0":"minecraft:blocks/log_oak" }, "display": { "thirdperson": { "rotation": [ -90, 0, 0 ], "translation": [ 0, 1, -3 ], "scale": [ 0.55, 0.55, 0.55 ] }, "firstperson": { "rotation": [ 0, -135, 25 ], "translation": [ 0, 4, 2 ], "scale": [ 1.7, 1.7, 1.7 ] } } } -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
Okay so I do have to make only one single json file with variants in the json code (as I don't use any custom mapper). For /blockstates. The blocks are fine when placed, but their inventory counter part is the classic Purple&Black, and a size of 1 block even in hand. EDIT : The rendering don't work because it tries to look for a non-existing json. For example, I have an item "bark" which use metadata to be any type of wood. I get this error (the mod is called stratification) : [00:15:24] [Client thread/ERROR] [FML]: Exception loading model for variant stratification:bark#inventory for item "stratification:bark", normal location exception: net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model stratification:item/bark with loader VanillaLoader.INSTANCE, skipping at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.java:153) ~[ModelLoaderRegistry.class:?] at net.minecraftforge.client.model.ModelLoader.loadItemModels(ModelLoader.java:317) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelBakery.loadVariantItemModels(ModelBakery.java:170) ~[ModelBakery.class:?] at net.minecraftforge.client.model.ModelLoader.setupModelRegistry(ModelLoader.java:147) ~[ModelLoader.class:?] at net.minecraft.client.renderer.block.model.ModelManager.onResourceManagerReload(ModelManager.java:28) [ModelManager.class:?] at net.minecraft.client.resources.SimpleReloadableResourceManager.registerReloadListener(SimpleReloadableResourceManager.java:122) [simpleReloadableResourceManager.class:?] at net.minecraft.client.Minecraft.startGame(Minecraft.java:540) [Minecraft.class:?] at net.minecraft.client.Minecraft.run(Minecraft.java:386) [Minecraft.class:?] at net.minecraft.client.main.Main.main(Main.java:118) [Main.class:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_102] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_102] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_102] at net.minecraft.launchwrapper.Launch.launch(Launch.java:135) [launchwrapper-1.12.jar:?] at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_102] at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_102] at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:1.8.0_102] at java.lang.reflect.Method.invoke(Unknown Source) ~[?:1.8.0_102] at net.minecraftforge.gradle.GradleStartCommon.launch(GradleStartCommon.java:97) [start/:?] at GradleStart.main(GradleStart.java:26) [start/:?] Caused by: java.io.FileNotFoundException: stratification:models/item/bark.json It should never look for bark.json since it's not a possible combination (possible ones are bark_oak, bark_spruce...) Besides that I also have a few net.minecraft.client.renderer.block.model.ModelBlockDefinition$MissingVariantException -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
My JSON structure is probably bad. I tried to compare with vanilla stone structure and it gets weirder and weirder. For stone, each variant has its file (I'm talking about /blockstates). And the "variants" of the stone.json are "variants": { "normal": [ { "model": "stone" }, { "model": "stone_mirrored" }, { "model": "stone", "y": 180 }, { "model": "stone_mirrored", "y": 180 } ] } So it does not look related to the actual meta variants. And I did not know that so it's probably why everything is messed. I will try it a bit later but I think that will solve my problems, thank you. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
I did. And I registered the rendering with for blocks (and their items at the same time, I believe) : ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), meta, new ModelResourceLocation(modid + ":" + file, "inventory")); for items : ModelLoader.setCustomModelResourceLocation(item, meta, new ModelResourceLocation(modid + ":" + file, "inventory")); I do it for each meta, so if I read the documentation well I should not need ModelBakery at all, right ? -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
With just a GameRegistry.register(block); GameRegistry.register(new ItemBlock(block).setRegistryName(block.getRegistryName())); it should create all possible combination item (item for the user, not talking about the class) ? Maybe I messed something somewhere else then.. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
Then I ask the question, how to properly register all the variants of a Block ? (and corresponding items). I can do standard blocks easily but with variants I end up with duplicate items in inventory. My end goal is to do two new variants of stone, and two new variants of each ore. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
I understand what you mean, I was trying to say 1 Block : 1 variant (no metadata). Which leads me to the question whether BlockStates are a good way to create different blocks (for the end user (who considers p.e. Stone and Diorite as different blocks)). The whole meta/blockstates thing looks more suited to changing blocks like Pistons or Doors. But it's not really the point of this topic. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
Well... nothing, I'll just turn all my blocks to 1 instance : 1 item as you said. But I still feel it's less a necessity than a guideline (which I'll be happy to follow). Thanks a lot, topic solved. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
There is no difference for the end user between two types and two items. And for the modding part I don't see anything you could do one way and not the other. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
The class BlockStone use metadata. In the end you get multiple blocks&items : Stone, Granite, Smooth Granite, Diorite, Smooth Diorite, Andesite and Smooth Andesite. The class BlockOre does not use metadata. In the end you have multiple items too, each ore (beside maybe Redstone which is in another class because of its special behaviour, but you get it). In both cases we have one class that ends up doing multiple blocks&items. But it's a different technique. - with BlockStone uses one meta value per variant, and checks this meta in its methods. Only one instance of BlockStone is created and registered. - with BlockOre for each variant a new instance is created, and methods are then applied on them to differentiate behaviour (like hardness). Before 1.9 both ways were perfectly working. -
[SOLVED][1.10.2] The Nightmare of Variants registering
Koward replied to Koward's topic in Modder Support
So the way BlockStone works (all of it here is in the end just an instance stored in Blocks.STONE) : ... STONE(0, MapColor.STONE, "stone"), GRANITE(1, MapColor.DIRT, "granite"), GRANITE_SMOOTH(2, MapColor.DIRT, "smooth_granite", "graniteSmooth"), DIORITE(3, MapColor.QUARTZ, "diorite"), DIORITE_SMOOTH(4, MapColor.QUARTZ, "smooth_diorite", "dioriteSmooth"), ANDESITE(5, MapColor.STONE, "andesite"), ANDESITE_SMOOTH(6, MapColor.STONE, "smooth_andesite", "andesiteSmooth"); ... You do not recommend it at all for modding ? I really wonder why Mojang did this instead of the ore way. Honestly this should be written somewhere because I'm pretty sure I'm not the only one to look at vanilla examples to figure out stuff and this one is pretty confusing.