Ah yeah.. i have a HasOxygen condition. It sounds like that does not detect oxygen properly. I will test it in a pressurized room and try and patch the detection for this.

On a planet it's working fine for me in vanilla. In a pressurised ship it's not spreading at all :(

Actually it might be some plugin clash. I use the plugin loader but i just tried a vanilla load and the blocks are changing colours red/yellow so i'll get back to you, sorry.

@MikeXS - I just cannot get this to work it seems. I started a new world, no other mods. Typed fb#start and it confirmed the command. Shot a thruster and turret on the red ship to start fires but they just don't spread. I even added wooden armour blocks to and around them. Tried fb#update 0.1 and fb#gridspread / fb#ignite etc. I'm at a loss

You can use the welder tool for this at the moment but indeed i want to add a extinguisher handtool shooting water/bubbles. It should extinguish a few blocks at a timer and not repair so will function different.

We have a (early) firetruck that automates it for an area though this still needs a rewrite for lower CPU load.
To use the firetruck spawn any grid and rename it to 'FBFireTruck'. Then type: #firetruck on
It will then extinguish fires in 25m range of the truck every 5 seconds. Note it does not repair so flame anims from damage blocks may still appear but wont spread. Thats odd so working on a solution.

So far ..mucho fun.. we using it in ww2 combat and its hellishly funny trying to defend with your ass on fire hehe.

- using a fire extinguisher tool to extinguish multiple blocks on fire.

Sounds great!, having to run around my ship putting out fires with a hand held extinguisher !

You type the prefix 'fb#' first. Like this;
fb#start
or
fb#batch 5

how do i use commands that show when you use help command ?

Feel free to post your uncensored comments if you are not happy with this mod ;)
It will be a long way till completion and all feedback is appreciated.

Future todo list contains amongst others:
- return block to original color after extinguishing the fire
- using a fire extinguisher tool to extinguish multiple blocks on fire
- synchronising skin changes for fire animations
- igniting fires using the welder
- realism mode
- weather effects

Requests for features can be dropped in the comments.

1.0710 is ready with finally acceptable DS performance.
Skin synchronisation is turned off by default and is beeing reviewed as on DS it fails.
Current settings are:
fb#update 0.5
fb#batch 1
fb#throttle 500
fb#events 200

After a while of tuning for local and DS use a new version is available.
Still not satisfied about the performance tweaking is continuing.
Inform me what values work best for you on DS.

1.065 is available with throttle and idling options for slower worlds.
This version also includes various corrections in damage detection.

1.062 Update
The error has been corrected. The SE event system can go wild when large grids collide or are fired upon. A strict semophore bases queueing is now in use.
This version also includes a performance check and upon results showing delays slows the FB script allowing the event system to process alot more that tick.
Let me know how this runs. Thanks in advance.

Hi Ace, thanks for testing. Yes i have sent an invite for the exchange. Thanks in advance o7

I did a similar test this morn and ive definitely noticed improvements. i was able to turn the batch size up to 75 under physics stress testing without a stutter. I did get a crash during the testing though while only running FB. Something about "destination's array was not long enough". I can send over the log if you'd like.

1.06 is now available wich applies the SE event system allowing for a much better spread of the load. The math is still simplified. 1.07 should include more realistic math.

And the grid checks and block checks are already processed spread over ticks. This was already in the earlier version but it has changed for performance a few times now. You were correct in assuming we can :)
Once this new version is stable i will continue testing for the stutter problem.

I just had the stutter problem without any blocks on fire. So this is not a load problem.

After some testing this morn I have some results. Using red ship default world with a spawned-in earthlike. Using same test ship. Maximum fires and batch size definitely both affect the duration of the stutter. It never gets any worse, as i tried crashing 10 600 block test ships at once and it was no worse than crashing 2 of them.
I was able to nearly get rid of the stutter with batch size of 50 and a 4sec update interval, with fires at 250. Any higher on any of those settings and the stutter will just barely begin. Testing turning on and off the mod shows like a 5~% cpu thread load difference.
Maybe separate the jobs onto separate ticks? Every other is a batch check and every other is a fire tick? (i have no idea how programming works)

On another note.. i got a framework for more realistic fires testing now.
This includes math for;
- flame as well as heat damage
- flame temperature per material
- flash and ignition points per material
- combustion points for certain blocktypes (eg. H2 tanks)
- conductivity of material or air that heat tranfered across
- material pyro and char phase damagefactors

Though it is fairly efficient i should probably allow switching between this heavier routine and a simplistic lighter routine. Prolly by using a 'realism on/off' setting

I also added new commands to enable/disable features like not allowing combustion by damage at all or not spreading across grids.

There are no deep loops so only many grids or large grids could have it run for long.
With fb#update 1 it runs every second.
An empty world with a 600 block ship would be read in one go as the maximum blocks read is set to 50000 by default. But just 600 blocks not burning is not that much so should not stutter.

As fire spread is going to be more realistic (eg. slower) i reckon that batch processing it over ticks won't harm realism. Try to set fb#batch 50 to check only 50 new blocks per tick. See if that removes the stutter effect. I will test with the settings as well.

My world has a few 1000+ block trading space stations and 10 700+ block story structures. Not sure if blocks in space still bothered to be calculated, but I did notice a few of my vanilla safe-zoned planetary trade stations did burn down. I deleted every grid in the world that i could, and spawned a single 600 block test ship and got a stutter every second fire update this time. I set everything to vanilla settings. Sim speed is still at 1.02 too. Also tested on a vanilla world and had the same results.

To stress test i found that bigger grids cause more load then many grids.
A grid of less then a a few hundred blocks is checked fast to so 10 or 20 small ships should not cause lag but a big mothership with small ships can. Still working on why this is.

That it does not stutter every four tick may be related to the batch size. Interesting hint, thanks.
I have not done much testing in space and on non oxygen planets so let me know if anything goes really wrong when you do.

Note that oxygen is now a requirement so a moon base outer surface won't burn.
I am still working on getting pressurized and vacuum rooms to react properly.

First i will be testing if i can track temperature for each block in the world and apply some realistic math to the system without turning it into a basic heater hehe

After some testing, i had to either turn the max fires down to 50, or turn the batch size to 8000. I also made sure that only one ship was burning this time. Im using a 5800X3D CPU and none of my threads are close to max. Another thing i noticed is it doesnt stutter every 4th fire tick for whatever reason.

For renerence this is the modpack im using https://sp.zhabite.com/sharedfiles/filedetails/?id=3138611210

I was running all of the MES mods, so there were 2 small grid rovers (they use burning air vents for cosmetics) and my test ship burning (all around 200-300 blocks per grid) and a bunch of happy MES ships and bases. The pack also spawns 3 grids ranging from 300-900 blocks on every planet & moon in the system, so they were there too but not burning. Would that be enough to stress it?

The realism pack is indeed a nice set of challenges. I will keep it in mind to assure it fits well in it !

The stuttering surprises me though. It is by default set to process fires on 250 blocks. But it does run through all grids in the world (in batches of 250 per run) to check each block on it (maximum 50.000 per run).

I have a world with near 250.000 blocks where the queued processing of 250 fires works fine.
I could run it upto about 1000 blocks on fire before stuttering gets visible.
On DS it may cause additional lag due to extra communication about block status to other players. This is still beeing tested.

You can fiddle with the below two settings to resolve stutters;
fb#max 100 - maximum number of blocks on fire at the same time (lower is less cpu load)
fb#batch 1000 - maximum number of new blocks to check per run (lower is less cpu load)
The defaults are max=250, batch=50000

Gotcha. I wasn't actually aware as to how new this mod is, so I probably should've known. Fingers crossed that your progress goes well! I'm constantly building my realism modpack and your mod is cool enough to be the center of the next update. Well not "cool" more like hot but whatever.

As for differentiating between existing damaged blocks, spawned in damaged blocks and damaged blocks by recent fire/collision, i am still testing for an efficient method. As i have to track each block in the world to detect this change it currently is a costly task.

An option for now is to set the ignite level higher allowing for more damage before blocks combust. Change the ignite value using the command "fb#ignite 0.5" to set it to ignite at 50% damage. I seen many designs that use grinded down blocks as decoration. Some of these cause fast combustion when spawned in. Changing the ignite seting should help against this.
Note that i see flames on most types around 5% damage hence why it is set as default so it matches the animated state.

I have turned the mod off by default so it will be easier to test as it starts to flame up grids right away. When it is balanced properly i will set it to be enabled by default again making restarts more pleasant.

You are correct. There is still a variety of tweaking to do for block types and skins. The mechanics for this are in place already but tweaking it for both local and grid spreading has become a puzzle.
For now you can slow down the fires using "fb#update 10" to slow it down by 10 times.

I forgot to include, I recommend a system that differentiates between a broken spawned-in block and a broken block that was just shot. Any salvageable wreckage that spawns immediately goes up in flames. That and once you type fb#start it would be a lot more convenient if it either auto came back on, or just is always on by default

Really good concept but it seems a bit too much. Some AI ships will spawn burning down already and im getting stuttering if there more than one or two grid fires ticking at the same time. Perhaps a heat system so a block has to be red long enough to begin taking damage. That and turn down the rate that fire damages. A steel ship wouldn't melt in half in 5 minutes.

Oxygen as requirement has been added.
This new version also requires Administrator level to access the commands.

fire (pun intended) mod to run with something like water, rust and damaged spawn pods

Currently i have only used this on planet surfaces but indeed in space and under water it should stop fires. I will look into that for options.

Is there a way to restrict where fires can start/spread? It wouldn't make much sense for your space ship to be engulfed in flames when you're in the vacuum of space.

If you knew me you would not ask hehe. Fire off those new idea's :)

As for models if you have one that burns better then that floating christmass tree i had then let me know and i will add it as promo for this mod.

I also have a Waterwars server that is in need of fitting ww2 models but thats a whole other story (see the Waterwars mod).

This mod is amazing, let me know if you need any models for it. Or are open to suggestions.