Please use this topic to report technical issues, questions or suggestions you may have regarding the Mantis BugTracker, as well as any other feedback related.
==========================
First issue: As of 7:45 PM CET today, I can’t access the “View Issues” page anymore. I am getting the following error message:
“APPLICATION WARNING #2702: Your session has become invalidated.”
And then I am redirected to My View page. I was doing nothing in particular when that happened (I was on antypika only for more than 1h logging bugs, not other web pages open), so I can’t think of any action from my part that may have caused it. The only thing that may be related, would be that after that (1-2 mins after the first failed attempt to access the page), I also got the ZoneAlarm warning regarding the “svchost.exe” file. It’s something I’m getting occasionally for quite a while and I never had the time to fix it (I googled it and it seems to be common, not dangerous, but complicated to fix - and I didn’t have the time for it yet). But again, I’m not sure if it’s related. I’ll try a system restart to see if the problem is on my side only.
EDIT: Rebooting the system didn’t help, so I guess the problem is with the site, not my PC.
I did try that as well but it didn’t help. I think there really was something with the site. But now it’s fixed already - I tried again yesterday night and it worked.
A tip for the Mantis users with Developer profile: if you mark any item as “Resolved”, it’ll automatically be associated with your ID. I’m saying this because I’ve seen few cases of items first resolved, then assigned. The “assign” function is only in case you want to take ownership of a report, but you did not fix the bug yet.
And just a humble suggestion: maybe it’s better not to mark an item as “resolved” just because it does not seem reproducible. I reopened two such reports today. If you are not aware of a change in the code that was meant to fix that, then maybe it’s best to wait for other devs or the reporter to confirm that before closing (it can always happen that it’s just not reproducible on your PC). In case you know about a fix, then better use “fixed in rXXXX” or “fixed in SVN” as comment, rather than “not reproducible”, as that can be misleading.
Strange, I don’t know why anyone needs to be assigned to resolved issue, so I agree with you.
Sometimes it’s possible that bug is resolved by a change we cannot easily track. I think it’s OK to mark not reproducible bugs as resolved if they don’t occur, are marked as always reproducible and seem to be independent of reporter’s installation. In other cases bug should be marked as resolved by someone who experienced it.
By the way, yesterday I found three issues both resolved and reopened - I think these two are mutually exclusive (issues 43, 73, 163).
Fair enough. Though it would be more obvious if in the “resolved” comment we have something like “fixed in rXXX” or simply “fixed in SVN”, because just “not reproducible anymore” leaves room for interpretation and testers may react with “hey, I can still reproduce it on my machine”. I know most of the time you guys do update it like that, so it’s not a complaint or anything, just a detail to keep in mind to avoid any confusion for the future.
As for assigning resolved reports, if it helps correcting the Mantis statistics, than it’s perfectly fine - forget I mentioned the above (I didn’t notice they were still in the “unassigned” list).
I think it’s the error we’re getting if it takes us more than XX minutes to submit a report. What I do then, is hit back, to not lose the details of the report, then I create a different one in a new window and copy-paste everything.
Of course, it would be nice if this could be somehow fixed (i.e.: give user more time to finish the report before invalidating the session).
I suggest adding GUI - Adventure Map, Mechanics - Adventure Map, Mechanics - Town and Mechanics - Heroes categories as there are / were pretty many issues sutiable for them. At the moment too many bugs belong to ‘others’ category.
I created ‘Mechanics - Town Screen’, because I just ran into such issue, and I believe there are lots of “mechanics” related to it: each building with its (sometimes multiple) functionalities.
Let me know if it’s fine with you and if you prefer that I move all the Tavern-related reports in this one as well, or shall we leave them as “Other”?
Many of these issues are scattered somewhere else among actual game code, but since the full town functionality is yet to come, I’d keep this one for convenience of reporters
I think than Mechanics - Town is much better description than Town Screen, on the other hand GUI - Town Screen may be needed sooner or later. It’s up to you.
Yes, I was going through the other reports and indeed ‘Town Screen’ is not a good category when it comes to mechanics (think of Lookout Tower). ‘Town’ sounds too vague. Shall I make it ‘Town Objects’ (and rename ‘Objects’ into ‘Adventure Objects’)? Or ‘Town Buildings’/‘Structures’?
If you want to be specific, Adventure Objects is indeed a good category. I’m not sure about ‘Town Objects’ though, as it has many different functionalities. Most important ones are already handled and there are mostly other town buildings yet to come, but bugs tend to be unexpected.
I went for ‘Mechanics - Town structures’ in the end, to be consistent also with the Google spreadsheet. So a category for all reports regarding the malfunctioning of one or another item in that list.
We’ll see depending on future reports if a more generic (or the contrary) name is necessary. But for now I cannot think of any town-related possible issues which wouldn’t fit in either mechanics-structures or GUI-screen categories.
