Minecraft Forums

I think this could help!

I´d say it´s definitively a vanilla thing.

Just like when you put a name tag (thing used to name mobs) on a mob, it shows the name in the same way.

I've sent you a personal message!

Quote from Phycozz»

This chances of this happen are a near 0% chance, but an enderman could pick up the block covering you and mobs could then kill you. That would be a death to write home about

Try the "Pam's Harvestcraft" mod

It gives a lot of food options, including alternate recipes that use tofu.

It also makes things like toficken and tofu(any meat) be oredictionary compatible with other recipes that require meat, even if they are from other mods.

That's too much tick time.

the original is 3 and if you want a lot set it to 100 or 1000.

Quote from EnchantedDiamondPickAxe»

About 2 days worth of work.

You have certainly done a very good work

I was boored (and feeling nostalgic) so I went to the maps section and I saw this.

I'm really looking forward to play this map!

Looks incredible!

It looks like this:

 # IF a dimensionId is listed in 'skySupportedDimensions' you can add it here to keep its sky render, but AS will try to render only constellations on top of its existing sky render. [default: ]
    S:weakSkyRenders <
        0
     >
}

There is no score doing that, though you can do that using a little trick :

The dimension a player is in is stored into its "Dimension" tag.

All you have to do is to create a "dimension" dummy objective and a deathCoun objective.

You'll have to permanently store each player's Dimension tag value into its "dimension" score, and when a player's deaths score matches 1.., simply look at its "dimension" score to check in which one it died.

Here are commands for that (not tested) :

Run once :

scoreboard objectives add dimension dummy
scoreboard objectives add deaths deaths

Run each tick :

execute as @a store result score @s dimension run data get entity @s Dimension
execute as @a[scores={deaths=1..,dimension=-1}] run say I died in netheeeeer! ___ //Nether is dimension -1
scoreboard players reset @a[scores={deaths=1..}] deaths

I am sorry, but I found this subject to be much more interesting than I first thought. I put together a much more versatile command that I think you will prefer over the first reply I had made. Once again, we are using two repeating command blocks set to always active with the following commands:

execute at @e[type=item,name="Coal"] if block ~ ~-1 ~ minecraft:stone if block ~ ~1 ~ minecraft:cobblestone run summon minecraft:item ~ ~ ~ {Item:{id:"minecraft:diamond",Count:1b}}

execute as @e[type=item,name="Diamond"] at @s if entity @s if block ~ ~-1 ~ minecraft:stone if block ~ ~1 ~ minecraft:cobblestone run kill @e[type=item,limit=1,name="Coal"]

These commands are much alike my previous ones, however, it will work relative to the dropped items position. This means that you are not limited to certain coordinates. The command is executing at the coordinates of the dropped Coal and searching for a block below and above the coal (Stone above and Cobblestone below). The things you will have to change in the commands are:

• The @e selectors
• You will have to change the "name=" of the item it is executing as. Be sure to use the actual listed name of the item! (Ex. Instead of "minecraft:experience_bottle" you have to use "Bottle O' Enchanting")

• The block searches
• You can specify any blocks for the above and below blocks by changing the minecraft:stone and minecraft:cobbestone. I have also tested to see if it works if both the above and below blocks were the same and it still works perfectly fine.

I hope this reply is better than the first one I had posted, and I once again give my apologies for making multiple replies, but I am sure it was worth it for the better commands. Enjoy! (P.S. Your English is perfect as far as I can see)

Input 1 goes into a torch, Input 2 goes into a repeater, then OR the outputs.

This is the Costa Fascinosa, a Concordia-class cruise ship and sister ship of the Costa Concordia. The ship was launched in 2012 when it was named the flagship of Costa Cruise Lines from 2012 to 2014. The Costa Fascinosa weighs 113,321 tonnes and can hold 3,800 passengers and 1,110 crew. The length of the ship is 290m and the breadth is 35.5m. This ship was the Carnival Splendor, but I am refurbishing it into the Fascinosa. I started this project in July of 2017, and have been slowly working on it, and now I bring you a halfway there download!

NOTE* THIS SHIP IS STILL IN THE MIDDLE OF BEING REFURBISHED SO SOME AREAS ARENT DONE YET, WHILE OTHERS ARE STILL THE Carnival Splendor.

I give tonnes of credit to Alexnyc8214, for the rooms, bridge, and most of the interior.
Carnival Splendor Link: https://www.planetminecraft.com/project/carnival-splendor-2753163/

Alexnyc8214's Page:]www.planetminecraft.com/member/alexnyc8214/]www.planetminecraft.com/member/alexnyc8214/

Link to my Planet Minecraft account: https://www.planetminecraft.com/member/orson_krennic/

Link to my project: https://www.planetminecraft.com/project/first-full-interior-mega-build-costa-fascinosa/

One of my biggest pet peeves is people posting screenshots taken in a dark cave which appear to be completely dark to me (or barely visible) yet they claim to clearly see something, or worse, videos that are unwatchable because you can't see anything; the ability to see in total darkness also renders torches unnecessary when caving, and while they can prevent mobs from spawning it doesn't matter if they spawn in areas you went through unless you go back and if you light up a cave system they will become concentrated in unlit areas, increasing the number of mobs you encounter (while exploring a large cave system the rate at which I encounter mobs peaks just before I completely light it up).

While the brightness, contrast, and gamma settings for your monitor play a role (in particular, the default gamma used by Windows is far too high for me as I have to use its color calibration tool to set it as low as possible to get a "good" gamma according to its calibration image) the main issue is that the game was coded so that rendered brightness varies between 3-99%; worse, when the gamma adjustment is applied it is additionally scaled by another 3-99%, amplifying the effect of increasing gamma (note the last three lines in each code block, which multiply a value by 0.96 and add 0.03):

float var4 = var2.getSunBrightness(1.0F) * 0.95F + 0.05F;
float var5 = var2.provider.lightBrightnessTable[var3 / 16] * var4;
float var6 = var2.provider.lightBrightnessTable[var3 % 16] * (this.torchFlickerX * 0.1F + 1.5F);

if (var2.lastLightningBolt > 0)
{
     var5 = var2.provider.lightBrightnessTable[var3 / 16];
}

float var7 = var5 * (var2.getSunBrightness(1.0F) * 0.65F + 0.35F);
float var8 = var5 * (var2.getSunBrightness(1.0F) * 0.65F + 0.35F);
float var11 = var6 * ((var6 * 0.6F + 0.4F) * 0.6F + 0.4F);
float var12 = var6 * (var6 * var6 * 0.6F + 0.4F);
float var13 = var7 + var6;
float var14 = var8 + var11;
float var15 = var5 + var12;
var13 = var13 * 0.96F + 0.03F;
var14 = var14 * 0.96F + 0.03F;
var15 = var15 * 0.96F + 0.03F;



var16 = this.mc.gameSettings.gammaSetting;
var17 = 1.0F - var13;
float var18 = 1.0F - var14;
float var19 = 1.0F - var15;
var17 = 1.0F - var17 * var17 * var17 * var17;
var18 = 1.0F - var18 * var18 * var18 * var18;
var19 = 1.0F - var19 * var19 * var19 * var19;
var13 = var13 * (1.0F - var16) + var17 * var16;
var14 = var14 * (1.0F - var16) + var18 * var16;
var15 = var15 * (1.0F - var16) + var19 * var16;
var13 = var13 * 0.96F + 0.03F;
var14 = var14 * 0.96F + 0.03F;
var15 = var15 * 0.96F + 0.03F;

This should be changed to use a range of 0-100%, or very nearly so, then the "brightness" setting will work as intended, by changing the light level curve between 0 and 15 from nonlinear on Moody to linear on Bright, with light levels of 0 and 15 being unaffected, as initially intended when it was first added by Optifine (I do not know if Optifine's original version used the same code as vanilla currently does; current versions (1.6.4) of Optifine do not alter it):

Minecraft uses non-linear light levels. The difference between level 0 and 1 is much smaller than the difference between level 14 and 15.

On a good calibrated monitor which can show near-black colors the Minecraft night scenes are almost fully black (light level 4). On the other hand, not so good monitors which have problems with near black colors show the night scenes very good.

The Brightness setting fixes the Minecraft light levels for properly calibrated monitors. Brightness 0% corresponds to default Minecraft light levels. Brightness 100% uses linear light levels, so the steps between all light levels are equal.

http://optifog.blogspot.com/2011/05/version-1501f.html

After modifying the brightness range from 3-99% to 0.3 to 99.6%* for both instances in the code shown above; the only things visible should be some fog near the center and mushrooms near the bottom (I can only (barely) see the latter on Bright in either vanilla or modified; fog is visible in all cases. According to GIMP most of the pixels in the second (Bright) screenshot have RGB values of 1,1,1 or less):

Also, here is a version of the second screenshot (on Bright) that I enhanced with GIMP:


Modified light levels with torches (Moody and Bright); the effect on nonzero light levels is minimal but torches are much more effective at visually lighting up an area up on Bright (and IMO the smoother light gradient looks much better):

*Note that a range of 0-100% caused Night Vision to not work underwater, and possibly in other situations but that may be related to MC-58177, which as noted causes Night Vision to be bugged on Moody in vanilla, likely due to a too-low brightness, and should be fixed regardless, but a minimum brightness of 0.3% should appear be the same as 0%.

Also, gamma should be internally limited to a range of 0-1 (0-100%) to prevent people from editing options.txt to get permanent "Night Vision" - if you want to see in the dark without torches use the Night Vision potion effect. This should have no effects on gameplay other than preventing cheating (unless mods are used) since mapmakers should use Night Vision instead of telling the player to increase gamma (I don't think anybody even does that anyway since you have to restart the game to change it to a value outside of the range set by the slider).

Note: This suggestion does not apply to the Nether or End, which intentionally increase the minimum brightness so you can see without having to use torches, similar to how the Overworld still has a light level of 4 at night.

Let's do some research, hm? Just bear with me on this.

People have been claiming that Minecraft is dying as soon as 11 months after Classic was released. Which was seven years ago.

There is a long history of threads like this. Long enough that I even made a two-year-long bet in order to prove that it wasn't dying.

All of the various issues that people claimed will kill/killed Minecraft or is a sign of dying/death and the times they claimed them (first posts of threads only), are as follows:

1. Notch's girlfriend, 2010

2. Lack of innovative content, 2011, 2012, 2013, 2013, 2014, 2014, 2015, 2017

3. Notch not working on things, 2011

4. Unbalanced/not fleshed-out content, 2011, 2013, 2013, 2013, 2015, 2017

5. Lack of things that are commonly suggested in the Suggestions Forum, 2011, 2013, 2017, 2017, 2017

6. Taking too many suggestions from the internet, 2011

7. New content/updates, 2010, 2011, 2011, 2011, 2011, 2011, 2012, 2012, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2014, 2015, 2015, 2016, 2017, 2017, 2017

8. Less frequent/lack of updates, 2010, 2011, 2013, 2014, 2015, 2016, 2016

9. The game has credits/The End, 2011, 2011

10. It's Jeb's fault/Notch stopped working on the game, 2013, 2013, 2013, 2014, 2015

11. Other newer games are better, 2011, 2013, 2013

12. Mojang being malicious, apathetic, lazy, or clueless, 2013, 2013, 2015, 2017, 2017, 2017

13. Children/child-friendliness/decreased difficulty, 2012, 2013, 2013, 2013, 2013, 2014, 2015, 2015, 2017, 2017

14. The community/mods, 2011, 2012, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2013, 2014, 2014, 2014, 2014, 2014, 2014, 2014, 2015, 2015, 2015, 2015, 2015, 2016, 2016, 2016, 2016, 2016, 2017, 2017, 2017, 2017

15. The EULA/Bukkit being taken down, 2014, 2014, 2014

16. Microsoft's involvement, 2012, 2014, 2014, 2014, 2014, 2014, 2015, 2015, 2017

17. Notch leaving Mojang, 2014

18. Personal lack of interest, 2013, 2014, 2014, 2015

19. Cyber attacks, 2015

20. Google Search stats/lack of media attention, 2015, 2016

(If anyone finds one not included, please let me know via PM. I'll add it to the list.)

This thread falls into three of these- #13, #2, and #12, which have, in the 4-6 years they have been claimed to be Minecraft-slayers, not killed Minecraft a single time. Nor is there evidence that they have generated a decline in said period of time.

If anything, #14 (specifically the community) is the most likely to kill Minecraft, seeing as, you know, Minecraft is alive so long as people play it. Though I am not of the opinion that any one group of bad players is going to do it. Rather, it'll be a slow and gradual death at the hands of apathy and time.

*project

Nintendo shut down the Pixelmon mod! It's so ridiculous, the mod doesn't even use the title of "Pokemon", it just has low-res models that happen to look like Pokemon! And it's not like the developers are making a profit from it.

This is like what happened with GTA V and it's modding community!

We need to boycott Nintendo, do not buy Pokemon Ultra Sun and Ultra Moon when they come out!

EDIT: Let's make this the most popular thread to spread the news, and also go sign the petition that the developers started that already has 2000 signatures!