Bug Reporter

[archanox]

Lately there has been an increased amount of activity with users who are expecting the emulator to work flawlessly immediately. Some of the users are reporting issues for the games on github, but not much can be taken from the bug report than the title of the same and that there in fact an issue, but not explicitly what the issue is based around.

Instead of training the users how to file a bug report and scroll through the console output, I propose, once the logger work is complete, to implement a "send bug report" feature that automates the process so we're not dealing with screenshots and memory dumps.

My original thought was to utilize the GitHub API and amend the issue based on the UMD ID and obviously create it if it doesn't exist. Another method I'd suggest is perhaps a Google Docs based solution.

Another Idea to curb expectations of the games compatability is to perhaps have a "health indicator" in the game list to show the percentage of implemented/unimplemented modules.

I'd love to hear other peoples thoughts on this and perhaps any other proposal other than github/google docs. Maybe a emailing solution?

[SsJVasto]

Indeed that'd be a good feature, but there are a couple of situations where this would not be the best:

• If a user doesn't have Internet on his machine during the crash could make the Logger crash;
• If the Logger crashes, there is no error report
• Even if a game crashes, aside from the ISO name, there isn't much we can do game-wize. That means we cannot confirm that the problem resides in the Emulator or a defect in the game (corrupt data somewhere);
• If the emulator gets caught in a loop or something, the Error Report will never fire, as the emulator has not crashed.

I think the idea is GREAT and also, I'd love to see where exactly in {UMD}\DATA.BIN (or EBOOT.PBP) where the code crashed. (like, the OPCODE and parameters in the executable that caused an error, possibly with a callstack or something...)

Anyway, I'm always for good management, but upon reading your post, these things poped into my head, thoughtI'd share them.

Also, I probably wouldn't use the GitHub API, because there is no garantee that GitHub will be used forever for the project, and if (years from now, once this is the best emulator in existance) people want to play "old-school PSP" on our emulator and experience a crash, the crash will crash if there is no GitHub to receive errors! I'd use plain GET data fed into a PHP script on soywiz's website.

---

Also, about the "Health Indicator", how would you do this? Automated, or managed? Do you want it on-site, or inside the emulator? Here is what I mean if you don't understand my "way of optimized speaking that avoids using too many words":

• Automated: The emulator will log all errors and produce a report on what % of the emulator works (including FPS);
• Managed: The users must set a score and log errors manually (more precise, and less code-based reading);
• on-site: we need to connect to pspemu.soywiz.com and enter the information;
• in enulator: there would be a tab that allows input on the game (where the ISO can be detected automatically using "UMD ID" as @archanox said) and the exact revision of csPspEmu.

[SsJVasto]

A thought just popped into mind:

Maybe (for the "Health Indicator") we could implement a "Test Game" button in the emulator, that will check all the Assembly in the executable and check see if there are unresolved dependancies (like missing codes). If all the code is implemented, it can then Test the run, and log errors, if there are. At least we'd know if the ISO is good on crash (and using a MD5 code or something we could make sure we don't re-test the same ISO a billion times)

[archanox]

So many questions! I'll try my best to answer them.

I think a "submit compatibility" button would be good, and ideally a long term DB would hold it. But free options could be used on the short term (github/Google docs). I don't think using these options would be an issue if the project went down or something, as I'd assume we'd be pushing new versions onto people.

I'm also keen on the idea you raised of user submitted bugs, but I think a hybrid would be "better". User marks a game as "crashes", "playable", "unplayable", etc so we can build up a compatibility list for users. But also do a test for modules, and error log related issues. Now I was thinking this test would be done at runtime, and not a separate test outside of the running game. To mitigate the issue of users not desiring to be penalized by performance for submitting this useful data to us, we could set it to an opt out dealio.

So yeah, ultimately I was picturing everything to be in game and then perhaps an online reference table? Sounds overboard, but the most immediate problem we need to solve is getting errors sent us easily and "usefully" with sufficient context.

[SsJVasto]

Yeah, well I think it's great, but I'm not for the idea of using a "Free Option" (not that I don't like open-source) simply because in a text file, you cannot perform Search or directly alter the table. There is no way of guaranteeing that the data will be in readable order (if people are using different revisions, it will be SOOO hard to filter it out manually). Also, since there is already a dedicated website for the emulator, we might as well use it to put information about the emulator! XD

I was thinking something along the lines of: http://pspemu.soywiz.com/compatibility.php?action=add

• &revision=<GIT revision #>
• &game=<game ID>
• &gameMD5=<Game's MD5 Checksum> (to make sure everyone has the same ISO)
• &compression=<ISO | CSO>
• &fps=<average FPS> (0 means crashes on first frame, -1 would mean crashes before first frame)
• &crash=<crash byte> (0 would mean the game didn't crash, otherwise, we return the address of the crash)

I imagine that standard stuff like the DATE could be determined by the PHP script, and we could have a Database with the UMD_ID to GameName list.