Skip to main content
Every product needs the element_sdk resource, and every product accepts only a range of SDK versions. This page describes how that requirement is expressed and exactly what happens when the installed SDK does not meet it.

​
Contract

A product declares one requirement against element_sdk: an operator and a version, recorded in the resource itself. You can read it in the product’s fxmanifest.lua:
The requirement is checked when the product starts. If it is not met, the product stops before it registers anything.

​
Inputs

Two values are compared: the version of the installed element_sdk resource, and the requirement declared by the product. A version can carry a pre-release suffix, such as 0.1.0-alpha.3. A pre-release sorts before the plain version it leads to, so 0.1.0-alpha.3 is older than 0.1.0.

​
Outputs

When the requirement is met, the product starts as expected and nothing is reported. The SDK version is visible at any time in the server console:
Quote both versions when you report a problem. See Getting help.

​
Errors

Five situations are reported, each with its own console line. Only the third is a warning; the rest stop the product from starting. The SDK is not installed, or the server does not know about it.
The SDK is installed but not running. This is what you see when the SDK failed to start, or when it was stopped by hand.
The SDK version cannot be read. A warning, not an error: the product continues to start. It usually means the SDK directory was replaced with an incomplete copy. The same line covers a version that is present but not a readable version number, because from your side it is the same situation.
The installed SDK is outside the accepted range.
The requirement itself cannot be read. The requirement is written into the product’s own fxmanifest.lua by its build, so this means that file was edited or the product was copied incompletely. There is no version left to check against, so the product does not start.
Each blocking case is followed by one line naming the product that refused to start:
The product then stops. It does finish starting first: a resource cannot stop itself on this server platform, so it asks the SDK to stop it, and the SDK does so on its next tick. ensure element_map therefore reports the resource started and then stopped a moment later, and the console shows both:
The end state is stopped rather than running with part of the SDK it expected. A product running against an SDK it was not built for fails later instead, in ways that are harder to trace. Because the SDK is what performs the stop, a product whose SDK is not running reports and then keeps running: there is nothing there to stop it. The report is still the answer: install or start element_sdk. The check can be turned off with the el:dependencyCheck server setting. That is a way to confirm a diagnosis, not a fix: the product will start and then misbehave. See Server settings.

​
Example

A full transcript of a version mismatch, and the fix:
Update element_sdk to a version that satisfies the requirement, then restart. Updating the SDK does not require updating the products that depend on it: a product accepts a range precisely so that later SDK releases inside that range need no action from you.