Deathwing reports: The murder holes block the flo ... #5869
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
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#5869
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?
Deathwing reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
You could technically still shoot arrows through them... but arrows suck and due to #5717 are now useless.
you can also place liquids below them if you can point at some wall below them
if they were to be allowed to "suck" fluids through them, there's considerations. source only, or flowing also? through how many would it work? - if you've got two murder holes on top of each other, should it work? if you've got 1000, should it work? should it work for all fluids? should it also work for falling nodes like gravel?
Adding my 2 cents:
If you are interested in checking out a PVP Castle Assault mini-game that I am working on come to 15567.0, 57.5, 16555.0
one thing about this idea of water and lava going through murder holes is that quest areas like the "Keeper of the Stones" quest would need to be changed since that area uses murder holes and above the murder holes is lava, it's used as lighting.
What if instead of interacting with fluids, holes just had a special
on_rightclick
handler that checked for the bucket in hand and put the liquid below the hole? It would make implementing it and pouring easier it seems?Because pouring stuff (especially lava) over hole and waiting for the block updates to "suck" it seems... not ideal.
But simulation vs special handling is usually more fun, so I'm not sure. :p
If you want to let lava or water flow down, then you just create appropriate space 1x1. I don't see any problem with integrating this into buildings, etc. At least you can shoot through the killer holes with a bow and arrow, which makes them valuable for some designs.
Letting liquids flow through murder holes and gravel and sand etc. also continue to fall through it would certainly make sense. It's not very easy. Perhaps there's some overlap to my moresnow mod for which I need a change to builtin of MT. Even then, falling through stacked murder holes would be very difficult as the falling node has to be somewhere. And when it turns out that after a long fall there is no open room at the other end - then what?
Whosits' idea of adding a special on_rightclick handler to the murder hole so that buckets placed cause the liquid to appear below sounds like a more realistic and practical approach given the MT code.
A formspec could be added with a toggle switch (defaulted to the old behavior), when the toggle switch is enabled then it could allow the new behavior. This is an easy way of avoiding breaking old builds in general. Of course it does make things more tedious for a design with lots of functional murder holes. Maybe add a second node that is a copy of the original murder hole, but with a rename, and the new functionality? Then there could be a bidirectional crafting recipe to switch between them.
What about treating it like an "air" node for the nodes specified in a whitelist (sands, gravel, all fluids)? The murder hole node wouldn't have an inventory or any state tracking, the code would just allow coincidence of nodes of those types, and the regular node physics (for sand, gravel, and fluids) would handle the rest. This has the advantages of being able to spill over a wider area if you design your murder holes right. Unless I am mistaken, such an implementation should be light weight, but I coincide that I haven't looked at the code myself yet.
Teleport to the coordinates in my long post above and check out my build. Arrows shot through a murder hole will be extremely difficult to land on a target (even one being slowed by lava). Strategic Embrasures at the ends of long corridors is where you want archers in a fortification. Again, reference my build for a visual of how that works since I have implemented those as well.
This is a workable solution, but limits design choices. For example, I could not create a spillway that channels flowing liquid over 2-4 murder holes at once (which was my original design intent for my build). On the other hand, your proposed solution would also make it easier to implement time limited liquid sources underneath a murder hole, so there is that as well. There should definitely be a formspec to set the fluid source duration (up to infinite).
[quote="Deathwing"]
What about treating it like an "air" node for the nodes specified in a whitelist (sands, gravel, all fluids)? The murder hole node wouldn't have an inventory or any state tracking, the code would just allow coincidence of nodes of those types, and the regular node physics (for sand, gravel, and fluids) would handle the rest.
[/quote]
Optimist! It's not that easy. Node physics are rudimentary at best, sadly.
i like whosit's proposal. i'm personally unlikely to implement anything more complicated given other priorities.