Remove mob fence and make all other fences not-jumpable #49

Closed
opened 2020-09-22 20:34:28 +00:00 by AliasAlreadyTaken · 7 comments

Reporter: Skyisblue

Reporter: Skyisblue
AliasAlreadyTaken added the
1. kind/enhancement
label 2020-09-22 20:34:28 +00:00
AliasAlreadyTaken added this to the (deleted) milestone 2020-09-25 06:12:33 +00:00
Skyisblue added the
2. prio/low
label 2020-12-08 19:40:45 +00:00
Owner

Not jumpable for mobs/pets I hope.

Not jumpable for mobs/pets I hope.
Member

The mobs fence does prevent mobs from jumping on the top of fence and escaping, but utterly fails in terms of keeping mobs from glitching through - even normal solid nodes can't do that. Additionally, there is no "from above" hitbox for mobs fence, you need to put a mobs:fence_top node on top of them, and almost no-one is aware of those.

My proposal:

  1. mobs:fence and mobs:fence_top should be aliased to default:wooden_fence
  2. all fences registered w/ default.register_fence should get a collision_box which is type="fixed" and has 3 layers of borders: a normal node (1 1 1), a slightly expanded normal node, and the current borders.
The mobs fence *does* prevent mobs from jumping on the top of fence and escaping, but utterly fails in terms of keeping mobs from glitching through - even normal solid nodes can't do that. Additionally, there is *no* "from above" hitbox for mobs fence, you need to put a `mobs:fence_top` node on top of them, and almost no-one is aware of those. My proposal: 1. `mobs:fence` and `mobs:fence_top` should be aliased to `default:wooden_fence` 2. all fences registered w/ `default.register_fence` should get a `collision_box` which is `type="fixed"` and has 3 layers of borders: a normal node (1 1 1), a slightly expanded normal node, and the current borders.
flux added the
4. step/want approval
label 2022-05-25 02:37:11 +00:00
flux added this to the flux's TODO list project 2022-07-02 17:50:04 +00:00
Member

the whole purpose of mobs:fence is to prevent mobs from glitching through them, not to prevent players from jumping over them. the solution is better mob API w.r.t. normal fences (and really, all nodes).

the whole purpose of mobs:fence is to prevent mobs from glitching through them, not to prevent players from jumping over them. the solution is better mob API w.r.t. normal fences (and really, all nodes).
flux added
4. step/at work
2. prio/interesting
and removed
2. prio/low
4. step/want approval
labels 2022-10-20 02:36:33 +00:00
flux added a new dependency 2022-10-23 23:50:44 +00:00

The mobs fence does prevent mobs from jumping on the top of fence and escaping, but utterly fails in terms of keeping mobs from glitching through - even normal solid nodes can't do that. Additionally, there is no "from above" hitbox for mobs fence, you need to put a mobs:fence_top node on top of them, and almost no-one is aware of those.

My proposal:

  1. mobs:fence and mobs:fence_top should be aliased to default:wooden_fence
  2. all fences registered w/ default.register_fence should get a collision_box which is type="fixed" and has 3 layers of borders: a normal node (1 1 1), a slightly expanded normal node, and the current borders.

There is an option in petz mod already: See screenshot and link:

https://forum.minetest.net/viewtopic.php?t=22245

> The mobs fence *does* prevent mobs from jumping on the top of fence and escaping, but utterly fails in terms of keeping mobs from glitching through - even normal solid nodes can't do that. Additionally, there is *no* "from above" hitbox for mobs fence, you need to put a `mobs:fence_top` node on top of them, and almost no-one is aware of those. > > My proposal: > 1. `mobs:fence` and `mobs:fence_top` should be aliased to `default:wooden_fence` > 2. all fences registered w/ `default.register_fence` should get a `collision_box` which is `type="fixed"` and has 3 layers of borders: a normal node (1 1 1), a slightly expanded normal node, and the current borders. There is an option in petz mod already: See screenshot and link: https://forum.minetest.net/viewtopic.php?t=22245
AliasAlreadyTaken added the
2. prio/controversial
label 2022-12-27 06:25:05 +00:00
Author
Owner

This change may alter people's existing builds, right?

This change may alter people's existing builds, right?
Member

This change may alter people's existing builds, right?

yes, this is certainly a change that should be communicated to players beforehand.

> This change may alter people's existing builds, right? yes, this is certainly a change that should be communicated to players beforehand.
flux removed the
4. step/at work
label 2023-02-27 21:15:49 +00:00
Author
Owner

In this case we'll go with upstream - if they ever decide to make this happen, we'll go along. Until then, we'll keep what we have. If the new mob API supports it, we'll use it. If not, then we'll also keep what we have.

In this case we'll go with upstream - if they ever decide to make this happen, we'll go along. Until then, we'll keep what we have. If the new mob API supports it, we'll use it. If not, then we'll also keep what we have.
AliasAlreadyTaken removed a dependency 2023-07-21 17:13:02 +00:00
AliasAlreadyTaken added the
5. result/maybe
label 2023-07-21 17:13:09 +00:00
flux removed this from the flux's TODO list project 2023-12-22 20:44:22 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: your-land/bugtracker#49
No description provided.