Using logic for resource dependencies

[Kiminaze]

I got an idea for dependencies in the fxmanifest:

When I’m making scripts, I usually try and keep them compatible with more than one framework at the same time (so not two versions of the same script).
However this means that I cannot use a dependency like dependency "framework_X" in the fxmanifest since the resource is also meant to be working with other frameworks.

Right now I just have to resort to manually check in the script if the framework is started and which one and if none is present, throw an error.

Would be kind of useful to have something like dependency "framework_X" or "framework_Y" (of course this won’t work like this because of Lua).
But maybe someone can think of a better solution to this problem than me

[Linden]

My idea was basically like the server dependency constraints, but using @ (like when referencing a resource) instead of /, and having tags like server and optional.

optional would be good enough for this case imo - basically being dependent on the resource if it exists.

Resource dependency constraints

We have server dependency constraints such as: dependencies { '/server:4000', '/server:999999', '/server:696969', '/policy:subdir_file_mapping', '/policy:meow', '/onesync', '/gameBuild:h4', '/native:0xE27C97A0', '/native:0xDEADBEEF', } It would be useful to add similar restraints for resource dependencies, as they are currently limited to “is this resource running”. -- check if a resource is running in the server context -- allows for server-only resources …

[Kiminaze]

Oh dang, shoulda used the search function properly

I even gave a thumbs up to that post already hahaha

Though I’m more looking for an XOR (or OR) dependency where I explicitly need at least one of them. Maybe more like this:

-- at least one
dependency "@resourcename1:OR:@resourcename2"

-- either or
dependency "@resourcename1:XOR:@resourcename2"

(your “optional” suggestion implicates that it doesn’t need to be there at all)

[tens0rfl0w]

Regarding framework compatibility →
Taking ESX and QBCore as examples, wouldn’t you still need to check for the specific framework in your script? As defining framework ‘A’ or framework ‘B’ as a dependency would require those two frameworks to have the same interfaces/exports.

(I do still see a use case for ‘early failing’ when no dependency is satisfied, but that solves only that one task, making your script still not ‘aware’ of the type of framework it’s interacting with.)

[Kiminaze]

@tens0rfl0w

Taking ESX and QBCore as examples, wouldn’t you still need to check for the specific framework in your script?

Yes, that still needs to be checked of course. But having it be the same “error” message across all resources that use that feature would make it super easy and prevent the resource from starting altogether.

[Linden]

@tens0rfl0w

I do still see a use case for ‘early failing’ when no dependency is satisfied

It also forces the resource to load if it does exist, which makes load order issues less problematic. A lot of people reporting issues like “export doesn’t exist” because they start an (optional) dependency after the dependent resource.

That early failing is pretty much the desired effect, at least for me, though – many other errors may result simply because a dependency doesn’t exist or hasn’t started yet, but I would need to rely on people modifying fxmanifest to add a dependency when enabling e.g. ox_target integration instead of distance checks.