0.74 bugs

International board Help & Bugs
#41

Hello programmers. How it is possible that this release has more important bugs then previous one. I mean bugs which we didn’t have in previous releases, i.e. units can not be upgraded, slow is not working. Maybe more, but I’ve just started to test it.
IMO it shouldn’t be done like this. That’s why we have development versions to omit to do “old” bugs.
Does anyone from you test/play even once new release before? How it is possible that no one noticed that units can not be upgraded?
New release shouldn’t be worse that previous but this one is. Siege and new resolutions are important but keeping already implemented things without creating new bugs is more important. Maybe this release was too fast after 073c.
Of course this is only my opinion :wink:

EDIT:
Is this possible to edit bugs added to mentis ?

#42

Actually that is something I can imagine wouldn’t be noticed. I’m not one of the programmers, so maybe they can answer better, but my guess is that they spend as much time as possible fixing bugs and implementing new features. So the release package is only built in the last 24h hours before a new release. Of course they test it a bit (see that the game starts, check menus, start a map, buy some creatures, fight a battle etc), but there’s just as much one can check in a quick test. Of course one can say they could build the package one day before and spend the release day testing it, but that would automatically give them one day less for coding. And why do old bugs come back sometimes? Most probably because different programmers work on different parts of the code, and when pieces are put together, it can be there are small conflicts, or things which get temporarily lost.

Also, let’s not forget these things happen even with big game developers. I’ve been in beta tests of official games and sometimes new builds were bringing new bugs for elements which worked before. And if you followed up on Heroes V for example, you would know that with every patch, Nival was correcting 20 bugs, but introducing 10 new (some even more frequent and annoying than what they fixed - see the infamous “Not enoughT mana”). Ubival had 10 times more programmers working on HV, and still its development moved way slower than VCMI does (IMO). So I guess we should try and accept the risk of a couple of bugs returning sometimes, to keep the project moving at this speed, rather than spend maybe too much time double checking everything.

Don’t get me wrong, I’m a perfectionist myself. I sometimes dig in old bug threads to double check old bugs didn’t return. But I wouldn’t ask that from the programmers. I prefer to know that they spend as much time as they like coding (even if that’s 90% coding and only 10% testing), rather than splitting their work 50-50 between coding and testing.

Bottom line is, if a bug comes back once or twice, I think that’s acceptable. Only if we’ll have bugs coming back 3 or more times after previously fixed, then it may be that the coders would need to find a better way of organizing themselves. But IMHO that’s not the case now.

I’m not sure if you have the ‘Edit’ button available for your reports. But if not, please don’t hesitate to send me a private message here with the change you want to make, or add it as a comment to your Mantis report. I’ll make the modification and if you want also delete the comment afterwards.

Cheers,
Zam :slight_smile:

#43

@Zamolxis Of course/like always/ you are right. Probably I wrote the previous post too fast when I was irritated in my work :wink:

I don’t have EDIT possibility (i can only edit comments). I can send you PM but it would be much easier if I could edit my reports even for few hours after I send it.

PS> You understood well my polish comment, I’ve already translated it.
If you are able you can edit my report and write that it is not implemented yet. And change the Severity for minor.

#44

I’ve updated the report.

Until we see if there’s a way to allow users to update their on report, you can always mention the changes you want to make in the comment notes and I’ll be happy to make the update. :slight_smile:

#45

It’s because we prefer to code rather than to test. Usually when we make a change we test most important features affected by this change - but it does not apply to big changes. For example, when we change processing of all spells on the server (ie. we add spell resistance) we don’t test all implemented spell to check if they still work but only a few. It leads to more bugs but makes development faster.

I’ll see if we can allow all users to edit their own reports.

EDIT:
We can only allow users to update all reports (not just their own). We could also grant everybody (except anobnymous users) editor proviliges. I don’t know which one is better.

#46

With this release, a couple of overhauls were made in the code, with the GUI and animations I think. When you replace a part of a system with a new one you can count on a whole lot of bugs and missing features just like when the old one was first introduced. But typically these bugs are easier to fix because of prior experience and knowing the differences between the old and new system.

#47

That is a bit risky/annoying. I guess we could give it a try, if there is request from the users, but if anyone abuses it, we change it back. I’ll let you & Tow decide on that. For me it’s fine either way.

#48

@mantis
perhaps easier is to not allow editing “for all” - all to put in new comments
if diffrencies are to big we can delegate one person to track updating messed “issue threads”

#49

I don’t think it matters if only administrators or programmers can update fields, because, for example, you may have done a wrong title and I think it’s quite acceptable for Zamolxis or another member of the team to edit the title (or other fields sometimes too). :smiley:

Best regards,
Steven.

#50

It looks that testers have found an incredible number of bugs, but there’s no one to fix them :stuck_out_tongue: I wish we could keep the amount of resolved issues above 10% :wink:

Have no fear, the day of glory will come.

#51

I and Tow have started new semester at our university so we have less time for VCMI. Additionally, Tow’s computer got broken and ubuntux made some changes that spoiled VCMI on Windows (it must be repaired before I start fixing bugs from mantis). Please be patient.

#52

Sorry to hear about Tow’s computer. That can be quite annoying… :frowning: Hope the hard drive wasn’t affected (I still remember the day my HDD crashed 2 weeks before my end thesis, with half of my research on it - that was the day I learned to back up important things more frequently:)

For the rest it’s okay to wait for the moment. VCMI is still pretty playable so we don’t “urgently” need a release.

#53

Plese give developer status to Ubuntux.

#54

@Warmonger

done

#55

Would it be possible to give the testers access to builds not released as a new version? I mean something like daily builds except that they most probably wouldn’t be daily :wink: This way we could avoid duplicating issues (like reporting something that’s already fixed since last release).

#56

You can always compile it yourself if you have the tools. Nightly builds could require some build automation. Personally I have some problems with Windows SxS, which won’t let me run the program on anything but my system. Linux users should be able to compile it themselves, there’s not a whole lot of dependencies anyhow.

To avoid reporting duplicate issues, the filter is very useful. You can just enter the term what it’s about like “artifact” and you will, at least at this point, only get a handful of reports that can easily be skimmed through if they cover your issue or not.

#57

Or alternatively to Mantis’s filter, you can change the default view of the issue list (e.g.: change the Show filter on top from 50 to 500) to have all reports displayed on one page. And then use CTRL+F. So for reports like 200-202, a simple search with “wait”, “stack” & “sword” would have revealed that they were already previously reported.

For the rest, it’s not a matter of “giving access” to builds. I believe the coders compile the new code changes themselves. As for really creating a build ready to install for us testers, that’s a bit time consuming. That’s why it’s done only once (max. twice) a month: the bi-monthly official release, plus 1-2 development releases in between. This time there’s been an exceptional delay in the release of a new dev.version (which I agree it may be needed, considering that about 50 bugs were corrected since 0.74 came out), because Tow’s computer crashed last month, and he’s usually the one preparing these packages. Let’s have a bit more patience until he gets a new one and then I’m sure we’ll get a new release. :wink:

#58

SPLIT:

[quote=“Tow”]

[size=84]The PC issue you had must have been quite a blow, which now probably makes December 1st a deadline pretty hard to meet for 0.75 (surely not with all the features you may have had in mind for it). However, just in case you are still considering it, here is what I could do from my part:

If you manage to prepare 0.73c with debug symbols and latest fixes (plus fix for #223) by Thursday, from Thursday evening till Sunday evening I have a free long week-end, which I could spend checking each and every of the bugs reported as fixed. Probably I’ll even have time to check all other items reported as implemented. And on the way I’m sure I’d spot any other major bugs still in there (I’m planning for 20-30h of thorough testing). If you and/or the other devs would be around to fix what can be still fixed, then we may be able to release a pretty bug-free 0.75 on December 1st. If we manage that, the testers may have a VCMI they could enjoy during the holidays :slight_smile: and happy-hunt for minor bugs, and you may have a more relaxed time to work on the major features you have in mind for 0.8, without being “bugged” :slight_smile: by crash reports and requests for dev. releases due to annoying bugs.

Of course, that may be just a hypothetic scenario, as I’m totally unaware of the time (and not only) resources that you may have these days. Otherwise, if there’s anything else I can help with, let me know… :wink: [/size]

#59

For me it is really good idea. I will have 2 weeks free around Holidays which mainly I will have to spend with my family so I hope I have much time for testing.
But what I would like to mention do not try to finish the 075 at the end of November by force. I know that it is kind of habit that new release appears first day of the month but what’s wrong with if it appears i.e. 10th of December. IMO nothing. And I’m sure that it is better way to omit the appearance of old renewed bugs and multiplied new bugs.

Let the power be with you :wink:

#60

I would like to see current version released at worst at 1st December, we can take it for bugfix release. We can wait with any major features for another month as in December I’m expecting the work to speed up. It’s rather irrelevant how the versions will be labeled as we won’t run out of numbers anyway.