Add greater control and server support to fire

[MegadreamsBE]

Is your feature request related to a problem? Please describe.

Fire is client-side right now and has to be manually synced by your scripts if you want it to be somewhat similar for other players including manual streaming (due to the 60 fires limit). It is however not even possible to get a hold of fire that wasn't created by your script (like fire spreading or fires caused by explosions).

Describe the solution you'd like

For a start a fire should be represented as an element, just like vehicles, peds, markers, projectiles, etc. This would make it much easier to get a hold of all active fires and already allow more control over them.

Then, it should be possible to control how a fire spreads (even completely disabling it) and for how long it actually lasts (not just only depending on its size).

At last it should also be possible to create fires server-side (should this also include fires created by explosion however? - discussion point) and have them properly synced among players. Just like other elements they'd be streamed (allowing for more active fires, although we could look into raising this hardcoded limit) and the fire spread will be handled by the player that is considered to be the syncer.

Describe alternatives you've considered

Scripting most of the above, which, let us be real, is not a complete solution.

[sbx320]

I've looked at this in the past. One major problem I faced back then was that practically everything fire-related incorporates some form of randomness, which makes it complicated to sync properly.

The fire limit is very simple to expand, as fire isn't all that complicated. After all it's just an effect with some minor logic stuck to it to spread, set things on fire and extinguish.

[MegadreamsBE]

The "easiest" thing to do then I suppose would be incorporating the logic into MTA directly and disallowing GTA SA itself from deciding things like fire spreading. From what I see there doesn't seem to be a lot of logic related to fire.

[qaisjp]

This sounds good and reasonable.

There is some prior work done ~10 years ago, here: https://github.com/multitheftauto/mtasa-blue/commits/feature/fire-sync. The branch was brought up to date last year and, last I checked, still works.

Feel free to start over or fork that branch.

Some questions to discuss:

• If I recall correctly, in that branch a created fire is more like a "fire source". Fire from the source may spread freely, and destroying the fire object will just extinguish the source. The fire that spreads just naturally dies out (eventually). Should we keep this behaviour?
• How do you think "naturally occurring fire" should behave? This is related to the above.
  • i.e. fire from / resulting from a burning vehicle; or as you mentioned - from explosions.
  • Should naturally occurring fire be their own objects?
  • Should naturally occurring fire be synced? Maybe just use a deterministic algorithm?
• There is an existing extinguishFire that takes a coordinate/radius. Obviously destroyElement would do the same thing on "elemental" fires, Should extinguishFire (at point) extinguish "elemental" fires?
• Should extinguished fires self-destroy (... self-destruct?). If so, how would m_pFire->Ignite() work? Should we keep/expose this?

[sbx320]

If I recall correctly, in that branch a created fire is more like a "fire source". Fire from the source may spread freely, and destroying the fire object will just extinguish the source. The fire that spreads just naturally dies out (eventually). Should we keep this behaviour?

I think this is rather unusual and unexpected behavior for MTA. Instead I think we should have burning fire as elements, which is able to expand via configurable options (where the default corresponds to GTA defaults). Once new fire is spawned, trigger some event (onClientFireExpanded?)

How do you think "naturally occurring fire" should behave? This is related to the above.
i.e. fire from / resulting from a burning vehicle; or as you mentioned - from explosions.

As it does right now + options to modify behavior (e.g. spread speed)

Should naturally occurring fire be their own objects?

Yes (elements though, not objects)

Should naturally occurring fire be synced?

Yes

Maybe just use a deterministic algorithm?
That's where I got stuck: How do you define that algorithm? We obviously don't want fire to just expand north all the time. Adding randomness on the other hand causes issues with sync (as even a deterministic rng would diverge).
Thinking about it a bit more now I'd attempt the following:

• Each fire gets a (potentially changing) syncer, similar to vehicles
• Each fire gets an individual pseudo rng with a seed. the rng state is synced to the server, which allows a future syncer to go on.
  Thoughts?

We'd need to add some minor logic to the server (fire should probably extinguish after a while even if no player is close). Moving the fire expansion logic to the server sadly doesn't work, as fire needs map information.

There is an existing extinguishFire that takes a coordinate/radius. Obviously destroyElement would do the same thing on "elemental" fires, Should extinguishFire (at point) extinguish "elemental" fires?

In order to keep current behavior, I think so

Should extinguished fires self-destroy (... self-destruct?). If so, how would m_pFire->Ignite() work? Should we keep/expose this?

With elemental fire as I described above there would not be a requirement for ignition, as a fire element would always be burning.

[qaisjp]

Maybe just use a deterministic algorithm?

That's where I got stuck: How do you define that algorithm? We obviously don't want fire to just expand north all the time. Adding randomness on the other hand causes issues with sync (as even a deterministic rng would diverge).

Thinking about it a bit more now I'd attempt the following:

• Each fire gets a (potentially changing) syncer, similar to vehicles
• Each fire gets an individual pseudo rng with a seed. the rng state is synced to the server, which allows a future syncer to go on.
  Thoughts?

Sounds good.

There is an existing extinguishFire that takes a coordinate/radius. Obviously destroyElement would do the same thing on "elemental" fires, Should extinguishFire (at point) extinguish "elemental" fires?

In order to keep current behavior, I think so

Should extinguished fires self-destroy (... self-destruct?). If so, how would m_pFire->Ignite() work? Should we keep/expose this?

With elemental fire as I described above there would not be a requirement for ignition, as a fire element would always be burning.

So fire elements would be extinguished using extinguishFire and/or destroyElement.

If naturally occurring fire elements were created, it would make sense to automatically destroy extinguished fires (to prevent the number of fire elements from getting out of control).

Worth mentioning that this would be the first case of elements that create themselves in response to world events.

A quick list of where I think fire could come from, off the top of my head:

• fire from pirate fire torch (i don't think this is just a particle effect, so nothing extra here)
• burning vehicles (i assume burning vehicles only create fire elements when they have been "picked up" by other elements)
• burning people
• exploding vehicles
• exploding createProjectile / vehicle projectiles
• weapon projectile explosion (grenade, satchel)
• flamethrowers
• createExplosion
• createFire
• burning objects / gtasa map