Xmx1G sets maximum heap size to 1GB of RAM, while Xmn128M sets minimum heap size to 128MB of RAM. I don't recognize the others. Google will probably know.
Command blocks would be much more useful with a simple scripting language. The ability to pick a player, store them in a variable and do several commands would be much more powerful than our current methods of picking a player, doing one command, and then trying to do another command on that same player using a second block. Right now you have to use hacks like teleporting people to a set place where all other command blocks will look for them, or mucking around with setting variables on the scoreboard, and hoping that timing is all done right.
The language should not be java, it's too complicated. It probably shouldn't even be javascript. My guess is that a unique language built specifically for minecraft would be best. It would have to be able to select players, manipulate their inventories, xp, health, food, position, etc. Create items with custom properties. Spawn mobs. Set blocks at a given position. Maybe output a redstone signal.
Example to give a player an enchanted pick in exchange for emerald:
Player p = @p[x,y,z] // look for player at that position
//check if player has emerald
if(p.inventory.contains(EMERALD, 1)){
p.inventory.remove(EMERALD, 1); //take the emerald
Item I = createItem(278); //make a diamond pick
i.enchant(FORTUNE, 1); // enchant it with lvl 1 fortune
p.inventory.add(i); //give the pick to the player
}else{
p.message("You don't have an emerald.");
}
I think that would work. Might be hard to code, but a lot more robust than current methods of giving a player an enchanted item (or any item) in exchange for another item.
Ultimately command blocks need a scripting language. Not being able to pass variables between blocks makes them limited.
If we had a simple scripting language we could do this:
Player p = @r;
Item i = 278 // diamond pick? It's been a while.
i.enchant(ENCHANT, LEVEL) // fill in those values with numbers
p.give(i);
That would select a random player and give them an enchanted item. A scripting language would be able to do a lot more than that. But I can see it wouldn't be the simplest thing to add to the game.
A common misconception is that flowering sunflower heads track the Sun across the sky. Although immature flower buds exhibit this behaviour, the mature flowering heads point in a fixed (and typically easterly) direction throughout the day.[23][24] This old misconception was disputed in 1597 by the English botanist John Gerard, who grew sunflowers in his famous herbal garden: "[some] have reported it to turn with the Sun, the which I could never observe, although I have endeavored to find out the truth of it."[11] The uniform alignment of sunflower heads in a field might give some people the false impression that the flowers are tracking the sun.
The uniform alignment results from heliotropism in an earlier development stage, the bud stage, before the appearance of flower heads (anthesis).[25] The buds are heliotropic until the end of the bud stage, and finally face East.[26][27] Their heliotropic motion is a circadian rhythm, synchronized by the sun, which continues if the sun disappears on cloudy days. If a sunflower plant in the bud stage is rotated 180°, the bud will be turning away from the sun for a few days, as resynchronization by the sun takes time.[28] The heliotropic motion of the bud is performed by the pulvinus, a flexible segment just below the bud, due to reversible changes in turgor pressure, which occurs without growth.
tl;dr: Real world sunflowers generally face east no matter how you plant them. This may be the one case where minecraft matches reality.
Somehow, my mind took this title to mean "we should be able to use it like a Chest" rather than "it should be able to become wheat again." Given the longstanding narrative history of people hiding in hay bales, I now demand that a single item or player can hide in a hay bale block. I demand this.
But also, your thing is important too.
haybales should be used as chests, but only for storing needles.
so once spellscript is a forge core mod, will it be easier to update hack mine in the future? At the rate minecraft is being updated it might be on 1.8 by the time you get it up to 1.5.2. Of course you probably can't make any estimate because mojang's updates are unpredictable.
I would almost be tempted to make a game from scratch instead of modding minecraft so hard that it's almost a totally different.
saddles have a recipe, it's called getting off your butt and spending half an hour looking for dungeons,strongholds, mineshafts, or nether forts. It's not hard. If you're on a multiplayer and all the chests have been raided either walk out into new territory or trade or steal one or find another server.
horses are too laggy on multiplayer anyway, keep lagging right into ravines. Tried to pull the horse back out using a cobble pillar and leash, but I guess fall damage builds up over time and as soon as it touched the ground on the surface it died. That seems like a bug.
Just have to show up every couple months to remind everyone about reality. Probably get some new readers who don't realize computers aren't miracle machines that magically turn ideas into games.
And unity isn't bad, it can't do 100% of "gamespace", but it can probably do 90%. I was in a group at my university using unity, but my grad student schedule took priority, I was being paid for 60 hours of labwork a week, not to make a game.
the whole mods vs update thing is crazy. I don't have anything against mods, but think of it like aftermarket parts to a car, if designed, built, and installed right it works great, but you can't guarantee that will happen. Updates are like official parts of the car, the engineers plan for it and make sure it's right.
Also, once you start installing mods there are issues with client / server communication, bug reporting, and a pile of other things. Install mods if you want to take that risk, but I keep my server as vanilla as I can and expect my players to keep their clients near vanilla, no non-aesthetic client side mods, they give unfair advantage.
as a farmer who has real haybales and real cattle I know from personal experience that haybales can be taken apart to get hay and find it akward that I can't do it in minecraft.
That being said, bread is made from the grains of wheat, not the whole plant, and making square hay bales requires a machine, before steam powered balers were invented in the late 1800s farmers just piled hay up. That's why the square bales in skyrim annoy me, but I've given up on minecraft physics.
Why are you shocked that depth sorting is difficult to do in unity? Unity is terrible for advanced rendering techniques, it's like a 3D version of Game Maker, not bad for making games, but if you want to push the limits of graphics, you'd better learn direct x or opengl and code at the hardware level, unity and programs like it simplify the game creation process at the cost of loss of flexibility and power.
Even if mojang rewrites the rendering code to allow for depth sorting, it will still depend on the users video card and drivers. Depth sorting of any type simply costs more. People with powerful graphics cards will be fine, but many players who can't afford it will be stuck with cruddy glass.
And making colored light with colored glass is still a bad idea, just terrible, it's like running a server side real time ray tracer.
Colored glass is hard enough to do right. The transparency issues are why transparency is limited to water and ice right now, anything more would be like twisting the knife already in the wound. (glass really isn't transparent, every pixel in the current glass texture has an alpha of 255 or 0, nothing in between) But colored lighting is at least an order of magnitude more difficult, requiring not just a total rendering engine rewrite and forcing the GPUs to work harder but also increasing map file size and slowing down chunk updates. But the concept of using colored glass to alter the color of light is computationally insane for a game meant to run on as large a playerbase as possible. If we all had renderfarms we could do it, but many of minecraft's players have baby laptops with integrated graphics. Not even AAA games like skyrim have the kind of dynamic colored lighting you're demanding, 99% of lighting is baked into the environment with those titles, and any dynamic lighting is kept as little as possible, and you never see anything like the idea of passing light through a transparent material to change it's color. Of course it would be a cool effect, but it's just too expensive for most people's computers.
The view would probably be totally opaque after just a few layers. No need to calculate beyond that.
Lets say we stop it at 5 blocks deep. Then lets say we have a griefer who takes advantage of this and builds this:
The orange dot in the middle is a torch, the squares around are colored glass blocks. The red dot is a glass block immediatly exposed to the torch. The blue dots are the paths traced out from the red, the green are from the blue. That one block that get's lit up by the torch affects at least the 37 blocks I show here. You'll notice that some blocks are hit more than once, I didn't draw all the interactions, but my guess is that some blocks will be hit many times, each hit is another light calculation. I only considered 1 of the 8 glass blocks around the torch, but each of those blocks will have its own tree of calculations. And the exterior blocks will be affected by light on the outside of the of the box coming in. And this diagram is only 1 layer thick, in reality, this would be built as a cube, greatly increasing the number of interactions. These interactions remind me of leaf decay, and I remember when notch tried to "improve" leaf decay a couple years ago and it got so slow that my laptop couldn't run minecraft until it got fixed, it didn't crash, it just slowed to a stop once I got near a forest. And leaf decay didn't have a light calculation at every step. You could alleviate some of the calculation problems by reducing the limit from 5 to 4 or 3 or 2 layers, but then you're almost at opaque glass and what's the point? (opaque glass would be fine for the Z buffer by the way, so I might like that)
First issue: What? I mean, what are you even going on about here? It has already been implemented once, in the fake-update. Maybe the colored light MAY cause lag, yet you decide to hate on the EASY part of the suggestion.
Secondly: This thread would not have survived thus far if this would have been a well acknowledged issue. How can you say for sure it would lag so much? The fake-update didn't lag more than any other update, and if you get such framedrops why not try out optifine? It's a great way to enhance your comp-performance?
It is a well known issue. Anyone who has ever done 3D graphics programming knows that transparency is a complicated problem. Look up Z buffers. In order to do transparency the z buffer must keep track of more pixels and sort those pixels by depth. The more layers of transparent pixels you have means the z buffer must do more work. While there are tricks to simplify this and get a few layers of transparency with relatively little impact on performance, minecraft is a game where the terrain is totally customizable and you can circumvent the tricks by placing many many layers of colored glass. More advanced methods such as order independent transparency can solve some the speed problems, but most players graphics cards can't do that yet.
In summary: Colored glass is not impossible, but impractible. To do it right would require major changes to minecraft's graphics pipeline which would harm performance for most of the playerbase, and probably keep many people from playing because they have weaker graphics cards. Mojang does not like to do that, it took them until the new 1.6 update to move to new JLWGE because it means that powerPC users can no longer play, even though most players will see improved FPS and controls. It's simply not worth the work needed to properly implement such a minor feature that would harm many aspects of the game. You could always implement the cheap and easy colored glass and get crappy looking transparency problems.
Will you please stop posting this mod here? Not only did we hear you the first time, but it's completely different: instead of adding colored glass that allows for colored lights, it just has colored lights.
I don't know what mod that guy refers to that keeps annoying you, but the idea to color light by passing it through colored glass is ridiculous. As bad as the overhead involved in colored glass and good transparancy is, colored light in general would be worse. But adding the additional requirement that light moving through a colored glass block changes the color of the light would really be the last nail in the coffin. Would you ray trace light from each torch through to every block it lights, look for intersections with colored glass, then do the color calculations? I suppose you could try and speed it up by limiting the radius to the 16 blocks around the torch, then searching that space for colored glass blocks, then only ray tracing through those blocks. However, if you built a wall of colored glass in front of a wall of torches, you still have a ton of calculations to perform. If you want to combine colored glass blocks to further control the color of the light, you'd need to an additional layer of ray tracing from each glass block to all the glass blocks around it, making the problem exponential.
These calculations could be server side or client side, but either way would cause serious reductions in FPS. The colored light data would most likely have to be stored in the map files, and if you want 256 shades each of red, green, and blue, that's 3 bytes (24 bits) per block on top of the 2 bits per block already used to determine light level (I suppose you could store intensity in the 3 bytes for color, since I can't imagine you'd have intense black light, darker colors would mean lower light levels, but you're still talking 24 bits for light instead of 2)
Calculating light levels server side would allow griefers to lag down servers with tons of torches and colored glass, and slow down chunk loading for players because of the increased memory per block. You could prevent this by doing lighting calculations client side, because you'd only have to tell the client that torches and colored glass exists, but the client would have to do the same lighting calculations, and wouldn't be able to store the data once calculated, it would have to calculate it every time the client loads the chunk or updates a block (at a minimum) where if the server did it it would need to calculate light on block updates, which probably doesn't improve much ( I have nightmares of giant colored glass and torch machines with pistons on fast clocks opening and closing windows and melting my server's CPU )
0
0
The language should not be java, it's too complicated. It probably shouldn't even be javascript. My guess is that a unique language built specifically for minecraft would be best. It would have to be able to select players, manipulate their inventories, xp, health, food, position, etc. Create items with custom properties. Spawn mobs. Set blocks at a given position. Maybe output a redstone signal.
Example to give a player an enchanted pick in exchange for emerald:
Player p = @p[x,y,z] // look for player at that position //check if player has emerald if(p.inventory.contains(EMERALD, 1)){ p.inventory.remove(EMERALD, 1); //take the emerald Item I = createItem(278); //make a diamond pick i.enchant(FORTUNE, 1); // enchant it with lvl 1 fortune p.inventory.add(i); //give the pick to the player }else{ p.message("You don't have an emerald."); }I think that would work. Might be hard to code, but a lot more robust than current methods of giving a player an enchanted item (or any item) in exchange for another item.
0
If we had a simple scripting language we could do this:
That would select a random player and give them an enchanted item. A scripting language would be able to do a lot more than that. But I can see it wouldn't be the simplest thing to add to the game.
0
tl;dr: Real world sunflowers generally face east no matter how you plant them. This may be the one case where minecraft matches reality.
6
haybales should be used as chests, but only for storing needles.
also, we need needles.
0
I would almost be tempted to make a game from scratch instead of modding minecraft so hard that it's almost a totally different.
0
horses are too laggy on multiplayer anyway, keep lagging right into ravines. Tried to pull the horse back out using a cobble pillar and leash, but I guess fall damage builds up over time and as soon as it touched the ground on the surface it died. That seems like a bug.
0
And unity isn't bad, it can't do 100% of "gamespace", but it can probably do 90%. I was in a group at my university using unity, but my grad student schedule took priority, I was being paid for 60 hours of labwork a week, not to make a game.
0
Also, once you start installing mods there are issues with client / server communication, bug reporting, and a pile of other things. Install mods if you want to take that risk, but I keep my server as vanilla as I can and expect my players to keep their clients near vanilla, no non-aesthetic client side mods, they give unfair advantage.
2
That being said, bread is made from the grains of wheat, not the whole plant, and making square hay bales requires a machine, before steam powered balers were invented in the late 1800s farmers just piled hay up. That's why the square bales in skyrim annoy me, but I've given up on minecraft physics.
0
Even if mojang rewrites the rendering code to allow for depth sorting, it will still depend on the users video card and drivers. Depth sorting of any type simply costs more. People with powerful graphics cards will be fine, but many players who can't afford it will be stuck with cruddy glass.
And making colored light with colored glass is still a bad idea, just terrible, it's like running a server side real time ray tracer.
2
1
Lets say we stop it at 5 blocks deep. Then lets say we have a griefer who takes advantage of this and builds this:
The orange dot in the middle is a torch, the squares around are colored glass blocks. The red dot is a glass block immediatly exposed to the torch. The blue dots are the paths traced out from the red, the green are from the blue. That one block that get's lit up by the torch affects at least the 37 blocks I show here. You'll notice that some blocks are hit more than once, I didn't draw all the interactions, but my guess is that some blocks will be hit many times, each hit is another light calculation. I only considered 1 of the 8 glass blocks around the torch, but each of those blocks will have its own tree of calculations. And the exterior blocks will be affected by light on the outside of the of the box coming in. And this diagram is only 1 layer thick, in reality, this would be built as a cube, greatly increasing the number of interactions. These interactions remind me of leaf decay, and I remember when notch tried to "improve" leaf decay a couple years ago and it got so slow that my laptop couldn't run minecraft until it got fixed, it didn't crash, it just slowed to a stop once I got near a forest. And leaf decay didn't have a light calculation at every step. You could alleviate some of the calculation problems by reducing the limit from 5 to 4 or 3 or 2 layers, but then you're almost at opaque glass and what's the point? (opaque glass would be fine for the Z buffer by the way, so I might like that)
2
It is a well known issue. Anyone who has ever done 3D graphics programming knows that transparency is a complicated problem. Look up Z buffers. In order to do transparency the z buffer must keep track of more pixels and sort those pixels by depth. The more layers of transparent pixels you have means the z buffer must do more work. While there are tricks to simplify this and get a few layers of transparency with relatively little impact on performance, minecraft is a game where the terrain is totally customizable and you can circumvent the tricks by placing many many layers of colored glass. More advanced methods such as order independent transparency can solve some the speed problems, but most players graphics cards can't do that yet.
In summary: Colored glass is not impossible, but impractible. To do it right would require major changes to minecraft's graphics pipeline which would harm performance for most of the playerbase, and probably keep many people from playing because they have weaker graphics cards. Mojang does not like to do that, it took them until the new 1.6 update to move to new JLWGE because it means that powerPC users can no longer play, even though most players will see improved FPS and controls. It's simply not worth the work needed to properly implement such a minor feature that would harm many aspects of the game. You could always implement the cheap and easy colored glass and get crappy looking transparency problems.
1
I don't know what mod that guy refers to that keeps annoying you, but the idea to color light by passing it through colored glass is ridiculous. As bad as the overhead involved in colored glass and good transparancy is, colored light in general would be worse. But adding the additional requirement that light moving through a colored glass block changes the color of the light would really be the last nail in the coffin. Would you ray trace light from each torch through to every block it lights, look for intersections with colored glass, then do the color calculations? I suppose you could try and speed it up by limiting the radius to the 16 blocks around the torch, then searching that space for colored glass blocks, then only ray tracing through those blocks. However, if you built a wall of colored glass in front of a wall of torches, you still have a ton of calculations to perform. If you want to combine colored glass blocks to further control the color of the light, you'd need to an additional layer of ray tracing from each glass block to all the glass blocks around it, making the problem exponential.
These calculations could be server side or client side, but either way would cause serious reductions in FPS. The colored light data would most likely have to be stored in the map files, and if you want 256 shades each of red, green, and blue, that's 3 bytes (24 bits) per block on top of the 2 bits per block already used to determine light level (I suppose you could store intensity in the 3 bytes for color, since I can't imagine you'd have intense black light, darker colors would mean lower light levels, but you're still talking 24 bits for light instead of 2)
Calculating light levels server side would allow griefers to lag down servers with tons of torches and colored glass, and slow down chunk loading for players because of the increased memory per block. You could prevent this by doing lighting calculations client side, because you'd only have to tell the client that torches and colored glass exists, but the client would have to do the same lighting calculations, and wouldn't be able to store the data once calculated, it would have to calculate it every time the client loads the chunk or updates a block (at a minimum) where if the server did it it would need to calculate light on block updates, which probably doesn't improve much ( I have nightmares of giant colored glass and torch machines with pistons on fast clocks opening and closing windows and melting my server's CPU )