這就是我們處理 Construct 3 和 Construct Animate 公開錯誤報告提交的地方。
不幸的是,許多用戶提交的錯誤是無用的,因為它們沒有包含足夠的資訊供我們對其採取任何措施。我們的政策是在不進行調查的情況下關閉這些錯誤。請遵循這些準則,以避免您的錯誤被關閉,並協助確保我們可以修復您報告的錯誤。
大多數錯誤實際上並不明顯,即使它們對您來說看起來很明顯。通常,問題實際上只發生在您碰巧遇到的一組非常特定的情況下。這些指南旨在確保我們能夠弄清楚發生了什麼事。因此,請永遠不要跳過指南的任何部分,無論您認為問題有多明顯,或者您之前提交了多少問題 - 我們每次都確實需要所有這些信息,跳過任何細節可能會讓事情變得更加困難讓我們幫助您。
許多錯誤報告實際上只是事件中的錯誤,或是對功能的誤解。請仔細檢查您的活動和文件。
為了避免報告我們已經修復的錯誤,請驗證問題是否發生在最新版本的 Construct 中,包括最新的測試版。
如果某些東西曾經可以工作,但被更新意外破壞,那麼告訴我們它破壞的是哪個版本是非常有用的。例如,如果某些內容在 r300 之前的所有版本中都有效,但在 r301 以後的所有版本中都被破壞,那麼請輸入 r301 作為第一個受影響的版本。 (請不要只輸入您碰巧測試的版本,因為這會產生誤導,並且可能會花費更長的時間來處理問題。)
Bug 提交頁面預先填入了一個範本。不要刪除它 -我們需要所有這些資訊才能為您提供幫助。請提供盡可能多的所需信息,包括每個報告中的系統詳細信息或崩潰報告信息。每次都提供完整的資訊 - 不要引用其他問題、其他地方的論壇帖子等,因此報告本身包含所有必要的資訊。
請在您建立的每一期中僅描述一個問題。同時擁有兩個單獨的描述是非常令人困惑的,通常意味著您跳過了其中一個的一些重要資訊。此外,我們還有有用的工具來分配和追蹤問題,但這些工具僅在問題涉及單一問題時才有效。
請盡可能包含一個演示該問題的最小項目。如果您不包含項目,即使您提供了書面描述或認為問題很明顯,您的報告很可能會在沒有調查的情況下關閉。這是因為如果沒有專案文件,我們幾乎總是發現一切都正常工作。通常,您的專案的某些特定因素實際上導致了問題,如果沒有它,就不可能提供幫助。因此需要附加一個項目。
專案應該盡可能小,使用盡可能少的事件和物件來演示問題。建立一個新的空項目並嘗試從頭開始重現問題。或備份您的項目並儘可能刪除,直到問題解決為止。請繼續,盡可能刪除任何不相關的物件、事件、佈局等。
不要在您的專案中使用第三方外掛程式。不幸的是,我們無法為第三方程式碼提供支援。第三方插件中的錯誤應報告給其開發人員。我們要求刪除第三方插件以證明它們不會造成問題。
請儲存單一文件項目。它們的檔案副檔名為.c3p
您可以透過選擇Menu -> Project -> Save As -> Download a copy來儲存這樣的項目。
.c3p 檔案可以在 Dropbox、OneDrive 或 Google Drive 等免費文件託管服務上公開分享。或者,如果將檔案新增至 zip,或將 .c3p 副檔名重新命名為 .zip,則可以將其附加到 GitHub 問題。 (GitHub 不會接受以 .c3p 結尾的文件。此外,如果它實際上是 .c3p 文件,Construct 仍然可以直接從 zip 開啟專案。)
如果您選擇不同的文件主機,並且它向我們發送廣告垃圾郵件,要求我們註冊或輸入訊息,或者在我們查看它時過期,我們將不會調查該錯誤。我們推薦前面提到的三種服務,因為它們效果很好。
我們處理了數千份報告,其中許多都是難題。為了幫助我們快速有效地處理您的問題,最好提供一個演示該問題的項目,該項目:
用戶通常會附上帶有錯誤報告的影片。這並不總是像您想像的那麼有用:我們無法調試影片來弄清楚發生了什麼。附加項目要有用得多。此外,具有簡短且編寫良好的重現步驟的報告通常可以更快地處理,考慮到我們要處理數千份報告,這一點很重要。
一般來說,除非我們要求,否則您可以跳過附加影片。如果我們在從書面步驟重現問題時遇到困難,它們會很有幫助,因為我們可以準確地觀察您在做什麼。如果您不介意節省時間,可以附上影片和書面步驟以供複製,以防萬一我們需要。
使用像 Construct 這樣的複雜軟體,可以創建故意模糊的項目,或故意模糊的步驟序列,這可能會產生意外的結果甚至崩潰。但是,如果沒有人以正常方式使用 Construct 遇到此類問題,那麼它們與 Construct 的實際使用沒有任何關係。我們致力於開發客戶可以信賴的強大、優質的軟體。然而我們發現解決這些問題基本上是浪費時間,而且實際上會降低建造的質量,因為每次更改都有導致其他問題的風險。因此,雖然理論上「以防萬一」報告此類問題是有用的,但實際上卻並非如此。我們是一個資源有限的小團隊,我們希望將有限的時間集中在支援人們使用 Construct 實現實際目的,而不是處理與客戶無關的困難且耗時的問題。因此,如果我們認為報告涉及故意尋找問題,或不代表 Construct 的實際使用,有時我們可能會關閉問題而不修復它們。
我們的員工隨時為您提供協助。我們擁有經驗豐富的工程師,他們處理過數千個錯誤報告。絕大多數記者都很樂於助人,並且很高興與我們合作。但是,如果您在與員工打交道時不合作或不必要地好鬥,我們將關閉您的報告並停止調查。如果有人按照準則提交報告,我們將恢復對該報告的調查。有關更多詳細信息,請參閱論壇和社區指南,該指南也適用於錯誤報告。
以下是錯誤回報過程中常見問題或疑慮的解答。這些確實經常被問到,所以值得一看。
您需要遵循本文中的所有準則,以便開發人員實際上有合理的機會來診斷並修復您嘗試報告的問題。我們收到了數千份錯誤報告,處理它們可能非常耗時。為了節省開發人員的時間,以便他們可以花更多的時間編寫新的、令人興奮的功能,並節省您的時間,這樣您就不會編寫對開發人員無用的無用報告,這些指南是強制性的,並且報告不遵循它們未經調查將被關閉。
請不要生氣;我們處理大量的錯誤報告,我們的目標是盡可能有效地處理它們。我們希望確保您養成提交有用、詳細、可操作的錯誤報告的習慣,我們可以快速診斷和修復這些錯誤報告。這對您也有好處,因為您更有可能更快地修復錯誤。因此,您學會在每個錯誤報告中盡可能遵循指南,這符合每個人的利益。我們可能會毫不客氣地說,未經調查就關閉了,但這可能是那天的幾個之一,我們想強調您需要如何幫助我們幫助您。
請不要回覆已關閉的錯誤報告。相反,請提交一份新報告,並確保遵循所有準則並提供任何缺失的資訊。
不,我們不想要你的整個專案。將您的整個專案發送給我們通常實際上沒有幫助。該指南要求一個最小的項目,其中包含盡可能少的事件和物件。最好能夠透過建立新的空項目並添加最少的事件和物件來顯示正在發生的情況來演示問題。這是開發人員診斷問題的唯一實用方法。具有數百甚至數千個事件或物件的項目對於測試來說是一場噩夢,因為引擎中發生了太多事情,幾乎不可能隔離哪個部分可能出現問題。此外,很大一部分錯誤報告只是事件中的錯誤,而不是真正的錯誤。花費數小時甚至數天的時間調試一個大型項目,卻發現它是事件中的一個錯誤,這對我們的開發人員來說成本太高,尤其是當我們是一個小團隊時。每個人都希望開發人員重新開始編寫新的、令人興奮的功能!一般來說,如果您無法在新的空項目中重現該問題,則這是一個強烈的信號,這實際上只是您的事件中的一個錯誤,因此這是從錯誤報告中過濾掉錯誤的好方法。
在您的最小項目中,您還可以輕鬆使用佔位符圖形而不是實際的藝術品。這也消除了對版權或必須簽署保密協議的任何擔憂。因此,這對您和開發人員都更好。
這是一個強烈的跡象,很可能是您自己的事件中出現了錯誤。首先,仔細檢查您的事件並確保它們正常運作。其次,開始隔離問題。備份您的項目並開始刪除其中的大部分內容。在某些時候,問題可能會消失,這表明原因在於您刪除的最後一個內容。在這種情況下,請返回並開始移除較小的部件,依此類推,直到您能夠準確識別導致該問題的原因。如果它看起來像一個錯誤,請以此為起點在新的空專案中示範該錯誤。如果在刪除內容時問題沒有消失,那麼您應該能夠刪除所有內容,直到最小的項目,沒有不必要的事件或物件。如果您確定問題是錯誤,而不是對事件的錯誤或誤解,那麼您可以在錯誤報告中提交該項目。
我們確實會查看每一份報告,但開發人員和發佈時間表意味著我們可能無法立即處理它。請允許幾週時間進行調查。如果您在等待,當開發人員確實抽出時間來解決問題時,您可以透過仔細查看這些指南並提供盡可能多的有關問題的有用資訊來提高解決問題的機會。如果您遺漏了任何內容,您可能會等待幾週才能得到答复,只是詢問遺漏的信息,然後您將再次等待。
有些錯誤可能實際上是瀏覽器或平台中的錯誤,而不是 Construct 的問題。這包括瀏覽器本身崩潰或出現“悲傷選項卡”的任何問題(選項卡將其內容替換為一條訊息,表示遇到問題或崩潰,您必須重新加載它) - Construct 的程式碼通常不會導致此問題,只會導致問題與瀏覽器本身。您可能會被要求直接向瀏覽器製造商報告問題。以下是報告瀏覽器問題的連結:
Chromium(Android 上的 Google Chrome、Microsoft Edge、NW.js、Cordova):crbug.com
Safari(Mac、iOS、iOS 上的 Cordova):WebKit Bugzilla
火狐:Mozilla Bugzilla
NW.js(僅在 NW.js 中發生的問題,而不是其他基於 Chromium 的平台中發生的問題):NW.js 問題
感謝您閱讀我們的指南!您可以透過訪問問題部分開始。