Simple as the title suggests. My event is subscribed properly and system.out.println works but the setLootingLevel thingy does not work.

Also please explain what "does not work" really means. How did you test it?

Code: Really, it is just a basic:

@SubscribeEvent(priority = EventPriority.NORMAL) 
	public void HandleEnchant(LootingLevelEvent fEvent)
	{	
	
		
		int levelLooting = 10

        //Testing
		
		fEvent.setLootingLevel(fEvent.getLootingLevel() + 3 + ((levelLooting - 1) * 2));
		
		System.out.println(fEvent.getLootingLevel());
}

 

The way it "doesn't work" is that if you put any value in the setLootingLevel, it still returns 1 (1 refers to default looting value which is added by 1 per looting level). However. if you have a looting enchantment, it changes (e.g. 2, 3, 4, and etc.).

56 minutes ago, [NoOneButNo] said:

Code: Really, it is just a basic:

@SubscribeEvent(priority = EventPriority.NORMAL) 
	public void HandleEnchant(LootingLevelEvent fEvent)
	{	
	
		
		int levelLooting = 10

        //Testing
		
		fEvent.setLootingLevel(fEvent.getLootingLevel() + 3 + ((levelLooting - 1) * 2));
		
		System.out.println(fEvent.getLootingLevel());
}

 

The way it "doesn't work" is that if you put any value in the setLootingLevel, it still returns 1 (1 refers to default looting value which is added by 1 per looting level). However. if you have a looting enchantment, it changes (e.g. 2, 3, 4, and etc.).

Shouldn't your handle function be static ?

 

public static void	HandleEnchant(final LootingLevelEvent event);

Also, I suggest your event would be final.

 

---

 

EDIT: my bad, I didn't see your handle function was properly called.

Edited March 8, 20187 yr by Major Squirrel

55 minutes ago, Major Squirrel said:

Shouldn't your handle function be static ?

Only if you use @Mod.EventBusSubscriber or register a class containing @SubscribeEvent methods.

1 hour ago, Major Squirrel said:

Also, I suggest your event would be final.

All this does it prevent you from assigning a value to it (which, if we're being honest, is something you shouldn't be doing anyway). You can still modify the event's properties through the setter methods, which is an ability you want to have.

 

As far as I'm concerned this suggestion is just adding a sticky note to the breaker box that says "do not repair." No one was going to be repairing it anyway, but we're absolutely going to go in and fiddle with the switches.

Back to the original problem. I don't have my workspace on this computer, but maybe the setLootingLevel() or getLootingLevel() is validating the value and clamping it to a certain range. For example, your math in your event would set looting level to 21 higher than what it already is. Is that a valid level? I thought looting levels go to 3 or something....

5 hours ago, larsgerrits said:

Only if you use @Mod.EventBusSubscriber or register a class containing @SubscribeEvent methods.

Like I said, it is properly registered and thus, system.out.println works. Otherwise it won't.

3 hours ago, jabelar said:

Back to the original problem. I don't have my workspace on this computer, but maybe the setLootingLevel() or getLootingLevel() is validating the value and clamping it to a certain range. For example, your math in your event would set looting level to 21 higher than what it already is. Is that a valid level? I thought looting levels go to 3 or something....

There is no clamp. You can get looting 1000 enchantment and probably crash the game. I've read it in the event's code itself. Also, I've read its call hierarchy.

I looked through the call hierarchy and technically in some cases it is in fact clamped. The LootingEnchantBonus.apply() method clamps the loot level to the "limit" which is set by deserializing the loot JSON for the looting_echant limit value. Now I don't think the vanilla looting tables specify a limit so I think they should deserialize to 0 in which case the clamping won't happen. But just saying there are cases of code that might impact the looting after you process your event so you need to look at that.

 

I think you should just use standard debugging and set breakpoints and trace the value along the way. Computers are pretty much perfectly logical so if you trace every step you're sure to see where it does something you didn't expect, and then the answer will be clear.

Edited March 9, 20187 yr by jabelar

6 hours ago, jabelar said:

I looked through the call hierarchy and technically in some cases it is in fact clamped.

But what's more interesting is that whatever value you put it will always yield 1 as if nothing is changed. The only way it changes is if you have a looting enchantment on the item you used to kill a particular entity.

3 hours ago, [NoOneButNo] said:

But what's more interesting is that whatever value you put it will always yield 1 as if nothing is changed. The only way it changes is if you have a looting enchantment on the item you used to kill a particular entity.

 

I have tried your function and the event had a lootingLevel value of 21. The context I tested it was killing a polar bear with a diamond sword (no enchants), it dropped me 12 fish.

 

In which context have you tested your event ?

Apparently, I tested this event in the latest forge vs the recommended and somehow, this bug didn't trigger. Try using the recommended one. It is working in the latest forge for some reason...