SWGEmu Project Status List
The SWGEMu Staff
How Can We Help?
Please help us iron out any bugs and missing features. Also test everything in the implemented list above.- Use your forums username/password to sign in to Mantis.
- You can keep up to date and see progress at Gerrit Code Review.
Bug Reporting Guide
thanks to Serpentkaa, Nebula, and Jimer
Who? We need you!
What? Try to break things! Bugs are errors, glitches, faults, strange defects, unintended behavior, typos, inconsistancies, inaccuracies, not working as intended, not true to Pre-CU, broken features, and crashes after being in game. Focus on the testing tasks given above and ignore unimplemented features or known issues. Rather than recalling from memory, try to use Biophilia’s scrapbook, archived SOE forums, or other sources as reference. Don’t confuse bug reports with needing in game support, such as being stuck in the air, or LPE help. If you file such a request using Mantis, your issue will probably remain unresolved. Instead /join #swgemusupport in IRC to receive live assistance from our Support Team and GM’s.
Why? Reporting bugs will help get us closer to finishing the OR and on to Suncrusher.
When? Try to report your bugs as soon as you discover them so that they are fresh in your mind.
Where? Please report all bugs on Mantis. Check to make sure that bug hasn’t already been reported by using the search feature.
How? QA reads through all player reports for verification and reproducibility, then assigns to developers. If we can’t understand what you’re saying, nothing can be done about the bug and the developers won’t have enough information to fix the issue. Developers often get frustrated because the player doesn't always realize what is needed in order to find and fix the bug, and so the report is incomplete or not useful. This means the bug probably won't get fixed or won't get fixed to the player's satisfaction. Then the player is left wondering why the developer didn't fix the problem. To prevent this from happening, follow the guidelines below.
Use proper grammar and spelling. Be exact when naming items and errors. Don’t just say “this doesn’t work” or “that is still broken”. Write a step by step set of events leading up to the bug. We must be able to reliably reproduce a bug based on your instructions. Is it game breaking such as an exploit or minor such as NPC dialogue? Actions intended to break, bend or in anyway alter the SWGEmu gameplay experience in favor of one player or against another player is considered an exploit. Is it repeatable? Are there workarounds? Include your planet and waypoint. Screenshots, crash dumps, and sources are extremely helpful. Leave personal comments out, we don’t need to hear about you “getting soaked in a Rori downpour”. If your bug has already been reported by someone or if you come across one you are familiar with, feel free to add notes to their report. Don’t be rude or inflammatory. Don’t demand that the problem be fixed or threaten to quit the game (if you’re doing that, you really should just quit now).
How are categories assigned?
Code:
Category Assign To
Banking and Commerce QA-World
Bazaar and Vendors QA-World
Cave, POI, Instance QA-World
Character QA-World
Containers and Storage QA-World
Crafting QA-Crafting
Exploits QA-World
Faction and GCW QA-World
Game Crashing QA-World
Mail and Chat QA-World
Missions QA-World
NPC, Creatures and Lairs QA-World
Other QA-World
Professions - Artisan Line QA-Crafting
Professions - Brawler Line QA-Combat
Professions - Entertainer Line QA-Medoutainer
Professions - Force Sensitive Line QA-Combat
Professions - Marksman Line QA-Combat
Professions - Medic Line QA-Medoutainer
Professions - Politician and Player City QA-World
Professions - Scout Line QA-Medoutainer
Resources QA-Crafting
Structures QA-World
Transportation and Vehicles QA-World
Example of a good bug report:
Title: “Schematics made with with exactly 100 items cause factories to disappear (this is an example, not a real bug.)”
Category: Structures
Reproducibility: Always
Severity: Major
Priority: Normal
Assign To: QA-World
Summary: This occurs when you make a schematic for exactly 100 items, no more and no less, and include precisely the amount of resources required to produce the item in the factory's ingredient hopper
Description: If I make a schematic for any item I can craft and put 100 items as the manufacturing limit, when I run the schematic and the factory is done, instead of simply shutting down, my factory vanishes.
Steps To Reproduce:
(assumes you're a Master Tailor, and using a Clothing and Armor Crafting tool. I used a +42.15 crafting station, located in Lok, -3223 1293)- Craft a schematic for any item (for example, reinforced fiber panel).
- Set the manufacturing limit to exactly 100 on the schematic.
- Use the schematic in a Wearables Factory. (in my case, the factory had about 10 days' worth of maintenance and 7 days worth of power)
- Place exactly the amount of resources required in the ingredient hopper to produce the item. Using more or less than is required will not reproduce the bug.
- When the schematic is completed, the factory will vanish.
Additional Information: I have verified that this occurs with any item I can make. If I make it for less than 100 or more than 100, the factory operates normally and no problems occur. Also, if I put more resources than is required to make 100 items, a schematic with exactly 100 items on its limit works normally. I do not receive an email stating that the schematic has run out.
Attached Files: [screenshots of factory running and hoppers]
This bug report is well written and provides all the necessary information for QA or a developer to diagnose the bug, or at the very least provides the info necessary for them to start digging. This player searched Mantis for any previous reports on the issue before submitting his own.
Example of a poor bug report:
Title: “my factory is f’ed up”
Category: Other
Summary: halp it wont make stuff & then disapeerd! DAMMIT SWGEmu YOU Suck! Fix IT NOW! ! if u dno't fix tihs n give me my factory bak, im gunna quit this stupid game!!!
We have to ask a few questions: What exactly is the bug? What steps did the player take? Perhaps this is a new player who doesn’t know that factories run on power and maintenance. Maybe a manufacturing schematic wasn't inserted with the exact resources, identical components with the same serial number, and activated. The player also isn’t aware of the fact that lost items cannot be refunded on the test server. We either ask for feedback or ignore the report entirely.
Which of the two bug reports shown above do you think the developers will pay attention to?
A Guide to Bug Reporting on Mantis by Labyrinth
Search, Search, and Search
Searching Mantis for duplicates of your bug before you report the problem you found is one of the most important things you can do. However, if you’re already thinking, “That’s always a pain,” then you’re not alone. The most effective way to search for a bug is to use relevant Keywords. It is important to note that the more clearly you can define your report, the easier it will be to search for similar issues. If your client crashes when you travel from Coronet Starport to Theed Starport, you might enter the keywords “crash” and “travel” (separated by spaces). If that turns up too many results, you can add the word “starport” or “coronet.”
Note that many search algorithms produce narrower results for higher amounts of keywords. In other words, the more specific you get, the less results you get. The inverse also applies; less keywords and specificity means more results.
Keep in mind
No search technique is perfect and sometimes the bug you want to report really hasn’t been reported yet, so you won’t find anything related to it. However, a little searching goes a long way and if you do find the same issue you discovered, you can add your input as a Note (this is not frowned upon and can help QA in understanding what is happening with a bug) instead of making a unique bug report.
Breaking It Down
Mantis offers a relatively simple interface that will give you the following options upon hitting “Report Issue”:
Category
Category is highly important for documentation. If a QA member or Emu player is searching for a particular bug, or skimming for a certain type, it is much easier to know at a glance what a bug is about by glancing at Category. Choosing the proper category is a quick process: Simply ask yourself what the bug applies to and choose the proper section. If it is an exploit, choose “Exploit.” If it is related to HAM, it fits Character. Think about what Category you would be likely to look under when searching for your own bug.
Reproducibility
Reproducibility allows QA and other testers to quickly assess whether a bug has been reproduced by the user or if it only occurs under difficult-to-pinpoint circumstances. If you have discovered a bug, it is always recommended that you attempt to repeat it before reporting; the less testing required by QA, the more bugs they can cover in a limited time span. The choices are self-explanatory; if you can always reproduce, choose “always,” if you haven’t tried to reproduce it, choose “have not tried,” etc.
Severity
Severity is a good way of allowing QA and developers to assess how important it is that a bug be addressed quickly. If the bug you have discovered causes the server to crash, be sure to choose “crash,” so that the bug will be spotted quickly.
Summary
Summary is your title and possibly the most important part of your report. If the title is not descriptive, it means more time spent reading the description, just to understand what the bug is about. A good title explains the bug as descriptively as possible in few words.
Good title:
My client crashes when I attempt to travel from Coronet Starport to Theed Starport
Poor title:
The game crashed
Description
Description is, essentially, an expansion of the Summary. Explain the bug as it occurred in complete sentences and add examples where necessary. Even with a good title, your report can still be incoherent if the description leaves out relevant details.
Steps to Reproduce
Steps to Reproduce should be as literal as its name. List numbered steps that lead to how the bug occurred:
1) Keep it relevant - if loading your client is not relevant to the bug, don’t include it.
2) Be succinct - if your steps are anything higher than 4, you may be able to shorten them.
3) Be detailed - use a crafting tool is not as clear as “use a Structure and Furniture crafting tool acquired from the blue frog.”
Additional Information
Many times this can be left blank, but it is an excellent place to enter side observations that may not pertain to the description. If crafting a Wrapped Skirt crashed your client, you may want to add here what the color is (if relevant) and whether similar items can be successfully crafted without a crash.
Upload File
As the saying goes, “A picture is worth a thousand words.” This could not be more true for a bug report. If you can acquire a screenshot of the error(s) occurring and upload it as part of your report, it will help immensely when others try to understand what your issue is. QA have many reports to sift through, so the quicker they can understand your problem, the more efficiently they can confirm bugs.
But What About the Other Options?
The following options are (often) unneeded:
Platform, OS, OS Version - an example where these options could be very relevant is in the case of a crash bug, especially one that crashes your client.
Thank you all for your support and help testing, we really appreciate it!
-- The SWGEmu Team
Last Updated: July 31, 2023
Whats Implemented in the SWGEmu Project?
What's New Since the Last Update?
