Savegame format freeze lifted

As I am reworking serialzier, save format will be broken anyway.
So if you have any planned changes that will break save format, now it is the time to make them.

Probably I’ll fix this by moving specialty bonuses directly to hero node.
Also would like to implement formulas for calculating bonus values on the fly (additional field), but it may be complicated feature and take time.

Ok will commit deep refactoring for spellhandler (and now with modable spells including addition of new).

What’s exactly wrong there? It should just work and it certainly did once work.
Perhaps serializer improvements will allow proper fixing this issue without moving things around.

Along with the shared_ptr I’m adding proper support for multiple inheritance, so many workarounds currently needed to serialzie bonus tree won’t be needed anymore. [basically, it’ll be possible to directly serialize CBonusSystemNode*]

Oh, and it’ll be possible to use pointers to abstract classes.

The issue is that hero can’t be attached to it’s member object (specialty) - more precisely, such relation is not serialized properly.

It is not particular to hero specialties. The connections between bonus nodes are never serialized, that’s why deserializationFix methods were introduced. I see you commented out restoring connections from CGHeroInstance::deserializationFix, that’s why it is lost after load.

The serializer rewrite will allow proper serializing the bonus tree nodes relations, so the deserializationFix functions won’t be needed anymore. The #1599 should be fixed with that as well.

That sounds risky. Having a list of bonuses should always be enough calculate their value. Otherwise, some problems might arise.

What are the use-cases?

Most certainly, hero specialties that depend on hero level. Currently they are difficult to manage and all based on workaround limited to typical cases.
Not to mention all the modders aks for it.

The use case is certainly important but bonus evaluation should not depend on the game state. Bonuses can be propagated outside their nodes.

Eg. what happens if I make a hero specialty bonus like “-1 to enemy morale for every 5 levels”? In such case enemy player to know morale of his troops need to know the level of enemy hero. This breaks cheat-proof MP design — private information about enemy should not be assumed to be present.

What we should look for here is rather a mechanism of automatically updating bonus value upon hero level change. This works the same from modder perspective and remains alright with the engine.

I’m not sure if value updating rules should be actually a part of bonus system. It is already big and complex, we should not overdo it or it will become some crippled substitute for the actual scripts support.
On the other hand… current approach to handling specialties feel even more crippled, so it may have sense to formalize updating rules for bonuses.