Mineclonia
/
Mineclonia
Archived
12
17
Fork 13
Code Issues 105 Pull Requests 19 Projects Releases Wiki Activity

ITEMS/mcl_fire: Fix fire spread to not freeze the game #234

Merged
erlehmann merged 13 commits from fix-fire into master 2022-02-12 04:39:41 +01:00
Conversation 58 Commits 13 Files Changed 2 +169 -238
cora commented 2022-01-15 15:25:49 +01:00
Member
Copy Link
Problem

TRACKING ISSUE: #174

Fire spread in Mineclonia is currently so inefficient that it quickly locks up a cpu preventing new clients to join. While this is just slow in singleplayer it makes multiplayer completely non functional (if there is a loaded large fire).

Solution

tl;dr: replace node timers with abms like the original fire mod from mtg does (which this was clearly adapted from).

Details

The information in the minecraft wiki is fairly incomplete but what is available there (i.e. the distances fire will spread) was implemented here. There is no information in there about how often or what chances there are for fire spread so the original abm values from mtg for "chance" and "interval" were taken.

Testing Steps

Note you can use any other map seed but "fire" on flat mapgen has a conveniently placed dense forest right at spawn.

Reproducing
  1. start mineclonia without this pr on flat mapgen with seed "fire"
  2. start a large fire (e.g. using mcl_fire:flint_and_steel or mcl_core:lava_source )
  3. observe minetest process maxing out one of your cpus eventually
Testing fix
  1. start mineclonia with this pr on flat mapgen with seed "fire"
  2. start a large fire (or just take the one you just started) it has to be a new world because the old one's fires will still have the old laggy node timers.
  3. observe that cpu does not max out no matter how large you make the fire. impact is negligible compared to the situation before (what do i know what slow cpus you guys have lol)
Testing functionality / regressions
  1. verify that flint and steel can set fire to flammable nodes
  2. verify that lava and nether lava (mcl_nether:nether_lava_source sets fire to flammable nodes (e.g. mcl_core:wood )
  3. verify that burning flammables are eventually removed / burned up by the fire.
  4. verify that fires without flammable nodes adjacent eventually go out.
  5. verify that water extinguishes fire (mcl_buckets:bucket_water)
  6. verify that fire on netherrack gets turned to mcl_fire:eternal_fire ( mcl_nether:netherrack ) - verify by pointing at the fire and looking at f5 debug info.
  7. verify that mcl_fire:eternal_fire sets fire to flammable nodes as well
  8. verify that the fire set by mcl_fire:eternal_fire is itsself normal fire (mcl_fire:fire)
  9. verify that nether portals are still lit when a fire node appears within e.g. by placing one piece of wood within the portal and one adjacent to it outside the portal and lighting the outer one on fire. (mcl_core:obsidian)
  10. verify that e.g. crafting tables catch fire but do not burn away (mcl_crafting_table:crafting_table). you can do this by placing them above lava e.g.

note that rain extinguishing fire code path is part of mcl_weather and was not touched here.


cpu b like "what fire"

##### Problem TRACKING ISSUE: #174 Fire spread in Mineclonia is currently so inefficient that it quickly locks up a cpu preventing new clients to join. While this is just slow in singleplayer it makes multiplayer completely non functional (if there is a loaded large fire). ##### Solution tl;dr: replace node timers with abms like the original fire mod from mtg does (which this was clearly adapted from). ##### Details The information in the minecraft wiki is fairly incomplete but what is available there (i.e. the distances fire will spread) was implemented here. There is no information in there about how often or what chances there are for fire spread so the original abm values from mtg for "chance" and "interval" were taken. ##### Testing Steps Note you can use any other map seed but "fire" on flat mapgen has a conveniently placed dense forest right at spawn. ###### Reproducing 1. start mineclonia without this pr on flat mapgen with seed "fire" 2. start a large fire (e.g. using mcl_fire:flint_and_steel or mcl_core:lava_source ) 3. observe minetest process maxing out one of your cpus eventually ###### Testing fix 1. start mineclonia with this pr on flat mapgen with seed "fire" 2. start a large fire ~~(or just take the one you just started)~~ it has to be a new world because the old one's fires will still have the old laggy node timers. 3. observe that cpu ~~does not max out no matter how large you make the fire.~~ impact is negligible compared to the situation before (what do i know what slow cpus you guys have lol) ###### Testing functionality / regressions 1. verify that flint and steel can set fire to flammable nodes 2. verify that lava and nether lava (mcl_nether:nether_lava_source sets fire to flammable nodes (e.g. mcl_core:wood ) 3. verify that burning flammables are eventually removed / burned up by the fire. 4. verify that fires without flammable nodes adjacent eventually go out. 5. verify that water extinguishes fire (mcl_buckets:bucket_water) 6. verify that fire on netherrack gets turned to mcl_fire:eternal_fire ( mcl_nether:netherrack ) - verify by pointing at the fire and looking at f5 debug info. 7. verify that mcl_fire:eternal_fire sets fire to flammable nodes as well 8. verify that the fire set by mcl_fire:eternal_fire is itsself normal fire (mcl_fire:fire) 9. verify that nether portals are still lit when a fire node appears within e.g. by placing one piece of wood within the portal and one adjacent to it outside the portal and lighting the outer one on fire. (mcl_core:obsidian) 10. verify that e.g. crafting tables catch fire but do not burn away (mcl_crafting_table:crafting_table). you can do this by placing them above lava e.g. note that rain extinguishing fire code path is part of mcl_weather and was not touched here. ![](https://mister-muffin.de/p/xQG1.png) cpu b like "what fire"
❤️ 1
cora force-pushed fix-fire from 35c375894c to 5183a307b1 2022-01-15 15:28:10 +01:00 Compare
Li0n_2 commented 2022-01-15 18:17:33 +01:00
Member
Copy Link

@cora your testing instructions don't mention anywhere the blocktype that can catch on fire by fire spread but never burns up, like crafting tables

@cora your testing instructions don't mention anywhere the blocktype that can catch on fire by fire spread but never burns up, like crafting tables
cora commented 2022-01-15 22:39:22 +01:00
Author
Member
Copy Link

@cora your testing instructions don't mention anywhere the blocktype that can catch on fire by fire spread but never burns up, like crafting tables

i'm not sure that was ever implemented. if it was i dont think it was in mcl_fire

> @cora your testing instructions don't mention anywhere the blocktype that can catch on fire by fire spread but never burns up, like crafting tables i'm not sure that was ever implemented. if it was i dont think it was in mcl_fire
cora commented 2022-01-15 22:41:48 +01:00
Author
Member
Copy Link

theres a whole thing about how long nodes burn and how likely it is they will catch fire - flammable nodes have an "encouragement" value in minecraft apparently - but yeah that is not implemented.

theres a whole thing about how long nodes burn and how likely it is they will catch fire - flammable nodes have an "encouragement" value in minecraft apparently - but yeah that is not implemented.
cora commented 2022-01-15 22:43:15 +01:00
Author
Member
Copy Link

we'd have to go through all node definitions and add such values i suppose

we'd have to go through all node definitions and add such values i suppose
cora commented 2022-01-15 22:52:10 +01:00
Author
Member
Copy Link

mmmh the crafting table thing does look like it worked before though. i'll have a look.

mmmh the crafting table thing does look like it worked before though. i'll have a look.
cora changed title from ITEMS/mcl_fire: fix fire spread to not freeze the game to WIP: ITEMS/mcl_fire: fix fire spread to not freeze the game 2022-01-15 22:52:18 +01:00
cora force-pushed fix-fire from 6cbe063667 to 8ebc3b3089 2022-01-15 23:09:10 +01:00 Compare
cora commented 2022-01-15 23:09:29 +01:00
Author
Member
Copy Link

*fix node ... lol

*fix node ... lol
cora changed title from WIP: ITEMS/mcl_fire: fix fire spread to not freeze the game to ITEMS/mcl_fire: fix fire spread to not freeze the game 2022-01-15 23:09:45 +01:00
cora commented 2022-01-15 23:10:26 +01:00
Author
Member
Copy Link

turns out this is in the node definitions ( group flammable=-1 )

turns out this is in the node definitions ( group flammable=-1 )
cora force-pushed fix-fire from 8ebc3b3089 to edb88c8be1 2022-01-16 00:07:33 +01:00 Compare
erlehmann commented 2022-01-16 11:39:50 +01:00
Owner
Copy Link

First: This is amazing! I can now have big fires without any lag (so far).

Second: I set fire to several two nodes high plants (e.g. rose bush) and beds.

When a two node high plant burns, it is possible for only one node to be deleted.

When a bed burns not the entire bed is deleted, making it possible to have half-beds.

First: This is amazing! I can now have big fires without any lag (so far). Second: I set fire to several two nodes high plants (e.g. rose bush) and beds. When a two node high plant burns, it is possible for only one node to be deleted. When a bed burns not the entire bed is deleted, making it possible to have half-beds.
RRmk.jpg
50 KiB
RRmk.jpg
cora commented 2022-01-16 14:25:03 +01:00
Author
Member
Copy Link

First: This is amazing! I can now have big fires without any lag (so far).

Second: I set fire to several two nodes high plants (e.g. rose bush) and beds.

When a two node high plant burns, it is possible for only one node to be deleted.

When a bed burns not the entire bed is deleted, making it possible to have half-beds.

should both be fixed now. The first one was sth i didn't properly understand (update falling node for the node above burnt out node) and the second was wrong all along: flammable value for beds was wrong

> First: This is amazing! I can now have big fires without any lag (so far). > > Second: I set fire to several two nodes high plants (e.g. rose bush) and beds. > > When a two node high plant burns, it is possible for only one node to be deleted. > > When a bed burns not the entire bed is deleted, making it possible to have half-beds. should both be fixed now. The first one was sth i didn't properly understand (update falling node for the node above burnt out node) and the second was wrong all along: flammable value for beds was wrong
erlehmann commented 2022-01-17 11:43:13 +01:00
Owner
Copy Link

Rebase this branch on the current master branch please.

Rebase this branch on the current `master` branch please.
cora force-pushed fix-fire from cb05936f9e to ec0d7e3787 2022-01-17 11:56:46 +01:00 Compare
erlehmann force-pushed fix-fire from ec0d7e3787 to 42a026a6ac 2022-01-22 17:52:33 +01:00 Compare
erlehmann commented 2022-01-22 17:52:38 +01:00
Owner
Copy Link

I rebased this on master just now.

I rebased this on master just now.
cora commented 2022-01-22 18:07:42 +01:00
Author
Member
Copy Link

Lol

Lol
Li0n_2 commented 2022-01-22 23:33:16 +01:00
Member
Copy Link

after some testing, I found a few fire related bugs using the fire branch. I did not test whether they also exist on master.

in creative mode you can stand in the edge of the fire without getting hurt even though your screen fills up with fire. this should not happen

fire does not hurt fast enough when a player or mob is inside a fire source

While inside a fire block, the fire inflicts damage at a rate of 1 [half heart] per half-second unless the player or mob has Fire Resistance or a total Fire Protection of 7 or higher.‌[BE only] When the player is on fire outside the fire block, they take damage at 1 [half heart] per second.

fire should not extinguish due to water that is diagonally below it

sometimes fire spreads to air with no adjacent block around it. I will make screenshots later. it keeps spreading diagonally below itself despite when only touching other nodes diagonally. this is all not supposed to happen according to minecraft rules. basically I built this thing and it was catching on fire https://minecraft.fandom.com/wiki/Fire?file=Fire-safe-building.png

I am not suggesting that these all need to be fixed before this PR can be approved. I simply want to document it for future reference, and perhaps some of them are caused by this PR.

after some testing, I found a few fire related bugs using the fire branch. I did not test whether they also exist on master. in creative mode you can stand in the edge of the fire without getting hurt even though your screen fills up with fire. this should not happen fire does not hurt fast enough when a player or mob is inside a fire source > While inside a fire block, the fire inflicts damage at a rate of 1 [half heart] per half-second unless the player or mob has Fire Resistance or a total Fire Protection of 7 or higher.‌[BE only] When the player is on fire outside the fire block, they take damage at 1 [half heart] per second. fire should not extinguish due to water that is diagonally below it sometimes fire spreads to air with no adjacent block around it. I will make screenshots later. it keeps spreading diagonally below itself despite when only touching other nodes diagonally. this is all not supposed to happen according to minecraft rules. basically I built this thing and it was catching on fire https://minecraft.fandom.com/wiki/Fire?file=Fire-safe-building.png I am not suggesting that these all need to be fixed before this PR can be approved. I simply want to document it for future reference, and perhaps some of them are caused by this PR.
erlehmann commented 2022-01-23 00:08:56 +01:00
Owner
Copy Link

in creative mode you can stand in the edge of the fire without getting hurt even though your screen fills up with fire. this should not happen

In creative mode, fire has always been burned players for only a very short time. Not sure if this is useful.

> in creative mode you can stand in the edge of the fire without getting hurt even though your screen fills up with fire. this should not happen In creative mode, fire has always been burned players for only a very short time. Not sure if this is useful.
erlehmann commented 2022-01-23 00:11:27 +01:00
Owner
Copy Link

basically I built this thing and it was catching on fire https://minecraft.fandom.com/wiki/Fire?file=Fire-safe-building.png

I think you mean this:

https://static.wikia.nocookie.net/minecraft_gamepedia/images/e/ea/Fire-safe-building.png/revision/latest?cb=20200819123501

> basically I built this thing and it was catching on fire https://minecraft.fandom.com/wiki/Fire?file=Fire-safe-building.png I think you mean this: https://static.wikia.nocookie.net/minecraft_gamepedia/images/e/ea/Fire-safe-building.png/revision/latest?cb=20200819123501
cora commented 2022-01-23 00:14:06 +01:00
Author
Member
Copy Link

after some testing, I found a few fire related bugs using the fire branch. I did not test whether they also exist on master.

in creative mode you can stand in the edge of the fire without getting hurt even though your screen fills up with fire. this should not happen

fire does not hurt fast enough when a player or mob is inside a fire source

While inside a fire block, the fire inflicts damage at a rate of 1 [half heart] per half-second unless the player or mob has Fire Resistance or a total Fire Protection of 7 or higher.‌[BE only] When the player is on fire outside the fire block, they take damage at 1 [half heart] per second.

Fire damage is not part of this i don't think.

fire should not extinguish due to water that is diagonally below it

This can prob easily be fixed in this pr - no idea about before - mmmh but i think i didnt touch that abm - i'll have a look

sometimes fire spreads to air with no adjacent block around it. I will make screenshots later. it keeps spreading diagonally below itself despite when only touching other nodes diagonally. this is all not supposed to happen according to minecraft rules. basically I built this thing and it was catching on fire https://minecraft.fandom.com/wiki/Fire?file=Fire-safe-building.png

Mmmh well the fire spread is implemented p much exactly like the wiki explained or maybe i misunderstood something - but yeah ig it would be good if that building is actually fire safe.

> after some testing, I found a few fire related bugs using the fire branch. I did not test whether they also exist on master. > > in creative mode you can stand in the edge of the fire without getting hurt even though your screen fills up with fire. this should not happen > > fire does not hurt fast enough when a player or mob is inside a fire source > > > While inside a fire block, the fire inflicts damage at a rate of 1 [half heart] per half-second unless the player or mob has Fire Resistance or a total Fire Protection of 7 or higher.‌[BE only] When the player is on fire outside the fire block, they take damage at 1 [half heart] per second. Fire damage is not part of this i don't think. > fire should not extinguish due to water that is diagonally below it This can prob easily be fixed in this pr - no idea about before - mmmh but i think i didnt touch that abm - i'll have a look > sometimes fire spreads to air with no adjacent block around it. I will make screenshots later. it keeps spreading diagonally below itself despite when only touching other nodes diagonally. this is all not supposed to happen according to minecraft rules. basically I built this thing and it was catching on fire https://minecraft.fandom.com/wiki/Fire?file=Fire-safe-building.png > Mmmh well the fire spread is implemented p much exactly like the wiki explained or maybe i misunderstood something - but yeah ig it would be good if that building is actually fire safe.
cora commented 2022-01-23 00:34:04 +01:00
Author
Member
Copy Link

yeah for the water thing its this abm it seems:

42a026a6ac/mods/ITEMS/mcl_fire/init.lua (L327)

I didn't change that but i suppose it would be easy to check ... also the fire node has an on_flood function so not sure why this abm is even needed. I'll try today or tomorrow.

yeah for the water thing its this abm it seems: https://git.minetest.land/Mineclonia/Mineclonia/src/commit/42a026a6ac3e1a9d95479dd045a871ac322348ff/mods/ITEMS/mcl_fire/init.lua#L327 I didn't change that but i suppose it would be easy to check ... also the fire node has an on_flood function so not sure why this abm is even needed. I'll try today or tomorrow.
Li0n_2 commented 2022-01-23 01:25:23 +01:00
Member
Copy Link

@cora firstly, on_flood does not cover all the cases, because fire should also extinguish if there is water next to it, even if it cannot reach onto the block.

secondly, here is a screenshot of my safe house. the fire was in the node where I have now placed the orange glass. it had the same shape as the other fire, as if it was burning on top of a node. I don't have a screenshot of it because I keep instinctively putting it out. I shhould note that it seems to always be in the southwest direction of the fire. with this glass block in place, the fire was still able to spread, but I did not catch where it spread first.

@cora firstly, on_flood does not cover all the cases, because fire should also extinguish if there is water next to it, even if it cannot reach onto the block. secondly, here is a screenshot of my safe house. the fire was in the node where I have now placed the orange glass. it had the same shape as the other fire, as if it was burning on top of a node. I don't have a screenshot of it because I keep instinctively putting it out. I shhould note that it seems to always be in the southwest direction of the fire. with this glass block in place, the fire was still able to spread, but I did not catch where it spread first.
fire-spread-bug.png
1.0 MiB
fire-spread-bug.png
Li0n_2 commented 2022-01-23 01:31:40 +01:00
Member
Copy Link

update: the fire also spread northwest, it was probably just coincidence. unless there is a problem with the randomness in fire spread that it always prefers to spread in a certain direction

here is a screenshot of the fire

update: the fire also spread northwest, it was probably just coincidence. unless there is a problem with the randomness in fire spread that it always prefers to spread in a certain direction here is a screenshot of the fire
fire-spread-bug2.png
996 KiB
fire-spread-bug2.png
Li0n_2 commented 2022-01-23 01:56:38 +01:00
Member
Copy Link

@cora fire should only be able to spread to an airblock that is touching a full face of the flammable block. in this case fire seems to also be spreading to airblocks that are only touching by 1 corner.

a fire block can turn any air block that is adjacent to a flammable block into a fire block. This can happen at a distance of up to one block downward, one block sideways (including diagonals), and four blocks upward of the original fire block (not the block the fire is on/next to).

here where it says "including diagonals" they mean the fire can spread diagonally, not that it can be diagonal of a flammable block.

@cora fire should only be able to spread to an airblock that is touching a full face of the flammable block. in this case fire seems to also be spreading to airblocks that are only touching by 1 corner. > a fire block can turn any air block that is adjacent to a flammable block into a fire block. This can happen at a distance of up to one block downward, one block sideways (including diagonals), and four blocks upward of the original fire block (not the block the fire is on/next to). here where it says "including diagonals" they mean the fire can spread diagonally, not that it can be diagonal of a flammable block.
Li0n_2 commented 2022-01-23 04:28:57 +01:00
Member
Copy Link

@cora great fix. next bug: in my testing, the crafting bench is not catching on fire, despite being near a fire in the dangerous area. afaik crafting benches should catch on fire just like any other flammable block, regardless of whether it burns up or not

@cora great fix. next bug: in my testing, the crafting bench is not catching on fire, despite being near a fire in the dangerous area. afaik crafting benches should catch on fire just like any other flammable block, regardless of whether it burns up or not
cora commented 2022-01-23 04:37:51 +01:00
Author
Member
Copy Link

mmmh i thought i fixed that. i'll have a look lol

mmmh i thought i fixed that. i'll have a look lol
Li0n_2 commented 2022-01-23 05:48:30 +01:00
Member
Copy Link

@cora this reddit post and its comments might have some useful information about fire spread timings, if you are interested https://www.reddit.com/r/technicalminecraft/comments/jm8tf0/details_of_the_fire_spreading_algorithm/

@cora this reddit post and its comments might have some useful information about fire spread timings, if you are interested https://www.reddit.com/r/technicalminecraft/comments/jm8tf0/details_of_the_fire_spreading_algorithm/
cora commented 2022-01-23 11:25:02 +01:00
Author
Member
Copy Link

Well i am dum lol

@cora this reddit post and its comments might have some useful information about fire spread timings, if you are interested https://www.reddit.com/r/technicalminecraft/comments/jm8tf0/details_of_the_fire_spreading_algorithm/

I read it a bit fast but from what I saw it has the exact no-info the wiki has: fire has an age property of 1-15 - great? but when does it increment?

The algorithm likely cant be copied 1:1 with abms anyways - if anything it can be close on average which is probably the reason why the previous implementation used node timers.

Well i am dum lol > @cora this reddit post and its comments might have some useful information about fire spread timings, if you are interested https://www.reddit.com/r/technicalminecraft/comments/jm8tf0/details_of_the_fire_spreading_algorithm/ I read it a bit fast but from what I saw it has the exact no-info the wiki has: fire has an age property of 1-15 - great? but when does it increment? The algorithm likely cant be copied 1:1 with abms anyways - if anything it can be close on average which is probably the reason why the previous implementation used node timers.
cora commented 2022-01-23 11:29:03 +01:00
Author
Member
Copy Link

I do think thats probably out of scope though - some time I'll probably rewrite the whole fire thing to take encouragement and flammability into account - i made a prototype with it and it looked really good:

I do think thats probably out of scope though - some time I'll probably rewrite the whole fire thing to take encouragement and flammability into account - i made a prototype with it and it looked really good: ![](https://mister-muffin.de/p/Q1Eu.png)
cora commented 2022-01-23 11:44:41 +01:00
Author
Member
Copy Link

Yeah so looking at the helpful file some guy posted it's incremented p much randomly - i'd say the best we can do is have someone look at actual mc fires and tune the abm chance and interval so it looks similarly

Yeah so looking at the helpful file some guy posted it's incremented p much randomly - i'd say the best we can do is have someone look at actual mc fires and tune the abm chance and interval so it looks similarly
cora commented 2022-01-23 11:53:00 +01:00
Author
Member
Copy Link

looking at yt minecraft fires it needs to spread a bit faster i suppose.

looking at yt minecraft fires it needs to spread a bit faster i suppose.
cora commented 2022-01-23 12:18:29 +01:00
Author
Member
Copy Link

Just for future generation i do like to point out getting all 6 adjacent nodes can relatively easily be done without that hideous static table as well:

local function twoofthree(b1,b2,b3)
	return ( b1 and b2 and not b3 ) or (b1 and b3 and not b2) or (b2 and b3 and not b1)
end

local function in_straight_line(p1,p2)
	return twoofthree(p1.x==p2.x,p1.y==p2.y,p1.z==p2.z)
end

local function is_adjacent(p1,p2)
	return in_straight_line(p1,p2) and vector.distance(p1,p2) <= 1
end
Just for future generation i do like to point out getting all 6 adjacent nodes can relatively easily be done without that hideous static table as well: ``` local function twoofthree(b1,b2,b3) return ( b1 and b2 and not b3 ) or (b1 and b3 and not b2) or (b2 and b3 and not b1) end local function in_straight_line(p1,p2) return twoofthree(p1.x==p2.x,p1.y==p2.y,p1.z==p2.z) end local function is_adjacent(p1,p2) return in_straight_line(p1,p2) and vector.distance(p1,p2) <= 1 end ```
erlehmann commented 2022-02-06 04:31:20 +01:00
Owner
Copy Link

I think that #258 should be merged before this.

Meanwhile, I will be testing this now.

I think that https://git.minetest.land/Mineclonia/Mineclonia/pulls/258 should be merged before this. Meanwhile, I will be testing this now.
erlehmann force-pushed fix-fire from 88060c76c3 to 06229b5963 2022-02-07 03:43:07 +01:00 Compare
erlehmann changed title from ITEMS/mcl_fire: fix fire spread to not freeze the game to ITEMS/mcl_fire: Fix fire spread to not freeze the game 2022-02-07 03:43:47 +01:00
erlehmann commented 2022-02-07 03:44:52 +01:00
Owner
Copy Link

I rebased this branch on master, and also fixed typos in commit messages and whitespace errors.

I rebased this branch on master, and also fixed typos in commit messages and whitespace errors.
erlehmann force-pushed fix-fire from 06229b5963 to 6c2fb98160 2022-02-07 04:51:36 +01:00 Compare
erlehmann commented 2022-02-07 05:18:18 +01:00
Owner
Copy Link

It seems to me that the fire spread has a slight bias, as the first time the adjacents are checked in has_flammable(), they are not shuffled properly.

Thus, the first fire check is always checking the adjacents in this order:

{
        { x =-1, y = 0, z = 0 },
        { x = 1, y = 0, z = 0 },
        { x = 0, y = 1, z = 0 },
        { x = 0, y =-1, z = 0 },
        { x = 0, y = 0, z =-1 },
        { x = 0, y = 0, z = 1 },
}

Additionally, the Fisher-Yates shuffle that is implemented in the function shuffle_adjacents() is using math.random() without the random number generator being initialized before in mcl_fire.

Both of this together should make fire spread in a deterministic way, but only in case no one else initializes the random number generator.

Is this intented behaviour or an oversight?

It seems to me that the fire spread has a slight bias, as the first time the adjacents are checked in `has_flammable()`, they are not shuffled properly. Thus, the first fire check is always checking the adjacents in this order: ``` { { x =-1, y = 0, z = 0 }, { x = 1, y = 0, z = 0 }, { x = 0, y = 1, z = 0 }, { x = 0, y =-1, z = 0 }, { x = 0, y = 0, z =-1 }, { x = 0, y = 0, z = 1 }, } ``` Additionally, the [Fisher-Yates shuffle](https://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle#The_modern_algorithm) that is implemented in the function `shuffle_adjacents()` is using `math.random()` without the random number generator being initialized before in `mcl_fire`. Both of this together should make fire spread in a deterministic way, but only in case no one else initializes the random number generator. Is this intented behaviour or an oversight?
erlehmann commented 2022-02-07 05:27:25 +01:00
Owner
Copy Link

To illustrate why a random number generator needs to be initialized, here is an example program:

local function shuffle_adjacents()
  for i = #adjacents, 1, -1 do
    local r = math.random(i)
    adjacents[i], adjacents[r] = adjacents[r], adjacents[i]
  end
end

adjacents = {1,2,3,4,5,6}
shuffle_adjacents()

for position, value in ipairs(adjacents) do
   print(position .. ": " .. value)
end

This program shuffles a list of numbers using shuffle_adjacens from this PR.

On my computer, it always outputs:

1: 1
2: 5
3: 3
4: 4
5: 2
6: 6
To illustrate why a random number generator needs to be initialized, here is an example program: ``` local function shuffle_adjacents() for i = #adjacents, 1, -1 do local r = math.random(i) adjacents[i], adjacents[r] = adjacents[r], adjacents[i] end end adjacents = {1,2,3,4,5,6} shuffle_adjacents() for position, value in ipairs(adjacents) do print(position .. ": " .. value) end ``` This program shuffles a list of numbers using `shuffle_adjacens` from this PR. On my computer, it always outputs: ``` 1: 1 2: 5 3: 3 4: 4 5: 2 6: 6 ```
erlehmann commented 2022-02-07 05:32:23 +01:00
Owner
Copy Link

You can seed the random number generator with the current time using math.randomseed(os.time()). If you insert such a function call in the program in my post above at any point before shuffle_adjacents() is called, the values get shuffled the same only during the same second (since then the seed is the same).

You can seed the random number generator with the current time using `math.randomseed(os.time())`. If you insert such a function call in the program in my post above at any point before `shuffle_adjacents()` is called, the values get shuffled the same only during the same second (since then the seed is the same).
erlehmann commented 2022-02-07 07:28:31 +01:00
Owner
Copy Link

I chatted with @cora about this and she thinks it is not a big deal that fire spread is deterministic. She also said said that she is not going to change this PR anymore.

I am thinking about adopting this PR to fix the RNG issue and whatever else we find.

I chatted with @cora about this and she thinks it is not a big deal that fire spread is deterministic. She also said said that she is not going to change this PR anymore. I am thinking about adopting this PR to fix the RNG issue and whatever else we find.
cora commented 2022-02-07 14:45:51 +01:00
Author
Member
Copy Link

If you think it through it really isn't a big deal in practise, while in theory being deterministic like this yeah, it's still going to be very hard to predict (and tbh impossible if another fire is happening outside the players rendering distance).

However this is obviously an oversight. The point is that I am quite tired of sporadic interest and then weeks of nothing so I said I will probably not fix an inconsequential detail like this (now).

I mean I can do it but please test the rest first and tell me everything you want changed and don't wait 2 weeks to find the next detail.

If you think it through it really isn't a big deal in practise, while in theory being deterministic like this yeah, it's still going to be very hard to predict (and tbh impossible if another fire is happening outside the players rendering distance). However this is obviously an oversight. The point is that I am quite tired of sporadic interest and then weeks of nothing so I said I will probably not fix an inconsequential detail like this (now). I mean I can do it but please test the rest first and tell me everything you want changed and don't wait 2 weeks to find the next detail.
erlehmann commented 2022-02-07 14:54:46 +01:00
Owner
Copy Link

I mean I can do it but please test the rest first and tell me everything you want changed and don't wait 2 weeks to find the next detail.

Ok!

> I mean I can do it but please test the rest first and tell me everything you want changed and don't wait 2 weeks to find the next detail. Ok!
cora commented 2022-02-07 19:05:45 +01:00
Author
Member
Copy Link

Btw. right now it is even more deterministic and it never seemed to bother anyone. At least I shuffle the adjacents.

Btw. if you want it "totally" random adding a randomseed is not enough. The aircube thing is likely biased in one direction (prob -/- idk) even though i doubt you could spot the difference.

Btw. right now it is even more deterministic and it never seemed to bother anyone. At least I shuffle the adjacents. Btw. if you want it "totally" random adding a randomseed is not enough. The aircube thing is likely biased in one direction (prob -/- idk) even though i doubt you could spot the difference.
erlehmann commented 2022-02-07 22:02:24 +01:00
Owner
Copy Link

Btw. right now it is even more deterministic and it never seemed to bother anyone. At least I shuffle the adjacents.

Just to spell it out here: Current fire is shit and you have created something much better.

Btw. if you want it "totally" random adding a randomseed is not enough. The aircube thing is likely biased in one direction (prob -/- idk) even though i doubt you could spot the difference.

I will look into if I can notice it. Generally I would like fire spread either to be totally deterministic to help with automated tests or I want it to be ”believably random”, i.e. people should not be able to figure out where the fire (even the first fire on some server) spreads.

> Btw. right now it is even more deterministic and it never seemed to bother anyone. At least I shuffle the adjacents. Just to spell it out here: Current fire is shit and you have created something much better. > Btw. if you want it "totally" random adding a randomseed is not enough. The aircube thing is likely biased in one direction (prob -/- idk) even though i doubt you could spot the difference. I will look into if I can notice it. Generally I would like fire spread either to be totally deterministic to help with automated tests or I want it to be ”believably random”, i.e. people should not be able to figure out where the fire (even the first fire on some server) spreads.
cora commented 2022-02-07 22:10:25 +01:00
Author
Member
Copy Link

Btw. right now it is even more deterministic and it never seemed to bother anyone. At least I shuffle the adjacents.

Just to spell it out here: Current fire is shit and you have created something much better.

Well you still prefer the "shit" version obviously if there is even a single thing about the "better" one you do not like lol. (e.g. bc it's "deterministic" even though the old version is even more so lol) Let me know when you're done then i'll fix the remaining issues.

> > Btw. right now it is even more deterministic and it never seemed to bother anyone. At least I shuffle the adjacents. > > Just to spell it out here: Current fire is shit and you have created something much better. Well you still prefer the "shit" version obviously if there is even a single thing about the "better" one you do not like lol. (e.g. bc it's "deterministic" even though the old version is even more so lol) Let me know when you're done then i'll fix the remaining issues.
erlehmann commented 2022-02-07 22:12:05 +01:00
Owner
Copy Link

Let me know when you're done then i'll fix the remaining issues.

Will do!

> Let me know when you're done then i'll fix the remaining issues. Will do!
erlehmann commented 2022-02-08 23:19:33 +01:00
Owner
Copy Link
Reproducing
  • start mineclonia without this pr on flat mapgen with seed "fire"

I had to check the mapgen flag “decorations” to get a forest to burn.

Minetest maxed out one CPU immediately, so I turned on opaque leaves.
That setting made rendering speed jump from 5 to 7fps to 25 to 27fps!

  • start a large fire (e.g. using mcl_fire:flint_and_steel or mcl_core:lava_source )

flint and steel noises

  • observe minetest process maxing out one of your cpus eventually

A small fire made rendering go down to 12fps and maxed out 2 of 2 CPUs.
The small fire also partially burned itself out, within a dense forest.

A large fire did not change much, except that the server would lag too.

At some point it would take a while until a right-clicked tree ignited.
Additionally, the server would not react to console commands anymore …

My PC got 4°C hotter from handling fires – less than any Matrix client.

After quitting Minetest, the server would hang around in the background.
So Minetest made my PC lag after I had closed the GUI. Extremely cursed!

Testing fix
  • start mineclonia with this pr on flat mapgen with seed "fire"

Again, I activated the mapgen flag “decorations” to get a forest to burn.

  • start a large fire (or just take the one you just started) it has to be a new world because the old one's fires will still have the old laggy node timers.

I started a small fire at first, to compare differences.
The fps dropped only a bit – they went from 27 to 24.
(This was, of course, while not looking at a fire.)

  • observe that cpu does not max out no matter how large you make the fire. impact is negligible compared to the situation before (what do i know what slow cpus you guys have lol)

No CPUs were maxed out in this step of testing the PR.
Additionally, I got very few ABM starvation warnings.

The small fire did not burn itself out, it grew larger!

In gameplay terms, the new fire seems much more useful:
I was able to create clearing in the woods by using it.

Testing functionality / regressions
  • verify that flint and steel can set fire to flammable nodes

flint and steel noises

Using a fire charge item works too.

  • verify that lava and nether lava (mcl_nether:nether_lava_source sets fire to flammable nodes (e.g. mcl_core:wood )

This works.

Lava is mcl_core:lava_source by the way.

Is flowing lava not intended to spawn fires though?

  • verify that burning flammables are eventually removed / burned up by the fire.

I like this a lot.

  • verify that fires without flammable nodes adjacent eventually go out.

  • verify that water extinguishes fire (mcl_buckets:bucket_water)

Punching fire extinguishes it.

Throwing water bottles extinguishes the fire.

Dropping water or river water directly on fire extinguishes it.

Any fire node close to a water note is extinguished, even when it is diagonally.

Is this intended behaviour? It seems a bit weird to me that fire does not need to touch the water.

  • verify that fire on netherrack gets turned to mcl_fire:eternal_fire ( mcl_nether:netherrack ) - verify by pointing at the fire and looking at f5 debug info.

This does not work in all cases.

Directly setting netherrack on fire creates eternal fire. I assume this is what you meant?

Placing or pushing or pulling netherrack under normal fire does it not turn into eternal fire though.

I am not sure if that ever worked, so if you do not want to fix it in this PR, I will open an issue later.

Note that I also verified that eternal fire is created above magma and bedrock (in the End).

  • verify that mcl_fire:eternal_fire sets fire to flammable nodes as well

This works. I tested it with the forest from the beginning.

  • verify that the fire set by mcl_fire:eternal_fire is itsself normal fire (mcl_fire:fire)

Tested in overworld and Nether.

  • verify that nether portals are still lit when a fire node appears within e.g. by placing one piece of wood within the portal and one adjacent to it outside the portal and lighting the outer one on fire. (mcl_core:obsidian)

This works.

  • verify that e.g. crafting tables catch fire but do not burn away (mcl_crafting_table:crafting_table). you can do this by placing them above lava e.g.

I did not place the crafting table over lava, but it did catch fire from an adjacent normal fire.

  • note that rain extinguishing fire code path is part of mcl_weather and was not touched here.

Note. Rain extinguishing fire works fine with the code from this PR though.

Additional notes

I think your patch is somehow making Minetest repeatedly allocating a lot of memory, leading to lag – but I have no idea how.

After about 20 to 30 minutes, Minetest started allocating RAM – 100 MB every few seconds, when I burned stuff in singlenode.
After some time, this maxes out the server memory, at which point the server either frees the memory or (rarely) crashes.

While the server is allocating memory, it is lagging noticeably – even when not many fires are present.
While even small fires on the master branch max out CPUs, I was not able to reproduce the problem there.

Also, do you see any way to clear up the lag left by previous fires? Will it burn itself away?

I am now convinced that the “stone clouds” in the Void, End, and Nether are the result of lag.

###### Reproducing - [x] start mineclonia without this pr on flat mapgen with seed "fire" I had to check the mapgen flag “decorations” to get a forest to burn. Minetest maxed out one CPU immediately, so I turned on opaque leaves. That setting made rendering speed jump from 5 to 7fps to 25 to 27fps! - [x] start a large fire (e.g. using mcl_fire:flint_and_steel or mcl_core:lava_source ) **flint and steel noises** - [x] observe minetest process maxing out one of your cpus eventually A small fire made rendering go down to 12fps and maxed out 2 of 2 CPUs. The small fire also partially burned itself out, within a dense forest. A large fire did not change much, except that the server would lag too. At some point it would take a while until a right-clicked tree ignited. Additionally, the server would not react to console commands anymore … My PC got 4°C hotter from handling fires – less than any Matrix client. After quitting Minetest, the server would hang around in the background. So Minetest made my PC lag after I had closed the GUI. *Extremely cursed!* ###### Testing fix - [x] start mineclonia with this pr on flat mapgen with seed "fire" Again, I activated the mapgen flag “decorations” to get a forest to burn. - [x] start a large fire (or just take the one you just started) it has to be a new world because the old one's fires will still have the old laggy node timers. I started a small fire at first, to compare differences. The fps dropped only a bit – they went from 27 to 24. (This was, of course, while not looking at a fire.) - [x] observe that cpu does not max out no matter how large you make the fire. impact is negligible compared to the situation before (what do i know what slow cpus you guys have lol) No CPUs were maxed out in this step of testing the PR. Additionally, I got very few ABM starvation warnings. The small fire did not burn itself out, it grew larger! In gameplay terms, the new fire seems much more useful: I was able to create clearing in the woods by using it. ###### Testing functionality / regressions - [x] verify that flint and steel can set fire to flammable nodes **flint and steel noises** Using a fire charge item works too. - [x] verify that lava and nether lava (mcl_nether:nether_lava_source sets fire to flammable nodes (e.g. mcl_core:wood ) This works. Lava is mcl_core:lava_source by the way. Is flowing lava not intended to spawn fires though? - [x] verify that burning flammables are eventually removed / burned up by the fire. I like this a lot. - [x] verify that fires without flammable nodes adjacent eventually go out. - [x] verify that water extinguishes fire (mcl_buckets:bucket_water) Punching fire extinguishes it. Throwing water bottles extinguishes the fire. Dropping water or river water directly on fire extinguishes it. Any fire node close to a water note is extinguished, even when it is diagonally. Is this intended behaviour? It seems a bit weird to me that fire does not need to touch the water. - [ ] verify that fire on netherrack gets turned to mcl_fire:eternal_fire ( mcl_nether:netherrack ) - verify by pointing at the fire and looking at f5 debug info. **This does not work in all cases.** Directly setting netherrack on fire creates eternal fire. I assume this is what you meant? Placing or pushing or pulling netherrack under normal fire does it not turn into eternal fire though. I am not sure if that ever worked, so if you do not want to fix it in this PR, I will open an issue later. Note that I also verified that eternal fire is created above magma and bedrock (in the End). - [x] verify that mcl_fire:eternal_fire sets fire to flammable nodes as well This works. I tested it with the forest from the beginning. - [x] verify that the fire set by mcl_fire:eternal_fire is itsself normal fire (mcl_fire:fire) Tested in overworld and Nether. - [x] verify that nether portals are still lit when a fire node appears within e.g. by placing one piece of wood within the portal and one adjacent to it outside the portal and lighting the outer one on fire. (mcl_core:obsidian) This works. - [x] verify that e.g. crafting tables catch fire but do not burn away (mcl_crafting_table:crafting_table). you can do this by placing them above lava e.g. I did not place the crafting table over lava, but it did catch fire from an adjacent normal fire. - [x] note that rain extinguishing fire code path is part of mcl_weather and was not touched here. Note. Rain extinguishing fire works fine with the code from this PR though. ###### Additional notes **I think your patch is somehow making Minetest repeatedly allocating a lot of memory, leading to lag – but I have no idea how.** After about 20 to 30 minutes, Minetest started allocating RAM – 100 MB every few seconds, when I burned stuff in singlenode. After some time, this maxes out the server memory, at which point the server either frees the memory or (rarely) crashes. While the server is allocating memory, it is lagging noticeably – even when not many fires are present. While even small fires on the master branch max out CPUs, I was not able to reproduce the problem there. Also, do you see any way to clear up the lag left by previous fires? Will it burn itself away? I am now convinced that the “stone clouds” in the Void, End, and Nether are the result of lag.
minetest-mod-mineclonia-fire-clearing.jpg
175 KiB
minetest-mod-mineclonia-fire-no-eternal-fire-on-netherrack.jpg
84 KiB
minetest-mod-mineclonia-fire-clearing.jpg minetest-mod-mineclonia-fire-no-eternal-fire-on-netherrack.jpg
erlehmann reviewed 2022-02-08 23:26:56 +01:00
erlehmann left a comment
Owner

This patch is really good and enables giant fires without noticeable lag.

However … I suspect it introduces or triggers a severe memory leak.

A problem with the memory leak is that it makes the game laggy.

So once the leak is fixed, I think this PR is finished.

Edit: Alternatively, convince me that the leak does not exist or should be handled elsewhere.

This patch is really good and enables giant fires without noticeable lag. However … I suspect it introduces or triggers a severe memory leak. A problem with the memory leak is that it makes the game laggy. So once the leak is fixed, I think this PR is finished. **Edit:** Alternatively, convince me that the leak does not exist or should be handled elsewhere.
erlehmann commented 2022-02-09 08:10:46 +01:00
Owner
Copy Link

I made a screencast of htop displaying the memory usage of Minetest with the code from this PR.

My test setup was a singlenode world in which I placed two of the structures from the schematic in the attached zip file using schemedit. I then set them on fire and waited.

Note the weird RAM behaviour. Also note that both CPUs are pegged at about 100%.

I made a screencast of `htop` displaying the memory usage of Minetest with the code from this PR. My test setup was a singlenode world in which I placed two of the structures from the schematic in the attached zip file using schemedit. I then set them on fire and waited. Note the weird RAM behaviour. Also note that both CPUs are pegged at about 100%.
mineclonia-fire-memory-leak-evidence.mp4
458 KiB
testburn.mts.zip
1.3 KiB
cora commented 2022-02-09 11:17:21 +01:00
Author
Member
Copy Link

well no idea.

well no idea.
cora commented 2022-02-09 16:55:41 +01:00
Author
Member
Copy Link

So once the leak is fixed, I think this PR is finished.

Edit: Alternatively, convince me that the leak does not exist or should be handled elsewhere.

No idea how to do either of that. I can't even seem to reproduce this. But it does sound fairly serious so i guess you'll stay with the freezes.

> So once the leak is fixed, I think this PR is finished. > > **Edit:** Alternatively, convince me that the leak does not exist or should be handled elsewhere. No idea how to do either of that. I can't even seem to reproduce this. But it does sound fairly serious so i guess you'll stay with the freezes.
cora changed title from ITEMS/mcl_fire: Fix fire spread to not freeze the game to WIP: ITEMS/mcl_fire: Fix fire spread to not freeze the game 2022-02-09 19:23:16 +01:00
erlehmann commented 2022-02-10 05:37:33 +01:00
Owner
Copy Link

I can't even seem to reproduce this.

If I copy the map.sqlite in the attached zip into a Mineclonia singlenode world with the seed fire and use the code from this PR, on my computer Minetest will gobble up RAM immedately, like it is the most delicious of meals.

Could you please try doing the same and look what happens?

> I can't even seem to reproduce this. If I copy the `map.sqlite` in the attached zip into a Mineclonia singlenode world with the seed `fire` and use the code from this PR, on my computer Minetest will gobble up RAM immedately, like it is the most delicious of meals. Could you please try doing the same and look what happens?
super_laggy_fire_singlenode_map.sqlite.zip
254 KiB
erlehmann commented 2022-02-10 05:49:12 +01:00
Owner
Copy Link

But it does sound fairly serious so i guess you'll stay with the freezes.

  • With master branch: Small fires lead to 100% CPU & lag. Large fires are impossible.
  • With code from PR: Large fires lead to 100% CPU & lag & other apps are OOM killed.

To me, neither the original fire nor the patched fire seem remotely usable right now.

> But it does sound fairly serious so i guess you'll stay with the freezes. * With master branch: Small fires lead to 100% CPU & lag. Large fires are impossible. * With code from PR: Large fires lead to 100% CPU & lag & other apps are OOM killed. To me, neither the original fire nor the patched fire seem remotely usable right now.
cora commented 2022-02-10 15:56:49 +01:00
Author
Member
Copy Link

let's hope this fixes it

let's hope this fixes it
erlehmann commented 2022-02-10 17:01:15 +01:00
Owner
Copy Link

I think the memory leak is fixed. I have now twice run games in which a lot of stuff burned without node timers. Memory use was essentially constant over 40 minutes each time, regardless of how big the fire got. Good work!

I think the memory leak is fixed. I have now twice run games in which a lot of stuff burned without node timers. Memory use was essentially constant over 40 minutes each time, regardless of how big the fire got. Good work!
minetest-mod-mineclonia-fire-clearing-3.jpg
200 KiB
minetest-mod-mineclonia-fire-clearing-3.jpg
erlehmann force-pushed fix-fire from 3dfe8d1d2e to 15fb5064c1 2022-02-11 05:14:33 +01:00 Compare
erlehmann changed title from WIP: ITEMS/mcl_fire: Fix fire spread to not freeze the game to ITEMS/mcl_fire: Fix fire spread to not freeze the game 2022-02-11 06:56:00 +01:00
erlehmann commented 2022-02-11 06:57:25 +01:00
Owner
Copy Link

Fire looks a bit nicer now that it dies out faster than before.

Fire looks a bit nicer now that it dies out faster than before.
minetest-mod-mineclonia-fire-clearing-4.jpg
80 KiB
minetest-mod-mineclonia-fire-clearing-4.jpg
erlehmann commented 2022-02-11 07:00:50 +01:00
Owner
Copy Link

I still have encountered no CPU or RAM issues after having fires run for over 30 minutes several times. I will now retest the stuff from before and then probably approve it.

There are still two isssues with fire spread that have to be addressed:

  1. Fire spread in protected areas. How to handle it? I will open an issue,

  2. Fires dying out near unloaded nodes. In my opinion, they should not die.

I still have encountered no CPU or RAM issues after having fires run for over 30 minutes several times. I will now retest the stuff from before and then probably approve it. There are still two isssues with fire spread that have to be addressed: 1. Fire spread in protected areas. How to handle it? I will open an issue, 2. Fires dying out near unloaded nodes. In my opinion, they should not die.
erlehmann commented 2022-02-11 08:45:11 +01:00
Owner
Copy Link
  • verify that flint and steel can set fire to flammable nodes
  • verify that lava and nether lava (mcl_nether:nether_lava_source sets fire to flammable nodes (e.g. mcl_core:wood )
  • verify that burning flammables are eventually removed / burned up by the fire.
  • verify that fires without flammable nodes adjacent eventually go out.
  • verify that water extinguishes fire (mcl_buckets:bucket_water)
  • verify that fire on netherrack gets turned to mcl_fire:eternal_fire ( mcl_nether:netherrack ) - verify by pointing at the fire and looking at f5 debug info.
  • verify that mcl_fire:eternal_fire sets fire to flammable nodes as well
  • verify that the fire set by mcl_fire:eternal_fire is itsself normal fire (mcl_fire:fire)
  • verify that nether portals are still lit when a fire node appears within e.g. by placing one piece of wood within the portal and one adjacent to it outside the portal and lighting the outer one on fire. (mcl_core:obsidian)
  • verify that e.g. crafting tables catch fire but do not burn away (mcl_crafting_table:crafting_table). you can do this by placing them above lava e.g.
- [x] verify that flint and steel can set fire to flammable nodes - [x] verify that lava and nether lava (mcl_nether:nether_lava_source sets fire to flammable nodes (e.g. mcl_core:wood ) - [x] verify that burning flammables are eventually removed / burned up by the fire. - [x] verify that fires without flammable nodes adjacent eventually go out. - [x] verify that water extinguishes fire (mcl_buckets:bucket_water) - [ ] verify that fire on netherrack gets turned to mcl_fire:eternal_fire ( mcl_nether:netherrack ) - verify by pointing at the fire and looking at f5 debug info. - [ ] verify that mcl_fire:eternal_fire sets fire to flammable nodes as well - [ ] verify that the fire set by mcl_fire:eternal_fire is itsself normal fire (mcl_fire:fire) - [ ] verify that nether portals are still lit when a fire node appears within e.g. by placing one piece of wood within the portal and one adjacent to it outside the portal and lighting the outer one on fire. (mcl_core:obsidian) - [ ] verify that e.g. crafting tables catch fire but do not burn away (mcl_crafting_table:crafting_table). you can do this by placing them above lava e.g.
erlehmann commented 2022-02-11 11:34:15 +01:00
Owner
Copy Link

You may wonder why I did not continue with the testing.
The answer is, unfortunately, in the attached image.

I used flint & steel, then Minetest filled my RAM.
(No … this does not make any sense at all to me.)

You may wonder why I did not continue with the testing. The answer is, unfortunately, in the attached image. I used flint & steel, then Minetest filled my RAM. (No … this does not make any sense at all to me.)
mineclonia-fire-memory-leak.jpg
25 KiB
mineclonia-fire-memory-leak.jpg
erlehmann commented 2022-02-11 11:36:54 +01:00
Owner
Copy Link

It seems that the RAM filling behavior only happens on x86 for me.

On x86_64, I got a segfault instead, after I used the flint & steel.

It seems that the RAM filling behavior only happens on x86 for me. On x86_64, I got a segfault instead, after I used the flint & steel.
erlehmann commented 2022-02-11 11:52:47 +01:00
Owner
Copy Link

I was able to get the following traceback on a x86_64 machine:

2022-02-11 11:38:36: ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod 'mcl_fire' in callback node_on_destruct(): C stack overflow
2022-02-11 11:38:36: ERROR[Main]: stack traceback:
2022-02-11 11:38:36: ERROR[Main]: 	[C]: in function 'set_node'
2022-02-11 11:38:36: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node'
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131>
2022-02-11 11:38:36: ERROR[Main]: 	[C]: in function 'set_node'
2022-02-11 11:38:36: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node'
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131>
2022-02-11 11:38:36: ERROR[Main]: 	[C]: in function 'set_node'
2022-02-11 11:38:36: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node'
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:36: ERROR[Main]: 	...
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131>
2022-02-11 11:38:36: ERROR[Main]: 	[C]: in function 'set_node'
2022-02-11 11:38:36: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node'
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131>
2022-02-11 11:38:36: ERROR[Main]: 	[C]: in function 'add_node'
2022-02-11 11:38:36: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:290: in function 'add_node'
2022-02-11 11:38:36: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:327: in function 'set_fire'
2022-02-11 11:38:36: ERROR[Main]: 	...s/Mineclonia/mods/ITEMS/mcl_fire/flint_and_steel.lua:43: in function <...s/Mineclonia/mods/ITEMS/mcl_fire/flint_and_steel.lua:13>
2022-02-11 11:38:37: ACTION[Main]: Server: Shutting down
2022-02-11 11:38:37: ERROR[Main]: ModError: Runtime error from mod 'mcl_fire' in callback on_shutdown(): C stack overflow
2022-02-11 11:38:37: ERROR[Main]: stack traceback:
2022-02-11 11:38:37: ERROR[Main]: 	[C]: in function 'set_node'
2022-02-11 11:38:37: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node'
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131>
2022-02-11 11:38:37: ERROR[Main]: 	[C]: in function 'set_node'
2022-02-11 11:38:37: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node'
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131>
2022-02-11 11:38:37: ERROR[Main]: 	[C]: in function 'set_node'
2022-02-11 11:38:37: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node'
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:37: ERROR[Main]: 	...
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131>
2022-02-11 11:38:37: ERROR[Main]: 	[C]: in function 'set_node'
2022-02-11 11:38:37: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node'
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire'
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131>
2022-02-11 11:38:37: ERROR[Main]: 	[C]: in function 'add_node'
2022-02-11 11:38:37: ERROR[Main]: 	...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:290: in function 'add_node'
2022-02-11 11:38:37: ERROR[Main]: 	...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:327: in function 'set_fire'
2022-02-11 11:38:37: ERROR[Main]: 	...s/Mineclonia/mods/ITEMS/mcl_fire/flint_and_steel.lua:43: in function <...s/Mineclonia/mods/ITEMS/mcl_fire/flint_and_steel.lua:13>
I was able to get the following traceback on a x86_64 machine: ``` 2022-02-11 11:38:36: ERROR[Main]: ServerError: AsyncErr: ServerThread::run Lua: Runtime error from mod 'mcl_fire' in callback node_on_destruct(): C stack overflow 2022-02-11 11:38:36: ERROR[Main]: stack traceback: 2022-02-11 11:38:36: ERROR[Main]: [C]: in function 'set_node' 2022-02-11 11:38:36: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node' 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131> 2022-02-11 11:38:36: ERROR[Main]: [C]: in function 'set_node' 2022-02-11 11:38:36: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node' 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131> 2022-02-11 11:38:36: ERROR[Main]: [C]: in function 'set_node' 2022-02-11 11:38:36: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node' 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:36: ERROR[Main]: ... 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131> 2022-02-11 11:38:36: ERROR[Main]: [C]: in function 'set_node' 2022-02-11 11:38:36: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node' 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131> 2022-02-11 11:38:36: ERROR[Main]: [C]: in function 'add_node' 2022-02-11 11:38:36: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:290: in function 'add_node' 2022-02-11 11:38:36: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:327: in function 'set_fire' 2022-02-11 11:38:36: ERROR[Main]: ...s/Mineclonia/mods/ITEMS/mcl_fire/flint_and_steel.lua:43: in function <...s/Mineclonia/mods/ITEMS/mcl_fire/flint_and_steel.lua:13> 2022-02-11 11:38:37: ACTION[Main]: Server: Shutting down 2022-02-11 11:38:37: ERROR[Main]: ModError: Runtime error from mod 'mcl_fire' in callback on_shutdown(): C stack overflow 2022-02-11 11:38:37: ERROR[Main]: stack traceback: 2022-02-11 11:38:37: ERROR[Main]: [C]: in function 'set_node' 2022-02-11 11:38:37: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node' 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131> 2022-02-11 11:38:37: ERROR[Main]: [C]: in function 'set_node' 2022-02-11 11:38:37: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node' 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131> 2022-02-11 11:38:37: ERROR[Main]: [C]: in function 'set_node' 2022-02-11 11:38:37: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node' 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:37: ERROR[Main]: ... 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131> 2022-02-11 11:38:37: ERROR[Main]: [C]: in function 'set_node' 2022-02-11 11:38:37: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:317: in function 'set_node' 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:94: in function 'spawn_fire' 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:137: in function <...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:131> 2022-02-11 11:38:37: ERROR[Main]: [C]: in function 'add_node' 2022-02-11 11:38:37: ERROR[Main]: ...ineclonia/mods/ITEMS/REDSTONE/mcl_observers/init.lua:290: in function 'add_node' 2022-02-11 11:38:37: ERROR[Main]: ...bin/../games/Mineclonia/mods/ITEMS/mcl_fire/init.lua:327: in function 'set_fire' 2022-02-11 11:38:37: ERROR[Main]: ...s/Mineclonia/mods/ITEMS/mcl_fire/flint_and_steel.lua:43: in function <...s/Mineclonia/mods/ITEMS/mcl_fire/flint_and_steel.lua:13> ```
erlehmann commented 2022-02-11 12:38:38 +01:00
Owner
Copy Link

The above two-node-arrangement bug happens only with code from this PR, but not on whatever runs on oysterity, i.e. this is definitely a bug that got introduced somewhere in this PR.

The above two-node-arrangement bug happens only with code from this PR, but not on whatever runs on oysterity, i.e. this is definitely a bug that got introduced somewhere in this PR.
erlehmann commented 2022-02-11 14:27:36 +01:00
Owner
Copy Link

Seems that cora found and fixed it. My testing will continue now.

Seems that cora found and fixed it. My testing will continue now.
erlehmann force-pushed fix-fire from cd0f863e6b to a685986fb4 2022-02-11 17:34:15 +01:00 Compare
erlehmann force-pushed fix-fire from a685986fb4 to f5ba6f5649 2022-02-11 17:44:43 +01:00 Compare
erlehmann commented 2022-02-11 17:46:18 +01:00
Owner
Copy Link

I edited two commit messages. Will test again.

I edited two commit messages. Will test again.
erlehmann commented 2022-02-11 18:39:56 +01:00
Owner
Copy Link
  • verify that flint and steel can set fire to flammable nodes
  • verify that lava and nether lava (mcl_nether:nether_lava_source sets fire to flammable nodes (e.g. mcl_core:wood )
  • verify that burning flammables are eventually removed / burned up by the fire.
  • verify that fires without flammable nodes adjacent eventually go out.
  • verify that water extinguishes fire (mcl_buckets:bucket_water)
  • verify that fire on netherrack gets turned to mcl_fire:eternal_fire ( mcl_nether:netherrack ) - verify by pointing at the fire and looking at f5 debug info.
  • verify that mcl_fire:eternal_fire sets fire to flammable nodes as well
  • verify that the fire set by mcl_fire:eternal_fire is itsself normal fire (mcl_fire:fire)
  • verify that nether portals are still lit when a fire node appears within e.g. by placing one piece of wood within the portal and one adjacent to it outside the portal and lighting the outer one on fire. (mcl_core:obsidian)
  • verify that e.g. crafting tables catch fire but do not burn away (mcl_crafting_table:crafting_table). you can do this by placing them above lava e.g.
- [x] verify that flint and steel can set fire to flammable nodes - [x] verify that lava and nether lava (mcl_nether:nether_lava_source sets fire to flammable nodes (e.g. mcl_core:wood ) - [x] verify that burning flammables are eventually removed / burned up by the fire. - [x] verify that fires without flammable nodes adjacent eventually go out. - [x] verify that water extinguishes fire (mcl_buckets:bucket_water) - [x] verify that fire on netherrack gets turned to mcl_fire:eternal_fire ( mcl_nether:netherrack ) - verify by pointing at the fire and looking at f5 debug info. - [x] verify that mcl_fire:eternal_fire sets fire to flammable nodes as well - [x] verify that the fire set by mcl_fire:eternal_fire is itsself normal fire (mcl_fire:fire) - [x] verify that nether portals are still lit when a fire node appears within e.g. by placing one piece of wood within the portal and one adjacent to it outside the portal and lighting the outer one on fire. (mcl_core:obsidian) - [x] verify that e.g. crafting tables catch fire but do not burn away (mcl_crafting_table:crafting_table). you can do this by placing them above lava e.g.
erlehmann approved these changes 2022-02-12 04:22:58 +01:00
erlehmann left a comment
Owner

I have tested this a lot. @cora has fixed all the bugs I found.

This is clearly better than what we had before.

I have tested this a lot. @cora has fixed all the bugs I found. This is clearly better than what we had before.
erlehmann merged commit 18e299d923 into master 2022-02-12 04:39:41 +01:00
erlehmann deleted branch fix-fire 2022-02-12 11:50:44 +01:00
This repo is archived. You cannot comment on pull requests.
Reviewers
No reviewers
erlehmann
Labels
Clear labels   
blocker

blocks release until resolved

  
bug

   
code quality

   
confirmed

   
critical

crashes, catastrophic bugs

  
discussion

   
high priority

   
incompatibility

incompatible with mcl2

  
incomplete feature

   
invalid

   
low priority

   
missing feauture

   
needs testing

   
packet spam

   
performance

   
project

meta-issues

  
regression

   
translations

   
unconfirmed
  
in review

   
ready for review
No Label
blocker
bug
code quality
confirmed
critical
discussion
high priority
incompatibility
incomplete feature
invalid
low priority
missing feauture
needs testing
packet spam
performance
project
regression
translations
unconfirmed
in review
ready for review
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Depends on
#258 MAPGEN/mcl_structures: Add (theoretically) fireproof test structure
Mineclonia/Mineclonia
Reference: Mineclonia/Mineclonia#234
No description provided.
Delete Branch "fix-fire"

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?