Trunk discussion / complains

MinGW is slow. I think MSVS should be much faster.

In Cmake-gui
CMAKE_BUILD_TYPE=Release
Click configure, then generate, then build it as usual.

Ok, thanks, I’ll try it out :wink:
Edit: Thanks, it helped. Now the mentioned files are very small (up to ~17 MB the biggest).

So, I’m back after a long time :slight_smile:

I migrated boost::bind/function/ref usage by their std:: variants. The mix of boost and std caused a problem with boost::split (!!) and I received a SIGSEV during VCMI startup all the time=) The stacktrace showed that the boost::split function called a callback from our codebase. Migration was easy, one thing I had to do was not to include boost’s placeholders and include std placeholders in global namespace.

This means, we shouldn’t use boost::bind/ref/function anymore.

Additionally I fixed a few Clang warnings.

2 questions:

  • I receive a SIGABRT when I close VCMI ingame. Is this normal? (mutex could not be destroyed)
  • I enabled SDL2 (it is default), but now the font looks sometimes akward. Someone else recognized this?

On std::function - last time we talked about this there were some issue with MSVC compilation - simple search & replace was not enough to make VS work. Was this fixed already?

This reappears so many times that I’m not even trying to fix it… It seems that boost does not like destruction of locked mutexes. Proper way to fix this would be to figure out why mutexes are locked to begin with. Something I never managed to do.

I never noticed anything like that. Can you post screenshot with these broken fonts?

I think I know what Beegee is talking about… I’ll try to catch these broken fonts and post screenshots here.
Edit: Hmmm, maybe it’s hard to see it, but sometimes text become blurred or ‘embossed’.



I don’t know. Warmonger could you check this? If there are a lot of issues, we can either revert my commit or I’ll fix those compilation errors. Third option would be to switch back to boost completely, this is now the second time I received such a random(!) program behaviour. I hope std will work for Visual Studio 2012.

@Kantor: Thanks for providing screenshots, that’s exactly what I meant. BTW do we use bitmap fonts or TTF?

We are already using std::function for new code, no issues were reported about it.

Short question, what’s the difference between baseAmount and count of a CStack? baseAmount is the original count before the battle started and count the current amount of creatures? Should be documented or named better.

By default we use bitmap fonts from H3. There is also mine mod in repo that provides true type fonts. I’ve been thinking about using ttf as default but so far there were no need for such switch.

And I think I figured out what causes broken rendering. Will fix soon.

I have a question: where can I post info about issues that comes from the latest dev branch of VCMI? If on Mantis, how should I describe version of VCMI then or in this topic?

Report it on mantis, Kantor. Simply write in description or somewhere else which version do you use.

I noticed some (regression) bugs regarding sacrifice spell. I think we really should write some unit tests and there are possible for a variety of use cases e.g. map objects, spells, abilities, battle rules, etc… Therefore we need to write a basic test framework and a few initial tests to see how it will work. Perhaps we can write then unit tests for every bugs we fixed and new features we have added (if possible =) ). The quality of our program and the code should improve (as refactorings are less risky). Bigger problem is someone has to do it =)

I nearly fixed the sacrifice bug reported here on mantis: bugs.vcmi.eu/view.php?id=1443
The problem is when the currently active stack will be destroyed (sacrificed). The GameHandler battle loop checks in a fixed intervall if the turn of the current stack is over, if the stack died or if the battle ended. Problem is that the CStack object will be deleted and any access results in undefined behaviour (i like these two words:). So there are three possible solutions:

  1. Save unique ID somewhere and test if stack is still available by checking current stack list. ID shouldn’t be given twice, so every stack ID can only assigned once. You can count internal stack ID number (like SVN revisions).
  2. Set somewhere a flag variable that current stack was removed or re-assign pointer to current stack by modifying game handler data.
  3. Use shared_ptr for all CStack instances and guarantee safe access. Now you can check if the CStack instance is still in the current stack list.

I vote for solution 3. Solution 1 is not object oriented (storing IDs everywhere instead of pointers) and solution 2 relies on modifying global object data (very dangerous). Solution 3 works continuous even for client and battle interface. Battle interface often caches stack instances for storing active stack, hovered stack, etc… The best would be that the CStack instance (no ID) will be transfered in the BattleStacksRemoved net package. So you can directly check if the cached variables need to be reset. Perhaps the battle game loop can be rewritten so that it doesn’t polls all the time but reacts on events, this makes CStack validation check easier.

In this thread Tow describes a similar aliasing problem for CHeroInstance, we should use more smart pointers or reset invalid pointer data: forum.vcmi.eu/viewtopic.php?t=845&start=0

Perhaps someone can use this information as help to fix this bug.

Just to let you know, I’ll stop VCMI development for unknown time and start another exciting project (in my free time).

I do not know where it is more correct to ask.
0,96b be? Test build with the error corrected. You said earlier that the release will be every month …

Or another idea-do not remove stack. Set it dead with some additional bool value like “nonRessurrectable” (or new bonus NOT_RESURRETABLE) and replace it’s dead body animation with dump graphics (with no graphics, only blue background in it).

What is M_DATA_DIR in the line

ui->lineEditGameDir->setText(QString::fromUtf8(M_DATA_DIR));

In csettingsview_moc.cpp file?

Another throught on extending creature properties.

There are some DEFs of creatures, that have instead of “Death” animation an “Unused Death” animation.
This thing is already implemented in HOTA somehow. If creature dies from spell, “Unused animation” is played.
I think it’s better to add “UD” animation playing for ranged/spell attacks (not only spell).

What do you think about it?
It should be something like

"rangedDeath":true

in “animation” section of creature config.
Or (for more modding possibility:

"deathAnimation":
{
"standard":true // if "true" than frames group "Death" is played, if not, played "UD"
"spell":true //if true than if creature is killed by spell, "UD" played , last fram goes as corpse animation.
"ranged":true //if true than if creature is killed by spell, "UD" played , last fram goes as corpse animation.
}
}

Warmonger, Location of data files, defined during compilation. On Win this is always “.” (current directory), on other platforms it can be defined differently.

If this is causing problems - replace it with VCMIDirs::get().dataPaths().front();

Macron1, much simpler solution:
if creature killed with spell and has unused death animation ( >0 frames) - use it instead of regular anim.

What if unused death is wanted to be shown after ranged attack also?
PS Some creatures can have “Unused Death” animation, but it can be incomplete (i found some creatures with only 1 frame of corpse in this group).
In this case >0 will not work out.
Of cause, if DEF file is made properly, than it can be exported to frames and made again without these errors.

PS I still didn’t started next works on current branch (some personal problems and decrease of will). I only plan now to create virtual machine with Ubuntu (or Debian) and configure QTCreator to work on VCMI. Only after that i plan to continue.

Okay, it looks that mega-merge is complete and all finished code is now in develop branch. I guess everyone who does not use CMake will have to update/recreate project files due to large reorganization of client/ directory

Note that this merge includes my not 100% finished reorganization of graphics (see that pull request for details). Current status:
By default, VCMI should work WITHOUT additional graphical package (aka core.zip). This means that quest window + creature windows should work with our own graphics from repo. However new resolutions & bonus icons still need it.

Here are repackaged files which include only resolutions/bonus icons. Unpack it into “Mods” directory (preferably - in user directory to keep it separate from git):
dropbox.com/sh/fwor43x5xrgz … s/vcmi.zip

For next release I’d like to finish my work on Launcher and upload this package into mod repository.

Std::bind causes new compile errors. Namely, functions with return type of bool cnanot be assigned to function with void return type, as in this code:

void CHeroWindow::dismissCurrent()
{
	CFunctionList<void()> ony = std::bind(&CHeroWindow::close,this);
	ony += std::bind(&CCallback::dismissHero, LOCPLINT->cb.get(), curHero);
	LOCPLINT->showYesNoDialog(CGI->generaltexth->allTexts[22], ony, 0, false);
}

CCallback::dismissHero has bool return type. In this particular situation it’s not obvious how this should be solved.

It becomes more apparent in ERM project which is littered with ambigious functors.