The ongoing 1.3 update epic

[RaustBlackDragon]

...and, if you have a block where only certain settings of the meta-data concern the client, instead of using setRequiresSelfNotify() and forcing info to be transfered every time the meta-data changes, you can instead call:

world.markBlockNeedsUpdate() only when the changes you want to be relayed take place.

Which also means that the Hand Crank is now updated to 1.3 ;)

The Hand Crank maintains an internal counter in metadata which corresponds to the clicks that you hear during its operation. However, those changes are of no relevance to the client (sounds are actually automatically transfered from server to client), only the on/off state.

Hey, do you really have to send a packet every tick? Wouldn't the server also know the decrease it every tick too?

[FlowerChild]

Useful tid-bit: world.PlaySoundEffect() is server side. It won't play locally on the client, only if it is called on the server (in which case it automatically notifies the client to play the sound).

world.PlaySound() on the other hand, plays it directly on the client.

This is useful if you're triggering sounds in code that is only run on the client, like in the randomDisplayTick() function that all blocks have. I use this to display random particles and the banging sounds while a Mill Stone is in operation.

Keep in mind these aren't Mojang function names, just MCP ones which are often rather ambiguous.

[FlowerChild]

Hey, do you really have to send a packet every tick? Wouldn't the server also know the decrease it every tick too?

I think you may have misread my post, as your question doesn't seem to relate to it.

[RaustBlackDragon]

Hey, do you really have to send a packet every tick? Wouldn't the server also know the decrease it every tick too?

I think you may have misread my post, as your question doesn't seem to relate to it.

Oops, quoted the wrong one. I meant to quote the one before it.

[FlowerChild]

Oops, quoted the wrong one. I meant to quote the one before it.

It doesn't relate to that one either.

I was just saying that I should do things differently with inLove so that it DOESN'T get sent every tick, so the only way your response *might* relate is in saying the exact same thing I just did.

Basically, you only need that information on the server. The client is just a "dumb" display device. It only needs to be aware of the on/off state of whether an animal is in love mode, so that it can emit particles. The server on the other hand needs to track and be aware of the tick-count so that it knows when to turn it off.

If you make the inLove variable itself watchable data, I believe it then automatically gets sent to the client whenever it changes, which is every tick. If you only want to send that data when it hits specific values (say 0 and 600), you'd probably need a custom packet for it. Alternatively, you can do what I described, create a separate boolean to track the on/off state, make that one watchable instead, and set the boolean server-side when your counter hits the pertinent values.

[FlowerChild]

BTW Raust, not sure if you noticed, but it looks like the wolf head-motion is back in 1.3. No more zombie wolves for you ;)

[RaustBlackDragon]

BTW Raust, not sure if you noticed, but it looks like the wolf head-motion is back in 1.3. No more zombie wolves for you ;)

Seriously!?

Awesome! :D

[FlowerChild]

Seriously!?

Awesome! :D

Hehe...yeah, I saw that and my first thought was "Well, Raust will be happy" :)

[RaustBlackDragon]

Seriously!?

Awesome! :D

Hehe...yeah, I saw that and my first thought was "Well, Raust will be happy" :)

Heh, yeah, but unless they also don't look at you incessantly while pathing towards you, I'm still sticking with the system you helped me with :)

[FlowerChild]

Heh, yeah, but unless they also don't look at you incessantly while pathing towards you, I'm still sticking with the system you helped me with :)

See, I never even knew that behavior existed. Kinda hard to notice it when all your wolves are locked up in individual cobble crypts :)

[RaustBlackDragon]

Heh, yeah, but unless they also don't look at you incessantly while pathing towards you, I'm still sticking with the system you helped me with :)

See, I never even knew that behavior existed. Kinda hard to notice it when all your wolves are locked up in individual cobble crypts :)

You're quite fortunate that you've been spared that sight. I'm often tempted to do that myself without the slightest bit of regret. That's how bad things have gotten.

But anyway, back on topic, you seem to be making amazing progress with this, and I really appreciate all of the information you've been providing fellow modders :)

[risingphoenix]

Reading this thread has nade me realize 2 things:
1. How glad I am that this mod is in such capable hands
2. How much I still have to go before I can understand what you guys are saying. Best I can do is. Ooo! I know what boolean means!

Thanks again for all your hard work FC it is trully appreciated. There will be mass wolf slaughter to feed you energy inmy world

[morvelaira]

Reading this thread has nade me realize 2 things:
1. How glad I am that this mod is in such capable hands
2. How much I still have to go before I can understand what you guys are saying. Best I can do is. Ooo! I know what boolean means!

If it's any consolation, I'm right there with you on that second one.

[CycloneSP]

Aye, same here. I'm currently half-way through college career with my goal to join up with a gaming company, and I have no clue how I'll ever be able to do any of the stuff FC is doing. I know some basic C++ and a smidget of java. But I feel like there is a vast gulf that cannot be traversed between my skill level and FC's (or any professional programmer) v_v The future can be scary at times.

Well, at least FC is more than capable to do what needs to be done.

[BinoAl]

Really? I'm a first year (going on second!) CS student, and I have a pretty clear idea of what he's saying. Then again, since I was a kid, I've read game developer's blogs and dev journals, so I do have a pretty clear understanding of things on the conceptual side. Sit me in front of a computer and tell me to utilize these concepts, however... :p

[Ethinolicbob]

I wouldn't expect any changes to the system really.

Well that wasn't the answer I was looking for...
You are making it hard to procrastinate.

[FlowerChild]

Raust: I think I just found the key piece that will make this a snap for you...

Check out the IAnimal interface. I believe all you have to do is implement that interface (which just involves saying you're implementing it in your class declaration...it's actually an empty interface), and your entities will be identified as a mob by EntityTracker.java. Spawning the entity will then automatically communicate it from server to client.

Then, put any data you also need communicated into watchable data as I previously described, and you should be good to go.

Also, digging into that aspect a bit further, I'm no longer certain about the every tick update thing. EntityTracker has parameters for specifying how often entities get updated, so it may only happen once a second or so for mobs and such, at which point, all data is updated.

Anyways, don't sweat this too much. Given the above, I highly doubt you'll need custom packets or anything that funky, and your update should be relatively straight-forward.

With my Water Wheels and such though, it's an entirely different matter ;)

[ignika42]

Just wanna say best of luck to you FC, and that as a programmer I find this very interesting.

[wolfe]

Hey flowerchild, good luck with updating! I myself just started updating my mod and it's been more or less the same deal. Been fucking stumped with tile entity rendering, same problem you had. Any idea how you fixed it? Half of my blocks in the mod have tile entities and all that shows for them is the bounding boxes :/

[FlowerChild]

Hey flowerchild, good luck with updating! I myself just started updating my mod and it's been more or less the same deal. Been fucking stumped with the entity rendering, same problem you had. Any idea how you fixed it? Half of my blocks in the mod have tile entities and all that shows for them is the bounding boxes :/

Tile entities and regular entities aren't the same thing man.

[wolfe]

Hey flowerchild, good luck with updating! I myself just started updating my mod and it's been more or less the same deal. Been fucking stumped with the entity rendering, same problem you had. Any idea how you fixed it? Half of my blocks in the mod have tile entities and all that shows for them is the bounding boxes :/

Tile entities and regular entities aren't the same thing man.

Huh, thought I put tile there... Whatever, late night posting. Edited the post to fix that typo.

[FlowerChild]

Huh, thought I put tile there... Whatever, late night posting. Edited the post to fix that typo.

Yes...you did. But what I was describing applies to regular entities...it's not the same problem at all.

Also, I detailed what I did to fix that. You're asking me questions I've already answered.

[FlowerChild]

Well, one of the things I was most worried about with this update was custom GUIs...

Spoiler

Show

<dances>

I still have to hook up the mechanical power indicator, but aside from that, it's working perfectly. Now that I understand the method of doing this, the other custom inventory blocks for the mod should be a breeze.

The tricky part about this right now is that while ModLoader provides functionality for this, it's currently entirely undocumented as the Javadocs haven't been updated for it yet. As such I'll provide the following code snippets and brief explanation for modders, since it's relatively rough to figure out. Please don't ask for additional explanation. I'm happy to pass this info along to help people out, but I definitely don't want this to turn into a modding 101 Q&A session, and will refrain from providing this kind of thing in the future if it does:

Spoiler

Show

First, you need to register a unique ID for the Container that will be handling your GUI:

Code: Select all

	private void RegisterCustomContainers()
	{
		ModLoader.registerContainerID( this, fcMillStoneContainerID );
	}

The container ID is just an int that I have defined within my mod_ class, and which I allow to be overridden through the mod's config file. I used a default value of 222 to hopefully avoid conflicts with other mods (so don't use that one ;) ).

Next is handling the clicking on the block on the server, and creating the server side container which the client-side GUI will interact with:

Code: Select all

	@Override
    public boolean onBlockActivated(World world, int i, int j, int k, EntityPlayer player, int par6, float par7, float par8, float par9)
    {
    	ItemStack playerEquippedItem = player.getCurrentEquippedItem();
    	
    	if ( playerEquippedItem != null && playerEquippedItem.getItem() instanceof FCIItem )
    	{
    		FCIItem fcItem = (FCIItem)playerEquippedItem.getItem();
    		
    		if ( fcItem.DoesItemOverrideBlockActivation() )
    		{
    			return false;
    		}
    	}
    	
        if ( !world.isRemote )
        {
            FCTileEntityMillStone tileEntityMillStone = (FCTileEntityMillStone)world.getBlockTileEntity( i, j, k );
            
        	if ( player instanceof EntityPlayerMP ) // should always be true
        	{
        		FCContainerMillStone container = new FCContainerMillStone( player.inventory, tileEntityMillStone );
        		
        		ModLoader.serverOpenWindow( (EntityPlayerMP)player, container, mod_FCBetterThanWolves.fcMillStoneContainerID, 0, 0, 0 );        		
        	}
        	else
        	{
	        	// display the Mill Stone gui...pre 1.3 legacy code
	        	
	            ModLoader.openGUI( player, 
	        		new FCGuiMillStone( player.inventory, tileEntityMillStone ) );
        	}
        }
        
        return true;
    }

Note that the instanceof check on EntityPlayerMP is not really necessary, as it's already been determined that this is on the server by the isRemote test above. I just left that in for testing purposes, and to provide a reference with the old way of doing things with openGui. The last three parameters that I pass in to serverOpenWindow() are all set to zero, because they don't have a specific purpose in the ModLoader code. I suspect they're just there to provide an easy way for modders to pass custom data to their GUI (I might use this to pass the initial state of the mech-power indicator for example).

Now we need to handle the client side of things. All that's really needed for this is for you to specify which GUI needs to be displayed on the client when it receives a message that one has been opened:

Code: Select all

	@Override
    public GuiContainer getContainerGUI( EntityClientPlayerMP entityclientplayermp, int iContainerID, int i, int j, int k )
    {
		if ( iContainerID == fcMillStoneContainerID )
		{
			return new FCGuiMillStone( entityclientplayermp.inventory, new FCTileEntityMillStone() );
		}
		
      return null;
    }

This is an override of a BaseMod method, so it should of course go within your mod_ class.

With the above, ModLoader takes care of all the rest of the details like handling player inventory interactions between client & server.

[CycloneSP]

lol, I love how most all of your variables and objects have the letters 'FC' or 'fc' at the beginning. That made me smile.

[FlowerChild]

lol, I love how most all of your variables and objects have the letters 'FC' or 'fc' at the beginning. That made me smile.

That's just to prevent problems if Mojang names a variable or method the same as any of mine, and to make mod code very easy to identify. It's not my sig or anything :)

I similarly label all base-class mods I make with "FCMOD" comments to make them easy to search for.

Just methods I've learned over the years to make my life easier, changed slightly to suit the nature of modding.