rheo reports: spawnit seems to think it's ok ... #6242

New Issue

yourland-report · 2024-02-05T21:43:11Z

yourland-report commented

2024-02-05 21:43:11 +00:00

rheo reports a bug:

spawnit seems to think it's ok to spawn on top of ignore nodes? even after the area is loaded and is just air (thanks whosit for pointing this out)

Player position:

{
	z = 4023.6198730469,
	x = 3123.4829101563,
	y = 29236.458984375
}

Player look:

{
	z = -0.015108191408217,
	x = -0.90163052082062,
	y = -0.43224316835403
}

Player information:

{
	avg_rtt = 0.18000000715256,
	min_jitter = 0,
	max_jitter = 5.1510000228882,
	avg_jitter = 0.0050000101327896,
	connection_uptime = 8853,
	serialization_version = 29,
	patch = 0,
	minor = 9,
	major = 5,
	formspec_version = 7,
	protocol_version = 43,
	max_rtt = 5.3319997787476,
	state = "Active",
	version_string = "5.9.0-dev-454dd8576-dirty",
	lang_code = "",
	ip_version = 6,
	min_rtt = 0.16599999368191
}

Player meta:

{
	fields = {
		["ocean_build.last_warning"] = "1.66814e+09",
		punch_count = "1242",
		["ocean_build.ocean_built"] = "6",
		inflicted_damage = "283022",
		arenalib_infobox_arenaID = "0",
		yl_commons_player_created = "1644205752",
		yl_commons_player_joined = "1707160553",
		partychat = "party",
		["stamina:exhaustion"] = "79.5",
		["petz:werewolf"] = "0",
		repellant = "0",
		["petz:lycanthropy"] = "0",
		yl_commons_thankyou = "73",
		hotbar_size = "16",
		hud_state = "off",
		played_time = "7578562",
		yl_church = "return {[\"last_death\"] = {[\"y\"] = 15, [\"x\"] = 1353, [\"z\"] = 1089}}",
		placed_nodes = "20959",
		died = "2",
		crafted = "2229",
		["petz:old_override_table"] = "return {[\"sneak\"] = true, [\"speed\"] = 2, [\"new_move\"] = true, [\"jump\"] = 1.5, [\"gravity\"] = 1, [\"sneak_glitch\"] = false}",
		xp = "0",
		["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}",
		["stamina:poisoned"] = "no",
		["petz:werewolf_clan_idx"] = "2",
		digged_nodes = "20427",
		["stamina:level"] = "0",
		["ethereal:fly_timer"] = "-99",
		["signslib:pos"] = "(741,28,4968)",
		["hud_manager:spawnit:hud_enabled"] = "y",
		["3d_armor_inventory"] = "return {\"3d_armor:boots_quickrun\", \"\", \"\", \"\", \"\", \"\"}",
		["petz:werewolf_vignette_id"] = "16",
		jointime = "1644205752",
		bitten = "0"
	}
}

Log identifier


[MOD] yl_report log identifier = wYohMpONdLa6tJ8kWwntHNIe9bZLQuoI

Profiler save:

profile-20240205T214311.json_prettyEE

Status:

# Server: version: 5.8.0-yl-test | game: Minetest Game | uptime: 11h 56min 58s | max lag: 0.492s | clients (3/52): flux, rheo, whosit

Teleport command:

/teleport xyz 3123 29236 4024

Compass command:

/give_compass Construction wYohMpONdLa6tJ8kWwntHNIe9bZLQuoI D2691E 3123 29236 4024

rheo reports a bug: > spawnit seems to think it's ok to spawn on top of ignore nodes? even after the area is loaded and is just air (thanks whosit for pointing this out) Player position: ``` { z = 4023.6198730469, x = 3123.4829101563, y = 29236.458984375 } ``` Player look: ``` { z = -0.015108191408217, x = -0.90163052082062, y = -0.43224316835403 } ``` Player information: ``` { avg_rtt = 0.18000000715256, min_jitter = 0, max_jitter = 5.1510000228882, avg_jitter = 0.0050000101327896, connection_uptime = 8853, serialization_version = 29, patch = 0, minor = 9, major = 5, formspec_version = 7, protocol_version = 43, max_rtt = 5.3319997787476, state = "Active", version_string = "5.9.0-dev-454dd8576-dirty", lang_code = "", ip_version = 6, min_rtt = 0.16599999368191 } ``` Player meta: ``` { fields = { ["ocean_build.last_warning"] = "1.66814e+09", punch_count = "1242", ["ocean_build.ocean_built"] = "6", inflicted_damage = "283022", arenalib_infobox_arenaID = "0", yl_commons_player_created = "1644205752", yl_commons_player_joined = "1707160553", partychat = "party", ["stamina:exhaustion"] = "79.5", ["petz:werewolf"] = "0", repellant = "0", ["petz:lycanthropy"] = "0", yl_commons_thankyou = "73", hotbar_size = "16", hud_state = "off", played_time = "7578562", yl_church = "return {[\"last_death\"] = {[\"y\"] = 15, [\"x\"] = 1353, [\"z\"] = 1089}}", placed_nodes = "20959", died = "2", crafted = "2229", ["petz:old_override_table"] = "return {[\"sneak\"] = true, [\"speed\"] = 2, [\"new_move\"] = true, [\"jump\"] = 1.5, [\"gravity\"] = 1, [\"sneak_glitch\"] = false}", xp = "0", ["unified_inventory:bags"] = "return {\"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\", \"unified_inventory:bag_large\"}", ["stamina:poisoned"] = "no", ["petz:werewolf_clan_idx"] = "2", digged_nodes = "20427", ["stamina:level"] = "0", ["ethereal:fly_timer"] = "-99", ["signslib:pos"] = "(741,28,4968)", ["hud_manager:spawnit:hud_enabled"] = "y", ["3d_armor_inventory"] = "return {\"3d_armor:boots_quickrun\", \"\", \"\", \"\", \"\", \"\"}", ["petz:werewolf_vignette_id"] = "16", jointime = "1644205752", bitten = "0" } } ``` Log identifier ``` [MOD] yl_report log identifier = wYohMpONdLa6tJ8kWwntHNIe9bZLQuoI ``` Profiler save: ``` profile-20240205T214311.json_prettyEE ``` Status: ``` # Server: version: 5.8.0-yl-test | game: Minetest Game | uptime: 11h 56min 58s | max lag: 0.492s | clients (3/52): flux, rheo, whosit ``` Teleport command: ``` /teleport xyz 3123 29236 4024 ``` Compass command: ``` /give_compass Construction wYohMpONdLa6tJ8kWwntHNIe9bZLQuoI D2691E 3123 29236 4024 ```

AliasAlreadyTaken was assigned by yourland-report

2024-02-05 21:43:11 +00:00

whosit referenced this issue

2024-02-05 22:00:46 +00:00

whosit reports: nether mobs spawn in air, fall ... #6237

flux added the

1. kind/bug

label 2024-02-06 01:19:17 +00:00

flux added this to the flux's TODO list project 2024-02-06 01:19:20 +00:00

AliasAlreadyTaken was unassigned by flux

2024-02-06 01:19:24 +00:00

flux self-assigned this 2024-02-06 01:19:24 +00:00

flux commented

2024-02-06 01:21:08 +00:00

i'm not 100% i identified the issue properly, but nether mobs in particular seem to think it's okay to spawn in the air along the very bottom layer of a mapblock, something to do w/ ignore nodes seems the most reasonable explanation.

or wait. perhaps this was near a newly generated portal. possibly those nodes were actually netherrack when spawnit ran, before mapgen had time to hollow out the caves...

i'm not 100% i identified the issue properly, but nether mobs in particular seem to think it's okay to spawn in the air along the very bottom layer of a mapblock, something to do w/ ignore nodes seems the most reasonable explanation. or wait. perhaps this was near a newly generated portal. possibly those nodes *were* actually netherrack when spawnit ran, before mapgen had time to hollow out the caves...

whosit commented

2024-02-06 05:03:19 +00:00

or wait. perhaps this was near a newly generated portal. possibly those nodes were actually netherrack when spawnit ran, before mapgen had time to hollow out the caves...

We were just outside the portal that leads to NetherLands, so it's definitely not new.

> or wait. perhaps this was near a newly generated portal. possibly those nodes *were* actually netherrack when spawnit ran, before mapgen had time to hollow out the caves... We were just outside the portal that leads to NetherLands, so it's definitely not new.

flux added the

2. prio/elevated

4. step/at work

labels 2024-02-06 18:04:57 +00:00

flux commented

2024-02-06 22:00:05 +00:00

and again, i can't replicate this locally. hm...

AliasAlreadyTaken commented

2024-02-07 16:09:22 +00:00

Maybe we have different settings in minetest.conf?

flux commented

2024-02-07 23:29:37 +00:00

Maybe we have different settings in minetest.conf?

nothing i can imagine. the more i think about it, the less sense it makes - all of the affected mobs have restrictions on which nodes they can spawn on. even if the code was somehow seeing "ignore" nodes instead of "air", it shouldn't be marking those places as spots anything can spawn.

> Maybe we have different settings in minetest.conf? nothing i can imagine. the more i think about it, the less sense it makes - *all* of the affected mobs have restrictions on which nodes they can spawn on. even if the code was somehow seeing "ignore" nodes instead of "air", it shouldn't be marking those places as spots anything can spawn.

AliasAlreadyTaken commented

2024-02-07 23:39:49 +00:00

Then we need to add logging and let them say why they spawn where they do and what node they want to spawn on?

Can we alter spawn rules from a running server, to make experiments?

Then we need to add logging and let them say why they spawn where they do and what node they want to spawn on? Can we alter spawn rules from a running server, to make experiments?

whosit commented

2024-02-07 23:54:55 +00:00

My bet is that these guys also load in air near the slope, fall down and unload:

My bet is that these guys also load in air near the slope, fall down and unload: ![image](/attachments/c8e51e5a-c5d7-4b03-829f-930a423eff45) ![image](/attachments/d1fe1753-f00f-4b1d-8f7d-f5eaa5981a30)

image.png

588 KiB

image.png

463 KiB

whosit commented

2024-02-07 23:56:31 +00:00

Maybe this has something to do with how spawnit is passing data to async env and back? (just a wild guess)

flux commented

2024-02-08 19:07:31 +00:00

Then we need to add logging and let them say why they spawn where they do and what node they want to spawn on?

they spawn where they do because some code in an async thread has previously identified that location as a place where they are able to spawn. part of the efficiency of spawnit is that the main thread doesn't have to do any of these checks. (if a node is built or destroyed, the spawn positions in that mapblock are cleared in a minetest.register_on_mapblocks_changed callback, and recalculated later).

Can we alter spawn rules from a running server, to make experiments?

no. in order to pass the spawn rules to the async environment, the rules have to be made immutable in an on_mods_loaded callback, saved to a file, and then loaded by the async environment.

the behavior is also not happening currently on the main server. you can see where things are spawning using the /spawnit_toggle_spawn_waypoints command, and check whether a mob can spawn in a given mapblock with the /spawnit_show_all_in_block <entity_name> command. ogres in particular seem to really like to walk off the edges of things, perhaps their fear_height value should be reduced. EDIT: hm, maybe not the fear height - several nether mobs have larger values and don't walk off cliffs. perhaps it's because their model is so "fat"...

> Then we need to add logging and let them say why they spawn where they do and what node they want to spawn on? they spawn where they do because some code in an async thread has previously identified that location as a place where they are able to spawn. part of the efficiency of spawnit is that the main thread doesn't have to do any of these checks. (if a node is built or destroyed, the spawn positions in that mapblock are cleared in a `minetest.register_on_mapblocks_changed` callback, and recalculated later). > Can we alter spawn rules from a running server, to make experiments? no. in order to pass the spawn rules to the async environment, the rules have to be made immutable in an `on_mods_loaded` callback, saved to a file, and then loaded by the async environment. the behavior is also not happening currently on the main server. you can see where things are spawning using the `/spawnit_toggle_spawn_waypoints` command, and check whether a mob can spawn in a given mapblock with the `/spawnit_show_all_in_block <entity_name>` command. ogres in particular seem to *really* like to walk off the edges of things, perhaps their `fear_height` value should be reduced. EDIT: hm, maybe not the fear height - several nether mobs have larger values and don't walk off cliffs. perhaps it's because their model is so "fat"...

flux commented

2024-02-08 19:13:21 +00:00

if i hadn't seen ogres spawning in the air right in front of me, and if spawnit_show_all_in_block hadn't shown me that those were marked as legit spawn positions, i wouldn't believe this.

if i hadn't seen ogres spawning in the air right in front of me, and if `spawnit_show_all_in_block` hadn't shown me that those were marked as legit spawn positions, i wouldn't believe this.

flux commented

2024-02-08 19:34:00 +00:00

ogres in particular seem to really like to walk off the edges of things, perhaps their fear_height value should be reduced. EDIT: hm, maybe not the fear height - several nether mobs have larger values and don't walk off cliffs. perhaps it's because their model is so "fat"...

the fat-ness is part of it - mobs_redo only checks whether there's solid ground over one corner of the mobs collision box d4a25064ea/api.lua (L1001-L1009)

> ogres in particular seem to *really* like to walk off the edges of things, perhaps their `fear_height` value should be reduced. EDIT: hm, maybe not the fear height - several nether mobs have larger values and don't walk off cliffs. perhaps it's because their model is so "fat"... the fat-ness is part of it - mobs_redo only checks whether there's solid ground over one corner of the mobs collision box https://codeberg.org/tenplus1/mobs_redo/src/commit/d4a25064eaab8158dc305c9a682d55d9a8f0d360/api.lua#L1001-L1009

flux commented

2024-02-19 02:13:11 +00:00

proof - the bubbles are places spawnit thinks ogres can spawn, in the air. this is not a newly generated mapblock, but i teleported near it and then flew in this direction.

proof - the bubbles are places spawnit thinks ogres can spawn, in the air. this is not a newly generated mapblock, but i teleported near it and then flew in this direction. ![image](/attachments/3545ae02-7a57-4f74-869a-48f084e0d39e) ![image](/attachments/2cefe966-f409-4a80-a772-2dc2eb1f763a)

image.png

440 KiB

image.png

553 KiB

flux commented

2024-02-19 02:20:12 +00:00

it's particularly weird that this only seems to affect nether mobs

AliasAlreadyTaken commented

2024-02-19 07:25:00 +00:00

Is this a setting we can enable on the testserver?

Would be really cool if those bubbles had some mouseover text which mob spawnspot that is.

Is this a setting we can enable on the testserver? Would be really cool if those bubbles had some mouseover text which mob spawnspot that is.

Bla commented

2024-02-19 09:59:53 +00:00

it's particularly weird that this only seems to affect nether mobs

If I remember correctly nether mobs are the only mobs that use a function (mob_core ?) to check if there is enough room to spawn, that might mess with your spawn positions.

> it's particularly weird that this only seems to affect nether mobs If I remember correctly nether mobs are the only mobs that use a function (mob_core ?) to check if there is enough room to spawn, that might mess with your spawn positions.

whosit commented

2024-02-19 12:04:25 +00:00

Is this a setting we can enable on the testserver?

Would be really cool if those bubbles had some mouseover text which mob spawnspot that is.

try /spawnit_toggle_spawn_waypoints

> Is this a setting we can enable on the testserver? > > Would be really cool if those bubbles had some mouseover text which mob spawnspot that is. try `/spawnit_toggle_spawn_waypoints`

👍 1

AliasAlreadyTaken commented

2024-02-19 13:10:10 +00:00

it's particularly weird that this only seems to affect nether mobs

If I remember correctly nether mobs are the only mobs that use a function (mob_core ?) to check if there is enough room to spawn, that might mess with your spawn positions.

We used mob_core and various other spawning methods, which were eventually all replaced by flux' spawning mod: https://github.com/fluxionary/minetest-spawnit

> > it's particularly weird that this only seems to affect nether mobs > > If I remember correctly nether mobs are the only mobs that use a function (mob_core ?) to check if there is enough room to spawn, that might mess with your spawn positions. We used mob_core and various other spawning methods, which were eventually all replaced by flux' spawning mod: https://github.com/fluxionary/minetest-spawnit

flux commented

2024-02-20 01:15:24 +00:00

If I remember correctly nether mobs are the only mobs that use a function (mob_core ?) to check if there is enough room to spawn, that might mess with your spawn positions.

our limited version of mob_core is totally disabled currently (though it hasn't been removed?). spawnit has much more sophisticated checks which should prevent mobs from spawning partially in walls.

Is this a setting we can enable on the testserver?
Would be really cool if those bubbles had some mouseover text which mob spawnspot that is.

the bubbles come from this command:

/spawnit_show_all_in_block <entity_name>

you first have to mark a position with worldedit (//1) or areas (/area_pos1). if the mob can spawn in that mapblock, bubbles will appear for every such location. if the mob can't spawn there, you'll get a chat message. if the mob doesn't exist, you'll also be informed.

in the above photos, i ran it against "yl_nether_mobs:ogre". the bubbles are ephemeral HUD waypoints, there's no meaningful way to "point" at them, but you already know which mob it is because it's part of the command.

note that every "valid" location may not be included! spawnit limits the number of spawn positions it notes per mapblock to 8 by default (16 for nether mobs). also, locations are removed if a mob successfully spawns there. these behaviors are intended to keep too many of the same kind of mob from spawning in the same area (unless it the area is unloaded and reloaded). the main reason for this is to nerf mob farms.

> If I remember correctly nether mobs are the only mobs that use a function (mob_core ?) to check if there is enough room to spawn, that might mess with your spawn positions. our limited version of mob_core is totally disabled currently (though it hasn't been removed?). spawnit has much more sophisticated checks which should prevent mobs from spawning partially in walls. > Is this a setting we can enable on the testserver? > Would be really cool if those bubbles had some mouseover text which mob spawnspot that is. the bubbles come from this command: ``` /spawnit_show_all_in_block <entity_name> ``` you first have to mark a position with worldedit (`//1`) or areas (`/area_pos1`). if the mob can spawn in that mapblock, bubbles will appear for every such location. if the mob can't spawn there, you'll get a chat message. if the mob doesn't exist, you'll also be informed. in the above photos, i ran it against "yl_nether_mobs:ogre". the bubbles are ephemeral HUD waypoints, there's no meaningful way to "point" at them, but you already know which mob it is because it's part of the command. note that every "valid" location may not be included! spawnit limits the number of spawn positions it notes per mapblock to 8 by default (16 for nether mobs). also, locations are removed if a mob successfully spawns there. these behaviors are intended to keep too many of the same kind of mob from spawning in the same area (unless it the area is unloaded and reloaded). the main reason for this is to nerf mob farms.

👍 1

whosit referenced this issue

2024-03-23 05:55:20 +00:00

spawnit nether issue ideas #6554

flux commented

2024-03-25 21:21:13 +00:00

Squawk had a similar issue in a nether farm - the mobs weren't spawning high up in the air, but they were also spawning in places where they shouldn't, on the lowest y coordinate of a mapblock, as if spawnit assumes the stuff below it is solid.

some ideas for resolving this:

possibly sending VoxelManip objects to the async environment doesn't work great if they extend beyond a single mapblock
possibly i'm querying beyond the bounds that were sent to the voxelmanip, because of the size of the entities collision box, and that's returning garbage
perhaps i can create a way to visualize what's sent to the async environment if and when it disagrees to the "real" world.

Squawk had a similar issue in a nether farm - the mobs weren't spawning high up in the air, but they were also spawning in places where they shouldn't, on the lowest y coordinate of a mapblock, as if spawnit assumes the stuff below it is solid. some ideas for resolving this: * possibly sending VoxelManip objects to the async environment doesn't work great if they extend beyond a single mapblock * possibly i'm querying beyond the bounds that were sent to the voxelmanip, because of the size of the entities collision box, and that's returning garbage * perhaps i can create a way to visualize what's sent to the async environment if and when it disagrees to the "real" world.

flux referenced this issue

2024-03-26 21:11:25 +00:00

flux reports: note to self: spawnit hud shou ... #6566

Sign in to join this conversation.