From OHRRPGCE-Wiki

Don't, it'll make us sad. :(

Just kidding! We like to hear about bugs (in the sense that we can fix them, not because we like bugs). But, before you go about reporting a bug, there are a few steps you can do to make sure that it is a bug, and that we don't already know about it.

Contents 1 Is it a bug? 2 Do we know about it? 3 Reporting the bug 3.1 Adding info to an existing bug 3.2 Attaching a file to a bug 3.3 Filing a new bug

[edit] Is it a bug?

The easiest way to determine whether the problem is in the OHR (as opposed to a user error) is to make a test case.

A test case is a simple RPG which has the bare minimum required to reproduce the bug. So, it might have one NPC, one Hero, one walkabout (shared between the two) and a script, but nothing else. The less stuff in the RPG, the better.

Why? If you have 1000 scripts, 30 heroes, 25 NPCs on each map, and 900 tags in use, it will likely be considerably harder to track down the bug.

Then, once you've made the test case, you can look at the problem feature, and determine the cause of the problem.

script, flash screen, begin
  fade screen out(64,64,64)
  wait(3)
  fade screen in
end

Say you figured out that the problem was in that script, and you made a bare test case to test it. Ok, so when you talk to the NPC, the screen doesn't change at all. Is it a bug?

No, in this case it's an error. The parameters to fade screen out can only be from 0 to 63, 64 is invalid. Thus, it doesn't do anything. Changing the parameters to 63 would fix this script.

This example was a bit rigged, I know, and sometimes you can't figure out what (if anything) is wrong. Then, you can post about it on the Castle Paradox forums, in the OHR Plotscripting Help forum, to ask one of the resident gurus (myself, Mike Caron/pkmnfrk, included).

[edit] Do we know about it?

Ok, let's say you made a bare test case, spent hours debugging your script, and it looks exactly how it should. Then, there's a good chance it may be a bug.

But, you're not ready to report it just yet. Head on over to the bug list, and see if a bug like yours has already been reported. If there's something similar to yours, you can click on the ID number to view the details.

If, when you read the description, the bug sounds like yours, and it's confirmed, you're done. You don't need to reconfirm it or anything.

However, if someone says something like "I can't reproduce this. Anyone?", that means that we're having difficulty determining whether it is a bug or not, and if it even exists. It would help us greatly if you could post the test case (in section three).

If there's no bug like yours, then you can move on to Step 3.

[edit] Reporting the bug

Before you can do anything with BugZilla (the bug tracking software), you must register an account.

[edit] Adding info to an existing bug

If you found a bug, and you have more information to add (a test case, more specific trigger incidents, etc.), it's easy to reply to a bug. Just type in the large box named "Additional Comments" on the bug details page, and press Submit. If you're not logged in you'll be asked to do so.

[edit] Attaching a file to a bug

If you want to attach a file (a patch, a test case, etc.), don't use the comments box. Instead, click on "Create a new attachment", to be brought to the attachment form. You'll be asked to log in, if you haven't already. Then, fill out the relavent details there.

The description should be a short line describing the attachment, such as "Test case" or "Patch to fix fading" or whatever.

If it's a patch, check the box. Otherwise, select "Auto-detect" below that.

If this is a newer version of another attachment (or a combination of two patches, or whatever), you can check off which attachments are replaced by yours, if any.

Finally, if you want to leave some comments, the box at the bottom is where they go.

Hit submit, and you're good!

[edit] Filing a new bug

IF there's no bug like yours, you can open a new bug.

A few coments on the fields:

• Version: Don't report bugs in older versions. If we've fixed them in the latest version, that's good. If we haven't, they'll still be in the latest, so there's no point in reporting under the old version.
• Component: Most people ignore this, but you can choose which area is most applicable to the bug.
• Priority: Leave it alone.
• Severity: Put the magnitude of the bug here. If the program crashes on start up, then it would be a "critical" bug. Or, if an NPC is misaligned a little bit for no reason, that would probably be a "minor" bug. If there's a spelling mistake somewhere (in a built in string, not in a customized one!), it would be "trivial".
  • As a special note, if you're using this to request features, put "enhancement", so we know to ignore it (kidding)
• Initial State through CC: Ignore these.
• URL: If you have uploaded a test-case to your own website, you can put a link to it here, rather than uploading the test case to bugzilla
• Summary: This should be eye catching and informative, such as "Plotscripting command fade screen out doesn't do anything"
• Description: This is where you describe in detail the nature of the bug. If there's a script that triggers it, put it in here (tell us what it's supposed to do, and what it really does). If there's special notes, put them here. If it's not a script, give us directions to reproduce the bug. So on, so forth.

• someone should put an example of an idea bug report*

When that's all done, hit Submit, and we'll reply to it with our commentary.