Soluções alternativas RMVXAce

RPG Maker VXAce é uma parcela maravilhosa da série RPG Maker da KADOKAWA (anteriormente ASCII e Enterbrain). Trouxe muitas novidades para a mesa e é considerado o favorito por muitos.

No entanto, assim como seus predecessores anteriores, sempre há algumas novas peculiaridades que tornam os métodos antigos obsoletos ou apenas novos problemas como um todo devido a uma mudança no sistema. O objetivo deste tópico é ajudá-lo a contornar essas peculiaridades e/ou problemas.

Por que isso está acontecendo?
A razão pela qual isso acontece é por causa de como RMVXAce lida com o processamento de eventos. Isso é devido a Fiber.yield. A única maneira de “consertar” isso é reescrever o interpretador do jogo ou o sistema de mensagens. Mas não se preocupe, há uma maneira de consertar isso!

Por que devo me preocupar?
Se você gosta de criar eventos animados por meio de processos paralelos, eles parariam sempre que uma caixa de mensagem fosse exibida!

Como faço para corrigir isso?
Basta colocar os comandos do evento de processo paralelo dentro de um loop ou usar label. Ele funcionará normalmente.


Por que isso está acontecendo?
Pelo que podemos dizer, é intencional e só funciona em tetos, mas não em paredes. Não confirmado, mas pode ser apenas topos de parede A4. Alguém teria que testar isso ainda mais.

Por que devo me preocupar?  
Você pode andar por autotiles e alcançar tetos.

Como faço para corrigir isso?
Use um ladrilho superior transparente sobressalente (BCDE) e defina o bloqueio para x e coloque-o ao longo das bordas.

Por que isso está acontecendo?
Pelo que posso dizer, está relacionado ao novo Fiber.yield. Geralmente acontece quando há uma mensagem de programa após o referido evento comum. Pode ser o resultado do salto de mensagem embutido do RM.

Por que devo me preocupar?
Ele interfere nos jingles de efeitos sonoros.

Como faço para corrigir isso?
Adicione mais quadros de espera após o efeito de som. 15-60 parece funcionar.

Por que isso está acontecendo?
Pelo que posso dizer, está relacionado ao novo Fiber.yield. Geralmente acontece quando há uma mensagem de programa após o referido evento comum. Pode ser o resultado do salto de mensagem embutido do RM.

Por que devo me preocupar?
Sua foto não vai desaparecer.

Como faço para corrigir isso?
Adicione mais quadros de espera ou limpe tudo após o evento terminar.

Vá para o Editor de Script e pesquise Game_Battler, linha 730:

Código:

self.tp = rand * 25

Mudar para:

Código:

self.tp = qualquer número que você quiser

Vá para o Editor de Script e pesquise por Game_Enemy, Linha 257:

Código:

rating_max = action_list.collect {|a| a.rating }.max

abaixo dessa linha, adicione isto:

Código:

rating_max = 12 if rating_max == 10

Há uma chance muito, muito pequena de fazer um ataque de prioridade 9. Infelizmente, sem alterar o sistema, isso é o melhor que podemos fazer.

Por que isso está acontecendo?
O bug é principalmente com gráficos congelados do mapa anterior. O processo paralelo do mapa anterior tem a particularidade de começar antes de todo o resto. Agora, isso é normal e tudo, mas se você usar um Teletransporte sem Fade In, ele também congela todos os PP no próximo mapa e o único que carregaria é um Início Automático. Os PPs só serão executados depois que o mapa for atualizado.

Por que devo me preocupar?
Digamos, por exemplo, que você tenha uma imagem do mapa anterior e tenha usado um evento Teletransporte para nenhum porque deseja que essa imagem permaneça até que o próximo mapa a apague. O problema é que, se o próximo evento do mapa que limpa a imagem for um Processo Paralelo, ele não será executado.

Como consertar?
Aqui está um trecho de Kread-Ex para corrigir esse bug! Este snippet adiciona um fade in falso ou conhecido como 1 frame de atualização, se você preferir.

Código:

class Scene_Map < Scene_Base
#--------------------------------------------------------------------------
def post_transfer
  case $game_temp.fade_type
  when 0
    Graphics.wait(fadein_speed / 2)
    fadein(fadein_speed)
  when 1
    Graphics.wait(fadein_speed / 2)
    white_fadein(fadein_speed)
  when 2
    fadein(1)
  end
  @map_name_window.open
  end
end

Por que isso está acontecendo?
Basicamente, quando um evento que usa a rota de movimentação personalizada está fora da tela, o VXAce para de atualizar esse evento como uma das formas de evitar o lag.

Por que devo me preocupar?
Este vídeo vai mostrar para você. Preste muita atenção nas cachoeiras até o final:

Como consertar?
O Kread é incrível por nos fornecer uma solução muito simples:

Código:

# Put [update] in the event's name and the move route will always update.
#
# ~Kread

class Game_Event < Game_Character
#--------------------------------------------------------------------------
# * Determine if Near Visible Area of Screen
#--------------------------------------------------------------------------
alias_method(:krx_alfix_ge_nts?, :near_the_screen?)
def near_the_screen?(dx = 12, dy = 8)
  # YEA compatibility
  if $imported && $imported["YEA-CoreEngine"]
    dx = dy = nil
  end # YEA compatibility
  return true if @event.name.include?('[update]')
  return krx_alfix_ge_nts?(dx, dy)
  end
end

Tópico original:
https://divisionheaven.me/tutorials/rmvxace-workarounds/