Longer burn time for specific blocks

[TheoVerhelst]

I'm making a modpack with Better with Mods, and I want to make some blocks (coal blocks, charcoal blocks, wood logs, etc) burn longer than vanilla. Ideally, they should burn for at least a few minutes. If not possible, I'd be happy to have infinite burn (like netherrack, or like /gamerule doFireTick false) for these specific blocks.

I tried to use your mod to achieve that without any success. Setting the block-specific burn speed ("flammability") to a low value prevents it from disappearing after the fire, but the fire still stops after a time similar to vanilla. The "encouragement" setting did not change anything in this regard.

Is there a way to achieve the behavior I want for specific blocks?

[Foreck1]

I completely second this idea for the same exact reasons. The current behaviour is still too unpredictable and blocks can burn too fast even when set to last much longer.

[Laike-Endaril]

I spent all of yesterday looking into this, but I've concluded that the only acceptable way of producing more stable burn times for materials would be to add data to every single block which has been partially burnt, as well as the itemstack versions of them (which then means they would only stack with the same item type if they also had the same "burnt" amount, or would have to average out the "burnt" amount across the stack when stacking). This is simply more work than I'm willing to put into the feature.

There are multiple reasons I came to this conclusion, but I'll only explain some of them unless more information is requested.

The main reason is that no matter what method I use to de-randomize burn times, it produces a certain exploit unless the "burnt" data I mentioned above is saved. Namely, you'd be able to break the block that's on fire any time before the known burn time has elapsed, re-place it, and effectively be able to make it burn for an infinite amount of time, as this would reset all temporary data related to how long it's been burning.

Which comes around to your alternate solution (having them act like netherrack as far as fire goes). This is fine, because it produces a well-defined behavior that doesn't result in any obvious exploits (at least I haven't thought of any). Game balance involving this feature will simply rely on the modpack maker's discretion. I believe I should be able to add this feature.

From here on is just some related information you may or may not find useful.

With the current systems, the variance in burn times cannot be changed by any noticeable amount, but the average burn time certainly can (via flammability). I did a few 10-sample tests with coal blocks to make sure. First I tested with vanilla settings (mod defaults: flammability of 5) and got from 0:02 to 4:10, with an average of 1:18.5. I then changed the flammability to 1 and got from 0:15 to 17:52 with an average of 6:45.6. These were small sample sizes, but it should be enough for an average at least.

Encouragement doesn't have anything to do with destroying blocks; it's only used for chance-based spreading of fire not involving the destruction of a block. Ie. when fire blocks are ticked, they have a chance of spreading to nearby blocks, and that chance depends heavily on the encouragement of the blocks they try to spread to. Effectively, high encouragement makes fire spread more easily to that block type.

The situation you mentioned where setting flammability to a low value prevents block burning...unless you set it to 0, that should not happen (at least not if the fire is on top of the block. If that's happening, you may have another mod messing with fire as well, causing a conflict. You may want to double-check that test with flammability of 1 and make sure the blocks are destroyed if they have fire on top. Fire on the sides can go out without burning the block, but I don't believe that's possible with top fire unless I missed a bit of code somewhere (unless it's raining ofc).

I'll leave this open for a while. Feel free to ask/suggest.

[Laike-Endaril]

Actually, I'm going to close this as I've at least released a new version with the alternative solution. I'll still see any new comments here (whenever I get around to checking github next)

[Foreck1]

This is a reasonable solution for me at least. One way I can think of fixing this exploit you mention would be to automatically have whatever block is listed in the config with a modified value to not drop itself, either by detecting "if block has fire on top, no drops happen" or by immediately spawning a fire where the block was destroyed so that it burns the item (or that it gives the impression of the player salvaging the block at the expense of probably getting burnt).

[Laike-Endaril]

That's an interesting workaround, but it wouldn't catch everything (eg. sticky pistons on a timer, some modded block movement, etc.).

Actually, you could also just put the fire out before breaking the block... :P

[Foreck1]

I do think that if you make it a config, it would still be useful for modpack makers who can decide for specific blocks to have said behavior, also, -and this is mostly a careless scenario- most players playing a modpack won't ever know this is a thin or have the patience to "reload" their fire using this behavior, what's more, this is only an issue in a pack where getting netherrack or similar is extremely difficult; for packs where it's not that hard, this is just a neat QoL (I'm not even including here the idea of putting out fires causing damage to the player, which would be pretty dope).

[Laike-Endaril]

I feel like more players would catch on than you expect, but yes, it's really only an issue if you either can't get netherrack easily, or if there is some other factor in play (eg. netherrack's behavior has been changed, or for some reason you're required to use a specific block). For most modpacks it would only be an issue early-game. For my own modpack (indev; not released) it could be an issue, but I'd probably just not use that config so that's fine.

On the flipside of that same point though, not having a stable burn time for your fuels would also only be an early-game issue for the player, and one that helps incentivize player progression, so that they don't have to deal with the unstable burn times of early-game fuels.

That being said, we can explore the idea more, but it's going to get very technical...

The next issue is that blocks don't each keep track of their own burning in any way. Instead, the fire block itself (ie. the block containing the actual fire, not the block that is "on fire") has an "age" (which only ranges from 0 to 15). The fire block also has a tick interval (with vanilla settings it ranges from 30-39 game ticks for each fire tick IIRC). Without adding any extra data, that's all I have to work with. And I don't particularly want to add any more data, because I'm pretty sure every combination of every possible value of every block property needs to be stored as a separate blockstate...

So I considered some ways of doing this using only the existing data, just using it in a different way. Probably the most interesting way I came up with was to use the fire block's age as a direct "burn power level". The way this would work is that if a fire's burn power (age) exceeds a certain level (depending on a per-block setting), the fuel block is destroyed. Going along with that, fire update times could also depend on the fire's age...basically letting you define 15 specific times at which fire could burn blocks. Ie. you'd have 15 different times, and all blocks that burn would burn at one of those times. This is probably flexible enough to get by.

There are a few issues with this though too. For example, if a fire has already been burning on a coal block for a while, and you happen to place another coal block next to the fire just before it reaches the time where it will destroy the first coal block, it will also destroy the 2nd coal block at the same time. If you were to place a block next to it with an earlier burn time, that block might disappear even sooner (maybe not instantly, but when the fire block reaches the next time in the list).

Overall, I just don't think the time investment on my end is worth the result you'd end up with.

[Foreck1]

I know it's been a while and this issue was closed already since we couldn't find any easy solution. I was thinking, wouldn't it be possible to have a boolean option that automatically increases the flammability of every registered block using an inverse proportionality to the global "Burn Speed Multiplier"? If the option is true and you set the burn multiplier to 0.5, then all registered block flammability values are multiplied x2, being fundamentally the same with the difference that now you can go to the whitelist and setting flammability to 1 for a block would override the previous multiplier, effectively allowing to make specific blocks burn slower.