Usar Export ou triggerEvent root para ativar função de outro script?

[ber]

Fiz um sistema de barra de progresso universal para que todo script possa ativá-la através do comando triggerClientEvent(source, "progress", source), pois o addEventHandler foi configurado como root e não resourceRoot. Mas nunca vi algum script utilizando esse tipo de mecânica, sempre é usado a função export, será que é porque isso ocasiona algum tipo de problema no servidor ou é apenas coincidência?

[Lord Henry]

Posso estar equivocado, mas acredito que a maioria prefere o Export pois o trigger dará conflito se já existir outro evento com mesmo nome.

[androksi]

Também prefiro exports.

[DNL291]

Acho que é uma pergunta interessante. Há muitos casos que exports pode ser trocado por um trigger. Um motivo para o exports ser bem mais utilizado deve ser porque alguns nem sabem que o trigger pode ser uma segunda opção.

Pode ser também por evitar problemas com possíveis conflitos - mas nada que definir um nome diferente/longo não resolva, exemplo: NomeDoResource.Progressbar.SetProgress

Função exportada talvez seja mais fácil já que o trigger pode dar problemas se não tiver de acordo com o elemento da árvore (se não tiver adicionada para root por exemplo e chamado por fora); Muitos não irão saber o que de fato significa vincular o evento ao localPlayer, ao resourceRoot, ou root.

O que também difere ambas é que fazer uma chamada com exports é mais amigável do que fazer com trigger.

Sobre exports, neste post tem um teste de benchmark com a função: https://forum.multitheftauto.com/topic/83715-question-cpu-usage/?do=findComment&comment=764086
exports é bem mais lento do que uma função local (mesmo resource).
Isso porque a função exportada precisa ser acessada em um ambiente diferente do local então existe uma perca de performance, que eu nunca cheguei a testar, mas se utilizada indevidamente acredito que reflita no uso de cpu.

Alguns scripters optam por enviar o código pelo exports, então uma vez recebido, o código é "transferido" (e executado) para o novo ambiente (resource) com loadstring

Acho que é uma questão de opção no fim das contas, mas como disse, muitos que são novos e não tem muito conhecimento acabam se limitando a isso por verem em toda parte, isso faz parecer ser a única opção, principalmente para quem não domina bem a linguagem.
Pessoalmente eu também sempre optei por função exportada, fica como melhor opção se você for fazer documentação das funções ou gosta da prática mais lógica. Falei da questão da performance mas o mesmo existe para trigger event - não é bom passar root como elemento, nem ter muitos events handlers em execução.

[androksi]

Fiz um exemplo abaixo de como eu costumo estruturar minhas funções exportadas. É bem bobo o exemplo.

--- Client-side
local playerIp

function updateClientIP(ip)
    playerIp = ip
end

addEvent("ip:update", true)
addEventHandler("ip:update", resourceRoot, function(ip)
    playerIp = ip
end)

addCommandHandler("verip", function()
    if playerIp then
        print(playerIp)
    end
end)

-- Server-side
function updateClientIP(player, ip)
    triggerClientEvent(player, "ip:update", resourceRoot, ip or "?")
end

No meta.xml, eu defino dessa forma:

<exports function="updateClientIP" type="shared" />

Sendo assim, nesse exemplo, o sistema pode alterar a variável playerIp em ambos lados, tanto client-side quanto server-side. Sem contar que, como o DNL291 disse, caso você for documentar tudo, ficará muito mais legível.