Pegasus Epsilon
Assigned
Reported
Comments
Boy, it sure would be nice if someone would bother fixing this, so people could actually test things...
You don't tell me how to do your job, and I won't tell you how to do mine.
I don't care if you have a fancy tag on your name. All you succeeded in doing is lowering the signal-to-noise ratio, and the lecture isn't helping. She already has her answer. The issue is closed, so do the last remaining fragment of your job that hasn't been done for you and close it.
You're very welcome. Best of luck to you. 😁
Again, not helpful. I already found her her answer. You're welcome.
"There is no crash log, please help."
"Where's the crash log?"
"There is no crash log."
"There is always a crash log. Where is it?"
"There is no crash log."
"WHERE IS THE CRASH LOG??"
Please. Read the report. Assume the person reporting the bug (or support request in this case) is doing their best to be honest and accurate. Under those assumptions, attempt to actually help. This is like watching an Indian call center do tech support in text format. Your scripted responses are not helpful. Do something helpful, or just don't do anything. You're only bothering the people actually trying to fix this.
Can you check for a crash log again? If it loaded to where you can see the Mojang logo, there's usually a crash log.
If it's still not there, can you make sure the indicated switch in the dialog pictured is enabled, and try again? It should pop up a white window full of logs, which you can just take a screenshot of.
[media]Old launcher or new launcher? Can you screenshot the logging window that pops up? Did you try moving/deleting the entire .minecraft folder?
Yup. I'm sure when he says "There is no crash report", harassing him for a crash report is the best way to help. Keep up the good work. 👍
Way to read the report. Good job.
Did you try deleting (or renaming) the entire .minecraft folder? Did you try paying attention to the logging window that opens when you start the game? Sometimes it has useful errors in it. Are you using the old launcher, or the new one?
1.13-pre5, on server startup:
[23:56:57] [main/WARN]: Ambiguity between arguments [teleport, destination] and [teleport, targets] with inputs: [Player, 0123, @e, dd12be42-52a9-4a91-a8a1-11c01849e498][23:56:57] [main/WARN]: Ambiguity between arguments [teleport, location] and [teleport, destination] with inputs: [0.1 -0.5 .9, 0 0 0][23:56:57] [main/WARN]: Ambiguity between arguments [teleport, location] and [teleport, targets] with inputs: [0.1 -0.5 .9, 0 0 0][23:56:57] [main/WARN]: Ambiguity between arguments [teleport, targets] and [teleport, destination] with inputs: [Player, 0123, dd12be42-52a9-4a91-a8a1-11c01849e498][23:56:57] [main/WARN]: Ambiguity between arguments [teleport, targets, location] and [teleport, targets, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
@unknown I'm not the one that discovered that problem. Tell @unknown.
That's not the bug anyway. Mojang should let us texture pack the bar, since that's a solution that will please everyone.
@unknown I specifically suggested that they let us texture pack it. That would let you go back to the old colors if you preferred them.
Now the durability bar doesn't turn red until the last pixel is left.
This is not a fix, this is replacing one bug with another. I support creating a new bug to get them to fix it properly.
@unknown I have no idea how to make red more visible, but if they'd let us texture pack it like I suggested, you could have a solid bar instead of a shrinking one that isn't even visible until it turns fully red at 5 or 10% durability.
Mojang - Please fix this properly, come on...
He wrote the original code and he's capable of commenting here, same as anyone else. He's the only one that can tell you with 100% certainty why it works how it does.
I have asked notch to comment on this issue, but until he does, or if he does not, let's examine the possibilities.
1) notch sat down and thought, and intentionally decided to make the durability bar nearly invisible at 50% and nearly unnoticable at 0%
2) notch didn't know how to do a HSV to RGB colorspace conversion
3) notch didn't understand why an HSV to RGB colorspace conversion was useful here
4) notch was busy, distracted, or lazy, when he wrote this code, and just did an RGB colorspace linear crossfade because it's faster to write.
Let's look at what those four options say about notch.
1) notch is a dick who enjoys screwing users. Works as intended.
2) notch is ignorant and can't work the google. Bug.
3) notch is incompetent and doesn't understand color. Bug.
4) notch was writing an entire game by himself, and decided that the durability bar wasn't important enough (at that moment) to write correctly. Bug.
So until notch himself shows up and tells you it's #4, what would you like to say happened again?
If I were suggesting that the bar be added, I'd agree with you. But I'm not suggesting that. I'm saying that the bars fade from green to red using the wrong colorspace. Which makes it a bug. It's also been this way since indev, which ranks it right up there with bug #4, IMO.
The good:
The BUD problem is a valid statement, BUDs should be deterministic regardless of coordinate, and fixing that first, will greatly simplify the rest of this problem.
The bad:
The idea that a circuit cannot be emulated properly regardless of coordinates is provably false. There are numerous circuit emulators out there that work just fine regardless of where you drag the components around in their UI. A "computer" incapable of deterministic operation is a worthless device.
I think we do need (at least) three separate passes on all redstone components in a circuit to do it properly, but the idea that it can't be done is absurd.
The funny:
$10 says I can use this piece of your proposed patch alone to send your server into a CPU-hogging infinite loop and never tick again.