0.74c development version

A little OT. In previous version the VCMI icon was without white background and it was better than it is now :wink:
http://img509.imageshack.us/img509/4534/clipboard01ens.jpg

@ 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?

Strange, after I read your post and check it one more time everything is correct, now. So like you wrote it was problem with my PC. Thx :wink:

EDIT:
After I started my PC today there is the same situation
img12.imageshack.us/img12/619/vcmiicon.th.jpg

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. :slight_smile:


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?

No, itā€™s just me. I simply donā€™t know how to do it and just now learned it may be necessary. :-/

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. :blush: 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. :wink:

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 :stuck_out_tongue: 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. :stuck_out_tongue:

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. :slight_smile: 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.

Best regards,
Steven.

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 :wink:
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 :slight_smile:
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.

Wowā€¦ congrats on your courage. :smiley: I had exactly the same ā€œplanningā€ in mind (no kiddinā€™) but being so far away from what Tow had in mind, I was afraid to say it. :stuck_out_tongue: I guess that due to my professional background (Sociology) I tend to go directly for the compromise solution, which is what I tried to do in my post above. In my head thatā€™s cutting through all the bargaining to a solution that would reasonably satisfy everyone, to save time. In reality though, it probably is just a bad bargaining start from my side. :laughing:

When I heard not even 0.75 was in the plans, it was a bit of a bummer, as I was expecting/hoping weā€™ll get at least as far as 0.77. I donā€™t like to rush to high numbers, as you never know what unforeseen issues you might run into, that would require more time and releases than expected. And then you end up like WoG, adding letters behind your numbers - and then even run out of those, if you decide that ā€œf=finalā€, so you have a ā€œscript updateā€ which brings quite some changes, but you canā€™t give it a number code, 'cause 3.58f was supposed to be the last, leading maybe to a bit of extra confusions - at least among the players who didnā€™t follow the project close enough.

Iā€™d rather have 0.75, 0.76,ā€¦ until 0.79, instead of 0.74d, ā€¦e, ā€¦f. I canā€™t say why - maybe it feels more elegant. Iā€™d also prefer a release on the 1st of every month (with a dev release 1 week before). But Iā€™m not one of the coders in this project, to realize the amount of work that would be necessary for that. Itā€™s a voluntary project and I realize that pushing too much for what I want might have the opposite effect on the developers. A release every 2 months (with a dev version 2 weeks before), seemed like an elegant decent compromise. We might have been on schedule if it wouldnā€™t have been for an unfortunate technical issue, but Iā€™d rather stick to the schedule and motivate the low amount of new features with that, then delay with 1 more month because of the same reason.

And another thing. I suspect that from a devā€™s perspective, who is better aware of the amount of work and changes from one release to another in the past, it feels uncomfortable to have at some point a release which doesnā€™t change even half of how much previous releases changed. From a testers perspective however (and I donā€™t know if I speak for everyone, but at least for a few), if it wouldnā€™t have been for this discussion, I wouldnā€™t have had at all the feeling of a ā€œhalf-releaseā€. Anyway previous releases had so many new features, that I never had the patience to go through all of them in my testing. If weā€™d have only 10 new features and 40 fixes per release, it would be easier to go through all of them. But weā€™ve had changelogs with almost 100 items. Iā€™ve tried a few times to go systematically through all of them for proper testing, but never managed to get to the end of the list (barely to the half). What I see now on Mantis is 104 resolved reports. So I guess what Iā€™m trying to say is that we have more than enough to put in the Changelog of a new release and that the general public will probably not perceive the release in a negative way, because most of them are not actually keeping track of the amount of new features that come with each release. Though, if there are lurkers who think otherwise - please donā€™t hesitate to share your opinion. :slight_smile:

So there it was, a more honest answer from my side, leaving all compromise attempts aside (as far from the reality as it may be). :stuck_out_tongue:

Actually being able to access the Main Menu from the game (to Load or start New game), itā€™s already a huge step (could be top of the list in the Changelog). :slight_smile: Making the ā€œLoadā€ button working itā€™s just fine tuning which can easily wait IMO. I even see a small positive side to it, that is the fact that weā€™re ā€œforcedā€ to go through the Main Menu to load, to have this path tested as well. Because otherwise 99% of the time weā€™d just use ā€œLoadā€ and risk to not notice a possible bug with the longer path.

I would strongly support this plan! :smiley: After all, 104 fixes is hardly a minor achievement, as Zamolxis says. =) I would be very happy to see a full 0.75 release before the day is out, if Tow is okay with it. :slight_smile: I think numbered releases such as Warmonger and Zamolxis have suggested make sense on a human psychology level as well as a consistent two-monthly 1st of the month release schedule. I also agree that it is better to allow for a few extra measured, numbered steps. :slight_smile:

Is this okay with you, Tow? Or more specifically, do you have time to release a full 0.75 release while it is still the 1st of December?

Best regards,
Steven.

At least in the most western time zones. :wink:


LE: Hey, what do you know. Weā€™ve made it for Dec 1st CET. :smiley:

Seriously now: Tow - thanks a lot. Iā€™m playing for about half an hour now and it looks great. Pretty stable. The only crash is a provoked one (shooting with Catapult at creatures), so it can be avoided easily. Most annoying bugs seem to be gone. Great work. Thanks to all coders! :slight_smile: