Windows .exe Is this deployer behaviour intended?

  • The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Status
Not open for further replies.

Jayemen

New Member
Jul 29, 2019
1
0
0
Everything below was done on a virgin copy of FTB 1.1.2, using the most recent version of Java 7 available at this time (update 21). All mod configuration has been left untouched.

I'm currently having an issue with deployers loaded with solid blocks acting oddly in the presence of liquid blocks. I've held off filing a bug report, because I'm not completely certain this is a bug.

To start off with, I have a deployer loaded with some stone. When activated, the deployer works as expected, placing a block directly in front of itself.
2013-06-16_19.50.50.png

However, if I add some water in front of the deployer, one block down, like so...
2013-06-16_19.51.00.png

... activating the deployer leads to the following, puzzling result:
2013-06-16_19.51.05.png

The deployer places the block below the expected destination. A second activation (with the stone still in place) works as expected, placing the block directly in front of the dispenser.

This happens with both source blocks and flow blocks, and with both lava and oil in addition to water. It happens when facing any direction on the horizontal, but I have not managed to get anything similar to happen with a vertically oriented deployer. It seems to happen when placing any solid block (I tested glass, stone, and cobblestone).

I just spent nearly an hour on Google trying to find more information on this, but I came up empty-handed. Sorry about writing such a long post for such a trivial thing; I spent over an hour trying to find out why a large frame-based machine was sporadically placing blocks incorrectly. It took me a while to narrow it down to this.

Edit:
If I disable everything except RedPower, this doesn't happen. If I enable CodeChickenCore, this begins to happen again.
 
Status
Not open for further replies.