Six's Better Item Frame Maps [v1.1 for MC 1.5.2]

[Six]

Description:
What this add-on / mod does is to change the way item frames render when they have a map in them. I was always disappointed with how this was done in vanilla, so I finally decided to do something about it:



News:
v1.1 Now working with MC 1.2.

v1.0 Now that BTW is working on 1.5.1, I guess I should push the updated version. It seems to be working fine, but make sure you backup before installing just in case. Please report any problems.

v0.8 Alpha release - I've not done extensive testing on this yet, so be warned that I'm not 100% sure it is entirely safe to your world, but I also can't think of any possible way it could break anything. I'd appreciate if people could do any kind of testing they can think with them and leave some feedback and pictures of them in use.

Installation:
Simply download the version you want, and drop the class file into your minecraft jar.

This only modifies the rendering class for the item frame, so it should be compatible with any mod which doesn't modify that particular file. Also, since this is just a client mod which changes a single rendering class and doesn't add any new data or blocks, it can be removed at any time on an update without any problems to your map.


Downloads:
Now the mod only comes in one flavor, and instead of being able to rotate the map, you right click to toggle it to either have the map sitting inset in the frame or borderless, sitting in front of the frame.

---DOWNLOAD LINK---


Enjoy!


(Original post)

Spoiler

Show

So I was playing through BTW again and I was struck by how uselessly maps in item frames were implemented in vanilla (it's almost like they don't play the game or something...), and how much of a lost opportunity they were. Finally got sick of it and dug into MCP to see how hard it would be to fix. Turns out with a bit of refactoring in the item frame renderer, it was actually super simple.

What I've done is to make it so that when a map is placed into an item frame, the item frame will expand to the full block face size and the map will look much larger in it. Pictures are below, but I also want some opinions.

Problem is, I've got a few options for how this should look:

Keeping a '1/16th of a block' frame like the current item frames:

Going for a frame half that thickness: (actually, half thick looks dumb)

Or the map scaled right up to the full face of the block, such that the map sits on the 'front' of the frame and tiles seamlessly with the ones next to it:


I think the first one looks most fitting for the vanilla look, but the seemless tiling of the last is super nice and you could add your own 'frame' with molding in BTW. The second was kind of trying to split the difference to minimize the frame (and because I'd coded it to be possible by changing a single number), but I'm not sure about breaking the '1/16th of a block minimum dimension' rule of minecraft. Does anything in BTW break that rule?

Actually, should I just put up all versions and give people the choice?


The other thing, is I am actually clueless about the proper way to distribute this. Putting the re-obfuscated file up for download somewhere should work for people to just drop into their jar, so long as FC hasn't also made any changes to RenderItemFrame.java, right? Or is there another way this is meant to be done? Am I meant to use modloader in some way?

Thanks for feedback, and I'll be editing this post to have the download once this is all worked out.

[andreinawolf]

Really cool mod! I hate how small maps are in item frames. It forces you to get very close to look at them properly, and this always looks strange in SMP.

I think the first one looks most fitting for the vanilla look, but the seemless tiling of the last is super nice and you could add your own 'frame' with molding in BTW.

You could have the item frame check for adjacent item frame entities that have the same orientation and switch to the borderless mode if so. Just do the same as EntityHanging and only check every 100 or so ticks.

[Detritus]

Mmm, looks nice. Personal preference is the first, but have you considered expanding all item frames to be the same size as that? when they're placed next to eachother like you had there (map next to other item) they look a bit odd being different sizes...

[Six]

Yeah, naturally connecting adjacent map frames is the obvious solution, but I don't really want to have to have them check for other frames nearby and all that. Plus there is another problem which people forget, in that if you are connecting adjacent frames the space you have to fill is no longer square, which complicates things a bit further. It would be possible, but I'm not sure it'd be worth the overhead or effort.

Also, item frames are wack and behave unlike any other item in the game, in that they can occupy blocks that other blocks are already in, including other item frames.

[FlowerChild]

You could do it without overhead if you store the state in the tile entity for the frame and only check for changes on a neighbor block change.

Adjusting scale is another matter, but I doubt people would mind if you just cropped the edges under the frame itself when dealing with adjacent maps.

Nice idea btw. Not the kinda thing I'd want to do myself, but I'm sure players who are into maps will really appreciate it.

[johnt]

based on the reaction in this thread, it'll be probably be in vanilla next patch.

[Six]

You could do it without overhead if you store the state in the tile entity for the frame and only check for changes on a neighbor block change.

The thing I like about it as it stands, is that it only changes numbers (and ordering of logic) in the rendering of the frame, so this could be added and removed from a client with no problem. Correct me if I'm wrong, but changing the tile entitiy to store the state could cause issues if the mod was removed from a map?

[Six]

Actually, it might be possible to intercept the right click rotation for maps and use that number instead for cycling through frame arrangements, similar to rotating BTW corners... Plus that would keep it all in the renderer. And although that wouldn't be as 'magic' as them auto connecting, it'd actually offer more functionality.

[FlowerChild]

The thing I like about it as it stands, is that it only changes numbers (and ordering of logic) in the rendering of the frame, so this could be added and removed from a client with no problem. Correct me if I'm wrong, but changing the tile entitiy to store the state could cause issues if the mod was removed from a map?

No, what you do is store the data as an NBT tag. If the code doesn't specifically request that tag, then it is just discarded.

Storing in metadata for vanilla blocks can be a little tricky for the reasons you are mentioning (since vanilla code may no longer be able to properly interpret the resulting bit-field), but the NBT data that tile entities use is perfectly safe as long as you remember to check whether the tag exists or not in the load function (since you might be loading a vanilla map that doesn't have the data).

I've done that kind of thing on a few occasions in BTW, and it works just fine. It's super simple if you dig into the code once and figure out how it works.

[andreinawolf]

The item frame itself is an Entity, so I don't think it has a corresponding TileEntity class. Since it's an Entity you can still put blocks in the space it occupies too. I love having a table against a wall with a torch on it, then placing a item frame behind it against the wall :)

The EntityHanging class (which EntityItemFrame extends) checks every 100 ticks to see if the block it is hanging on is a valid surface and if the block it occupies is empty enough for it to exist. If not, it pops off into item form.

If entities receive block updates, then FC's solution would absolutely be the best. I couldn't figure out if they do or not but FC is crazy experienced with MC so it may very well be in there :)

If they don't, you could expand the item frame's bounding box in the relavent directions to check a 3x3 area for other item frames. If item frames are found, oriented the same way and contain maps, then you could trigger them to switch to the borderless mode.

If you do this only every X ticks like EntityHanging, you should be able to minimize the overhead this causes. You'd just want to store the last known result of that check for the interim ticks.

I haven't looking into the code for how entity state changes are sent to the client, but I'm guessing some modding would be necessary there for SMP support.

[FlowerChild]

The item frame itself is an Entity, so I don't think it has a corresponding TileEntity class. Since it's an Entity you can still put blocks in the space it occupies too. I love having a table against a wall with a torch on it, then placing a item frame behind it against the wall :)

Same thing with regards to the NBT data. Both entities and tile ents use the same system.

If entities receive block updates, then FC's solution would absolutely be the best. I couldn't figure out if they do or not but FC is crazy experienced with MC so it may very well be in there :)

Ah...you're right there. Regular entities do not receive block updates. That is a valid problem with my proposed solution, and yes, you would likely require periodic updates to test for the corresponding conditions as a result.

Those are relatively low overhead mind you as long as you spread them out and make sure to stagger them amongst entities of the same type. Using the entity ID to do this works pretty well IMO, along the lines of

if ( ( worldTime + entityID ) % updateFrequency == 0 )

It's not guaranteed to stagger them evenly, but it's a nice simple approximation of doing so to spread the load of the updates, and it's exceedingly unlikely to result in a massive number of entities all trying to update on the same tick, which is really what you're trying to avoid.

I haven't looking into the code for how entity state changes are sent to the client, but I'm guessing some modding would be necessary there for SMP support.

What you need for entities is a data watcher. There are examples of this in pretty much every vanilla entity, and the mod ones as well.

Data watchers automatically send an update to the client whenever there's a change in the associated data (and ONLY when there's a change...if you assign the same value as the one currently there, it won't send any data), so it pretty much automates the whole client server thing.

The only pain is that you have to assign a hard-coded index to the data in question and make sure it doesn't conflict with those already in the vanilla entity. If you create accessor functions for them though, usage becomes largely transparent.

[FlowerChild]

With regards to data watchers, here's an example from the mod's changes to EntityWolf that illustrate what I mean about data watchers and the associated accessor functions:

Code: Select all

    // FCMOD: Function Added    
    public boolean isFed()
    {
        return dataWatcher.getWatchableObjectByte( m_iIsFedDataWatcherID ) > 0;
    }
    // END FCMOD
    
    // FCMOD: Function added
    public void setFed( boolean bIsFed )
    {
    	Byte tempByte = 0;
    	
    	if ( bIsFed )
    	{
    		tempByte = 1;
    	}
    	
        dataWatcher.updateObject( m_iIsFedDataWatcherID, Byte.valueOf( tempByte ) );
    }
    // END FCMOD

I use that to track whether wolves are fed for dung production purposes. I use data watchers for it instead of regular variables because the client needs to know if wolves are fed or not so they can whine and such when they're not without having to transmit those sounds from server to client each time they occur. The data only changes when wolves eat or when they shit (both relatively rare occurrences), so doing it this way minimizes bandwidth usage.

EDIT: Oh, and the associated definition of the ID itself for clarity:

Code: Select all

    // FCMOD: Code added
    private static final int m_iIsFedDataWatcherID = 25;
    // END FCMOD

[andreinawolf]

Same thing with regards to the NBT data. Both entities and tile ents use the same system.

You're right. I was thinking too concretely. I have seen the chunk saving code enough times to know better!

Those are relatively low overhead mind you as long as you spread them out and make sure to stagger them amongst entities of the same type. Using the entity ID to do this works pretty well IMO, along the lines of

if ( ( worldTime + entityID ) % updateFrequency == 0 )

Ooo! I've thought of using some kind of random number for checks that I do often but this is a much more elegant solution as I don't need to store the random number somewhere.

What you need for entities is a data watcher. There are examples of this in pretty much every vanilla entity, and the mod ones as well.

Ah very nice! I've looked over the data watchers a bit but haven't needed to dive too deep. If I ever get to making client changes this knowledge will be very useful.

[Six]

Put up the downloads for the 'alpha' version, just using the simple methods originally mentioned. Want to get some people to test that, make sure nothing crazy is happening before bumping it up to a v1.0.

And I'm still unsure if going into the EntityItemFrame code and modifying that is really worth it for the results it'll end up giving.

[DNoved1]

Well, not a bug per se, as it occurs with the normal item frames as well, but this:

Spoiler

Show

becomes this...

Spoiler

Show

...when I scroll down to where about 1/4 of the frame should be visible. It seems that if less than 1/4 or so of the frame is on the screen the whole thing simply is not rendered. It's not a bug with your mod though as it also occurs with normal frames, its just a lot easier to notice when your frames take up the whole block.

Also, great work with the mod. It really does look great (though it also looks much better when your map is fully filled in).

[FlowerChild]

Put up the downloads for the 'alpha' version, just using the simple methods originally mentioned. Want to get some people to test that, make sure nothing crazy is happening before bumping it up to a v1.0.

And I'm still unsure if going into the EntityItemFrame code and modifying that is really worth it for the results it'll end up giving.

Yeah...you may definitely be right there. You could always just leave it to the player to frame large maps themselves using Moulding or what have you, like I've done with the Canvases in BTW.

[Six]

...when I scroll down to where about 1/4 of the frame should be visible. It seems that if less than 1/4 or so of the frame is on the screen the whole thing simply is not rendered. It's not a bug with your mod though as it also occurs with normal frames, its just a lot easier to notice when your frames take up the whole block.

Yeah, this has bugged me in vanilla frames too, and you're right about it being more noticeable with the full block face. Might have to look into where this is coming from.

[xou816]

Nice little add-on, maps look definetely better this way! Thanks!

[ThePuzzleMasher]

now I feel like making a giant underground room with no purpose other than to hang a giant map made of many un-zoomed-out maps

[NotEvenOdd]

Hey I saw this over on /r/minecraft a few days ago. So it's you that made this possible! Thanks a lot and great job. :)

[Rugaard]

think you could make it possible to place them on the floor?

ive always wanted to do one of those massive floor map things

[MoRmEnGiL]

Wow, this looks so much nicer..to the point where it might actually be useful to map your world!

[Ethazeriel]

I installed this addon a little while ago, and just recently finished this:

Spoiler

Show

Yes, I do very much like this mod. Nice work :)

[Detritus]

I installed this addon a little while ago, and just recently finished this:

Spoiler

Show

Yes, I do very much like this mod. Nice work :)

Very nice.

[wirer]

wow. 24 full maps. I'm very impressed. how'd you cover all that water?