-
Posts
5120 -
Joined
-
Last visited
-
Days Won
75
Posts posted by Choonster
-
-
Please don't post your email address publicly. I've removed it from your post.
-
Duplicate of the following topic:
-
Duplicate topic.
-
Duplicate of the following:
-
The bots have been banned.
-
Duplicate of this topic:
-
9 hours ago, Seawarrior said:
i annotated with SubscribeEvent look at the code
Read Paint_Ninja's message again, there's an additional requirement that you're not meeting.
-
Use DamageSource#getDirectEntity to get the projectile entity.
- 1
-
5 hours ago, Hipposgrumm said:
This is a log, not a crash report. Crash reports are in {directory, probably Pixelmon or something}/crash_reports.
The debug.log includes the crash report and other information, there's no need to post crash reports separately.
Regardless, 1.16.3 is no longer supported on this forum.
-
It's entirely possible for crafting table recipes to customise their output (including setting NBT/damage) by overriding IRecipe#assemble. I have a recipe that does a similar thing for armour here.
-
ServerChatEvent was overhauled in the 1.19.1 update to support the secure chat system, it's probably not going to be possible to fix this without updating to 1.19.1 or 1.19.2.
-
19 minutes ago, Sweetmimike said:
Hello,
Thank you for your anwsers, I finally succeeded. I have just one more question :
Why in the code below, the parameter TOOL is not considered ? Indeed, when I try to generate loot from a cow, it generates beef whereas I added a parameter TOOL with a diamond sword with fire aspect, so It should generate Steak.
If you look at the loot table for cows, you'll see that it checks whether the entity is on fire to determine whether to drop steak; not whether the tool has Fire Aspect.
-
I never found a way to ignore the errors; but I eventually replaced HWYLA with Jade, which doesn't have this issue.
-
Instead of using an interface and extending the vanilla entity classes, could you use a capability? You could have a base class with the shared logic and then entity-specific implementations attached to different entity classes.
If you need to do stuff every tick, you'd need to use LivingUpdateEvent.
-
ObfuscationReflectionHelper methods always take SRG names, even in the development environment. In development, the SRG name is automatically remapped to the corresponding MCP name.
-
The second argument of withExistingParent is the path to a model file to use as a parent, not a texture. For basic block items, the model normally uses the block model as the parent, rather than specifying individual textures.
I use this helper method in my BlockStateProvider implementation to generate block item models that simply extend the block model. You can see an example of this here.
On a side note, the DeferredRegister instance should always be created in the same class as it's used in; don't put the DeferredRegister and RegistryObject fields in separate classes.
- 1
-
NBTIngredient doesn't have an of method itself, you're actually calling Ingredient.of. You need to create an instance of NBTIngredient directly (or a class that extends it, since the constructor is protected).
-
2 minutes ago, Draco18s said:
Touche. You can simulate it with the ref keyword, or by returning a Tuple.
Java doesn't have ref either, but does have tuples (from Minecraft and Apache Commons Lang).
-
1 minute ago, Draco18s said:
Learn about the out keyword.
I think you're mixing up C# and Java.
-
On 1/25/2021 at 1:47 AM, ChampionAsh5357 said:
My only comment would be on OpenClientScreenMessage as the Minecraft instance can just be obtained inside the method itself. This is still 'safe' I believe, but we should avoid calling anything that might only be available on the client that is not isolated in a different class. This is my opinion as it still won't be loaded unless on the physical client.
Thanks, that makes sense.
-
19 hours ago, ChampionAsh5357 said:
From what I understand, this is not the correct way to use DistExecutor. For the case where you can't supply a runnable or supplier, DistExecutor#unsafe* should be used instead. This will supply a runnable of what you want to execute (e.g. () -> () -> //Do things). This does not verify nor guarantee that the code is completely safe to access; however, if the runnable executes another method that is isolated in a different class, it is 'safe' since classloading will not occur. So, the proper way to implement the code above is DistExecutor.unsafeRunWhenOn(Dist.CLIENT, () -> () -> ClientScreenManager#openScreen).
Thanks, I think that makes sense.
I've tried to follow this advice and clean up all my DistExecutor code in this commit, does this look correct?
-
I have a packet that's sent to the client to open a GUI, which I'm using DistExecutor to do.
The packet's handler method does the following:
DistExecutor.safeRunWhenOn(Dist.CLIENT, () -> ClientOnlyNetworkMethods.openClientScreen(message))
ClientOnlyNetworkMethods.openClientScreen currently looks like this:
public static DistExecutor.SafeRunnable openClientScreen(final OpenClientScreenMessage message) { return new DistExecutor.SafeRunnable() { @Override public void run() { ClientScreenManager.openScreen(message.getId(), message.getAdditionalData(), Minecraft.getInstance()); } }; }
ClientScreenManager is a client-only class that handles opening the GUI.
As you can see from the code, I need to pass arguments from the packet to the client-only method; which rules out using a method reference as the SafeRunnable implementation.
When I replace the anonymous class implementation of SafeRunnable in ClientOnlyNetworkMethods.openClientScreen with a lambda, DistExecutor.validateSafeReferent throws an "Unsafe Referent usage found in safe referent method" exception. From what I can see, using any non-lambda implementation of SafeReferent simply bypasses the safety checks in validateSafeReferent but doesn't necessarily mean that the code is safe.
The current code with the anonymous class does seem to work on the dedicated server, but is this the correct way to use DistExecutor; or is there a better way to do it?
-
5 hours ago, loordgek said:
https://github.com/MinecraftForge/MinecraftForge/pull/6668
is this what you want ?
Yes, that probably would have been a useful feature. It's a shame that the author didn't have time to complete it.
-
44 minutes ago, diesieben07 said:
This is why getShareTag should be used for the capability data, not some custom system.
You don't have any control over when and how ItemStacks are sent over the network, getShareTag is the only real place.
Part of the idea with my system was to allow syncing capabilities attached to arbitrary items, not just items that know about their capabilities. What would you recommend for capabilities attached to items from Vanilla or another mod?
SafeMode
in Support & Bug Reports
Posted
Duplicate of the following topic: