Minecraft Snapshot 12w17a

[Tom]

You sound like you've looked at the source code.  Maybe I should do that as well before further conjecturing on what they could / should change / fix

Not looked at it, but many of the blocks and objects have collision shapes. At one point the collision shape was removed from ladders (or signs)? Then it was added back. Also I've been hanging around a bunch of people that make games. This is how its typically done

[Thorin]

You want to explore the Minecraft Coder Pack

My couple of years at a GIS company taught me that object collision detection code starts off really simple as long as everything is a four-sided block, but gets very complicated as soon as you allow non-regular shapes.  For instance, dimples on the surface of even one of the objects makes it very hard to determine if there actually was contact, or just closeness.

Nevertheless, as I said before, I wouldn't mind if they worked on collision detection code to (hopefully) stop the glitching.

[Darren Dirt]

Editable books! does this mean the end of literal "Wall of Text" in Adventure maps?

make sure you don't misspeel dialooooj... I mean dialogue!

[Mr. Analog]

Editable books! does this mean the end of literal "Wall of Text" in Adventure maps?

make sure you don't misspeel dialooooj... I mean dialogue!

Hahah Ah! More Dialooj.

[Tom]

You want to explore the Minecraft Coder Pack

My couple of years at a GIS company taught me that object collision detection code starts off really simple as long as everything is a four-sided block, but gets very complicated as soon as you allow non-regular shapes.  For instance, dimples on the surface of even one of the objects makes it very hard to determine if there actually was contact, or just closeness.

Most things skimp on accuracy. In most cases you can get away with varying sizes of rectangles. Other times you might want to do circles, or polygons. Circles aren't too bad. Polygon collisions is a bit more complex, but its not /that/ bad. That tends to involve line segment tests.

Nevertheless, as I said before, I wouldn't mind if they worked on collision detection code to (hopefully) stop the glitching.

Indeed.

Editable books! does this mean the end of literal "Wall of Text" in Adventure maps?

make sure you don't misspeel dialooooj... I mean dialogue!

Hahah Ah! More Dialooj.

Ahaha. Dialouge!

[Mr. Analog]

I think that's been one of my favourite adventures, alongside Deep Space Turtle Chase

[Tom]

I think that's been one of my favourite adventures, alongside Deep Space Turtle Chase

You're going to sigh... But I can't remember which one that was. I've watched so many of them...

[Darren Dirt]

I think that's been one of my favourite adventures, alongside Deep Space Turtle Chase

You're going to sigh... But I can't remember which one that was. I've watched so many of them...

part 1: http://www.youtube.com/watch?v=ZsRqhBTe8Mk

and ... now I have something to watch during my lunchtimes next week    ( parts x 12-18 minutes each = yup pretty much all of next week :wheee: )

[Thorin]

You want to explore the Minecraft Coder Pack

My couple of years at a GIS company taught me that object collision detection code starts off really simple as long as everything is a four-sided block, but gets very complicated as soon as you allow non-regular shapes.  For instance, dimples on the surface of even one of the objects makes it very hard to determine if there actually was contact, or just closeness.

Most things skimp on accuracy. In most cases you can get away with varying sizes of rectangles. Other times you might want to do circles, or polygons. Circles aren't too bad. Polygon collisions is a bit more complex, but its not /that/ bad. That tends to involve line segment tests.

That's one of those things that's easy to say, but experience will teach you that skimping on accuracy just gets you complaints, and not skimping on accuracy is hard.

Here's an example: In an area bounded by what I would consider my volume of hair, I want to know if a certain cubic micrometer is hair or air.  I could brute-force it and check every hair, but I want this entire check to take no more than 500 microseconds and I can probably accomplish 2 checks per microsecond.  So first I remove all hairs that do not intersect any of the X, Y, and Z axes of the cubic micrometer, since if they don't intersect any at all they don't count.  To make it easier I instead select all the hairs that _do_ intersect all of the X, Y, and Z axes of the cubic micrometer, since that's the only way they'll be able to occupy that particular micrometer.  But hairs can bend, and they could bend in such a way that they occupy one of the axes at a time but not the rest.  So now for all those hairs left, I have to check for each of the three axes where the hair intersects them in respect to the other axes.  As the hairs are stored as bendable tubal shapes not straight lines, I can't simply say "where X is this and Y is that and Z is this other number".  This is normally done with very short straight segments, but the longer the segments the less accurate the final result.

And accuracy is probably what is missing from Minecraft's collision detection code, probably causing the glitching.  Then again, if it's made super accurate then it would take longer than the 50ms of a Minecraft tick just to do the collision detection for Steve and a couple creepers.

[Tom]

You want to explore the Minecraft Coder Pack

My couple of years at a GIS company taught me that object collision detection code starts off really simple as long as everything is a four-sided block, but gets very complicated as soon as you allow non-regular shapes.  For instance, dimples on the surface of even one of the objects makes it very hard to determine if there actually was contact, or just closeness.

Most things skimp on accuracy. In most cases you can get away with varying sizes of rectangles. Other times you might want to do circles, or polygons. Circles aren't too bad. Polygon collisions is a bit more complex, but its not /that/ bad. That tends to involve line segment tests.

That's one of those things that's easy to say, but experience will teach you that skimping on accuracy just gets you complaints, and not skimping on accuracy is hard.

Here's an example: In an area bounded by what I would consider my volume of hair, I want to know if a certain cubic micrometer is hair or air.  I could brute-force it and check every hair, but I want this entire check to take no more than 500 microseconds and I can probably accomplish 2 checks per microsecond.  So first I remove all hairs that do not intersect any of the X, Y, and Z axes of the cubic micrometer, since if they don't intersect any at all they don't count.  To make it easier I instead select all the hairs that _do_ intersect all of the X, Y, and Z axes of the cubic micrometer, since that's the only way they'll be able to occupy that particular micrometer.  But hairs can bend, and they could bend in such a way that they occupy one of the axes at a time but not the rest.  So now for all those hairs left, I have to check for each of the three axes where the hair intersects them in respect to the other axes.  As the hairs are stored as bendable tubal shapes not straight lines, I can't simply say "where X is this and Y is that and Z is this other number".  This is normally done with very short straight segments, but the longer the segments the less accurate the final result.

And accuracy is probably what is missing from Minecraft's collision detection code, probably causing the glitching.  Then again, if it's made super accurate then it would take longer than the 50ms of a Minecraft tick just to do the collision detection for Steve and a couple creepers.

Most games do not need nor want perfectly accurate collision detection. It is incredibly expensive to do. So what you do, is build up a set of bounding "boxes" or "spheres" or "shapes" and test against those. A single object may have more than one collision component. It gets sorta close to perfect, but not so close that you have to start checking every pixel.

Some accuracy might be missing from MCs code, but I think its more like the AI is incredibly broken, and doesn't fully respect the collision bounds. My impression of the original code base (before jeb started on it, he seems to have been doing a good job improving things and fixing bugs), is that it is a pile of hacks piled on top of more hacks.

[Thorin]

Yes, I fully understand hit boxes and collision bounding boxes.  And using boxes makes things quick and easy (and explains why I can hit you in MvC3 without my character touching yours).  Your previous comment made it sound like you thought collision detection was easy - it is if you are okay with lacking accuracy, but polygonal shapes, especially with holes, are actually quite hard.  Which is why, as you say, most games switch to rectangles for everything (that's why in Black Ops (or MW3?) you shoot at the ground in front of the guy and still kill him).

While you may ultimately be correct about the state of the Minecraft code back when Notch was working on it, I strongly suggest you look at the code first before passing judgement.  Flipping on the idiot switch without even looking at the code is a terrible habit to have if you plan to program for a living, as you will come across a _lot_ of code that for the first twenty read-throughs will seem like a real WTF - then you change it and everything breaks, and then you learn about some subtle bug in the OS that this WTF code works around.

And at that GIS shop I worked at, we _did_ have to be super-accurate about intersecting objects, as part of the software figured out which strand of fiber should be looped in which direction without contacting certain other materials.

[Mr. Analog]

Reminds me of this vid for hitbox in TF2 (I think it's slightly different now)
http://youtu.be/9TJmiDcsxdA

Cool nonetheless, also helpful if you're a newbie Sniper

[Tom]

Yes, I fully understand hit boxes and collision bounding boxes.  And using boxes makes things quick and easy (and explains why I can hit you in MvC3 without my character touching yours).  Your previous comment made it sound like you thought collision detection was easy - it is if you are okay with lacking accuracy, but polygonal shapes, especially with holes, are actually quite hard.  Which is why, as you say, most games switch to rectangles for everything (that's why in Black Ops (or MW3?) you shoot at the ground in front of the guy and still kill him).

While you may ultimately be correct about the state of the Minecraft code back when Notch was working on it, I strongly suggest you look at the code first before passing judgement.  Flipping on the idiot switch without even looking at the code is a terrible habit to have if you plan to program for a living, as you will come across a _lot_ of code that for the first twenty read-throughs will seem like a real WTF - then you change it and everything breaks, and then you learn about some subtle bug in the OS that this WTF code works around.

And at that GIS shop I worked at, we _did_ have to be super-accurate about intersecting objects, as part of the software figured out which strand of fiber should be looped in which direction without contacting certain other materials.

It's hard to take a look at closed source code Generally though you can tell the quality of code by using the program, noting the types of bugs, and how long and how many tries it takes to fix.

And I do realize there is a lot of WTF code out there. It doesn't really excuse many of the bugs that have plagued Minecraft though. There is a difference between complex and hairy code, and pure buggy code.

[Thorin]

You want to explore the Minecraft Coder Pack

Minecraft's _complete source code_ is available to anyone who wants it.  Notch did this so that modders could more easily mod Minecraft, instead of having to try and de-obfuscate on their own and get it wrong.

And because of that particular attitude, I actually feel more compelled to pay for a copy rather than pirate it - he clearly is trying to follow the "do no evil / help your users enjoy your software" ideals.  Which doesn't necessarily make him a good coder, but certainly a better company to interact with than many profits-focused large companies.

Anyway, if you think you can make it better, get MCP, crack open the source, and fix it.  Re-compile and re-obfuscate, then release as a mod.  Or alternately don't release as a mod but send to Mojang as a fan-created patch.  I'm sure they wouldn't mind if it actually fixes the problems.

[Tom]

You want to explore the Minecraft Coder Pack

Minecraft's _complete source code_ is available to anyone who wants it.  Notch did this so that modders could more easily mod Minecraft, instead of having to try and de-obfuscate on their own and get it wrong.

And because of that particular attitude, I actually feel more compelled to pay for a copy rather than pirate it - he clearly is trying to follow the "do no evil / help your users enjoy your software" ideals.  Which doesn't necessarily make him a good coder, but certainly a better company to interact with than many profits-focused large companies.

Anyway, if you think you can make it better, get MCP, crack open the source, and fix it.  Re-compile and re-obfuscate, then release as a mod.  Or alternately don't release as a mod but send to Mojang as a fan-created patch.  I'm sure they wouldn't mind if it actually fixes the problems.

Wow. That is not something I expected. Notch was /very/ against that to begin with. I might just have to mess around with it for a bit. For one, I want a god damn mine shaft elevator. And a mine cart sensor that senses if someone is in the cart or not.