Installation Guide

Step-by-step setup for oxide-weather — prerequisites, turning off your old weather script, startup order, the database, admin access and verification.

Step-by-step setup for oxide-weather. Follow it in order and you will be running on the first try. Then follow the guide for your framework — QBCore, QBX or ESX — for the steps that differ there.

Prerequisites

Required resources

ResourceMinimum versionPurpose
oxmysqllatestThe database driver. It is what lets a resource read and write your MySQL database
ox_liblatestShared utility library. Loads the language file
o-link1.8.0The bridge that lets this resource run on any framework. It also handles notifications, the admin check, logging, the shared map the zone editor and radar draw on, and the in-world drawing tool
FrameworklatestOne of qb-core, qbx_core, or es_extended

o-link 1.8.0 is a hard requirement. oxide-weather loads the shared map files that o-link first ships in 1.8.0, so on an older o-link it does not start. If you are unsure which version you have, open o-link/fxmanifest.lua and look at the version line near the top.

Optional resources

ResourcePurpose
oxide-tabletAdds the Weather app, the home-screen widget and alert notifications. See Optional: the tablet weather app
oxide-chatShows the /weather subcommands with their help text as you type

Supported frameworks

FrameworkSupport
QBCore (qb-core)Full
QBX (qbx_core)Full
ESX Legacy (es_extended)Full

If you installed o-link normally, this is already covered and there is nothing for you to do. It is listed here for reference.

oxide-weather uses these parts of o-link:

  • The admin check (olink.framework.IsAdmin) — decides who may use /weather
  • Notifications (olink.notify.Send) — the on-screen messages the commands reply with
  • Callbacks (olink.callback) — how the admin panel, settings menu and zone editor talk to the server
  • Logging (olink.logger) — console and log output
  • The shared map (olink.map) — the map the zone editor and the radar draw on, and the Map mode setting that picks how it is shown
  • Map drawing (olink.placement) — used to draw region and shelter shapes in the world. If your o-link does not provide it, everything else still works and the drawing buttons simply report that drawing is unavailable
  • The tablet (olink.tablet) — only used if you run oxide-tablet

Installation

Place the resource

Put the oxide-weather folder inside your server's resources folder. Most servers keep all their Oxide resources together in a folder named [oxide], which is fine.

The user interface is already built. You do not need to install anything, run any commands, or build anything. The packaged web files ship inside the resource.

Turn off your old weather and time script

This is the most important step, and skipping it is the number one cause of problems.

Only one resource may control the sky and the clock. If a second one is running, the two fight and you get weather that flips back and forth every few seconds, or a clock that jumps.

Look through your resources folder and your server.cfg for anything that syncs weather or time, and stop it. Common names to look for:

  • qb-weathersync
  • Renewed-Weathersync (sometimes spelled renewed-weathersync)
  • cd_easytime
  • vSync or vsync
  • night_natural_disasters
  • anything else with weather, time or sync in its name

If you start resources one line at a time in server.cfg, delete or comment out the line:

server.cfg
# ensure qb-weathersync

If you start a whole folder at once (for example ensure [qb] or ensure [standalone]), removing a line is not enough. The resource starts because it sits inside that folder. Move the folder out instead:

resources/[qb]/qb-weathersync   ->   resources/[disabled]/qb-weathersync

Do not add ensure [disabled] anywhere. Anything in that folder stays off.

Also check anything else that can change the sky:

  • Admin menus. vMenu and similar menus have weather and time options. If an admin uses them, they override oxide-weather for whoever is nearby until the next sync tick. Turn those options off for anyone who should not have them.
  • txAdmin. If you use txAdmin's weather or time controls, stop using them. Change weather with /weather instead.

Some stock resources talk to the old weather script directly — qb-apartments, qb-houses, the admin menu and the bank robbery on QBCore, and qbx_adminmenu and qbx_bankrobbery on QBX. The framework guides cover the small edit each one needs.

Database (nothing to do)

oxide-weather saves the state of the world. The time, the weather, the season, snow cover, storms and your regions all survive a restart. It keeps that in two database tables, and it creates both of them by itself the first time it starts:

TableHolds
oxide_weather_stateThe saved snapshot of the world, one row per server: clock, weather and forecast queues (global and per region), region shapes and settings, season progress, snow cover, storm fronts, outages and the road grid
oxide_settingsYour settings, shared with other Oxide resources. Weather rows use resource = 'oxide-weather'

There is nothing to import. The only requirement is that the database user on your mysql_connection_string line is allowed to create tables, which is the case on a normal setup.

If your host does not allow that, run sql/install.sql by hand: open your database manager (HeidiSQL, phpMyAdmin, DBeaver, or the database tab in your hosting panel), select the database your server uses, paste the contents of the file into the query window and run it.

If you genuinely do not want anything saved, you can instead turn Save simulation off (see Configuration → Persistence).

Add it to your server.cfg

Your server.cfg is the text file that tells your server which resources to start, and in what order. Order matters here.

server.cfg
# 1. Database and library first
ensure oxmysql
ensure ox_lib

# 2. Your framework
ensure qb-core            # or qbx_core / es_extended

# 3. o-link - the bridge. After your framework, before any Oxide resource
ensure o-link

# 4. Oxide resources
ensure oxide-tablet       # optional - adds the weather app and widget
ensure oxide-weather

The only hard rule is that o-link starts after your framework and before oxide-weather.

If you keep all your Oxide resources in a folder called [oxide], you can replace the last block with a single ensure [oxide] line.

Save the file.

Make sure you can use the admin tools

Every /weather command is admin-only. Admin here means your account holds a server permission called an ACE, a permission rule your server checks. It is separate from your framework's own admin list.

Two lines in server.cfg set this up. Add them if they are not already there:

server.cfg
add_principal identifier.license:YOUR_LICENSE_HERE group.admin
add_ace       group.admin                          admin allow
  • The first line puts you in the admin group.
  • The second line gives that whole group the admin permission.

To find your license identifier, join your server and look at the console line printed when you connect, or run status in the live server console. It looks like license:1a2b3c4d5e6f.... Paste the whole thing after identifier..

If your server already has add_ace group.admin command allow (stock QBCore and QBX ship with it), your existing admins already pass and you do not need to change anything. On ESX, the framework's own admin and superadmin groups pass automatically.

The server console counts as an admin for every command, so you can always run weather commands from there even before you set this up. Full details are in Admin Tools → Permissions.

Start the server

Start or restart your server and watch the console.

What working looks like:

  • No red dependency errors mentioning ox_lib, oxmysql or o-link

  • A console line confirming it started:

    [INFO][oxide-weather][lifecycle] Weather synchronization ready

    On a restart you also get:

    [INFO][oxide-weather][persistence] Weather simulation restored from SQL.
  • Nothing red or yellow repeating every minute

  • Join the server. The in-game clock should be moving, and after a while the weather should change on its own. Each change prints [INFO][oxide-weather][weather] Weather changed

If you never see the lifecycle line, the resource has not finished loading. That almost always means it could not reach the database, or the database user is not allowed to create tables. See Troubleshooting → The weather never loads.

Set it up the way you want it

You have two ways to change settings, and it matters which one you use.

  • Before the first start: edit the files in shared/ (see Configuration). Everything in them is copied into the database the first time the resource runs.
  • After the first start: run /weather settings in game. The database is now the source of truth, and editing the files does nothing.

For a brand new install, the usual path is:

  1. Start the server once with the defaults.
  2. Run /weather settings in game and adjust what you want.
  3. Run /weather zones if you want to redraw the weather regions on the map.

Full details are in Configuration and Admin Tools.

Framework-specific setup

Follow the one guide that matches the framework you actually run:

  • QBCore setup — disabling qb-weathersync and updating the stock resources that use it.
  • QBX setup — disabling Renewed-Weathersync and updating qbx_adminmenu and qbx_bankrobbery.
  • ESX setup — checking for an added weather script and the ESX admin groups.

Optional: the tablet weather app

If you run oxide-tablet, oxide-weather registers two things on it automatically:

  • a Weather app, with a forecast page, a radar page and an alerts page
  • a Weather home-screen widget, available in small, medium and large sizes

Players install the app and place the widget themselves from the tablet. There is nothing for you to configure beyond the on and off switches under Broadcast in /weather settings.

Severe weather alerts also arrive as tablet notifications, with a sound. You control which alerts are loud enough to notify, and whether players hear about other regions or only their own, under the same Broadcast settings.

If you do not run oxide-tablet, nothing breaks. The forecast, radar and alerts still exist on the server and other resources can still read them. There is just no player-facing app.

Verification

Server starts with no dependency errors and no repeating database errors.
Join the server. The clock is moving.
Type /weather in game. The admin panel opens with a map and a Conditions tab. If it says you do not have permission, go back to Make sure you can use the admin tools.
Type /weather set rain. The rain should start within a few seconds, for everyone.
Type /weather time 2 30. It should be half past two in the morning, for everyone.
Type /weather forecast. You should get a short list of upcoming weather with countdowns.
Type /weather inspect. You should get a line with your region, the weather, rain amount, temperature, whether you are under cover, and how wet or icy the road is.
Type /weather zones. The zone editor opens with the six shipped regions drawn on a map. Close it without saving.
Restart the resource with restart oxide-weather in the server console. The time and weather should come back where you left them, not reset to noon and clear.

Notes

Nothing to build

The user interface ships already built inside the resource. There is no install step, no build step, and no folder to compile.

Languages

The text in the commands, the admin panel and the weather app comes from locales/en.json. To translate it, copy that file to locales/<language>.json, translate the values on the right of each line (leave the names on the left alone), and add this to your server.cfg:

server.cfg
setr ox:locale <language>

Leave anything like %s and %.1f exactly where it is. Those are placeholders the resource fills in.

Running more than one server on one database

If two servers share the same database, give each one its own Simulation key so they do not overwrite each other's saved world. It is under Runtime in /weather settings, or Config.Persistence.Key in shared/config.lua before the first start. Any short name works, for example main and dev.

Database character set

The settings table uses utf8mb4, the modern default character set for MySQL and MariaDB. If your database server is still on plain utf8, the table may fail to create. To check, run this in your database manager:

SHOW VARIABLES LIKE 'character_set_server';

If the answer is not utf8mb4, ask your host to switch it or upgrade your database.

Cayo Perico

By default, snow never falls on Cayo Perico and the island stays clear while the mainland is in a blizzard. That is deliberate — the island's map does not handle snow well. You can change it under Rendering in /weather settings.

Next Steps