Hey,

 

I was strugling with some clientside updates, and I noticed that there is a possible bug.

What I did was making a simple Tick Handler, and registered it with this:

		FMLCommonHandler.instance().bus().register(new TickEventHandler());

 

this is the EventHandler class

@SideOnly(Side.CLIENT)
public class TickEventHandler
{
@SubscribeEvent
public void onTickEvent(TickEvent.ClientTickEvent event)
{
	if(event.phase == event.phase.START)
	{
		//some code wich get executed every tick
	}
}
}

 

I added a debug line to this code to see when its called, and I noticed it got called in the following situations:

1. When a world is running (SP)

2. When a world is paused(SP)

3. When a world is closed after it was startup once!!

 

You can imagine that this went pretty crazy with my mod.(and my head!)

I solved the problem for me already, but I was curious if this is something normal, or a bug with this forge version?

 

The solution is as follows:

//if(event.phase == event.phase.START) -  replace this with the following:
if(event.phase == event.phase.START  && !Minecraft.getMinecraft().isGamePaused() && Minecraft.getMinecraft().thePlayer != null)

That does seem a bit weird.

 

If you follow the call hierarchy for ClientTickEvent with START phase, it is only called in the onPreClientTick() method, and that is called in the Minecraft classes runTick() and it isn't really qualified in any way (no if-then that might prevent it).

 

So I assume it is being posted as long as a Minecraft is doing a runTick(). So I guess that class is still instantiated and calling runTick().

This is not really a bug, just for the record - it was like that since forever, it is ClientTick, not world, nor anything else, also I am myself using this event also since forever and I do same if statement that you are doing in order to make world decrement some integer within server (WorldTick is only (unless something changes lateely) called from Server thread on server worlds, I needed to tick also on client world).

 

Just sharing experience.

@jabelar

 

I'm not English so I have a hard time understanding what you're trying to point out. But basicly what you're saying is: It shouldn't call the methode, but cause its phase START, its still calling runTick()?

 

No matter how I look at it, it is wierd. I can imagine it will ignore a paused game somehow. but it makes zero sence to me why it is called in the gamemenu(after the world is closed). cause there shouldn't be any tick events possible.

 

Luckly there is a work-around, but I'm sure there are some getting a headache of this.

@Ernio

 

Thanks for sharing your experiance!

I didn't know it is suppose to be this way, but its still interresting to see that the ClienTicks are only started when a world is loaded.

@jabelar

 

I'm not English so I have a hard time understanding what you're trying to point out. But basicly what you're saying is: It shouldn't call the methode, but cause its phase START, its still calling runTick()?

 

No, I'm saying that is the other way around. Minecraft#runTick() always calls the onPreClientTick() which posts the ClientTickEvent.START. So you should see the event as long as there is a Minecraft instance executing runTick(0.

 

Anyway, as Ernio says "client" doesn't strictly mean "world". It just means user interface is running.

It's not a bug, but just a feature which the client tick event has.

Since client means everything related with gui/rendering, the feature should be reasonable one (at least to me).

 

What I think is strange is that the client tick event is not called when the client main screen shows up.