Deathwing reports: The murder holes block the flo ... #5869

Open
opened 2023-12-30 17:50:46 +00:00 by yourland-report · 14 comments

Deathwing reports a bug:

The murder holes block the flow of liquid, which defeats the point of them.

Player position:

{
	x = 15568.809570313,
	y = 27.5,
	z = 16590.20703125
}

Player look:

{
	x = 0.96727246046066,
	y = -0.24344572424889,
	z = -0.07154093682766
}

Player information:

{
	minor = 8,
	state = "Active",
	version_string = "5.8.0",
	lang_code = "",
	max_jitter = 7.8290004730225,
	ip_version = 6,
	min_rtt = 0.17599999904633,
	avg_rtt = 0.27500000596046,
	formspec_version = 7,
	protocol_version = 42,
	avg_jitter = 0.091000005602837,
	connection_uptime = 50933,
	serialization_version = 29,
	patch = 0,
	max_rtt = 9.2349996566772,
	major = 5,
	min_jitter = 0
}

Player meta:

{
	fields = {
		jointime = "1702598206",
		["3d_armor_inventory"] = "return {\"3d_armor:chestplate_crystal 1 10260\", \"3d_armor:helmet_crystal 1 10260\", \"3d_armor:leggings_crystal 1 10260\", \"shields:shield_rainbow 1 4104\", \"3d_armor:boots_crystal 1 10260\", \"\"}",
		["stamina:level"] = "18",
		crafted = "30607",
		["stamina:poisoned"] = "no",
		bitten = "0",
		["stamina:exhaustion"] = "33.5",
		punch_count = "1162",
		yl_commons_player_created = "1702598206",
		yl_commons_player_joined = "1703907733",
		yl_church = "return {[\"last_death\"] = {[\"z\"] = 16661, [\"x\"] = 15821, [\"y\"] = 57}, [\"last_death_portal\"] = 1702623254}",
		hud_state = "on",
		xp = "107993",
		played_time = "437389",
		digged_nodes = "179774",
		placed_nodes = "22547",
		died = "8",
		repellant = "0",
		inflicted_damage = "20862",
		yl_commons_thankyou = "2",
		["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}",
		["signslib:pos"] = "(1959,-1993,1456)"
	}
}

Log identifier


[MOD] yl_report log identifier = GEbqxcNYu6IrZ6ywZ0Dv7QUWOYLlunum

Profiler save:

profile-20231230T175046.json_prettyEE

Status:

# Server: version: 5.7.0-yl-thx-tmm | game: Minetest Game | uptime: 14h 25min 55s | max lag: 1.19s | clients (31/52): 123p, _Nod_, AliasAlreadyTaken, Bailiff, bleek, Boot, Brabenec, BTS-, Craftsman, crankyape, daydream, Deathwing, DragonWrangler1, ElManu, Emie, Empempires, flux, formations52, jackofthebean000, Kadax, Keya, LucyUnicorn_Queen, Lupercus, Murmel, Noii, Pif, prowler, Ravise, Sokomine, taonza12, whosit

Teleport command:

/teleport xyz 15569 28 16590

Compass command:

/give_compass Construction GEbqxcNYu6IrZ6ywZ0Dv7QUWOYLlunum D2691E 15569 28 16590
Deathwing reports a bug: > The murder holes block the flow of liquid, which defeats the point of them. Player position: ``` { x = 15568.809570313, y = 27.5, z = 16590.20703125 } ``` Player look: ``` { x = 0.96727246046066, y = -0.24344572424889, z = -0.07154093682766 } ``` Player information: ``` { minor = 8, state = "Active", version_string = "5.8.0", lang_code = "", max_jitter = 7.8290004730225, ip_version = 6, min_rtt = 0.17599999904633, avg_rtt = 0.27500000596046, formspec_version = 7, protocol_version = 42, avg_jitter = 0.091000005602837, connection_uptime = 50933, serialization_version = 29, patch = 0, max_rtt = 9.2349996566772, major = 5, min_jitter = 0 } ``` Player meta: ``` { fields = { jointime = "1702598206", ["3d_armor_inventory"] = "return {\"3d_armor:chestplate_crystal 1 10260\", \"3d_armor:helmet_crystal 1 10260\", \"3d_armor:leggings_crystal 1 10260\", \"shields:shield_rainbow 1 4104\", \"3d_armor:boots_crystal 1 10260\", \"\"}", ["stamina:level"] = "18", crafted = "30607", ["stamina:poisoned"] = "no", bitten = "0", ["stamina:exhaustion"] = "33.5", punch_count = "1162", yl_commons_player_created = "1702598206", yl_commons_player_joined = "1703907733", yl_church = "return {[\"last_death\"] = {[\"z\"] = 16661, [\"x\"] = 15821, [\"y\"] = 57}, [\"last_death_portal\"] = 1702623254}", hud_state = "on", xp = "107993", played_time = "437389", digged_nodes = "179774", placed_nodes = "22547", died = "8", repellant = "0", inflicted_damage = "20862", yl_commons_thankyou = "2", ["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}", ["signslib:pos"] = "(1959,-1993,1456)" } } ``` Log identifier ``` [MOD] yl_report log identifier = GEbqxcNYu6IrZ6ywZ0Dv7QUWOYLlunum ``` Profiler save: ``` profile-20231230T175046.json_prettyEE ``` Status: ``` # Server: version: 5.7.0-yl-thx-tmm | game: Minetest Game | uptime: 14h 25min 55s | max lag: 1.19s | clients (31/52): 123p, _Nod_, AliasAlreadyTaken, Bailiff, bleek, Boot, Brabenec, BTS-, Craftsman, crankyape, daydream, Deathwing, DragonWrangler1, ElManu, Emie, Empempires, flux, formations52, jackofthebean000, Kadax, Keya, LucyUnicorn_Queen, Lupercus, Murmel, Noii, Pif, prowler, Ravise, Sokomine, taonza12, whosit ``` Teleport command: ``` /teleport xyz 15569 28 16590 ``` Compass command: ``` /give_compass Construction GEbqxcNYu6IrZ6ywZ0Dv7QUWOYLlunum D2691E 15569 28 16590 ```
AliasAlreadyTaken was assigned by yourland-report 2023-12-30 17:50:46 +00:00
AliasAlreadyTaken added the
1. kind/enhancement
label 2023-12-30 18:20:42 +00:00

You could technically still shoot arrows through them... but arrows suck and due to #5717 are now useless.

You could technically still shoot arrows through them... but arrows suck and due to https://gitea.your-land.de/your-land/bugtracker/issues/5717 are now useless.
Member

you can also place liquids below them if you can point at some wall below them

you can also place liquids below them if you can point at some wall below them
Member

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?

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:

  • Let them "suck" flowing and source blocks, but don't let them "flow over" the murder hole node to adjacent nodes (The hole takes all the fluid).
  • The stack of murder hole nodes is interesting. It would make sense that they should continue to let water fall if a player designs a build that way. The only consideration I could see to implementing a MAX number would be if the "suck" implementation was resource intensive (Like hoppers). In which case just finding a way to make the block passable by fluids (like an "air" node) might be a simpler approach and achieve the same effect for free (server resource wise).
  • It should work for all fluids. It would be nice to see a new "Hot Oil" fluid added which causes player and mob damage. Also, it would be a good idea to add a "Castle Cauldron" node that holds an infinite liquid source (of any type), but if you use a bucket on it will add to the bucket a liquid source node of the same type that disparages after a few seconds after being placed in the world.
  • Regarding falling nodes like gravel, I would say it wouldn't be critical to the design intent of a "Murder Hole", but it could end up being interesting (Again if the implementation is not resource intensive). Defenders could drop gravel or sand as an impediment that attackers need to dig through.

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

  • Right now I just have lava flowing down the only way attackers can access the castle. Since Crystal Armor is the norm, this only serves to slow players down (water doesn't work to well for this purpose). Put on some crystal armor and walk through it to see what it is like. Check out the defenders side of the palisades. The fortifications are very well thought out.
  • There is a dead-fall at the end of the murder channel just before the muster yard outside the barracks. It is currently controlled with a digilines switch to simply open or close it (like a draw bridge), but the next milestone for it is to make closing (or bridging) the deadfall an attacker objective which they need to complete to continue forward in the assault.
  • The large structure beneath the posted coordinates is the barracks, which is 2 stories and the upper store will serve as the initial re-spawn point for the defenders.
  • Once the attackers breach the muster yard and take the barracks flag (Which will be on the roof), the re-spawn point of the defenders will be moved up to the next level of defense towards the keep (not yet built, but you can see where the jungle forest has been cut through to where the keep will go at the top of the hill.
  • There will be 3 or 4 levels of defenses and re-spawn points before the keep assault.
  • Game balance is achieved by asymmetric team sizes.
  • I envision further milestones in which attackers are allowed to build specific structures (like ladders, battering rams, & trebuchets) at specific locations that open up different paths for players to go which increase the attack surface on the fort. This would only be needed if the mini-game turns out to be popular and a lot of people play it simultaneously.
  • Further milestones include building some outlying villages with interconnected roads to the keep, a marketplace and a farm within the outer wall of the castle, and a series of quests specific to this area of the world for people to explore. Eventually I plan on making it a city and connecting it to the airship network.
Adding my 2 cents: - Let them "suck" flowing and source blocks, but don't let them "flow over" the murder hole node to adjacent nodes (The hole takes all the fluid). - The stack of murder hole nodes is interesting. It would make sense that they should continue to let water fall if a player designs a build that way. The only consideration I could see to implementing a MAX number would be if the "suck" implementation was resource intensive (Like hoppers). In which case just finding a way to make the block passable by fluids (like an "air" node) might be a simpler approach and achieve the same effect for free (server resource wise). - It should work for all fluids. It would be nice to see a new "Hot Oil" fluid added which causes player and mob damage. Also, it would be a good idea to add a "Castle Cauldron" node that holds an infinite liquid source (of any type), but if you use a bucket on it will add to the bucket a liquid source node of the same type that disparages after a few seconds after being placed in the world. - Regarding falling nodes like gravel, I would say it wouldn't be critical to the design intent of a "Murder Hole", but it could end up being interesting (Again if the implementation is not resource intensive). Defenders could drop gravel or sand as an impediment that attackers need to dig through. 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 - Right now I just have lava flowing down the only way attackers can access the castle. Since Crystal Armor is the norm, this only serves to slow players down (water doesn't work to well for this purpose). Put on some crystal armor and walk through it to see what it is like. Check out the defenders side of the palisades. The fortifications are very well thought out. - There is a dead-fall at the end of the murder channel just before the muster yard outside the barracks. It is currently controlled with a digilines switch to simply open or close it (like a draw bridge), but the next milestone for it is to make closing (or bridging) the deadfall an attacker objective which they need to complete to continue forward in the assault. - The large structure beneath the posted coordinates is the barracks, which is 2 stories and the upper store will serve as the initial re-spawn point for the defenders. - Once the attackers breach the muster yard and take the barracks flag (Which will be on the roof), the re-spawn point of the defenders will be moved up to the next level of defense towards the keep (not yet built, but you can see where the jungle forest has been cut through to where the keep will go at the top of the hill. - There will be 3 or 4 levels of defenses and re-spawn points before the keep assault. - Game balance is achieved by asymmetric team sizes. - I envision further milestones in which attackers are allowed to build specific structures (like ladders, battering rams, & trebuchets) at specific locations that open up different paths for players to go which increase the attack surface on the fort. This would only be needed if the mini-game turns out to be popular and a lot of people play it simultaneously. - Further milestones include building some outlying villages with interconnected roads to the keep, a marketplace and a farm within the outer wall of the castle, and a series of quests specific to this area of the world for people to explore. Eventually I plan on making it a city and connecting it to the airship network.

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.

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.
Member

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

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
Member

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.

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.
Member

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.

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.

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.

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.

> 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. 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.

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.

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.

> 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. 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.

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.

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.

> 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. 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.

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

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).

> 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 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).
Member

[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.

[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.
Member

i like whosit's proposal. i'm personally unlikely to implement anything more complicated given other priorities.

i like whosit's proposal. i'm personally unlikely to implement anything more complicated given other priorities.
Sign in to join this conversation.
No Milestone
No project
No Assignees
8 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#5869
No description provided.