Construct bugs
1.0.0
É aqui que lidamos com envios públicos de relatórios de bugs para Construct 3 e Construct Animate.
Infelizmente, muitos usuários registram bugs que são inúteis porque não contêm informações suficientes para que possamos fazer algo a respeito. Nossa política é fechar esses bugs sem investigá-los. Siga estas diretrizes para evitar que seu bug seja fechado e ajude a garantir que possamos corrigir o bug que você está relatando.
A maioria dos bugs não são realmente óbvios, mesmo que pareçam óbvios para você. Freqüentemente, os problemas só acontecem em um conjunto muito específico de circunstâncias que você tem. Essas diretrizes foram elaboradas para garantir que possamos descobrir o que está acontecendo. Portanto, por favor, nunca pule nenhuma parte das diretrizes, não importa o quão óbvio você acha que o problema é, ou quantos problemas você já registrou antes - nós realmente precisamos de todas essas informações sempre, e pular quaisquer detalhes provavelmente tornará tudo muito mais difícil. para nós ajudá-lo.
Muitos relatórios de bugs são, na verdade, apenas erros em eventos ou recursos mal compreendidos. Verifique novamente seus eventos e a documentação.
Para evitar relatar bugs que já corrigimos, verifique se o problema ocorre na versão mais recente do Construct, incluindo a versão beta mais recente.
Se algo costumava funcionar, mas foi quebrado acidentalmente por uma atualização, é muito útil nos informar em qual versão ele foi invadido. É para isso que serve o campo Primeira versão afetada do modelo de relatório de bug. Por exemplo, se algo funcionou em todas as versões até r300 e depois quebrou em todas as versões a partir de r301, insira r301 como a primeira versão afetada. (Por favor, não insira apenas a versão que você testou, pois isso é enganoso e pode levar mais tempo para resolver o problema.)
A página de envio de bugs é pré-preenchida com um modelo. Não o exclua - precisamos de todas essas informações para poder ajudá-lo. Forneça o máximo possível das informações solicitadas, incluindo detalhes do sistema ou informações do relatório de falhas em cada relatório. Forneça sempre essas informações completas - não faça referência a outros assuntos, postagens de fóruns em outros lugares, etc., para que o relatório inclua todas as informações necessárias por si só.
Descreva apenas um problema em cada edição que você criar. É muito confuso ter duas descrições separadas ao mesmo tempo e geralmente significa que você pulou algumas informações importantes de uma delas. Além disso, temos ferramentas úteis para atribuir e rastrear problemas, mas elas só serão eficazes se um problema se referir a um único problema.
Sempre que possível, inclua um projeto mínimo demonstrando o problema. Se você não incluir um projeto, seu relatório provavelmente será encerrado sem investigação, mesmo que você tenha fornecido uma descrição por escrito ou pense que o problema é óbvio. Isso ocorre porque sem um arquivo de projeto quase sempre encontramos tudo funcionando bem. Geralmente há algo específico no seu projeto que realmente causa o problema e é impossível ajudar sem isso. Portanto é necessário anexar um projeto.
O projeto deve ser o mínimo possível, utilizando o menor número possível de eventos e objetos para demonstrar o problema. Crie um novo projeto vazio e tente reproduzir o problema do zero. Alternativamente, faça backup do seu projeto e exclua o máximo possível até que o problema seja isolado. Continue o máximo que puder, excluindo quaisquer objetos, eventos, layouts, etc. não relacionados.
Não use complementos de terceiros em seu projeto. Infelizmente não podemos fornecer suporte para código de terceiros. Bugs em complementos de terceiros devem ser relatados aos seus desenvolvedores. Exigimos que os complementos de terceiros sejam removidos para provar que não estão causando o problema.
Salve um projeto de arquivo único. Eles têm a extensão de arquivo .c3p
Você pode salvar um projeto como este escolhendo Menu -> Projeto -> Salvar como -> Baixar uma cópia .
O arquivo .c3p pode ser compartilhado publicamente em serviços gratuitos de hospedagem de arquivos como Dropbox, OneDrive ou Google Drive. Alternativamente, se você adicionar o arquivo a um zip ou renomear a extensão .c3p para .zip, ele poderá ser anexado ao problema do GitHub. (O GitHub não aceitará um arquivo que termine em .c3p. Além disso, o Construct ainda pode abrir projetos diretamente de um zip se for realmente um arquivo .c3p.)
Se você escolher um host de arquivo diferente e ele nos enviar spam com anúncios, solicitar que nos inscrevamos ou inserir informações, ou expirar no momento em que o examinarmos, não investigaremos o bug. Recomendamos os três serviços mencionados anteriormente porque funcionam bem.
Lidamos com milhares de relatórios e muitos são problemas difíceis. Para nos ajudar a lidar com o seu problema de forma rápida e eficaz, é ideal fornecer um projeto demonstrando o problema que:
Freqüentemente, os usuários anexam vídeos com relatórios de bugs. Isso nem sempre é tão útil quanto você imagina: não podemos depurar vídeos para descobrir o que está acontecendo. Anexar um projeto é muito mais útil. Além disso, relatórios com etapas de reprodução curtas e bem escritas costumam ser mais rápidos de lidar, o que é importante visto que lidamos com milhares de relatórios.
Em geral, você provavelmente pode ignorar a anexação de um vídeo, a menos que solicitemos um. Eles podem ser úteis se estivermos tendo problemas para reproduzir o problema a partir das etapas escritas para reprodução, pois podemos observar exatamente o que você está fazendo. Se você não se importa em perder tempo, você pode anexar um vídeo junto com as etapas escritas para reproduzi-lo, caso precisemos.
Com um software complexo como o Construct, pode ser possível criar projetos deliberadamente obscuros ou sequências de etapas intencionalmente obscuras, que podem produzir resultados inesperados ou até travamentos. No entanto, se ninguém que usa o Construct de maneira normal encontrar tais problemas, então eles não terão relevância para o uso do Construct no mundo real. Estamos comprometidos em desenvolver software robusto e de qualidade no qual os clientes possam confiar. No entanto, descobrimos que corrigir esses problemas é basicamente uma perda de tempo e pode, na verdade, degradar a qualidade do Construct, pois cada alteração acarreta o risco de causar outros problemas. Portanto, embora em teoria seja útil relatar tais problemas "apenas no caso" de alguém se deparar com isso, na prática não é. Somos uma equipe pequena com recursos limitados e queremos concentrar nosso tempo limitado no suporte às pessoas que usam o Construct para fins do mundo real, em vez de lidar com problemas difíceis e demorados que são irrelevantes para os clientes. Portanto, às vezes podemos encerrar problemas sem corrigi-los se sentirmos que o relatório envolveu uma busca deliberada de problemas ou, de outra forma, não representa um uso realista do Construct.
Nossa equipe está aqui para ajudá-lo. Temos engenheiros experientes que lidaram com milhares de relatórios de bugs. A grande maioria dos repórteres é prestativa e fica feliz em trabalhar conosco. No entanto, se você não cooperar ou for desnecessariamente combativo ao lidar com a equipe, encerraremos sua denúncia e pararemos de investigá-la. Retomaremos a investigação da denúncia se alguém a apresentar de acordo com as diretrizes. Para mais detalhes, consulte as diretrizes do Fórum e da Comunidade que também se aplicam a relatórios de bugs.
Aqui estão as respostas para perguntas ou preocupações comuns durante o processo de relatório de bugs. Essas perguntas são realmente feitas com frequência, então vale a pena dar uma olhada.
Você precisa seguir todas as diretrizes desta postagem para que os desenvolvedores tenham uma chance razoável de diagnosticar e corrigir o problema que você está tentando relatar. Recebemos literalmente milhares de relatórios de bugs e lidar com eles pode consumir muito tempo. Para economizar o tempo do desenvolvedor para que ele possa gastar mais tempo escrevendo recursos novos e interessantes, e para economizar seu tempo para não escrever relatórios inúteis que não são úteis para os desenvolvedores, estas diretrizes são obrigatórias e os relatórios que não as seguem será fechado sem investigação.
Por favor, não se ofenda; lidamos com um grande número de relatórios de bugs e nosso objetivo é lidar com eles da maneira mais eficiente possível. Queremos garantir que você adquira o hábito de preencher relatórios de bugs úteis, detalhados e acionáveis, que possamos diagnosticar e corrigir rapidamente. Isso também beneficia você, já que é mais provável que seu bug seja corrigido e mais rápido. Portanto, é do interesse de todos que você aprenda a seguir as diretrizes ao máximo possível para cada relatório de bug. Podemos dizer sem cerimônia que ele está fechado sem investigação, mas esse é provavelmente um entre vários naquele dia, e queremos destacar como você precisa nos ajudar a ajudá-lo.
Por favor, não responda a relatórios de bugs fechados. Em vez disso, registre um novo relatório e certifique-se de seguir todas as diretrizes e fornecer todas as informações ausentes.
Não, não queremos todo o seu projeto. Enviar-nos todo o seu projeto geralmente não é realmente útil. As diretrizes exigem um projeto mínimo com o menor número possível de eventos e objetos. De preferência, você poderá demonstrar o problema criando um novo projeto vazio e adicionando eventos e objetos mínimos para mostrar o que está acontecendo. Esta é a única maneira prática para os desenvolvedores diagnosticarem o problema. Projetos com centenas ou até milhares de eventos ou objetos são um pesadelo para testar porque há muita coisa acontecendo no mecanismo e é quase impossível isolar qual parte está potencialmente errada. Além disso, uma proporção muito significativa de relatórios de bugs são simplesmente erros em eventos, e não realmente bugs. Passar horas ou até dias depurando um projeto enorme apenas para descobrir que houve um erro nos eventos é simplesmente muito caro para o tempo do nosso desenvolvedor, especialmente porque somos uma equipe pequena. Todo mundo quer que os desenvolvedores voltem a escrever recursos novos e interessantes! Geralmente, se você não consegue reproduzir o problema em um novo projeto vazio, isso é um forte sinal de que é apenas um erro em seus eventos, então esta é uma boa maneira de filtrar erros de relatórios de bugs.
Em seu projeto mínimo, você também pode usar facilmente gráficos de espaço reservado em vez de sua arte real. Isso também elimina qualquer preocupação com direitos autorais ou com a necessidade de assinar NDAs. Portanto, é melhor para você e para os desenvolvedores.
Este é um forte sinal de que provavelmente é um erro em seus próprios eventos. Em primeiro lugar, analise cuidadosamente os seus eventos e certifique-se de que estão funcionando corretamente. Em segundo lugar, comece a isolar o problema. Faça backup do seu projeto e comece a excluir partes dele. Em algum momento, o problema pode desaparecer, o que indica que a causa estava na última coisa que você excluiu. Nesse caso, volte e comece a remover peças menores e assim por diante até identificar exatamente o que está causando isso. Se parecer um bug, use isso como ponto de partida para demonstrar o bug em um novo projeto vazio. Se o problema não desaparecer enquanto você exclui o conteúdo, você poderá excluir tudo até um projeto mínimo, sem eventos ou objetos desnecessários. Se você tiver certeza de que o problema é um bug e não um erro ou mal-entendido dos eventos, você poderá enviar este projeto em um relatório de bug.
Analisamos todos os relatórios, mas os cronogramas de desenvolvimento e lançamento significam que talvez não possamos fazer isso imediatamente. Por favor, aguarde algumas semanas para que isso seja investigado. Se você estiver esperando, poderá aumentar a chance de o problema ser resolvido quando um desenvolvedor resolver o problema, revisando cuidadosamente essas diretrizes e fornecendo o máximo possível de informações úteis sobre o problema. Se estiver faltando alguma coisa, você pode acabar esperando algumas semanas por uma resposta, simplesmente pedindo as informações que faltam, e então voltar a esperar.
Alguns bugs podem ser considerados bugs no navegador ou na plataforma, em vez de serem um problema do Construct. Isso inclui qualquer problema em que o próprio navegador trava ou faz uma "guia triste" (onde a aba substitui seu conteúdo por uma mensagem dizendo que encontrou um problema ou travou e você precisa recarregá-lo) - O código do Construct normalmente não pode causar isso, apenas problemas com o próprio navegador. Você pode ser solicitado a relatar o problema diretamente ao fabricante do navegador. Aqui estão os links para relatar problemas nos navegadores:
Chromium (Google Chrome, Microsoft Edge, NW.js, Cordova no Android): crbug.com
Safari (Mac, iOS, Cordova no iOS): WebKit Bugzilla
Raposa de fogo: Mozilla Bugzilla
NW.js (problemas que ocorrem apenas em NW.js, e não em outras plataformas baseadas em Chromium): problemas de NW.js
Obrigado por ler nossas diretrizes! Você pode começar visitando a seção Problemas.
