Jump to content

entity.getShadowSize() missing


jredfox

Recommended Posts

entity get shadow size is missing I used this for rendering entities in inventory based on the item's nbt similar to nei and that's how I scaled the entity for open gl based on that shadow size. How am I suppose to do this in 1.12.2 with no IItemRender and no shadow size?

 

yes this is missing no workaround for object orientation just hard code shadowsize = ent.height / 2.0F;

Edited by jredfox
Link to comment
Share on other sites

On 4/11/2018 at 3:21 AM, diesieben07 said:

Render::shadowSize stores the value.

The renderer hashmaps even in post init appear to be empty I tried running this is my proxies post init

and it printed for the hashMaps:"[ ]"
 

public static void populateShadowSizes() 
	{
		System.out.println("Cacheing Shadow Sizes");
		RenderingRegistry rinstance = (RenderingRegistry) ReflectionUtil.getObject(null,RenderingRegistry.class, "INSTANCE");
		Map<Class<? extends Entity>, Render<? extends Entity>> entityRenderersOld = (Map<Class<? extends Entity>, Render<? extends Entity>>)ReflectionUtil.getObject(rinstance, RenderingRegistry.class, "entityRenderersOld");
		JavaUtil.printMap(entityRenderersOld);
		//populate list
		Map<Class<? extends Entity>, IRenderFactory<? extends Entity>> facRenders = (Map<Class<? extends Entity>, IRenderFactory<? extends Entity>>) ReflectionUtil.getObject(rinstance, RenderingRegistry.class, "entityRenderers");
		RenderManager rmanager = Minecraft.getMinecraft().getRenderManager();
		for(Class<? extends Entity> clazz : facRenders.keySet())
			entityRenderersOld.put(clazz, facRenders.get(clazz).createRenderFor(rmanager));
		
		for(Class clazz : entityRenderersOld.keySet())
		{
			ResourceLocation loc = EntityList.getKey(clazz);
			Render render = entityRenderersOld.get(clazz);
			Float shadowSize = (Float) ReflectionUtil.getObject(render, Render.class, MCPMappings.getField(Render.class, "shadowSize"));
			entShadows.put(loc,shadowSize);
		}
		for(ResourceLocation loc : entShadows.keySet())
			System.out.println(loc  + " shadowSize:" + entShadows.get(loc));
	}

 

Link to comment
Share on other sites

RenderingRegistry is just temporary storage for mod entity renderers/factories during the startup process, RenderManager#entityRenderMap stores the actual instances used to render entities during gameplay.

  • Thanks 1

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

15 hours ago, Choonster said:

RenderingRegistry is just temporary storage for mod entity renderers/factories during the startup process, RenderManager#entityRenderMap stores the actual instances used to render entities during gameplay.

during post init those maps are always empty then? I should be grabbing them from the render manager during post init?

Link to comment
Share on other sites

3 hours ago, jredfox said:

during post init those maps are always empty then? I should be grabbing them from the render manager during post init?

 

They won't be empty if there are mods that have used the RenderingRegistry methods, but they'll never have the Vanilla instances and the Render instances you create from the IRenderFactory instances won't be the same ones that are used to render the entities during gameplay. It's best to use the ones stored in RenderManager.

 

Mods that use the non-deprecated IRenderFactory registration method of RenderingRegistry will have their Render instances added to the RenderManager instance when it's created between preInit and init. Mods that use the deprecated Render registration method of RenderingRegistry will have their Render instances added to the RenderManager instance after postInit.

 

If you really want to support the mods that are still using the deprecated method two years after it was replaced (it was deprecated with this commit and meant to be removed in 1.9), you could lazy-load the shadow sizes for each class when they're required rather than loading them all at startup.

  • Thanks 1

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

On 4/14/2018 at 6:37 PM, Choonster said:

 

They won't be empty if there are mods that have used the RenderingRegistry methods, but they'll never have the Vanilla instances and the Render instances you create from the IRenderFactory instances won't be the same ones that are used to render the entities during gameplay. It's best to use the ones stored in RenderManager.

 

Mods that use the non-deprecated IRenderFactory registration method of RenderingRegistry will have their Render instances added to the RenderManager instance when it's created between preInit and init. Mods that use the deprecated Render registration method of RenderingRegistry will have their Render instances added to the RenderManager instance after postInit.

 

If you really want to support the mods that are still using the deprecated method two years after it was replaced (it was deprecated with this commit and meant to be removed in 1.9), you could lazy-load the shadow sizes for each class when they're required rather than loading them all at startup.

Ok it appears there is a major issue in 1.7.10 and below entity shadow size was always for vanilla mobs this.height/2. it is simply not the case here what should I be looking for in later versions? I used it in past for render like nei on mob spawners. I printed was that entity.height/2 == size it said false
 

minecraft:ender_dragon:0.5 false

 

Link to comment
Share on other sites

31 minutes ago, jredfox said:

Ok it appears there is a major issue in 1.7.10 and below entity shadow size was always for vanilla mobs this.height/2. it is simply not the case here what should I be looking for in later versions? I used it in past for render like nei on mob spawners. I printed was that entity.height/2 == size it said false
 


minecraft:ender_dragon:0.5 false

 

 

That's what Entity#getShadowSize returned, but that method no longer exists; if you compare the 1.7.10 and 1.12.2 implementations of Render#renderShadow, you'll see that they're fairly similar but the entity's shadow size is no longer used.

 

The Render#shadowSize field is 0.5 for RenderDragon in both 1.7.10 and 1.12.2.

Please don't PM me to ask for help. Asking your question in a public thread preserves it for people who are having the same problem in the future.

Link to comment
Share on other sites

50 minutes ago, Choonster said:

 

That's what Entity#getShadowSize returned, but that method no longer exists; if you compare the 1.7.10 and 1.12.2 implementations of Render#renderShadow, you'll see that they're fairly similar but the entity's shadow size is no longer used.

 

The Render#shadowSize field is 0.5 for RenderDragon in both 1.7.10 and 1.12.2.

but, the entity.getShadowSize() for ender dragon was like 1.5 or something. so I can't use that data for what I need anymore I will just hardcode it for 1.12.2+ thanks anyways.

Link to comment
Share on other sites

  • 3 months later...
On 4/12/2018 at 5:56 PM, jredfox said:

Entity

 

On 4/14/2018 at 6:37 PM, Choonster said:

 

They won't be empty if there are mods that have used the RenderingRegistry methods, but they'll never have the Vanilla instances and the Render instances you create from the IRenderFactory instances won't be the same ones that are used to render the entities during gameplay. It's best to use the ones stored in RenderManager.

 

Mods that use the non-deprecated IRenderFactory registration method of RenderingRegistry will have their Render instances added to the RenderManager instance when it's created between preInit and init. Mods that use the deprecated Render registration method of RenderingRegistry will have their Render instances added to the RenderManager instance after postInit.

 

If you really want to support the mods that are still using the deprecated method two years after it was replaced (it was deprecated with this commit and meant to be removed in 1.9), you could lazy-load the shadow sizes for each class when they're required rather than loading them all at startup.

Ok first off if I cache the sizes is it the same as entity.getShadowSize() in versions <= 1.7.10? If it is how am I suppose to support the depreciated version which fires after post init on load complete then? I prefer to have everything added depreciated or not.

I need this code for rendering entities and scaling them based on their shadow size in item blocks with mob spawners

Link to comment
Share on other sites

On 8/7/2018 at 9:50 AM, jabelar said:

Why shadow size instead of the actual width of the entity?

because nei render code for mob spawners goes based upon shadow size to adjust the scale size for bigger entities without the new dynamic scaling that I don't entirely agree with or like.

Edited by jredfox
Link to comment
Share on other sites

On 4/16/2018 at 4:39 AM, Choonster said:

 

That's what Entity#getShadowSize returned, but that method no longer exists; if you compare the 1.7.10 and 1.12.2 implementations of Render#renderShadow, you'll see that they're fairly similar but the entity's shadow size is no longer used.

 

The Render#shadowSize field is 0.5 for RenderDragon in both 1.7.10 and 1.12.2.

I know the fields are not the same the dragon render is 4.0 in 1.7.10 and 0.5 in the render manager. What am I suppose to do?\


Also the entity dragon is the same size as a blaze so this is not reliable for what I needed the shadow sizes on based on 1.7.10 getShadowSize()

[17:13:42] [main/INFO] [STDOUT]: [com.EvilNotch.lib.minecraft.proxy.ClientProxy:onLoadComplete:105]: EntityBlaze,0.5
[17:13:42] [main/INFO] [STDOUT]: [com.EvilNotch.lib.minecraft.proxy.ClientProxy:onLoadComplete:105]: EntityDragon,0.5
        float scale = 0.4375F;
        if(EntityUtil.getShadowSize(entity) > 1.5)
            scale = 0.1F;

where the scale for rendering the entities in the item block mob spawner would become smaller
 

Link to comment
Share on other sites

1 hour ago, jredfox said:

because nei render code for mob spawners goes based upon shadow size to adjust the scale size for bigger entities without the new dynamic scaling that I don't entirely agree with or like.

This is a ridiculous statement. Why not just make your own way of scaling the entities that is possible in the recent versions of Minecraft and is more stable. What if there was a modded entity that was bigger than the Ender Dragon and the shadow size represented that, and a scale size of .1 did not successfully shrink the entity enough.

VANILLA MINECRAFT CLASSES ARE THE BEST RESOURCES WHEN MODDING

I will be posting 1.15.2 modding tutorials on this channel. If you want to be notified of it do the normal YouTube stuff like subscribing, ect.

Forge and vanilla BlockState generator.

Link to comment
Share on other sites

4 hours ago, Animefan8888 said:

This is a ridiculous statement. Why not just make your own way of scaling the entities that is possible in the recent versions of Minecraft and is more stable. What if there was a modded entity that was bigger than the Ender Dragon and the shadow size represented that, and a scale size of .1 did not successfully shrink the entity enough.

I like nei and older render I am porting older render code. Dynamic scaling will be an option eventually but, till everything else is done I am not even going to consider it especially since in the items it would be barley see able unless I increased the scale and developed my own dynamic scaling.

99% of entities didn't override the method anyways for the shadow size meaning it's going to work most of the time entity.height/2 to get it's size. The code is ported from nei and older versions using their equations so I am confident that it won't break and if a giant massive mob shows up I like to see it render.

Anyways looking at the Render.class I don't see why they removed it the entire part when rendering shadows is gone seems stupid to not have that anymore since it was part of the equation for rendering and now it's completely gone.

Edited by jredfox
Link to comment
Share on other sites

Just add the old method in through a core mod or something. Your core modding everything else I don’t see how this is different

About Me

Spoiler

My Discord - Cadiboo#8887

My WebsiteCadiboo.github.io

My ModsCadiboo.github.io/projects

My TutorialsCadiboo.github.io/tutorials

Versions below 1.14.4 are no longer supported on this forum. Use the latest version to receive support.

When asking support remember to include all relevant log files (logs are found in .minecraft/logs/), code if applicable and screenshots if possible.

Only download mods from trusted sites like CurseForge (minecraft.curseforge.com). A list of bad sites can be found here, with more information available at stopmodreposts.org

Edit your own signature at www.minecraftforge.net/forum/settings/signature/ (Make sure to check its compatibility with the Dark Theme)

Link to comment
Share on other sites

Honestly fox - If you're already porting code, then you could do it completly. And evaluating a scale isn't hard math... 

 

float scale = desiredSize/Math.max(height,width);

 

Will scale it down to desired size (I'm unsure which one's your problem, or if you're maybe rotating it, so it supports both height and width (cause it's 3 dimensional you propably want to take z-axis in account to... I haven't put much thought into it) ) . 

Edited by Major Tuvok
A scaling method
Link to comment
Share on other sites

On 8/11/2018 at 1:36 AM, Cadiboo said:

Just add the old method in through a core mod or something. Your core modding everything else I don’t see how this is different

the point of adding the method back has to be done with forge since mods have to override it when necessary that's the only part I was worried about.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • They were already updated, and just to double check I even did a cleanup and fresh update from that same page. I'm quite sure drivers are not the problem here. 
    • i tried downloading the drivers but it says no AMD graphics hardware has been detected    
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.