the block itself is rather dull, even if I use a bright texture.

Look at netherrack

Okay, so adding a glow/brightness is quite difficult, right?

There's no method similar to setLightValue(), where you can just set a value.

There is getBlockBrightness(), but that doesn't seem to help...

 

So I have to create a renderer and set the brightness with a tesselator, if I'm not mistaken?

Or is there an easier method?

____

Basically, I just want to make the block look like it recieves light from a torch on every side. Or something like that.

Ooh, you want it to LOOK like it is fully lit without actually emitting light.

 

That's trickier, but involves rendering the block yourself.

Okay, nevermind. I was dumb to assume that setLightValue(2F) would be brighter than setLightValue(1F).

 

The difference was like this:

 

 

and

 

So now that I use 1F, the problem is fixed. Sorry for my noobishness

There is still one thing bothering me: In the documentation

http://mcforge.readthedocs.org/en/latest/datastorage/worldsaveddata/

it says:

 

There are two ways to attach the data: per dimension, or globally.

[...]

In code, these storage locations are represented by two instances of MapStorage present in the World object. The global data is obtained from World#getMapStorage(), while the per-world map is obtained from World#getPerWorldStorage().

 

However, I didn't use getMapStorage or getPerWorldStorage...

So is my BlockList stored per dimension or globally?

Have you looked at the source of the

World#loadItemData

method? In 1.8.9, it uses

World#mapStorage

(global) rather than

World#perWorldStorage

(per-dimension).

Thank you!!

 

An instance of "world" is a dimension, like overworld, or nether, right? Or is it the whole world containing all dimensions?

 

So right now my BlockList is global, which means spawns will be denied in all dimensions. So when I put a MonsterBlocker-Block in the overworld, spawns will be denied in same area of the nether, too, although there is no MB-Block in the nether. Did I understand this right?

 

If that's the case, I somehow need to use World#perWorldStorage(), and I think that I'll be able to do that on my own - so please just confirm if I'm right, or correct me if I'm wrong.

Wait, something's not right.

 

	public void LSECheckSpawn(LivingSpawnEvent.CheckSpawn event)
{
	List<Position> mbBlockList = new ArrayList();
	MBSave mbdata = get(event.world);
	mbBlockList = mbdata.getList();

 

I'm retrieving the mbdata from a certain world (dimension).

So it SHOULD be right the way it is now? I'm confused...

Thank you!!

 

An instance of "world" is a dimension, like overworld, or nether, right? Or is it the whole world containing all dimensions?

 

So right now my BlockList is global, which means spawns will be denied in all dimensions. So when I put a MonsterBlocker-Block in the overworld, spawns will be denied in same area of the nether, too, although there is no MB-Block in the nether. Did I understand this right?

 

If that's the case, I somehow need to use World#perWorldStorage(), and I think that I'll be able to do that on my own - so please just confirm if I'm right, or correct me if I'm wrong.

 

An instance of

World

is one dimension, yes.

 

Wait, something's not right.

 

	public void LSECheckSpawn(LivingSpawnEvent.CheckSpawn event)
{
	List<Position> mbBlockList = new ArrayList();
	MBSave mbdata = get(event.world);
	mbBlockList = mbdata.getList();

 

I'm retrieving the mbdata from a certain world (dimension).

So it SHOULD be right the way it is now? I'm confused...

 

There's no point in creating an

ArrayList

if you're immediately assigning another value to the variable. Declare the

mbBlockList

variable in the same statement as you're calling

mbdata.getList()

in.

 

Your

get

method does receive a

World

argument, but it uses

World#loadItemData

to load the data from that

World

. At least in 1.8.9, this uses the global

MapStorage

(

World#mapStorage

) instead of that dimension's

MapStorage

(

World#perWorldStorage

).

Okay, nevermind. I was dumb to assume that setLightValue(2F) would be brighter than setLightValue(1F).

 

So if light is 0 to 15, and 1.0f corresponds to 15 and it bit-overflows, what happens is we double that?

My old get method was this:

	public static MBSave get(World world) {
	MBSave handler = (MBSave) world.loadItemData(MBSave.class, DATA_NAME);
	if(handler==null) {
		handler = new MBSave();
		world.setItemData(DATA_NAME, handler);
	}
	return handler;
}

 

And in World.class there is

    public WorldSavedData loadItemData(Class par1Class, String par2Str)
    {
        return this.mapStorage.loadData(par1Class, par2Str);
    }

 

But instead of mapStorage (global) I need perWorldStorage. So my new get method is:

	public static MBSave get(World world) {
	MBSave handler = (MBSave) world.perWorldStorage.loadData(MBSave.class, DATA_NAME);
	if(handler==null) {
		handler = new MBSave();
		world.perWorldStorage.setData(DATA_NAME, handler);
	}
	return handler;
}

 

Is that right? If it is, then I'm a bit proud that I'm understanding Java and Minecraft and Forge a little more than when I started this thread

At least it is working when I test it with these changes.

If the

World#perWorldStorage

field is public in 1.6.4, your new code is correct. The field is protected in 1.8.9, but that may be a recent change.