Trunk discussion / complains

Warmonger, lets make develop branch history linear. Please do not merge upstream develop to your local develop use pull fast-forward only or rebase local changes.

What about merging develop into branches?

Tried Ivan’s serialization branch:

Error	2	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector	2144
Error	3	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	4	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	5	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	6	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	7	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	8	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	9	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611
Error	10	error C2280: 'std::unique_ptr<T,std::default_delete<_Ty>>::unique_ptr(const std::unique_ptr<_Ty,std::default_delete<_Ty>> &)' : attempting to reference a deleted function	C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xmemory0	611

Not very informative. Here’s compilation log:

pastebin.com/hSRE1vVG

This is different question.(Also, I do not care about branches.) As for me I rebase small and my own branches and merge large long-term branches and branches with more than one contributor.

I recently tried to compile VCMI via MinGW/CMake and encountered this error:

  1%] Built target minizip
  1%] Building CXX object lib/CMakeFiles/vcmi.dir/filesystem/FileStream.cpp.obj

D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp: In function 'void* fopen64_file_func(voidpf, const void*, int)':
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp:22:58: error: 'fopen64' was not declared in this scope
 #define FOPEN_FUNC(filename, mode) fopen64(filename, mode)
                                                          ^
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp: In function 'fpos_t ftell64_file_func(voidpf, voidpf)':
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp:23:44: error: 'ftello64' was not declared in this scope
 #define FTELLO_FUNC(stream) ftello64(stream)
                                            ^
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp: In function 'long int fseek64_file_func(voidpf, voidpf, fpos_t, int)':
D:\C++\VCMI_BUILD\VCMI\Source\lib\filesystem\FileStream.cpp:24:76: error: 'fseeko64' was not declared in this scope
 #define FSEEKO_FUNC(stream, offset, origin) fseeko64(stream, offset, origin)
                                                                            ^
lib\CMakeFiles\vcmi.dir\build.make:357: recipe for target 'lib/CMakeFiles/vcmi.dir/filesystem/FileStream.cpp.obj' failed
mingw32-make[2]: *** [lib/CMakeFiles/vcmi.dir/filesystem/FileStream.cpp.obj] Error 1
CMakeFiles\Makefile2:139: recipe for target 'lib/CMakeFiles/vcmi.dir/all' failed
mingw32-make[1]: *** [lib/CMakeFiles/vcmi.dir/all] Error 2
Makefile:148: recipe for target 'all' failed
mingw32-make: *** [all] Error 2

Is there a way to fix it?

I think update MinGW is the only solution. What is your versions of MinGW itself and gcc?

I’m currently using gcc 5.1.0, but if there is newer version I’ll certainly update it, thanks.
BTW, I didn’t install Qt5 package, which is needed just by launcher (if I’m not mistaken), and version 5.1.0 of gcc seems to be still the latest one for windows.

gcc 5.1.0 is more than enough, but what is “version of MinGW itself”?

Also try add

#define __USE_MINGW_ANSI_STDIO 0

before

#include <cstdio>

In FileStream.cpp

Hmm, honestly I don’t know how to figure it out :blush:. I’m using TDM-GCC package, which has required toolchain included. For now I managed to get version of mingw32-make, which is 3.82.90; in other hand headers and libraries are from version 3.20.

Im using [MinGW-w64](https://sourceforge.net/projects/mingw-w64/), never tried TDM. May be its a TDM bug.

Ok, seems like it works now :slight_smile: with your package, many thanks.

Anyway, please report this in tracker. We should support TDM too.

If that wasn’t done before I’m think it’s worth to block force push for develop branch:
github.com/blog/2051-protected- … tus-checks

We never had problem with that before, but I think it’s would be handy to make it impossible to damage develop accidentally. Important for me since I’m sometimes force push to my branches and each time it’s give me similar feeling like using “rm -rf” do. :-/

Added new category to Mantis: Multiplayer.

Thanks!

So since I’m working on automated tests there some interesting features (private branch ) that soon will land into develop or appear as separate PR:
[ul]]Headless mode for client. “gNoGUI” fixed and improved./:m]
]Spectator view for adventure map and battles. When client running with “–spectate --onlyAI” options in any new game there will be player interface with full visibility./:m]
]OnlyAI support for games loading. On loading all human players replaced with AI./:m][/ul]Everything is WIP, but already working. All those options should help a lot with debugging of adventure map and battle AIs, bugged save games, etc.

Hi.

I was looking on VCMI code and I have few questions.

  • Creature limit - why do you use signed int32 for creature number? Why not si64? si32 usage and other small types are present in many places.
  • Signed overflows seems to happen in many places.

Just like many other things in VCMI this most likely for historical reasons: it’s was implemented that way back when project started 10+ years ago and no one changed it since.

It’s super easy to change while keeping backward compatibility for saves.

Yeah and there also tons on very shady type conversions going all around code that building with MSVS tend to report. We’re as developers don’t try to stick to weird code or bad practices, but our time is limited and so far there were always more important things that need attention.

So if you wish to help us fix something like that we’ll be happy to see PR.

  1. Creature number can be negative. It means causalties and other events that reduce the number of creatures.
  2. It is easy to check for overflow of signed value and prevent / fix it.
  3. Damage number is 64-bit. This ensures that 32-bit count multiplied by 32-bit creature number doesn’t give us overflow with 64-bit damage number.
  4. There is absolutely no reason to allow more than 2 billion of creatures in a stack.