Laylem reports: [moreblocks] I'm wondering, wh ... #3527
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#3527
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?
Laylem reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
sent an email to laylem:
Additionally, we can see that slabs and panels etc. smaller than 1/8th don't get 100% efficiency?
every stairs+ node is "x/8" of a normal node, where 1 <= x <= 8. despite the fact that they sometimes don't translate to the nearest reasonable value for their volume, they're all consistent - you can trade them back in for exactly as much material as you used to create them, if you don't hit an of the current moreblocks bugs.
imo, there's no good reason why the value of a node should be equal to it's apparent relative volume.
let's see, volume of a cone is
base * height / 3
, so the volumes of those shapes are1/3
and1/6
respectively. rounding to the nearest multiple of1/8
, this becomes3/8
and1/8
. that means the stack sizes ought to be8
and24
, so it looks like the number of 8ths allocated toslope_outer_half
is2/8
when it should be1/8
, but again, the material isn't actually lost, since the thing can be recycled.however, i should audit the quantities allocated to the shapes to make sure they're correct in my moreblocks fork.
implemented in
39c0558248
i suppose i never addressed this directly.
players will have a fit if they can't recover even small slivers of their valuable materials (or even sgg), which they used to be able to recover. that is why i consider losing material a non-starter. however, as this issue pointed out, some of the values needed slight tweaking.
trying to allow meaningful divisions of a node into smaller-than-1/8th pieces is technically possible, but it's quite tricky to get right, particularly if you want everything to be recycle-able. sure, it's easy to say that you need 2 1/16 slabs to recover 1/8 of a node of material, but players will get confused when they can e.g. only recover material w/ input in multiples of 7 for one shape and 11 for a different shape. the current mechanics (well, the mechanics in my moreblocks fork) are logical and intuitive, once you learn that everything is calculated in 1/8th nodes.
Let's test this issue together with moreblocks ore reschedule