Sorry for the brief description but I wanted to post this build tonight.
This version with a few not complicated fixes possibly) can be released as 0.75, if it’ll seem to be relatively not bugged.
I have very little time, so nothing bigger will get changed probably
As for the description, I guess for dev. releases we don’t need anything more detailed.
Question about Mantis bug management: shall I close the “Resolved” reports for previous releases, if I see that in 0.74c they are fully solved? Or wait for one of the next public releases?
The 0.74c Settings.txt was built on the old 0.73 version, affecting most of the custom resolutions. I’ve uploaded the corrected one here (after installing 0.74c from Tow’s archive above, extract the file from the archive in my link and place it in the /config folder).
The file seems to have been edited to support the in-game console, however CTRL+1 does not open it as expected. I’m not sure if it was left out intentionally or some file is missing from the archive.
@ Boulie: I don’t seem to have the issue with the application shortcut in 0.74c. So it could be a local issue on your machine (because of certain settings or OS). Though I see you have it only with VCMI, not with SoD. How did you create the shortcut? Do you get the same if you use a different method to make the shortcut?
I never get it (I have XPsp2), so I’m still not sure if it’s VCMI or sth with your settings. But I’m not an expert in icons, so maybe someone else could help.
On a separate note, I’ve noticed that very often, after bug fix or feature implementation, the item works correctly in a new game, but is buggy if we play a saved game. As a humble advise to the devs, may I suggest (if time allows on your side), running a short test of your fix/feature also on a saved game, to check if it’s of the nature for which special coding needs to be done also for saving?
That is more or less impossible, for the alpha versions you can expect your old saves to become useless.
When objects are changed so will the way they are written to disk, as well as how they are read. It’s difficult to automate any compatibility fix, it would have to be done manually by keeping track of how the parameters differ with different versions and would clutter the codebase with special cases. (And that is without looking at the fact that it’s going to be pretty impossible to figure out what all those changes were for each new version)
So as long as we don’t have everything fully implemented, the save file format will just have to differ with every version.
In version 1.0 and onward when all objects and features are dealt with the issue of file format is more relevant. If a change made then perhaps some form of backwards compatibility can be made.
As a side note, this problem will also be present in network communication. But I suspect people with different versions will be prevented from connecting to each other when that time comes.
@ Warmonger: The latest example on Mantis just reminded me of it, but it’s actually something I noticed long ago (I think in previous versions even more often). Few times we had bugs reported which could not be reproduced by devs, because it worked in a new game, while the tester had it on a saved one (but did not link it with that when writing the report). And we have spent some time going back and forth until it was figured out.
@ OnionKnight: I am indeed not aware how it works with the saves between two dev. releases, so maybe it was not a territory I should have come with suggestions. But just to avoid any confusion - as I see you mention “old saves” - it could be I wasn’t very clear in my explanation. I didn’t mean trying old saves, but after you test that the new fix works, to save the game in your working version, and reload to double check it still works. But again - I am not sure how this works on the coding side (could be saving/loading don’t always works with the latest code, until some other changes are made by Tow before the release, to ensure compatibility…)
Anyway, it was just meant as a “humble suggestion”, just in case it won’t take you more than 2-3mins (save-load-retest). If it’s more complicated than that, please ignore it.
But I understand from Warmonger’s explanation for #71 for example, that one fix in the code for a certain item, may require changes of a different nature in other parts of the code to avoid issues with saves or end turn. And the coder who fixed the original issue, may not be comfortable also with the parts of the code which are responsible for impacts on save or end turn. If that’s the case, I’ll move back in “Resolved” some items I reopened and just create new reports when necessary (not #9 though - as the original report for that one was already referring to saved games).
You don’t need to know either, just casting some light on why it doesn’t really work for the curious. There’s no harm in suggesting solutions, it’s a developer’s problem to deem whether it’s feasible or not anyway and is no responsibility for a tester.
I think I see what you mean now, and yes that’s no problem at all. But I can’t really relate, does it have to do with a developer posting a save from the working version and testers using the development release gets strange behavior by using it?
I was thinking of something else actually. For example you decide to implement “Altar of Sacrifice”. It will take you - let’s say - 10 hours of coding, including retests, recoding, etc, until it works perfectly. What I meant was, at the end of those 10h of coding, to take 3 more minutes to save, reload and then visit the Altar of Sacrifice again, to see if it still works.
Like this, when next release goes public, we can be more comfortable about adding that item to the change logs.
Currently it can turn pretty time consuming, for both testers and devs:
it takes a tester 10-15 minutes to write the report (screenshots, files, details to reproduce)
then you see it, take 5 minutes to test the official release to make sure your code was correctly included and compatible, plus 5 more minutes to reply that it’s not reproducible, asking more details
then it make take even more time from both sides (and from others joining the discussion), until we figure out it only fails for saved games.
so then the fix will be in the earliest in the release following the one that reported the item as “implemented”
Instead of that, IF it takes only 2-3 minutes on your side, it would be more efficient and elegant:
if you notice it fails after save and cannot solve yourself, you can check with the other devs. Perhaps it will be fixed by the next release already
if it can’t be fixed by the next release, at least it can be mentioned in the change log as “Altar of Sacrifice (does not work on saved games)”. Like this testers don’t need to worry about it anymore, and easier focus on bugs that are not yet known.
Oh, now I understand, looking at that bug report. Excuse my tardiness.
It’s no problem to validate that saved games work, especially since serializing objects properly is part of implementing them. I think we just forget about testing loaded games because, at least I, just fire up a new game on my big test map, see if things work, then close.
Testing time is over, we have what we have and we need to take a decision.
Should I release 0.74c + fixes (as of reported on mantis) as 0.75 today or should we give it another month of testing and fixing?
If we give it another month, would that mean we jump directly to 0.8, or will there still be a 0.75?
I’d like a 0.75 release today, though I wonder if for the right reasons:
Stick to the bi-monthly release (maybe good for PR - but who knows)
0.75 sounds like a milestone, so I wouldn’t skip it
I’d like to finish the year with a last 0.7x release, and start 0.8x next year
But I wonder if my reasons are not rather autistic, then strong arguments in making the best decision. Few days ago I very much wanted 0.75 tomorrow, and I thought I’d be disappointed if it’s cancelled. Somehow it’s not the case anymore. Especially if there are better arguments than mine above, I’d be same as fine with a delay.
On the other hand, numbers aside, the more often you make a release, the more reports you get. I’ve noticed that over 50% of the reports in a month seem to be opened in the first days after the release. I guess it’s like a hot bread freshly baked. It doesn’t matter how much you changed the flavor since last time (50 new features, or only 5). People still want to try it when it’s fresh. So if a new release is always welcome, why not have one today?
Well I’m not sure. For example, the bug whenever you build a new structure that you again get the special building bonus seems to quite a big one, gameplay wise, and then after saves the bonus buildings don’t work at all too. Also the config info for Creature Banks does not save properly yet for Creature Banks that have been seen by the player, ruling out the use of Creature Banks in most games.
What do others think about a new release now? (I just have the feeling that the multiple bonus building bug might be seen as, well, “a little unprofessional”, not that I am insinuating anything guys, just taking an outside viewpoint. Being able to get +4 attack or +5 defense for the one hero in a few turns, IMHO, “looks” bad, even though it is probably a pretty easy bug to fix.)
I am very interested in other’s viewpoints though. =) I’ll go with the team decision.
A solution for that would be to just go back to the previous version of the code on this, when the only issue was that if you build the structure, you have to exit and re-enter the town to benefit from the bonus. On the other hand, the solution may be trivial. I only created the report a couple of hours ago so it can be Warmonger didn’t see it yet. Perhaps it can be still fixed by the time Tow would start building the package later today (if the case).
I’m also curious about other members’ opinion and I’d be okay whatever the decision.
What I would however like (to continue from my previous post), in case 0.75 is not released today, to still have a dev release sometime soon then. Maybe even try a system that after 50 (or at least 100) resolved reports a new dev version is released. After a while one gets anxious to test on a cleaner version, and not still running into small bugs that are resolved on Mantis for quite a while.
As I wrote it before, for me development numbers and dates are not so important as good prepared version.
We’ve just got new devel. version (0.74c) 3 day ago - I don’t even start to test it deeply.
What about, only in this case ;), to change the system and create the 0.75 on Christmas it will be also good PR (many games are released in this way ;). And then we will have first release in new year 2010 numbered 0.80. So everybody will be happy
0.75 for Christmas - milestone release
0.80 in new year (i.e. first of February) - good start in 2010.
But ofc everything what you decide to do will be fine, don’t stress with it.
I was thinking about something like this:
0.75 - now
0.76 with some actual features (win/lose conditions, heroes’ specials?) - new year
0.77 and further each month if necessary, until…
0.8 when most of game objects (buildings, spells, abilities, artifacts) are ready and we can focus on other features.
I was hoping I could get the artifact screen interface working completely before 0.75
I’ve also thought about testing save games, the load games button does not yet work from the system menu during play. It would make testing saved games a lot more easier if it did.
But just to avoid any confusion - as I see you mention “old saves” - it could be I wasn’t very clear in my explanation. I didn’t mean trying old saves, but after you test that the new fix works, to save the game in your working version, and reload to double check it still works. But again - I am not sure how this works on the coding side (could be saving/loading don’t always works with the latest code, until some other changes are made by Tow before the release, to ensure compatibility…)
and just create new reports when necessary (not 