Flash Flood

Flash Flood raises the map's water level through a sequence of water files, then lowers it and reloads the default water. It includes a standalone start command and an integration for Disaster Hub.

Current source limitations: The inspected server and client disagree on the flood event arguments, and the standalone command does not check the invoking player's permission correctly. These affect reliable operation and access control. See known limitations before relying on this build.

{:is-warning}

{:links-list}

INSTALLATION

  1. Copy the inner BigDaddy-FlashFlood resource folder into your server's resources folder. Use the folder containing fxmanifest.lua, settings.ini, the DLLs, bridge, and data.
  2. Add your own product key to key1 under [licensing] in settings.ini. Leave the supplied synchronization value unchanged.
  3. Keep all packaged data/water*.xml files, including water_default.xml. The flood and recovery sequence depend on them.
  4. Start your weather resource first if you use one. Start BigDaddy-EAS before Flash Flood if you want its optional emergency alert.
  5. Add ensure BigDaddy-FlashFlood to server.cfg. If you use Disaster Hub, start Flash Flood before BigDaddy-DisasterHub.
  6. Configure permissions and restart the resource. Reconnect before testing so the player initialization runs again.

DO NOT RENAME THE FOLDER. The resource must be named BigDaddy-FlashFlood; its configuration and water-file paths use that name.

{:is-danger}

Disaster Hub and EAS are optional integrations. There is no framework, inventory, database, or menu configuration.

CONFIGURATION

settings.ini

“Supplied” means the value in the inspected package. “Fallback” means the value read by the source when a setting is absent or cannot be parsed.

Section Setting Supplied / fallback Description
[licensing] key1 Your product key Enter your own product key here.
[settings] UseAcePermissions true / false Enables the command's permission gate. See the permission limitation below.
[settings] AcePermission command / command ACE object checked during player initialization.
[settings] UseEAS true / false Enables the standalone flood alert when BigDaddy-EAS is started.
[settings] EASTitle EMERGENCY ALERT SYSTEM / same Title passed to EAS for the standalone alert.
[settings] EASMessage Dangerous Flash Flooding is imminent. Find high ground immediately. / same Standalone flood warning text.
[settings] debug true / false Enables additional resource diagnostic messages where implemented.
[settings] DesyncKey Supplied by the package Internal synchronization value. Leave it unchanged.

Restart the resource after editing settings. Setting names are case-insensitive. Edit the existing keys rather than adding duplicate entries.

There are no INI settings for flood height, rise speed, fall speed, duration, automatic scheduling, or random flood probability in this source.

ACE permissions

To configure a dedicated permission, set these values under the existing [settings] section:

UseAcePermissions=true
AcePermission=bigdaddy.flashflood

Grant the object to your administrator group in server.cfg:

add_ace group.admin bigdaddy.flashflood allow

Your administrators must also belong to that group. See the permissions guide for assigning principals.

Permission limitation: The server stores a single hasPermission flag, overwritten whenever a player initializes. /startflashflood reads that shared flag instead of checking the command caller. Access can therefore depend on the most recently initialized player. This configuration does not provide reliable per-player command protection until the handler is corrected. The flood event handlers also contain no ACE checks of their own.

{:is-warning}

COMMANDS AND FLOOD BEHAVIOR

Command Purpose
/startflashflood Requests a standalone flood after successful resource initialization. Takes no supported arguments.

The command ignores arguments, so /startflashflood 300 does not select a five-minute duration. There is no registered stop command, in-game menu, or automatic scheduler in Flash Flood itself.

The standalone server handler requests weather suspension through its bridge, selects a random duration from 45,000 to 119,999 milliseconds, and broadcasts the flood event. It requests an EAS warning after ten seconds, then resumes the weather provider when that server duration expires.

The client routine is written to transition to THUNDER over ten seconds when its forceWeather argument is true. It then raises the water, waits longer at the peak only if the requested duration exceeds the rise time, and lowers the water. When forcing weather, it requests OVERCAST as the water starts receding.

These describe the server and client routines individually; the event mismatch listed below prevents treating this sequence as verified end-to-end behavior.

Water levels and timing

The current client loads water1.xml, water3.xml, and so on through water349.xml, waiting 850 milliseconds per step. Those packaged endpoints define water heights of 0.1 and 34.9. The files define a broad water area rather than a configurable local flood zone.

The rise takes approximately 149 seconds, regardless of a shorter requested duration. The descent takes approximately another 150 seconds before loading water_default.xml. A normal rise-and-fall sequence therefore takes about five minutes, plus any initial weather transition or additional peak hold time.

The requested duration is not the total time until the water returns to normal. The server's weather-resume timer can expire while the client is still raising the water.

DISASTER HUB INTEGRATION

Start BigDaddy-FlashFlood before BigDaddy-DisasterHub, then select Flash Flood in /DisasterHub. The Hub can also request floods from eligible rain or thunder weather checks. Configure those checks and FlashFloodChance in the Hub, not in Flash Flood's settings.

The Hub calls BigDaddy-FlashFlood:StartFlashFloodHub with a duration in seconds. That handler broadcasts a flood intended to run without Flash Flood forcing the weather. It does not suspend/resume Flash Flood's weather bridge or send Flash Flood's standalone EAS alert; the Hub handles its own weather and alert logic.

Both resources register a command named startflashflood. Avoid relying on that shared command when both are running; use the Hub menu for Hub-managed requests, subject to the event mismatch below.

Server integration events

Server event Argument Intended behavior
BigDaddy-FlashFlood:StartFlashFlood Integer duration in seconds Standalone path with weather bridge and optional EAS. Pass 0 for the random duration.
BigDaddy-FlashFlood:StartFlashFloodHub Integer duration in seconds Hub path without Flash Flood's own weather bridge or EAS calls. Pass 0 for the random duration.

Use these from authorized server logic. Neither handler checks permissions or prevents a second flood from starting while one is active. For positive standalone durations, use at least ten seconds: the handler waits ten seconds before calculating its remaining delay. Increasing duration does not change the fixed rise/fall speed.

WEATHER BRIDGE

Edit Config.WeatherBridge at the top of bridge/weather.server.lua.

Option Default Description
Enabled true Enables bridge suspend/resume handling. Turning this off does not disable flooding or the client's direct weather requests.
Provider 'auto' Detects the first started provider in the order below, or selects an explicit provider identifier.
RestorePreviousWeather true Lets the QB handler request the saved weather on resume when available.
Debug false Enables [WeatherBridge] diagnostics, including failed export calls.
Detection order / resource Identifier Implemented bridge behavior
BigDaddy-Weather bigdaddy Reads GetWeather; sends weather-sync suspend/resume events.
qb-weathersync qb-weathersync Reads weather/dynamic state; attempts to disable dynamic weather and restore the saved state on resume.
cd_easytime cd_easytime Reads GetAllData; no working suspend/resume hooks are supplied.
Renewed-Weathersync renewed Reads GlobalState.weather; no working suspend/resume hooks are supplied.
vSync vsync Detection only; no stock weather getter or working suspend/resume hooks are supplied.
vMenu vmenu Detection only; no stock weather getter or working suspend/resume hooks are supplied.

These are the hooks present in this project, not confirmation of compatibility with every provider version. No detected provider gives none; you can also explicitly set Provider='none'.

For a custom integration, select Provider='custom' and fill the Custom fields in the bridge:

  • SuspendEvent / ResumeEvent: server events called with (enabled, reason).
  • SuspendExportResource / SuspendExportName: server export called on suspend with the same arguments.
  • ResumeExportResource / ResumeExportName: server export called on resume with the same arguments.
  • CurrentWeatherExportResource / CurrentWeatherExportName: getter called without arguments, returning a weather string or a table with a recognized weather field.

Both the event and export are called if both are configured for an action. The weather getter does not create automatic flood behavior; Flash Flood has no weather watcher.

Bridge server exports

The resource exposes Suspend(enabled, reason), Resume(reason), IsSuspended(), GetSuspendedReason(), GetProvider(), and GetCurrentWeather() through its Lua bridge. Pass true to Suspend to request suspension. Resume requests resumption.

IsSuspended() reports the bridge's recorded state, not proof that the provider paused. Placeholder handlers and caught export failures can still leave that state marked suspended. GetCurrentWeather() returns a weather string or nil when unavailable.

EMERGENCY ALERTS

For standalone floods, enable UseEAS=true and start BigDaddy-EAS. Approximately ten seconds after the server begins the flood, it sends EASTitle and EASMessage to BigDaddy-EAS:BuildEAS, with an empty alert-type argument.

Hub-triggered floods skip this alert. Configure the Hub's Flash Flood EAS settings for that path instead.

KNOWN LIMITATIONS

These findings apply to the inspected source. The manifest declares version 1.0.0; the packaged DLLs have not been tested on a live FiveM server and may come from a different revision.

Finding Effect
Server/client event arguments disagree Both server paths send (durationMs, scale, forceWeather), but the client expects (int duration, bool forceWeather). The extra floating-point argument occupies the position where the client expects a boolean. Dispatch or weather behavior may fail or differ from the intended path until these signatures agree.
Shared command permission flag The most recently initialized player's permission can affect other callers. See the ACE section.
Missing first descent file After rising through index 349, the counter is 351. The descent first attempts data/water351.xml, which is absent, before continuing through the existing odd-numbered files. The return value from loading water is not acted on.
Duration differs from full flood lifecycle The client completes its fixed rise and descent even if the server's requested duration is shorter. Weather may resume before the water recedes.
Overlapping triggers are not blocked Client flood routines share the same water counter, so repeated triggers can interfere with each other.
No active-flood catch-up for new players Player initialization does not send the current flood stage to someone joining after the flood broadcast.
No resource-stop cleanup handler The client restores default water only at the end of its normal descent. Stopping the resource mid-flood does not explicitly reload default water or resume weather through a cleanup handler.

TROUBLESHOOTING

Problem What to check
Command is unavailable Confirm successful resource initialization, the exact folder name, your product key, and server/F8 logs. The command is registered after synchronization succeeds.
Command access seems inconsistent Review the shared permission flag limitation; changing ACE grants alone does not fix the caller check.
Flood fails to start or weather behavior is unexpected Check logs for the event argument mismatch and confirm the client/server build versions match.
Water stays high beyond the chosen duration The client uses a fixed rise and fall sequence; duration is not a total flood timeout.
Missing water or failed water loading Confirm the complete data folder is installed and the resource has not been renamed. The missing water351.xml call is a separate source issue.
Weather changes while flooding continues Check provider support, enable bridge debug logging, and review the server/client timer difference.
No EAS alert For standalone floods, check UseEAS, the started state of BigDaddy-EAS, and the ten-second delay. For Hub floods, check the Hub's alert settings.
Rain never starts floods automatically Flash Flood has no automatic weather watcher. Configure that behavior in Disaster Hub.

Use debug=true in settings.ini and Debug=true in the weather bridge when gathering diagnostics. See the log collection guide.