Minecraft Forums

If you're going to make a suggestion, have the decency to post your own ideas, instead of linking to someone else's.

While we're on the topic of decency, you do not insult someone for calling you out for breaking rules/guidelines.

Quote from mg127

suggestion for the light-update problem:

data:
i am suggesting two 1bit 2d-maps for each populated chunk. = 2x 256bit per populated chunk + 1x int
1. one map contains the actual sunlight reaching this chunk
2. the other one contains the layout of the chunk, points where light can pass through to the next chunk or get blocked (like a hightmap but only with one bit)
3. a variable with the next next populated chunk below the actual chunk. (relative distance or absolute y pos)

loading:
on server: this meta-data could be loaded and processed in a larger radius than the chunks it self are loaded around each player.
on client: load together with chunk

processing:
at a chunk-update (e.g. block change) the two maps are recalculated and and also on each chunk in the same vertical stack that is in processing-range(see above). the last loaded/processed chunk gives the actual light value map (1) to the next chunk that is out of range below. smooth light and light bending/spread is precessed local in loaded chunks nearby. in auctual vanilla minecraft, indirect light has a maximum range of 15 blocks in all directions (falloff -1 per block) thus it is ok not to store it in the lightmap.
for chunks in range the sunlight would be processed simply by binary multiplying the two maps on each chunk and the result is given to the next chunk below (3.)

other stuff:
cyclic calls (e.g. once a minute) could update chunks below an updated lightmap that are out of range
every other light has a falloff range of max 15 blocks and therefore could be processed like normal

currently transparent* blocks will also cause a continuous falloff and after 15 blocks no light is left. to solve this, both maps had to be 8-bit and creating 4kbit per populated chunk with transparency or light strength other than maximum. and that is a bit much i think. (maybe enable via config ?)
*e.g. ice will cause a falloff <-> glass and stained glass is 100% transparent (air)

lets say we have two players and 3 layers of floating islands
everything on this map is generated and already light-updated (from top to bottom)
the light grey areas are loaded chunks
the light yellow framed areas demonstrate the light-update range
the blue areas are shadows (a bit dark this world, but that is only because it is a 2D world)



when now player A builds something that changes the light below, it will not be updated until a player goes through the chunks below from top to bottom



lets move player A a litte bit down ... and the light changes will update through to the bottom

What if we moved the sunlight heightmaps to separate files? This way, if somebody were to build a giant house X chunks above their chum's house, the guy below would receive the changes to the height map and it would be reflected on the ground below.

I'm working on a voxel engine right now with a cubic chunk system, and that's the solution I've been considering. Essentially have two folders for the world, one filled with the chunk data while the other is filled with the skylight data. Considering it would be a 2D grid of 16x16 integer array, the load time would be instant, and the chunks would be able to update the light levels to reflect the changes without the in-between chunks being loaded.

Please update this mod

Does somebody have the old solution to the lighting issue and why it wasn't good enough? I'd like to take a look at it and see if there's a workaround.

Here's a technical question: what's the name of the visual effect used for the rift doors and end portals, and are there tutorials/explanations for it online?

100% Forge free? To quote Notch, "Let's danec!" <dances>

8192

Nerfing implies making the mechanic harder. This actually made it easier.

Quote from Neospector

But it can, or should, at least, if all the slots are filled with, say, emeralds, and it needs one emerald more to turn on, the hopper will only take emeralds. Like how works, only easier to make since that video is slightly old.

As for the droppers being useless because the dispenser exists...I'm just going to say this, for now.

I'll have to try that out a bit, it might actually fit the bill.

Yeah, I'm hoping for the best with Nathan, but I'm expecting the worst.

Quote from Neospector

-snip-

These changes would not affect arrows or other projectiles. However I can see your point in terms of pre-existing item dispensers.

I know how the droppers function, but the point is they are mostly useless since the dispenser already exists.

I was talking about hoppers, not chests. In real life, hoppers often have a filter so that only certain things can pass through. I was also referring to how it outputs signal. If the hopper is filled with X amount of Y, then it would output a signal, and then you can dispense the contents into a chest. The issue was with the hopper as it is being unable to tell Y from Z, and when it should output the signal.

However, thank you for the criticism.

Quote from Malatak1a

Lol, support.

That story was actually taken from personal experience back in beta. Of course the method we used was costly(storage minecart pushed through a hole to an obsidian room), but either way I'd end up with a bunch of carts filled with stuff I didn't want, as well as running out of diamond tools.

I try and use stories I've heard or experienced when pitching an idea, as it helps people understand potential uses in the idea while getting a laugh.

No problem. Actually, I'm gonna go decompile a fresh jar to see how hard it would be to add this feature with the command block. It's definitely not a bad idea in terms of adventure mode, and if it can be done I'd definitely try and contact Jens or one of the other developers.

Quote from jpmrocks

Maybe a new subtype of command block, like the Texture Block? You send it a redstone signal, and it switches packs.

Why make a new block when you can improve on what you have?

Quote from Rex1900Roblox

Problem with that: How would it know which pack to switch in?

here's a sample command:

/texturepack <player> <texturepack>

The command block can pick out players that are nearby, so that solves the issue of finding out who activated it.

I've been working with the bukkit and craftbukkit APIs for a couple months, and I've been working in the actual minecraft codebase for 2 years. I know my stuff when it comes to this.

Okay, so recently they announced the dropper block. My first thought was "Okay, this is basically made for the player to drop 3, maybe 4 items.

As it is, I personally will never need nor want to craft a dropper, as it provides no use to me that I can't cover with my dispenser(When would I need to drop an arrow/egg/snowball?) However, I see potential changes to these two blocks that wouldn't affect builds and could improve them while maintaining the suspension of disbelief.

Firstly, the dispenser. It's basically useless now for dropping items normally, but what about throwing them? Now the idea is that the redstone signal sent to the block is measured, and the item is shot out with a distance relative to the signal given(a low signal merely plunks it a block or two, but a full signal can propel it a good 20 or so blocks forward) In addition, it could allow a monster hatched with a spawn egg to be fired towards a point(think spider jumping at you from ten blocks away from a hidden dispenser in an adventure map) The primary use of long range item dispersion is for faster transport, as water can take too long and minecarts are slowly becoming mobile death machines instead of viable transportation(here's to the hopper hopefully fixing that)

Now the dropper can have a use for close up item dispersion. Say you build a store for your pals on your LAN server and you want them to be able to sell them stuff without being online. You can have droppers drop the items down into a water stream that leads to where the buyer is at after the transaction. The buyer then gets his stuff, goes away and then realizes that he paid an emerald for 13 wheat.

Lastly, the hopper. I gotta say, this was a feature that I've been very intrigued in until I got my hands on it myself. It couldn't filter items, which was the main thing I was getting giddy for. Now, knowing the system BTW used is very difficult to maintain, here is a simpler approach that could work. Say you make your store and you realize that your friends are taking you for a fool and dropping a block of dirt in for a diamond sword. Firstly, find new friends. Secondly, you need to make a system for finding out if the items being given are the right type and amount. For the hopper in BTW, you would have a detector block count out the items put in, and have the hopper filter out the unwanted items. However since we lack the detector block and filter system, we need to have a way for the hopper to count how much is in it and what is in it. In the GUI for the hopper, you can be given the option to either allow anything in, or allow a certain amount of blocks/items to pass. For this example, we'll say 9 as that is consistent with the rest of the GUIs. So you can put an emerald into the hoppers whitelist row, and the hopper will only collect diamonds. Great, but you can't tell how many emeralds you have. Since 8 emeralds is a fair price for a stack of ender pearls, you'll set the hopper to output a signal via comparator when it hits 8, and will then dispense the emeralds into a nearby chest.

This is just my little spin on these blocks, and I sincerely hope it'll get at least a few gears turning in peoples minds in terms of creative solutions. Not everything needs to be hard, but a friendly challenge is what we all need as it provides us to come up with ways to improve in terms of gameplay and a growth in the players problem solving skills.

Quote from Rex1900Roblox

We dont know... Was anyone even expecting Dinnerbone to successfully add new spawner mechanics? Such as the spawning radius, spawning area and such?

And plus, this one only affects rendering engine

Well that was different, this feature is quite far from that mechanics wise. You'd need a rewrite of the rendering engine, not to mention this would require a non-block related field to be saved in the world for the effect to work reasonably. The spawner was just adding more options to a pre-existing feature that was already somewhat optimized for customization. All they had to do was make more of the existing features possible to modify.


Saying it only affects rendering doesn't make it better, and is in fact false. First off, rendering is the one of the most important part of the game for the player, as without it you've got a really bad looking end product that would drive people away. That being said, it is so easy to screw up rendering, and hard to unscrew it without backups. Secondly, this feature in particular goes into the world saving mechanics. That would be another one of the more important points of minecraft, as you're kinda screwed when it goes wibbly. With this system, it's not likely that you'd experience it in normal gameplay, but in adventure maps it would be somewhat common if the mapper didn't know what they were doing or they messed up somewhere.

Now don't get me wrong, it would be interesting, but it's more difficult to pull off in execution than one would think in the method you're describing. Not to mention that the system is more tiresome on the mappers part as they'd have to install more programs to use a vanilla feature. Perhaps a method using preexisting features would be better(Add a command to command blocks that changes the texturepack, and set up redstone so that the command is executed when the player sets something off.)