This fixes several issues with compatibility with C++20. C++23 was also
tested, but apparently it does not have any additional breaking changes
compared to C++20 (or we don't have those).
VCMI still uses C++17 as before - goal is only to make potential
transition easier.
There were 2 cases that are deprecated in C++20 that we use:
- Floating point operations on enums are deprecated
- `this` can no longer be captured when using default capture by value
`[=]`
Both of those should now be replaced with code that works fine in both C+
+17 and in C++20 mode
- class CGuiHandler is now called GameEngine to better describe its
functionality
- renamed global GH to more clear ENGINE
- GH/ENGINE is now unique_ptr to make construction / deconstruction
order more clear and to allow interface / implementation split
- CGuiHandler.cpp/h is now called GameEngine.cpp/h and located in root
directory of client dir
- Replaced overcomplicated and broken math on dwelling ID's with fixed
enum
- Fixed broken 2nd upgrades and 8th dwelling
- Removed no longer used enumeration values from building ID's
Final goal (of multiple PR's) is to remove all remaining pointers from
serializeable game state, and replace them with either identifiers or
with shared/unique pointers.
CGTownInstance::town and CGHeroInstance::type members have been removed.
Now this data is computed dynamically using subID member.
VLC entity of a town can now be accessed via following methods:
- getFactionID() returns ID of a faction
- getFaction() returns pointer to a faction
- getTown() returns pointer to a town
VLC entity of a hero can now be accessed via following methods:
- getHeroTypeID() returns ID of a hero
- getHeroClassID() returns ID of a hero class
- getHeroType() returns pointer to a hero
- getHeroClass() returns pointer to a hero class
- This is more clear - in case if building generates queries
- Avoids some edge cases, like what to do if building is single-use and
town has 2 heroes
- In line with hota version of this feature
