Musician Archive
Thread: Help test the new Knowledge Base
BlueOx wrote:
soe8086 -- last paragraph refers to usage experience being required to improve as a crafter. This is outdated and incorrect. Usage xp was removed during mid-Beta3 for most professions, with the rest being removed shortly after launch. A few crafters have reported random amounts of usage xp still being generated if they stand directly next to a person using their crafted item (much like a factory grants 10% xp if you are near it), but at best this is residual xp that just missed being removed by the devs (i.e. a bug), not something that is "required to advance."
The following articles have "ad barking" misspelled as "add barking": soe8638, soe8639, soe8640, soe8648, soe8650, soe8751, soe8753.
Sorting bug with the database: After completing a search, if you click on any of the headers to sort the article list by Article ID, Match % or Title, the interface appears to reorder the articles, but if you click on one, instead of being shown the article with that particular title, you will actually be shown the article that would have been in that spot if you hadn't sorted.
Nice work! Those typos are corrected and I'll forward that bug to QA. The last paragraph for soe8086 was also rewritten.
Message Edited by CSRDavidF on 02-24-2004 03:27 PM
Message Edited by Q-3PO on 02-25-2004 10:19 AM
Is there any intent to put current known bugs into the KB? It would help a lot and save frustration if as soon as a bug made it to your tracking system a KB entry was made with the release number in it, and it was removed as soon as the bug was tested as fixed.
Since customer service is reported to tell people on the phone "that is a known bug", that could save a lot of phone calls. This would especially be true if information about whether a loss due to it was re-imbursable were included as most known bugs seem not to be from forum reports.
Haruspex77 wrote:
Is there any intent to put current known bugs into the KB? It would help a lot and save frustration if as soon as a bug made it to your tracking system a KB entry was made with the release number in it, and it was removed as soon as the bug was tested as fixed.
Since customer service is reported to tell people on the phone "that is a known bug", that could save a lot of phone calls. This would especially be true if information about whether a loss due to it was re-imbursable were included as most known bugs seem not to be from forum reports.
If this feature were added, it would also be desirable to have a way to view recent additions.
Yes. We plan to maintain that type of resource in the Knowledge Base but it is not expected to be in place before Publish 7.
Ekhben wrote:
The following articles have "ad barking" misspelled as "add barking":
Maybe they are referring to Attention Defecit Disorder barking, ie, repeating the same ad every 3 seconds so it stays fresh in the TV addled minds of today's youth?
The user interface resets 90% of the time that the client crashes. This is probably due to the game constantly writing to the config file. If it is in the process of writing to the config file, and the client crashes (or the computer freezes), the config file becomes corupted, and the default is used upon reboot.
To the interface coders:
FILE *cfg = fopen("config.file.NEW", "w");
...
fclose(cfg);
unlink("config.file.OLD");
rename("config.file", "config.file.OLD");
rename("config.file.NEW", "config.file");
...
Rinse and repeat anywhere you write files in code that you aren't sure is safe from crashes, or where the file you're writing is particularly important, noting that multithreaded programs are never safe from crashing, no matter how well written the bit of code you're looking at is. (Go, coroutines!)
Instead of
rename("config.file", "config.file.OLD");
rename("config.file.NEW", "config.file");
you should do
copy("config.file", "config.file.OLD");
copy("config.file.NEW", "config.file");
delete("config.file.NEW");
That way if it crashes during either of the steps you are safe.
If the client boots up and a corrupted config.file is found, check if config.file.NEW exists and is not corrupted, if so grab that one. if not, check for config.file.OLD, which will be there.
Your way left open the chance for a crash during rename, which would leave you with nothing. This way always keeps one intact version of the file
If the config.file is corrupted, check config.new
anyway ignore that last line before my sig