LeetPeet reports: Can you make colored bricks no ... #1201
Labels
No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#1201
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
LeetPeet reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
Aloha,
I cannot reproduce the issue, can you show me? In my experiments the coloured bricks were set down the way they should.
We're talking of cblocks:stonebrick_magenta and sorts?
Greetings, Alias
This might depend on your "rhotator settings".
I placed a
cblocks:stonebrick_orange
on adarkage:basalt_brick
w/param2=0
. I rotated it once, so thatparam2=2
.I then placed another
cblocks:stonebrick_orange
against the west side of the firstcblocks:stonebrick_orange
. It set itself w/param2=18
, which is far from expected for any model I can intuit.I'm not certain where the param2 shenanigans originate, but I suspect rhotator.
Why would rhotator do that? I better not ask. Let's reproduce with and without rhotator, if your suspicion holds true, then this is an upstream rhotator issue. If not, then this is an upstream cblocks issue.
Reproduced flux setup.
same strange rotations like flux & LeetPeet
perfectly works using a previous copied rotation
nicely rotates to the same param2 as the node you pointed at.
Also tried with default:stonebrick same result except with rhotator off I dont get strange rotations.
So I guess that it isnt rhotators fault but cblocks.
checked cblocks code and in Line 110 there is
on_place = minetest.rotate_node,
I dont totally get what rotate_node does but could that be the culprit?
ah, yes, that's almost certainly it. however, rhotator does muck w/ nodes that don't define an
on_place
themselves.though not when rhotator memory is set to off. apparently the engine does the rotation for facedir nodes automatically, unless you set
place_param2 = 0
Are those coloured bricks the only ones that have this?
If they are the only ones, we should disable it on them as well. I'd like to unify how rotation works when placing a block.
Participants in this discussion are only a small fraction of those that use the feature, we could ask the general audience in a demonstration in Haven which way they prefer and then make this available for everyone.
I am opposed to each and every block deciding on their own, how they want to be placed - unless there is a compelling reason they are different?
no, moretrees planks are another notable example