Detector block functionality question

A place to talk to other users about the mod.
Post Reply
User avatar
Harcion
Posts: 59
Joined: Thu Jul 21, 2011 9:20 am

Detector block functionality question

Post by Harcion »

TL;DR version: When I let an item drop 70-75 blocks before it passes a detector block, the DB does not seem to detect it. It works for smaller and greater distances. How does the DB detect items, really?

Long version:

Hi everyone. I've been away from Minecraft for some time but recently I got back and have been working on a little physics experiment since.

The idea was to determine the gravitational constant using only ingame equipment. To do this I first built a high tower (which unfortunately does not lean like the one in Pisa where Galileo reputedly performed his famous experiment.) Then I set up detector blocks at regular intervals on the outside of the tower and down into a deep shaft. Each detector is hooked up to a little piston circuit that lengthens the emitted pulse, and then I have a simple redstone line circling up the inside of the tower with repeaters where needed.

On the top of the tower I have a timer that is activated by the first DB. It is a piston pulser that emits a pulse every 0.5 seconds (5 ticks). These are sent to a block dispenser that drops blocks of sand onto a hopper where they are collected. Kind of like a hourglass with metric tons of sand. This lets me measure time up to +- 0.5 seconds.

The idea is then to place an item on top of a block above and in front of the first DB, then remove that block with a sticky piston so that the item falls down. When it passes the first DB the timer is started. Then I have just one of the other DBs connected at the level where I want to measure. When the item passes this DB a signal is sent up which stops the timer. I have inserted repeaters to compensate for the delays incurred when the signal is transmitted up through the tower.

As +-0.5 seconds is a quite big error margin I perform 6 (or 7 to be sure) measurements at each level. In each, I delay either the first or the second signal by a set number of ticks. In this way I can bring down the error margin to 1/2 tick, i.e. 0.05 seconds.

So far so good, but I have until now only managed to determine that feathers and iron blocks fall equally fast and that Steve falls faster than items. (I hypothesize that there exists some kind of DSAF, Dark Steve Attracting Force.) As for the rest, I'm getting slightly strange data that makes me believe that there might be a problem with the equipment, i.e. the detector blocks.

Dropping items 10, 20, 25, 30, 40, 50, 60, 80, 90 and 100 blocks before the DB 'sees' them seems to work fine. However, when I try to measure at 70 or 75 blocks down I get no signal at all. I double-checked the setup and it should be correct (like at the other levels). I also tried dropping the item from 10 blocks lower than usual and then I get a signal...so it seems to be the distance fallen that is the issue, or maybe rather the velocity of the item. I'm thinking that maybe the items are falling fast enough that they pass the DB before it recognises them as being there and that the 80, 90 and 100 block distances are just lucky - the item happens to be in front of the detector when it tries to detect.

So...my question is basically: How does a DB detect an item, really? Does it check every tick? Every n ticks? When a nearby block updates?
I'm still using version 2.92 (will upgrade soon...) so I'm pre-wheat-detection if that changes anything.

I also tried using sand blocks instead of items, and those seem to work at all distances (because they have a greater size?). At one time I was also using a powered hopper to drop the items through since they then fall straight down. If I remember right, I had no problems with the 70-level then but rather with 80. I have to double-check this, though, but it seems consistent; I think the hopper spits out the items with a greater initial velocity than my remove-block-below method.

I kinda doubt my data because of this issue, and haven't started looking at using it to determine the gravitational constant. However, I'm starting to believe that there is a terminal velocity of 32 blocks/second for items, so that's the kind of velocity we are talking about; 0.03125 seconds to fall one block.
User avatar
FlowerChild
Site Admin
Posts: 18753
Joined: Mon Jul 04, 2011 7:24 pm

Re: Detector block functionality question

Post by FlowerChild »

My suspicion would be that the item in question is traveling at a sufficient velocity that it "skips" over an entire block vertically as it passes the detector and thus is not in front of it during an update. Updates occur 20 times a second, so you can probably work out the math from that.

This is a pretty standard kind of collision issue in games, but given that it would be a real pain to "fix" it in this case, I wouldn't be inclined to do so. Just think of it as the Detector Block not having time to "see" the fast moving object that is in front of it, or having time to change states even if it does before it is gone again.
User avatar
Battosay
Posts: 2043
Joined: Mon Jul 04, 2011 7:37 pm

Re: Detector block functionality question

Post by Battosay »

Have you tried to place a delayer directly after the DB instead of a redstone dust ?
I had a similar problem once (DB not "seeing" an item falling) and it solved it. It wasn't from so high though.
User avatar
Harcion
Posts: 59
Joined: Thu Jul 21, 2011 9:20 am

Re: Detector block functionality question

Post by Harcion »

FlowerChild wrote:My suspicion would be that the item in question is traveling at a sufficient velocity that it "skips" over an entire block vertically as it passes the detector and thus is not in front of it during an update. Updates occur 20 times a second, so you can probably work out the math from that.

This is a pretty standard kind of collision issue in games, but given that it would be a real pain to "fix" it in this case, I wouldn't be inclined to do so. Just think of it as the Detector Block not having time to "see" the fast moving object that is in front of it, or having time to change states even if it does before it is gone again.
Yes, this was what I was thinking too, and the 0.03125 seconds per block at an approximate velocity of 32 blocks/second is indeed less than 0.05 seconds. Darn it. Maybe I can work this into the error margin somehow, I'll have to think about it.

And no, I was not at all going to ask you to "fix it", I merely wanted to confirm that it worked like I thought it did. :) Thanks for confirming my suspicions.
Battosay wrote:Have you tried to place a delayer directly after the DB instead of a redstone dust ?
I had a similar problem once (DB not "seeing" an item falling) and it solved it. It wasn't from so high though.
Thanks for the suggestion. Even though I believe the issue above is the cause, I will try this too just to check. I think my pulse lengtheners are actually doing something similar, but it doesn't hurt to test.
User avatar
Fracture
Posts: 570
Joined: Tue Jul 05, 2011 12:38 am

Re: Detector block functionality question

Post by Fracture »

In addition to the DSAF making him accelerate faster, it also allows him to ignore terminal velocity and, from my experience on CMP servers with incredible height limitations, accelerate infinitely. This is not, however, true in lava or water, only air.
Abracadabra, you're an idiot.
User avatar
Harcion
Posts: 59
Joined: Thu Jul 21, 2011 9:20 am

Re: Detector block functionality question

Post by Harcion »

Harcion wrote:
Battosay wrote:Have you tried to place a delayer directly after the DB instead of a redstone dust ?
I had a similar problem once (DB not "seeing" an item falling) and it solved it. It wasn't from so high though.
Thanks for the suggestion. Even though I believe the issue above is the cause, I will try this too just to check. I think my pulse lengtheners are actually doing something similar, but it doesn't hurt to test.
Just to report that I tried this, with no change, so it must be the items falling too fast. This also explains why the sand blocks are fine, as their greater size means that during 0.05 seconds at least some part of them will be in front of the detector at that speed.

I also determined that because of the way I set up the experiment I only lose another +-0.05 seconds of certainty because of DB lag, and I have a feeling that it could be made even less with some clever adjusting of the DB positions. However, until I figure that out, +-0.1 seconds certainty feels like a little too much when the largest data value is 3.7 seconds. Or perhaps I'm just not enough of a statistician. I'll have to run some more tests on more height levels.
Fracture wrote:In addition to the DSAF making him accelerate faster, it also allows him to ignore terminal velocity and, from my experience on CMP servers with incredible height limitations, accelerate infinitely. This is not, however, true in lava or water, only air.
Very interesting, thanks for sharing. :) I had a feeling the acceleration was constant, but a 100 block drop is not really that far and I don't quite trust my senses any more. Using Steve as the test subject is quite tedious too, since you have to get up to the top after each trial. Even with a boat elevator it takes some time.

I tried using wolves, but they are a pain to get into position, and I had even more "non-detect" troubles with them. Also, they keep moving in the air or something and die from impacts with the ground. Which messes up the detector circuits because of stray wolfchops. Hrm. When they manage to get it right it's nice though, because as they stand up when hitting water they immediately teleport up to me at the top of the tower...but all in all it was more trouble than it was worth.
rosstafan
Posts: 43
Joined: Thu Aug 11, 2011 6:58 am
Location: climbin in yo window

Re: Detector block functionality question

Post by rosstafan »

If you can make the shaft two wide have it alternating to slow the items down
Like this:

Were @ is water source
And X is the walls
And - Is signs or ladders
And Y is running water

X X
X X
X X
X X
X X
@YYX
XX-X
XX X
XX X
XYY@
X-XX

And there is your brake (hope it's easy to understand
The list I could make of all the things this mod is better than.
User avatar
Fracture
Posts: 570
Joined: Tue Jul 05, 2011 12:38 am

Re: Detector block functionality question

Post by Fracture »

rosstafan wrote:If you can make the shaft two wide have it alternating to slow the items down
Like this:

Were @ is water source
And X is the walls
And - Is signs or ladders
And Y is running water

X X
X X
X X
X X
X X
@YYX
XX-X
XX X
XX X
XYY@
X-XX

And there is your brake (hope it's easy to understand
Slowing things down would be a bit counter-productive to finding Minecraft's gravitational constant or the magnitude of the DSAF.
Abracadabra, you're an idiot.
rosstafan
Posts: 43
Joined: Thu Aug 11, 2011 6:58 am
Location: climbin in yo window

Re: Detector block functionality question

Post by rosstafan »

Fracture wrote:Slowing things down would be a bit counter-productive to finding Minecraft's gravitational constant or the magnitude of the DSAF.
Sorry, though that you were more interested with the DB detecting the item rather than find the speed
The list I could make of all the things this mod is better than.
Post Reply