Construct bugs
1.0.0
Aquí es donde manejamos los envíos públicos de informes de errores para Construct 3 y Construct Animate.
Desafortunadamente, muchos usuarios reportan errores que son inútiles porque no contienen suficiente información para que podamos hacer algo al respecto. Nuestra política es cerrar estos errores sin investigarlos. Siga estas pautas para evitar que se cierre su error y ayudar a asegurarnos de que podamos corregir el error que está informando.
La mayoría de los errores no son realmente obvios, incluso si a usted le parecen obvios. A menudo, los problemas en realidad sólo ocurren en un conjunto de circunstancias muy específicas, que usted tiene. Estas pautas están diseñadas para garantizar que podamos descubrir qué está pasando. Por lo tanto, nunca omita ninguna parte de las pautas, sin importar cuán obvio crea que es el problema o cuántas incidencias haya presentado antes; realmente necesitamos toda esta información en todo momento, y omitir cualquier detalle probablemente hará que todo sea mucho más difícil. para que te ayudemos.
Muchos informes de errores son en realidad errores en eventos o características mal entendidas. Por favor revise sus eventos y la documentación.
Para evitar informar errores que ya hemos solucionado, verifique que el problema ocurra en la última versión de Construct, incluida la última versión beta.
Si algo solía funcionar pero se rompió accidentalmente debido a una actualización, es muy útil decirnos en qué versión se rompió. Para esto está el campo Primera versión afectada de la plantilla de informe de error. Por ejemplo, si algo funcionó en todas las versiones hasta la r300 y luego se rompió en todas las versiones desde la r301 en adelante, ingrese r301 como la primera versión afectada. (No ingrese simplemente la versión que probó, ya que esto es engañoso y podría demorar más en solucionar el problema).
La página de envío de errores está precargada con una plantilla. No lo elimines: necesitamos toda esta información para poder ayudarte. Proporcione toda la información solicitada que pueda, incluidos los detalles del sistema o la información del informe de fallas con cada informe. Proporcione esta información completa cada vez; no haga referencia a otros problemas, publicaciones en foros en otros lugares, etc., para que el informe incluya toda la información necesaria por sí solo.
Describa solo un problema en cada problema que cree. Es muy confuso tener dos descripciones separadas a la vez y generalmente significa que te saltaste información importante para una de ellas. Además, contamos con herramientas útiles para asignar y rastrear problemas, pero estas solo son efectivas si un problema se refiere a un solo problema.
Siempre que sea posible, incluya un proyecto mínimo que demuestre el problema. Si no incluye un proyecto, lo más probable es que su informe se cierre sin investigación, incluso si proporcionó una descripción escrita o cree que el problema es obvio. Esto se debe a que sin un archivo de proyecto, casi siempre encontramos que todo funciona bien. Por lo general, hay algo específico de su proyecto que realmente causa el problema y es imposible ayudar sin él. Por lo tanto es necesario adjuntar un proyecto.
El proyecto debe ser lo más mínimo posible, utilizando la menor cantidad de eventos y objetos posibles para demostrar el problema. Cree un nuevo proyecto vacío e intente reproducir el problema desde cero. Alternativamente, haga una copia de seguridad de su proyecto y elimine tanto como sea posible hasta que se aísle el problema. Continúe tanto como pueda eliminando objetos, eventos, diseños, etc. no relacionados.
No utilice complementos de terceros en su proyecto. Lamentablemente, no podemos brindar soporte para códigos de terceros. Los errores en complementos de terceros deben informarse a sus desarrolladores. Requerimos que se eliminen los complementos de terceros para demostrar que no están causando el problema.
Guarde un proyecto de un solo archivo. Estos tienen la extensión de archivo .c3p
Puede guardar un proyecto como este eligiendo Menú -> Proyecto -> Guardar como -> Descargar una copia .
El archivo .c3p se puede compartir públicamente en servicios de alojamiento de archivos gratuitos como Dropbox, OneDrive o Google Drive. Alternativamente, si agrega el archivo a un zip o cambia el nombre de la extensión .c3p a .zip, se puede adjuntar al problema de GitHub. (GitHub no aceptará un archivo que termine en .c3p. Además, Construct aún puede abrir proyectos directamente desde un zip si en realidad es un archivo .c3p).
Si elige un servidor de archivos diferente y nos envía spam con anuncios, nos pide que nos registremos o ingresemos información, o caduca cuando lo miramos, no investigaremos el error. Recomendamos los tres servicios mencionados anteriormente ya que funcionan bien.
Nos ocupamos de miles de informes y muchos de ellos son problemas difíciles. Para ayudarnos a solucionar su problema de forma rápida y eficaz, lo ideal es proporcionar un proyecto que demuestre el problema que:
A menudo los usuarios adjuntan vídeos con informes de errores. Esto no siempre es tan útil como podría pensar: no podemos depurar vídeos para descubrir qué está pasando. Adjuntar un proyecto es mucho más útil. Además, los informes con pasos breves y bien escritos para reproducir suelen ser más rápidos de procesar, lo cual es importante dado que tratamos con miles de informes.
En general, probablemente puedas omitir adjuntar un video a menos que te lo solicitemos. Pueden ser útiles si tenemos problemas para reproducir el problema a partir de los pasos escritos para reproducir, ya que podemos observar exactamente lo que estás haciendo. Si no le importa dedicar tiempo, puede adjuntar un vídeo junto con los pasos escritos para reproducirlo en caso de que lo necesitemos.
Con una pieza de software compleja como Construct, es posible crear proyectos deliberadamente oscuros, o secuencias de pasos intencionalmente oscuras, que pueden producir resultados inesperados o incluso fallas. Sin embargo, si nadie que usa Construct de manera normal encuentra tales problemas, entonces no tienen relevancia para el uso de Construct en el mundo real. Estamos comprometidos a desarrollar software sólido y de calidad en el que los clientes puedan confiar. Sin embargo, hemos descubierto que solucionar estos problemas es básicamente una pérdida de tiempo y, de hecho, puede degradar la calidad de Construct, ya que cada cambio conlleva el riesgo de causar otros problemas. Entonces, si bien en teoría es útil informar estos problemas "por si acaso" alguien se topa con ellos, en la práctica no lo es. Somos un equipo pequeño con recursos limitados y queremos centrar nuestro tiempo limitado en ayudar a las personas que utilizan Construct para fines del mundo real, en lugar de lidiar con problemas difíciles y que requieren mucho tiempo y que son irrelevantes para los clientes. Por lo tanto, a veces podemos cerrar problemas sin solucionarlos si creemos que el informe implicó una búsqueda deliberada de problemas o si no representa un uso realista de Construct.
Nuestro personal está aquí para ayudarle. Contamos con ingenieros experimentados que se han ocupado de miles de informes de errores. La gran mayoría de los periodistas son útiles y están felices de trabajar con nosotros. Sin embargo, si no coopera o es innecesariamente combativo al tratar con el personal, cerraremos su informe y dejaremos de investigarlo. Reanudaremos la investigación del informe si alguien lo presenta cumpliendo con las pautas. Para obtener más detalles, consulte las pautas del foro y la comunidad, que también se aplican a los informes de errores.
Aquí encontrará respuestas a preguntas o inquietudes comunes durante el proceso de informe de errores. Realmente se preguntan con frecuencia, por lo que vale la pena echarle un vistazo.
Debe seguir todas las pautas de esta publicación para que los desarrolladores tengan una posibilidad razonable de poder diagnosticar y solucionar el problema que está intentando informar. Recibimos literalmente miles de informes de errores y solucionarlos puede llevar mucho tiempo. Para ahorrar tiempo a los desarrolladores para que puedan dedicar más tiempo a escribir funciones nuevas e interesantes, y para ahorrarle tiempo a usted y no escribir informes inútiles que no son útiles para los desarrolladores, estas pautas son obligatorias y los informes no las siguen. se cerrará sin investigación.
Por favor, no se ofenda; Nos ocupamos de un gran número de informes de errores y nuestro objetivo es tratarlos de la forma más eficiente posible. Queremos asegurarnos de que adquiera el hábito de presentar informes de errores útiles, detallados y procesables que podamos diagnosticar y corregir rápidamente. Esto también le beneficia a usted, ya que es más probable que solucione el error antes. Por lo tanto, es de interés para todos que aprenda a seguir las pautas en la mayor medida posible para cada informe de error. Podemos decir sin ceremonias que está cerrado sin investigación, pero probablemente sea uno de varios ese día, y queremos resaltar cómo usted necesita ayudarnos a ayudarlo.
No responda a informes de errores cerrados. En su lugar, presente un nuevo informe y asegúrese de seguir todas las pautas y proporcionar la información faltante.
No, no queremos todo tu proyecto. Enviarnos su proyecto completo generalmente no es útil. Las pautas requieren un proyecto mínimo con la menor cantidad de eventos y objetos posibles. Preferiblemente, podrá demostrar el problema creando un nuevo proyecto vacío y agregando los eventos y objetos mínimos para mostrar lo que está sucediendo. Esta es la única forma práctica que tienen los desarrolladores de diagnosticar el problema. Es una pesadilla probar proyectos con cientos o incluso miles de eventos u objetos porque suceden muchas cosas en el motor y es casi imposible aislar qué parte está potencialmente fallando. Además, una proporción muy significativa de los informes de errores son simplemente errores en eventos y no errores en realidad. Pasar horas o incluso días depurando un gran proyecto sólo para descubrir que fue un error en los eventos es simplemente demasiado costoso para nuestro tiempo de desarrollador, especialmente porque somos un equipo pequeño. ¡Todos quieren que los desarrolladores vuelvan a escribir funciones nuevas y emocionantes! Generalmente, si no puede reproducir el problema en un nuevo proyecto vacío, es una fuerte señal de que en realidad es solo un error en sus eventos, por lo que esta es una buena manera de filtrar errores de los informes de errores.
En su proyecto minimalista también puede utilizar fácilmente gráficos de marcador de posición en lugar de su obra de arte real. Esto también elimina cualquier preocupación sobre los derechos de autor o la necesidad de firmar acuerdos de confidencialidad. Entonces es mejor tanto para usted como para los desarrolladores.
Esta es una fuerte señal de que lo más probable es que se trate de un error en sus propios eventos. En primer lugar, revise cuidadosamente sus eventos y asegúrese de que estén funcionando correctamente. En segundo lugar, comience a aislar el problema. Haga una copia de seguridad de su proyecto y comience a eliminar partes del mismo. En algún momento el problema puede desaparecer, lo que indica que la causa estuvo en lo último que eliminó. En este caso, regresa y comienza a quitar las piezas más pequeñas, y así sucesivamente hasta que puedas identificar exactamente qué lo está causando. Si parece un error, utilícelo como punto de partida para demostrar el error en un nuevo proyecto vacío. Si el problema no desaparece mientras elimina el contenido, debería poder eliminar todo hasta un proyecto mínimo sin eventos u objetos innecesarios. Si está seguro de que el problema es un error y no un error o una mala comprensión de los eventos, puede enviar este proyecto en un informe de error.
Analizamos todos los informes, pero los calendarios de lanzamiento y desarrollo significan que es posible que no podamos abordarlo de inmediato. Espere unas semanas para que se investigue. Si está esperando, puede mejorar las posibilidades de que se resuelva cuando un desarrollador lo solucione revisando cuidadosamente estas pautas y brindando tanta información útil sobre el problema como sea posible. Si le falta algo, puede terminar esperando algunas semanas para recibir una respuesta simplemente solicitando la información que falta, y luego volver a esperar.
Algunos errores pueden concluir como errores en el navegador o la plataforma, en lugar de ser un problema con Construct. Esto incluye cualquier problema en el que el navegador falla o muestra una "pestaña triste" (donde la pestaña reemplaza su contenido con un mensaje que dice que encontró un problema o falló y que debe volver a cargarlo). El código de Construct normalmente no puede causar esto, solo problemas. con el propio navegador. Es posible que se le solicite que informe el problema directamente al fabricante del navegador. Aquí están los enlaces para informar problemas en los navegadores:
Chromium (Google Chrome, Microsoft Edge, NW.js, Cordova en Android): crbug.com
Safari (Mac, iOS, Cordova en iOS): WebKit Bugzilla
Firefox: Mozilla Bugzilla
NW.js (problemas que ocurren solo en NW.js, y no en otras plataformas basadas en Chromium): problemas de NW.js
¡Gracias por leer nuestras pautas! Puede comenzar visitando la sección Problemas.
