|
|
|||||||
| Announcements Major Project Announcements |
 |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
09-30-2010, 07:43 PM
|
|||||||||
|
|||||||||
|
SWGEmu Project Status List
SWGEmu Project Status List Development  Last Updated: December 17, 2010 What’s Implemented in the SWGEmu Project?Green - Feature has been implemented and is usable (may require fine tuning). Orange - Feature has been partially implemented and is mostly usable (requires fine tuning). Red - Feature is currently in the planning or development stage. A. Preliminary Features Character Communication, Transportation, and Messaging Economy Missions and Quests Buffs B. Combat Features
C. Crafting Features Resources Crafting D. Database
E. Housing, Installations, and Cities Housing Structures Cities F. Professions
G. Miscellaneous
 What's New Since the Last Update?[Date of change] [Description of change] October 5 - Vehicles added to blue frogs October 6 - Vehicles were taken off the blue frogs and can be crafted October 11 - City rank and advancement, /grantzoningrights October 12 - City militia, /cityban, /citypardon October 25 - Food and drinks added to blue frogs October 31 - Musician, /bandflourish, /startMusic, /changeMusic, /listen, /stoplisten, Nalargon and Ommni Box added to blue frogs November 1 - Stat migration in tutorial November 4 - Guild creation, sponsoring, accepting, kicking, and disbanding November 5 - Guild chat November 19 - /transferstructure November 21 - Signs, structure terminals added for remaining city buildings November 23 - In game Mantis bug reporting (disabled temporarily), bank terminals added in NPC cities December 17 - Line of sight Last edited by xavia; 01-03-2011 at 04:36 PM. |
|
#2
09-30-2010, 07:43 PM
|
||||
|
||||
|
SWGEmu Project Status List Development  How Can We Help?Quote:
Stat Migration in Tutorial Food and Drinks Guilds Clothing/Amor de-equiping bug Other help needed with research: Tatooine guild all terminal Ent flourishes We would like to complete the starter professions: Artisan, Brawler, Entertainer, Marksman, and Medic. Please help us iron out any bugs and missing features. Also test everything in the implemented list above.
 Bug Reporting Guidethanks 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 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)
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 LabyrinthSearch, 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
__________________
 Xavia@swgemu.com | eSupport Helpful Links | Status List & Reporting Bugs SWGEmu is a non-profit, open source project. Last edited by xavia; 11-09-2010 at 09:53 AM. Reason: thanks to Labyrinth for his guide! |
|
|
|
Hybrid Mode
