Big Bug (tricky tracks)

BUG!

Descobri um bug no projeto! Se você não sabe do que se trata, o projeto está aqui. Não sei como ele acontece, quando acontece, nem porque, mas aconteceu.
Gostaria que me ajudassem. Se o bug acontecer com você, procure descrever o mais detalhadamente possível a situação - em que momento ocorreu, que sons foram tocados (se algum som tocar), como o jogo passou a se comportar.

O que acontece é o seguinte: ao clicar numa pista durante o jogo, a mesma é destruída e uma nova é criada. Quando o carro passa de uma pista pra outra, ele destrói aquela em que estava e passa a percorrer a nova pista SE essa pista estiver ligada à anterior. Caso a nova pista NÃO esteja ligada à anterior, é game over.
O bug é que o carro passou pra uma pista que eu tinha acabado de criar e não estava ligada à aterior. O carro ficou parado, mas não deu game over. Travou o jogo, o carro não andava nem batia.
O bug é MUITO raro de acontecer. Acredito que só aconteça ao criar a nova pista no mesmo step em que o carro termina a pista anterior, e mesmo assim em condições específicas.

Tentei forçar a barra. Logo antes do evento de mudar de pista, puxei o mouse pra pista seguinte e mandei executar o evento do clique. Não voltou a acontecer. Tentei o mesmo logo depois do evento, não voltou a acontecer. Se fosse uma única vez, eu ignoraria e diria que foi alucinação da minha cabeça, mas o bug acontece de tempos em tempos, quando eu metralho de clicks, a pista em que o carro vai entrar. Mas não acontece quando eu forço a barra, nesses casos, ou continua ou dá game over, dependendo da pista estar ok ou não.

Um pouco de como o jogo funciona:
Cada pista tem um path associado a ela.
Quando ela é destruída, o path é destruído junto. Quando ela é criada, o path é criado (a partir de alguns paths-base).
Quando o carro chega ao final do path, ele verifica de forma bem direta qual o objeto-pista adiante (instance_position(x + lengthdir_x(1, image_angle), y + lengthdir_y(1, image_angle)). Uma vez que ele tem a pista que está adiante, ele sabe qual o path que está associado a ela. Uma vez que tem o path, ele sabe se está na posição 0 ou 1 do path.
Se o carro está na posição 0 ou 1, ele percorre o path, em sentido normal ou inverso, respectivamente. Se não estiver em nenhuma dessas posições, game over.
Se a pista à frente for uma pista especial, o carro SEMPRE vai ter um path pra percorrer, então a engine é um pouco diferente (mas o erro aconteceu quando todas as pistas eram comuns, então isso não é relevante).

Um pouco de códigos:

objCarro, evento end_of_path:

Código:

//força a barra, clicando no path seguinte
window_view_mouse_set(0, objCarro . x + lengthdir_x(2, objCarro . image_angle), objCarro . y + lengthdir_y(2, objCarro . image_angle));
with(objPlacePath){
   event_perform(ev_mouse, ev_global_left_press);
   }
   
objControle . passado[(objeto . x - grStartX) / grid, (objeto . y - grStartY) / grid] = true; //verifica onde o carro já passou
with(objControle){
   event_perform(ev_trigger, 0);
   }

//grava a pista anterior numa variável
objetoVelho = objeto;
//verifica se há uma pista adiante
objeto = instance_position(x + lengthdir_x(1, image_angle), y + lengthdir_y(1, image_angle), objParentPath); //o pedaço logo adiante
if (objeto == noone){ //se não há, game over
   event_perform(ev_trigger, 0);
   exit;
   }

//se ainda estamos aqui, há uma pista adiante

Path = objeto . pathDentro;
if (objeto . object_index == objPedacoPath){//se é um objPedacoPath
   if (x == path_get_x(Path, 0) && y == path_get_y(Path, 0)) { //se estamos no começo do novo path
      event_perform(ev_trigger, 1);
      }
      else if (x == path_get_x(Path, 1) && y == path_get_y(Path, 1)) { //se estamos no final do novo path
         path_reverse(Path);
         event_perform(ev_trigger, 1);
         }
         else { //se não estamos nem no começo nem no final, game over
            event_perform(ev_trigger, 0);
            }
   }
   else if (objeto . object_index == objDoublePath){ //senão, é um objDoublePath e TEM QUE TER como seguir
      event_perform(ev_trigger, 2);
      }

os event trigger são o seguinte:
ev_trigger0: game over
ev_trigger1: continua o path seguinte, deletando o "objetoVelho"
ev_trigger2: continua o path especial (ajusta o especial e chama o trigger1)

objPlacePath (o que efetivamente cria as pistas ao clicar), evento global_left_pressed, trecho de código após verificar se o jogo já começou:

Código:

      if (objCarro . objeto != instance_position(x, y, objPedacoPath) && !instance_exists(objPausa)){ //se não é onde o carro está e não está em pausa
//(isso não está nesse trecho do código, mas a posição (x, y) do objeto é igual a do mouse (mouse_x, mouse_y) )
         //primeiro, deleta o que estiver por baixo
         with(instance_position(x, y, objParentPath)){
            if (object_index == objDoublePath){ //se o objeto for um objDoublePath
               criaNovo = false; //ele não irá criar o objeto que deveria ao ser destruído (após a passagem do carro)
               }
            instance_destroy();
            }
         //depois, cria um novo objeto na grid
         var pathToAdd, pedaco, shiftX, shiftY; //variáveis pra ajustar a pista criada
         if (especial == false){ //se é uma pista comum
            if (Tipo == 0){ //reta
               pathToAdd = PathReta;
               shiftX = 0;
               shiftY = 0;
               }
            if (Tipo == 1){ //curva
               pathToAdd = PathCurva;
               // cria um deslocamento extra pra curva (que não tem o centro estrategicamente localizado, como a reta)
               shiftX = (grid / 2) * (rot == 1 || rot == 2);
               shiftY = (-grid / 2) * (rot == 2 || rot == 3);
               }
            pedaco = instance_create(x, y, objPedacoPath);
            //agora, define as variáveis que o tal objeto precisa pra criar o path, no final
            with(pedaco){
               sprite_index = other . sprite_index;
               rot = other . rot;
               pathDentro = path_duplicate(pathToAdd);
               path_rotate(pathDentro, 90 * rot);
               path_shift(pathDentro, x + shiftX, y + shiftY);
               }
            }
            else { //(especial == true) -> pista especial
               if (Tipo == 0){
                  pathToAdd = PathReta;
                  }
               if (Tipo == 1){
                  pathToAdd = PathCurva;
                  }
               pedaco = instance_create(x, y, objDoublePath);
               //agora, define as variáveis que o tal objeto precisa pra criar o path, no final
               with(pedaco){
                  sprite_index = other . sprite_index;
                  rot = other . rot;
                  pathDentro = path_duplicate(pathToAdd);
                  Tipo  = other . Tipo;
                  } //deslocar e rodar será feito pelo carro
               }
         //por fim, tira o excesso de pontos
         objCarro . travessias = 0;
         }
      with(objChoosePath){
         if (!instance_exists(objPausa)){
            event_perform(ev_trigger, 0);
            }
         }

No objChoosePath, o trigger0 ajusta a próxima pista a ser criada

Dá pra se perder no meio de tanto código, não dá? Mas acho que está tudo bem organizado - na verdade, eu sacrifiquei um pouco de eficiência pra manter o código organizado. E então? O único fato que eu posso garantir é que o bug só acontece se eu clicar no path que o carro está entrando em algum momento muito próximo da mudança. Não sei se a pista destruída deve ser adequada pra continuar o caminho, não sei se a pista criada deve ser inadequada pra continuar o caminho, não sei se é no exato step em que o carro muda de pista ou no imediatamente posterior ou em qualquer outro step.
Dicas de debug também serão bem-vindas.

Edit: Quando ele trava, pedi pro debug motrar o valor de Path e path_speed, ambos eram valores válidos

eu acho que sei oq deve estar acontecendo ... antes de vc clicar ele "checa" a pista que estava ali anteriormente. ai vc clica e cria outra, mas essa não será checada, pq a anterior ja foi 'checada' e passou no teste, causando o bug. será?

Mesmo assim é estranho porque já que a pista "checada" é destruída, o path também é. Nesse caso ele deveria mostrar uma mensagem de erro com um path faltando. Mas eu não vi os códigos ainda, vou ver agora. Pela explicação resumida talvez a gente consiga chegar numa solução mais rápido...

Pelo visto o script de forçar a barra funcionou, certo? Então tenta trocar a action do "mouse left pressed" pra um código gml ("if mouse_check_button_pressed)", seguindo a mesma ordem de acontecimentos do script. Talvez na própria instância do carro...

diego333 escreveu:eu acho que sei oq deve estar acontecendo ... antes de vc clicar ele "checa" a pista que estava ali anteriormente. ai vc clica e cria outra, mas essa não será checada, pq a anterior ja foi 'checada' e passou no teste, causando o bug. será?

Essa foi minha primeira hipótese. Realmente quando o bug acontece, é difícil não pensar isso. Mas como o Ninja falou, o evento de mudar de pista é um só. O carro verifica se tem uma pista lá e, se tiver, passa pra ela, destruindo a anterior. Quando ele faz isso, a nova pista passa a ser a pista atual, de forma que o clique não pode mais destruí-la. Foi depois que me forcei a ver isso (não é tão fácil acreditar na lógica quando ela falha) que passei a forçar a barra com o clique.

Ninja8086 escreveu:Pelo visto o script de forçar a barra funcionou, certo? Então tenta trocar a action do "mouse left pressed" pra um código gml ("if mouse_check_button_pressed)", seguindo a mesma ordem de acontecimentos do script. Talvez na própria instância do carro...

Talvez seja mesmo uma solução, mas eu sou chato pra caramba. Pra mim não basta funcionar, tem que estar organizado (não precisa estar bonito, mas precisa fazer sentido daqui a, digamos, 2 meses sem mexer nesses códigos) e os bugs têm que ter uma explicação. Realmente a ordem dos eventos parece interferir, aqui, mas acho que tem a ver com um clique no step anterior, e não no mesmo step, como a forçação de barra faz.

O que me está doendo a cabeça é que ambos eventos se fecham, no final. Se o carro muda de pista, ele trava, no final do código, o clique. Ao clicar, a pista muda e o carro só pode verificar pela nova pista. Não tem por onde dar erro nessa lógica, salvo erro no código.

Tentei forçar a barra do clique ANTES da mudança de pista. Pra isso, coloquei "path_position -= path_speed", depois de um show_question (pra poder determinar qual é o step imediatamente anterior à mudança de pista). O carro passou a travar sempre, mesmo quando eu não mudo a pista seguinte. Quer dizer, o fato de eu ter determinado o path_position travou o carro, sabe-se lá porque. Também não sei se tem relação com o problema, mas é mais uma informação.

hum... nem li direito esse post! Fui direto ao outro pra ver do que tava falando, e estou baixando, tentando o seu game.

quanto ao erro: Unexpected Error ocurred when running the game, que deu pro capoty aconteceu comigo ao tentar o anti-life...
Nao sei se era o mesmo erro numa enguine de velocidade de ler texto do Jiraya, mas ele consertou imediatamente! talvez ele ajude...(?)

download em 3g tinta é dose! !!!! 9,30mb!??? to baxando... Fuiz!

Acho que faz sentido que seja a ordem dos eventos, já que pelo fato da instância ser criada depois do carro, o evento dela viria depois também. Eu queria ver o bug, mas não consegui simular. Tentei várias vezes, mas nenhuma deu. Queria ver a velocidade do carro no path e se acontece só com algum determinado tipo de pista.

O problema maior é que ele não acusa erro. Isso que dificulta. Se você quiser, tem um jeito de mandar o jogo com o Debug. Depois que você manda ele rodar no Debug Mode, você entra na pasta de arquivos temporários e pega o executável de lá.

Tentei forçar a barra do clique ANTES da mudança de pista. Pra isso, coloquei "path_position -= path_speed",

Mas tem um negócio aí. O path_position vai de 0 a 1, e o path_speed pode ser qualquer valor (até negativo se usar o path_reverse). Teria que dividir o comprimento dele na mesma proporção e multiplicar pelo quanto ele avança a cada passo, tipo:

Código:

path_position -= (1/path_get_length(path_index)) * path_speed;

T+

Ninja8086 escreveu:Acho que faz sentido que seja a ordem dos eventos, já que pelo fato da instância ser criada depois do carro, o evento dela viria depois também.

Só faz sentido se houver algum erro no código. Independente da ordem em que os eventos ocorrem, eles deveriam ser "fechados". Quer dizer, se o evento do carro acontece, o do clique deveria ser impossível (ao clicar, eu pergunto ao carro se esse instância que eu estou querendo apagar não é a que ele está usando). Se o clique acontece, ele já muda a instância e suas características, tudo num evento só, então quando o carro chegar lá - e isso pode ser nesse mesmo step - ele já vai encontrar a nova instância. Tudo teoria, claro. Pode Deve ser que eu esteja deixando passar alguma coisa.
Ah, só pra constar, algumas pistas são criadas antes do carro, mas de fato a maioria é criada depois. Mas o objeto que tem esse evento do clique não, ele é criado antes do carro (na verdade, ele é quem realmente cria o carro, naquela parte do código que eu cortei).

Ninja8086 escreveu:Eu queria ver o bug, mas não consegui simular. Tentei várias vezes, mas nenhuma deu. Queria ver a velocidade do carro no path e se acontece só com algum determinado tipo de pista.

Eu alterei o jogo pra mostrar alguns dados em "show_message" ao apertar uma tecla. Deu que o Path era maior que zero (!= noone) e o path_speed era 0.2, acelerando à medida que o tempo ia passando (tem um alarme pra acelerar o carro).

Ninja8086 escreveu:O problema maior é que ele não acusa erro. Isso que dificulta. Se você quiser, tem um jeito de mandar o jogo com o Debug. Depois que você manda ele rodar no Debug Mode, você entra na pasta de arquivos temporários e pega o executável de lá.

Dificulta MUITO. Estou pensando em disponibilizar é o editável, porque só com o debug, você dificilmente vai saber os nomes das variáveis a serem pesquisadas. Eu tenho uma versão em .gmk e outra em arquivos externos (o jogo foi elaborado usando o "jogo genérico"). Se eu conseguir ligar o computador em casa, vou disponibilizar o .gmk, senão coloco os arquivos externos num .rar, mesmo. Hei, eu tenho uma forma de debugar a versão com arquivos externos! Tinha me esquecido dela!

Ninja8086 escreveu:

Tentei forçar a barra do clique ANTES da mudança de pista. Pra isso, coloquei "path_position -= path_speed",

Mas tem um negócio aí. O path_position vai de 0 a 1, e o path_speed pode ser qualquer valor (até negativo se usar o path_reverse). Teria que dividir o comprimento dele na mesma proporção e multiplicar pelo quanto ele avança a cada passo, tipo:

Código:

path_position -= (1/path_get_length(path_index)) * path_speed;

T+

Acho que não vai dar um valor negativo se usar path_reverse, porque eu uso o path_reverse constantemente durante o jogo e path_speed só aumenta. Entendo que o que acontece é simplesmente inverter a posição dos pontos dos paths, como se inverte uma ds_list (uma vez, eu comecei uma discussão de como realmente funcionam os paths, tenho algumas teorias, mas nunca testei nada, efetivamente).
No caso do jogo, acredito que path_speed dificilmente será maior que 1. Dessa forma, usar path_position-=path_speed no path_end event foi uma forma que eu tentei usar pra saber que, no próximo step, o path terminaria DE NOVO. E teria dado certo, se o carro não travasse e chegasse de novo no final do path. Mas ele fica paradinho, com path_speed positivo (e aumentando) e path_index diferente de noone. É como se ele não estivesse num path ou se o path tivesse sido deletado, mas isso sim, daria erro.

saim escreveu:Acho que não vai dar um valor negativo se usar path_reverse, porque eu uso o path_reverse constantemente durante o jogo e path_speed só aumenta.

Tem razão mesmo! Fui testar aqui agora e o que inverte o path_speed é aquela action "set path -> at end -> reverse". path_reverse não inverte o speed. Mas é estranho, ele nem faz um "mirror". Pelo que dá pra ver ele só troca qual é o ponto de origem, mantendo o local absoluto do path.

Mas ele fica paradinho, com path_speed positivo (e aumentando) e path_index diferente de noone. É como se ele não estivesse num path ou se o path tivesse sido deletado, mas isso sim, daria erro.

Já que o path_reverse não inverte a velocidade, justifica o fato dele ficar parado. Se fosse negativa ele teria que fazer o caminho de volta. Mas talvez isso dê até uma ideia do que possa ser...

Vamos supor que você esteja definindo a image_angle pela direção entre o ponto anterior no path e o ponto atual. Numa remota possibilidade do carro porventura pegar a mesma pista em que já estava, ele não a deletaria e ficaria parado no final dela. E também justificaria o fato dele encontrar ela mesma se o ângulo fosse "0" (já que ele não se move) onde deveria ser "90" ou "270", pois ele verificaria o ponto da instance_position no lugar errado.

Poderia ser isso?

Falou!

Poderia sim! Droga, deve ser isso mesmo! Quando eu começo o path, eu mando ele começar o path, o "endaction" é 0 (stop). Eu confiava que o instance_position jamais errasse.
Na verdade, eu lembro de estar receoso ao implementar o código - apenas um pixel à frente num ângulo que não é precisamente um múltiplo de 90 poderia dar problema - mas como o erro não aconteceu (pelo menos com frequência), eu fiquei tranquilo.
Mais que isso, fiz um teste e mandei um objeto começar o path "20" num jogo que não tem path nenhum, o bicho não viu problema nenhum naquilo. Eu esperava que ele apresentasse um erro, mas não, ficou tranquilão, parado.

, refazer a engine de "saber pra onde ir" vai ser osso, mas realmente ele ter chegado ao final do path e parado é uma explicação que se aplica perfeitamente ao bug. Ele não está nem na pista anterior nem na próxima, simplesmente cumpriu sua tarefa e parou.

Mas eu já tenho uma boa idéia de um método infalível: baseado na posição do carro em relação à borda da pista atual e na posição da pista atual em relação à grid, eu posso saber qual posição da grid o carro está chegando. Aí, volto pra engine normal, verificando se tem uma pista lá, se a pista está virada pro lado certo, o diabo.

A princípio, o problema está resolvido e a moderação pode trancar o tópico. Vai demorar pra eu testar e saber se realmente o problema é esse, mas deve ser. Não tem sentido manter o tópico aberto. Se for o caso, eu entro em contato e peço pra reabrirem.

MUITO obrigado!

Edit: Update: Nem foi tão difícil assim. O código ficou um pouco maior, mas ainda deu pra usar o instance_position, só que dessa vez eu uso a posição da pista com relação à grid, e não ao carro. O que eu fiz foi substituir a linha "objeto = instance_position(x + lengthdir_x(1, image_angle), y + lengthdir_y(1, image_angle), objParentPath);" por [code]var saida, XCelula, YCelula;
XCelula = objetoVelho . x; YCelula = objetoVelho . y;
if (x = objetoVelho . bbox_left) { saida = 180; }
if (y = objetoVelho . bbox_bottom + 1) { saida = 270; }
if (x = objetoVelho . bbox_right + 1) { saida = 0; }
if (y = objetoVelho . bbox_top) { saida = 90; }
objeto = instance_position(XCelula + lengthdir_x(grid, saida), YCelula + lengthdir_y(grid, saida), objParentPath); //o pedaço logo adiante[code]onde "grid" é o tamanho das células. Isso evita a necessidade de perguntar pra onde o carro está apontando e DEVE eliminar o bug . Caso contrário, volto a postar aqui...

Edit2: Não... ainda consigo metralhar a próxima pista e reproduzir o erro... Acredito que, agora, não exista mais o risco no novo "objeto" ser a pista em que o carro está. Pra não soltar um palavrão, vou dizer que isso está me deixando muito frustrado.

Consegui simular! É estranho por dois motivos. Primeiro: não deveria ser possível destruir a nova pista, pois como você falou, ele deveria travar a destruição dela. Mas não está travando. Consigo destruí-la mesmo depois do "bug".

E segundo porque, depois do "end of path" não deveria haver mais nenhum path associado, mas como você falou que o path_index é diferente de noone, ele só poderia estar mesmo no path da pista anterior.

Nesse ponto, o evento "end of path" já aconteceu e o carro vai ficar sem ação. A impressão que dá é que ainda tem haver com esse "não travamento" da pista, porque o que desencadeia tudo isso é justamente o clique.

Joguei várias vezes aqui, com várias mudanças nas pistas, e sem o clique no momento certo não dá problema. Até daria pra "remendar" o código e eliminar o bug, comparando path_position com path_positionprevious. Se forem iguais, game over. Mas eu também acho que não é o melhor caminho pra resolver.

Isso eu já tenho como certo: O carro ainda está no path da pista anterior, mesmo ele tendo sido destruído. Fiz um teste que manda um objeto começar um path que não existe (coloquei um número inteiro como argumento, ao invés de um path) e o objeto topou. Ficou parado, como se o path inexistente fosse um path de um ponto.
Então não resta dúvida, ele ainda está percorrendo o path_index da pista anterior, que não existe mais.

Agora precisamos descobrir PORQUE o clique no step certo possibilita o bug. Se conseguíssemos descobrir qual step é esse (pode ser o imediatamente anterior à mudança de pista, o mesmo step da mudança de pista ou o imediatamente posterior), isso reduziria o número de variáveis a considerar.

Vou manter esse remendo em mente, pro caso de não conseguirmos resolver, mas ele pode gerar outro problema: a velocidade é muito baixa em alguns momentos do jogo, e os paths muito pequenos. Não sei se é nula a possibilidade de um arredontamento retornar path_position==path_positionprevious.

Demorei um bocado pra voltar a postar, né?
Bom, finalmente coloquei o editável no dropbox!
Eis o link.
Espero que com isso vocês consigam encontrar o problema. Se precisar de qualquer explicação, claro que me disponho a fornecer (desde que eu me lembre do que se trata...).