IsModelValid returns false at high altitudes (around z >= 610) for some props

FiveM Resource Development & Modding Discussion
1

For a good bug report you should probably include:

  1. Client (production/canary) and FXServer version
    Client: Canary / Production
    DLC Version: 2802 (also tested on 2189)
    FXServer: 6497/5848 (vanilla server with vMenu)
  2. What you expected to happen
    Be able to spawn certain objects at high altitudes and/or have native IsModelValid return true
  3. What actually happens
    When attempting to spawn some objects (eg: vanilla prop v_res_tre_storagebox) on top of mount chilliad. Native IsModelValid returns false and HasModelLoaded never returns true after RequestModel. Object can only be spawned if the model is already loaded
  4. Category of bug
    objects
    native
  5. Reproducible steps, preferably with example script(s)
    Add the following command to any script
RegisterCommand('debug_load', function()
    local hash = `v_res_tre_storagebox`
    SetEntityCoords(PlayerPedId(), vec3(491.927521, 5559.857910, 784.925476))
    Citizen.Wait(500)
    print(IsModelValid(hash))
    Citizen.Wait(2000)
    SetEntityCoords(PlayerPedId(), vec3(863.106201, 4494.342285, 53.487194))
    Citizen.Wait(500)
    print(IsModelValid(hash))
end)

Update: Seems to not be elevation based but location, running the following loop sometimes print false, other times 1

CreateThread(function()
    while true do
        Wait(1000)
        print(IsModelInCdimage(`v_res_tre_storagebox`))
    end
end)

Video: 2023-06-11-19-49-03

2

Only models defined in archetype files that are declared as PERMANENT_ITYP_FILE or DLC_ITYP_REQUEST are always available - any other models are subject to dynamic loading and are technically not intended to be used from script.

In your case, v_res_tre_storagebox is defined in platform:/levels/gta5/interiors/int_props/int_residential.rpf:int_residential.#typ, which is not such a permanently-loaded file.

The reason it works when you’re in some locations is because at such locations, you’re within the streaming bounds of a .#map file which has a dependency on this .#typ file.

As to a solution, at this time there’s no function to manually request a .#typ file to be loaded from script. You could technically define it as a DLC_ITYP_REQUEST, but this’d have other side effects (getting closer to hitting the 65k archetype limit as described in Too many archetypes leading to LOD/SLODs displaying - #3 by d-bubble), or you could duplicate both the model and the archetype definition into your own resource (with a different name, or you’d hit the duplicate archetype issue as described in LOD / SLOD Texture issues - #59 by lugubrious_loompa), so this is very easy to get wrong and the side effects of getting it wrong tend to suck.

Since this is intended base GTA behavior and not a bug, this topic has been moved out of Bug reports and into Discussion.

2 Likes
3

Ah, that explains it thank you, found it weird to happen to some props and not to others. Was gonna say it can be closed but since you have moved the thread to discussions I guess it can stay open (?)

4

Sorry to bump this issue again, but just wanted to add that this was not an issue some months ago ( cannot exactly pinpoint when it started).

Is it possible something was changed in the client or most likely I had a resource turned on that had maptypes dependencies that also span a wide range of stuff so it just worked?

5

Game code has been this way since 2013. If anything ‘changed’, this would be in your setup.