Some natives "improve" link, links to wrong github

[ModoSN]

Clicking "Improve" on https://docs.fivem.net/natives/?_0x829F2E2 sends you to https://github.com/citizenfx/fivem/edit/master/ext/native-decls/SetPedPropIndex.md (Error 404)

it should send you to https://github.com/citizenfx/natives/edit/master/PED/SetPedPropIndex.md

[LokiLeiche]

I digged around a little, even though this is already open for over a year.

This happens to all automatically generated server side RPC native equivalents to client natives. In that example you mentioned, the original file declaring the SetPedPropIndex native on client side is /PED/SetPedPropIndex.md, which defines it in the PED namespace but with an additional server side function hash which seems to lead to the docs auto-generating a server side file for it as well. The server side CFX namespace natives are configured in config.toml to link to the citizenfx/fivem repo since they are usually defined there, except for these RPC native equivalents.

This also means the edit button in the documentation of the client side counterpart (https://docs.fivem.net/natives/?_0x93376B65A266EB5F) works as intended. It just doesn't work for the server native because the source file is expected to be in the fivem repo due to the CFX namespace, when it actually is in this natives repo.

I couldn't find the source code where this actually is defined and happens, maybe it's not open source and an element has to look into it. Probably just needs some additional logic to use the natives repo link instead of the fivem repo link for RPC native equivalents.

@technetium-cfx hope it's okay to ping you, maybe you can take a look, hope my research makes it a bit easier. You seem to be the one who takes care of this repo. I understand that it's probably very low priority though lol

[AvarianKnight]

This happens because any native under the CFX, you'll also notice this for other natives that aren't under the direct path of the natives repo like DELETE_RESOURCE_KVP.

This is all because the logic is pretty "dumb", i.e. it just uses the native hash with no additional logic, in order to fix it we would have to actually include more info in doc generation (like if its in a subfolder, which subfolder its in, since for example GET_EXTERNAL_KVP_FLOAT is under native-decls/kvp/external), properly add a json field for if it's an RPC native, sub directory native, etc.