[Question] Random Fires only with dispatch system and starting fire from another script?

[Ma-Ko-dev]

Hi!

first i want to say i like this firescript, i especially like the spreading feature! My first question is about the random fires. I read that random fires will only spawn if i activate the build in dispatch system. Is this right or did i misunderstood something there?

I am currently using Emergency Dispatch and of course i want to use this instead of another Dispatch system to alarm my players :D

My second question is pretty simple. Is it possible to start a fire from another script? If so - how?

[gimicze]

Hey,

As the code is right now, you need to use the dispatch system. However, if you're not afraid of a bit of coding, you could easily modify the following code section so that it only uses method Dispatch:addFirefighter() instead of Dispatch:subscribe(). I now see that I could have written it in a way that basically wouldn't require players to be sent the dispatch notifications, etc. but too late I guess 😄

https://github.com/gimicze/firescript/blob/e7f25eeceb39724615012318bcfd5b2756bff790/server/main.lua#L576-L650

Using the Dispatch:addFirefighter() function will not send any dispatch notifications to the specified player but will count them towards the spawner criteria (see this part of code, notice it uses Dispatch:firefighters() which simply returns number of players registered as firefighters).

It is possible to start a fire from another script - though I haven't written much events nor provide any exports to use, you could use the ExecuteCommand native. The list of things you could achieve with this approach will probably be limited - one major problem with this is you will not have access to list of scenarios, etc. You could bypass this by creating a function similar to getSharedObject from ESX, which would pass the Fire class, and then exporting this function and using the Fire class in any resource.

In case you need to know hot certain commands work, they should all be defined here:

https://github.com/gimicze/firescript/blob/e7f25eeceb39724615012318bcfd5b2756bff790/server/main.lua#L55-L459

Refer to the wiki page as well, but it is dated and it probably isn't written very clearly. Hopefully this will help you - there is a lot of areas in which the script could and maybe even should be improved, but I don't have the time to do so (feel free to track your changes here on GitHub and publish a pull request :-).

[Ma-Ko-dev]

Thank you for the helpful reply!

So far, i tested some things on my local server.

Interestingly, i do get fires when i set

Config.Dispatch = {
    enabled = false
    ...
}

Of course i need some scenarios for that, but i do get random fires without the dispatch set to true. I also found out that i can use a pre-created scenario when i want to start a fire from another script (with ExecuteCommand() just like you mentioned, i saw it in the release page a bit later :D). This is of course not 100% ideal, but good enough for the moment.

So what i probably will do is continue some tests locally and later online (if my admin is okay with that :D) before i start to change some stuff (the chat messages for example) and the way players get notified.

I am also thinking of not adding any player or job to the whitelist, since i dont want to allow every firefighter to use the start/stop fire commands, or create scenarios. That would be, in theory, not a problem when i set "players = 0" :D Maybe if we got different "tiers" of whitelist with different things they can do. But thats more of an idea for a new feature and should not be the topic here. Its just a safety thing. Players will abuse that 100% :D

I will give everything a good read when i have more time, even tho i am not very skilled in lua (and i kinda dislike it too :D). I will probably at least provide some example fire scenarios later for everyone to use :)

[gimicze]

Glad I could help.

I have actually just now found that I was probably thinking of your first question at some point and implemented Config.Dispatch.disableCalls variable, but I completely forgot about it 😄 . So basically, you can enable dispatch in config, add a line under Config.Dispatch which sets disableCalls = true. That way the system will track firefighters according your defined jobs but won't send any dispatch messages. So if you use ESX or QB core, I'd recommend using this approach as it should work as is now.

Config.Dispatch = {
    disableCalls = true,
    enabled = true, -- Set this to false if you don't want to use the default dispatch system
    timeout = 15000, -- The amount of time in ms to delay the dispatch after the fire has been created
    ...

(Example of a few config.lua lines to disable the dispatch messages)

The enabled option actually only enables/disables automatic subscription of players to the dispatch based on their job.

As for whitelist, I didn't want to complicate it. You can bypass the whitelist by using ace permissions, so it might make more sense to utilize them (see this method - it is called at the beginning of every command handler and you can specify the required permission as second argument). The ace permission firescript.all allows the use of every command provided by the script.

The whitelist commands were intended only for situations where you want to let's say temporarily allow non-admin play with the scenarios, etc., thus not for every player (as the spawner would start the fires anyway, so there wouldn't be need for anyone except the admin team to have access to the commands).