dúvida TFS 1.x Tipos de dados em Storages

[Mateusoo 15]

Olá amigos!
Estou mexendo em um servidor TFS 1.2 e me deparei com o seguinte:
A função que estava mexendo era:

player:setStorageValue(key, value)

Ao tentar setar um storage(key) para o player de tipo de dado diferente de INT o valor(value) não é salvo.

O motivo é: O banco de dados tem o tipo do campo que vai receber o parâmetro value definido como INT, então só ira aceitar inteiros. Porem eu preciso passar outro tipo de dado(string no caso), pesquisei e achei em outro fórum uma forma de salvar todos os tipos de dados, porem é criando uma função, que cria uma tabela em um arquivo .lua na pasta do servidor, e SALVA e CARREGA essa tabela sempre que o servidor desligar/ligar respectivamente. Não me interessou essa função, pois se o server crashar os dados serão perdidos, e quanto tempo levaria para salvar TODOS os storages de TODOS os players do servidor?

Eu pensei em: alterar o campo do banco de dados, mas para que tipo? Com certeza seria necessário alterar a função SetStorageValue e getStorageValue para que leia o novo tipo do banco de dados e trate o dado de forma adequada, que acredito não ser complicado também.
Poderia também fazer novas colunas no banco de dados para todos os tipos de dados, porem teria que criar as funções para as mesmas(isso eu não acho que seria fácil pra mim)

Mas a questão é:

O que vocês acham? Qual teria a melhor performance? Por que?
Tem alguma outra ideia de como fazer isso? Deixa ai.
Obrigado desde já, abraços a todos!

[Alayen 14]

Não é simples assim, só alterar o tipo do campo. Primeiro porque muitos scripts ainda dependem do storage como um inteiro e isso ia quebrar muita coisa. Segundo que você teria que fazer muitas alterações na source pra mudar o tipo de inteiro (mais precisamente int32_t) pra string. Se você sabe o que está fazendo, vai fundo, se não, nem tente porque vai dar muito trabalho.

 

O que você pode fazer e eu recomendo fortemente é um mapa de valores possíveis do storage pro que você vai salvar. Tenho um script, por exemplo, que recebe o idioma do player configurado no OTClient e salva como um storage da seguinte forma:

 

 

local languages = {
  ["en"] = 0,
  ["br"] = 1,
  (...)
}
 
function ...(...)
  (...)
    player:setStorageValue(storage, languages[buffer])
end

 

Onde storage é uma chave qualquer e buffer é o idioma do player (en, br, de, etc). Faz algo nesse estilo, eu realmente não consigo pensar em nada que seja realmente muito dinâmico e não dê de mapear dessa forma.

 

[Mateusoo 15]

Não é simples assim, só alterar o tipo do campo. Primeiro porque muitos scripts ainda dependem do storage como um inteiro e isso ia quebrar muita coisa. Segundo que você teria que fazer muitas alterações na source pra mudar o tipo de inteiro (mais precisamente int32_t) pra string. Se você sabe o que está fazendo, vai fundo, se não, nem tente porque vai dar muito trabalho.

 

O que você pode fazer e eu recomendo fortemente é um mapa de valores possíveis do storage pro que você vai salvar. Tenho um script, por exemplo, que recebe o idioma do player configurado no OTClient e salva como um storage da seguinte forma:

local languages = {
  ["en"] = 0,
  ["br"] = 1,
  (...)
}
 
function ...(...)
  (...)
    player:setStorageValue(storage, languages[buffer])
end

Onde storage é uma chave qualquer e buffer é o idioma do player (en, br, de, etc). Faz algo nesse estilo, eu realmente não consigo pensar em nada que seja realmente muito dinâmico e não dê de mapear dessa forma.

 

Olá,

Obrigado pela resposta. Sim, essa forma é excelente, continua com a boa performance que o setStorageValue tem, e resolveria o problema, podendo ser passado qualquer tipo de dado. Muito obrigado, não vou marcar como melhor resposta ainda, espero que comentem um pouco mais sobre o assunto, se não acontecer eu dou como melhor resposta. Reputado.

Abraços.

[Alayen 14]

Outra coisa que você pode fazer é guardar a string como storage em vez de value:

 

 

player:setStorageValue("uma string qualquer", 1)

 

Mas isso só se você tiver como buscar a string de volta depois.

[Mateusoo 15]

Outra coisa que você pode fazer é guardar a string como storage em vez de value:

player:setStorageValue("uma string qualquer", 1)

Mas isso só se você tiver como buscar a string de volta depois.

Oi,

Seu primeiro método é mais eficiente, na realidade é complicado definir qual é mais eficiente, mas acredito ser o primeiro modo... Ainda aguardando novas respostas...

Abraço.

[Bruno 535]

Tópico movido para dúvidas / pedidos resolvidos.