Hey! I've recently returned to developing Forge applications for version 1.9, but got stuck with some basic stuff.

The mod I am trying to create is client-side only, and therefore the events working in Singleplayer are not triggered.

 

Currently I list all items dropped when a mob dies (which was killed by the player) in the chat, but the LivingDropsEvent used in this case is (as expected) not triggering when used on a server without the mod. I am aware of the fact that it can't work the way I am trying, and would be delighted if someone could point me into the right direction. As this is a very basic scenario, I do not think it is neccessary to provide the code.

Most events are only posted on the server so if you find you need any of them to make your mod, then the only solution is to not make a client-side-only mod.

Every in-game change should be done server, which means the drops should be changed on the server side.

So, are you planning to make a SSP-only mod?

The mod is supposed to enhance and provide extra functions for a server I play, e.g display the name of a dropped item before picking it up; I do know it is possible, but I wasn't able to find a client-side only solution myself yet

I think it'd be more effective to check if the mob dying was killed by the user, as that'd require the user to be in a certain range.

Yeah, there is no way to do that on the client. The client does not know if it hit an entity and the entity therefor dies or if the entity was killed because of whatever. The client simply gets told "yeah, Entity X is now dead".

I guess limiting it to a range is the only possiblity then?

Still, I am not certain how I'd do that

You could use

EntityJoinWorldEvent

to detect when new item entities are spawned, but that's the best you can do purely on the client. The client does not know why these are spawned or where they are coming from.

How comes I've seen it happend? This is a screenshot from a similiar mod, on the same server, purely clientsided

http://puu.sh/q8nfq.jpg

Yes, but it shows all item entities (within radius). That is of course fully possible.

Thanks! Final question: I assume I could get a list of all entities in a specific radius using the EntityJoinWorldEvent and check if they are instance of xyz entity? If so, is it also possible to get their data, e.g lore?

Yes, but it shows all item entities (within radius). That is of course fully possible.

Thanks! Final question: I assume I could get a list of all entities in a specific radius using the EntityJoinWorldEvent and check if they are instance of xyz entity? If so, is it also possible to get their data, e.g lore?

 

if(event.entity instanceof EntityItem) { ... }

and

entityItem.getEntityItem();//returns the itemstack, which you can then request lore from

Thanks! In both cases, how'd I get the player-instance? As it is required to check in which radius of the player the items were dropped

Since you are on the client the player is always

Minecraft.getMinecraft().thePlayer

.

Thanks again! And sorry for my basic-questions, I am quite new to Forge modding, coming from Bukkit.

Since you are on the client the player is always

Minecraft.getMinecraft().thePlayer

.

While the code is now working perfectly in Singleplayer, the item is always "Stone" in multiplayer. Is this due to the Server not passing on information about the item?

 

Currently using

@SubscribeEvent
public void onSpawn(EntityJoinWorldEvent e) {

	if (e.getEntity() != null && Minecraft.getMinecraft().thePlayer != null) {

		if (e.getEntity().getDistanceToEntity(Minecraft.getMinecraft().thePlayer) <= 10) {

			if (e.getEntity() instanceof EntityItem) {

				EntityItem item = (EntityItem) e.getEntity();

				Util.chat(Minecraft.getMinecraft().thePlayer, "Item: " + item.getEntityItem().getDisplayName(),
						TextFormatting.GREEN);

			}

		}

	}

}

 

The entity-data is filled in through a 2nd packet (sent after the spawn packet). So when the entity joins the client does not immediately know all it's data.

Would a scheduler delaying the "reading" of the item work, or is there a second event used?

You basically have to wait a tick.

Tried that; it doesn't seem to do the trick.

While it works in singleplayer (where it is fired twice, for some reason. One time with stone and one time with the right item), it doesn't work with multiplayer

Nevermind, used the wrong timer

For everyone still seeking a solution, this one works for me!

	@SubscribeEvent
public void onSpawn(final EntityJoinWorldEvent e) {

	new java.util.Timer().schedule(new java.util.TimerTask() {
		@Override
		public void run() {

			if (e.getEntity() != null && Minecraft.getMinecraft().thePlayer != null) {

				if (e.getEntity().getDistanceToEntity(Minecraft.getMinecraft().thePlayer) <= 10) {

					EntityItem item = (EntityItem) e.getEntity();

					Util.chat(Minecraft.getMinecraft().thePlayer, "Item: " + item.getEntityItem().getDisplayName(),
							TextFormatting.GREEN);

				}

			}

		}
	}, 100);

}

Oh hell no, don't do that!

java.util.Timer spawns a new thread, but you can only interact with the world from the main thread. You need to listen for tick events and count.

Sorry! To be honest, I never quite touched timers

 

I know there is the update methode called once per tick, but how would I implement it in this case? Wouldn't it have to be "counted" within the EntityJoinWorldEvent?

Wouldn't vanilla's

IThreadListener

system work for this purpose?

Wouldn't vanilla's

IThreadListener

system work for this purpose?

No, since it first checks if you are already calling from the correct thread and in that case immediately executes the task.

 

Ah, I didn't realise that.

This solution now works for me, I do hope I did it right this time

package at.skyblok.client;

import java.util.LinkedList;
import java.util.Queue;

import net.minecraft.client.Minecraft;
import net.minecraft.entity.Entity;
import net.minecraft.entity.item.EntityItem;
import net.minecraft.util.text.TextFormatting;
import net.minecraftforge.event.entity.EntityJoinWorldEvent;
import net.minecraftforge.event.entity.living.LivingEvent.LivingUpdateEvent;
import net.minecraftforge.fml.common.eventhandler.SubscribeEvent;

public class WynncraftEvents {

Queue<Runnable> queue;

public WynncraftEvents() {

	queue = new LinkedList<Runnable>();

}

void addTask(Runnable r) {
	queue.add(r);
}

@SubscribeEvent
public void onPlayerUpdate(LivingUpdateEvent e) {

	if (e.getEntity() != null && Minecraft.getMinecraft().thePlayer != null) {

		if (e.getEntity().getDistanceToEntity(Minecraft.getMinecraft().thePlayer) <= 10) {

			while (!queue.isEmpty()) {
				queue.remove().run();

			}

		}
	}

}

@SubscribeEvent
public void onSpawn(final EntityJoinWorldEvent e) {

	if (e.getEntity() != null && Minecraft.getMinecraft().thePlayer != null) {

		if (e.getEntity().getDistanceToEntity(Minecraft.getMinecraft().thePlayer) <= 10) {

			if (e.getEntity() instanceof EntityItem) {

				addTask(new Runnable() {

					@Override
					public void run() {

						readItem(e.getEntity());

					}
				});
			}

		}

	}

}

private void readItem(Entity en) {

	EntityItem item = (EntityItem) en;
	Util.chat(Minecraft.getMinecraft().thePlayer, "Item: " + item.getEntityItem().getDisplayName(),
			TextFormatting.GREEN);

}

}

http://mcforge.readthedocs.org/en/latest/concepts/sides/

 

Few things:

 

1. If your mod will be client only - mark it with clientSideOnly="true".

* This way pretty much there is no way it can be loaded by dedicated server and you don't have to worry about using client-only stuff ever (thus @SideOnly will not be needed anywhere in mod).

 

2. If your mod is sided:

* I recommend separating code in packages such as "common", "client", "server" (where server will be almost never used unless you are writing private and/or server mods).

* Mark all classes in given packages with @SideOnly(Side#side) to honor given side.

 

3. Why am I mentioning above? Aside from using @SidedProxy, you should make sure everything works as you want it to - here @SideOnly ensures you actually are not using stuff that doesn't belong in given place (because it will crash otherwise).

 

Other:

4. Null-checks are pointless for pretty much any event (regarding entities, not e.g: BreakBlock). Note: "Minecraft.getMinecraft().thePlayer != null" is valid.

5. Please rename your method "onPlayerUpdate" - false, it fires for all entities (I recommend naming method "on"+eventName).

6. $readItem should take EntityItem, and casting should be made by method caller.

 

Aside from that:

* I don't see any damn logic in your approach so I will interpret it as code for testing. If that is not - tell your goal so maybe we could give better solution.

http://mcforge.readthedocs.org/en/latest/concepts/sides/

 

Few things:

 

1. If your mod will be client only - mark it with clientSideOnly="true".

* This way pretty much there is no way it can be loaded by dedicated server and you don't have to worry about using client-only stuff ever (thus @SideOnly will not be needed anywhere in mod).

 

2. If your mod is sided:

* I recommend separating code in packages such as "common", "client", "server" (where server will be almost never used unless you are writing private and/or server mods).

* Mark all classes in given packages with @SideOnly(Side#side) to honor given side.

 

3. Why am I mentioning above? Aside from using @SidedProxy, you should make sure everything works as you want it to - here @SideOnly ensures you actually are not using stuff that doesn't belong in given place (because it will crash otherwise).

 

Other:

4. Null-checks are pointless for pretty much any event (regarding entities, not e.g: BreakBlock). Note: "Minecraft.getMinecraft().thePlayer != null" is valid.

5. Please rename your method "onPlayerUpdate" - false, it fires for all entities (I recommend naming method "on"+eventName).

6. $readItem should take EntityItem, and casting should be made by method caller.

 

Aside from that:

* I don't see any damn logic in your approach so I will interpret it as code for testing. If that is not - tell your goal so maybe we could give better solution.

Thanks for the advice!

The mod was written for a "RPG" server, where items dropped are unidentified, and there is no way to know which item you'll get unless you take it to a npc and so on, therefore this code is quite helpful for reading out the name of anything that's dropped nearby, to stop unecessary collecting of items.

The mod was written for a "RPG" server, where items dropped are unidentified, and there is no way to know which item you'll get unless you take it to a npc and so on, therefore this code is quite helpful for reading out the name of anything that's dropped nearby, to stop unecessary collecting of items.

In other words, you're writing a client-side mod to defeat the purpose and rules of a server (i.e. cheating). I think we're done here.

The mod was written for a "RPG" server, where items dropped are unidentified, and there is no way to know which item you'll get unless you take it to a npc and so on, therefore this code is quite helpful for reading out the name of anything that's dropped nearby, to stop unecessary collecting of items.

In other words, you're writing a client-side mod to defeat the purpose and rules of a server (i.e. cheating). I think we're done here.

You shouldn't try to judge before you know the whole story.

It was more of an experiment at first, and after I was done I asked for allowance, which was given to me.