we can do the research type-specific directly with nyan by testing the patch hierarchy:

// this procedure may of course change, but the principle will most likely remain.

nyan::Object research = ...;  // the research nyan object that now shall apply
// apply the research patch
nyan::Transaction tx = database.transaction();
for (auto &patch : research.get<nyan::Patch>("patches")) {
    tx.add(research);
}
tx.apply();

if (research.extends("openage.research.AgeAdvance")) {
    // do things for age advancements that nyan didn't patch (i don't know what that would be, maybe gui updates?)
}

(I'm back)

EDIT: This was actually a typo: advance_age is handled at the first if, this was supposed to be generic, thinks that couldn't be handled just with nyan (eg. research that allows to see the enemy line of sight).
However my following explanation for the advance_age still stands

The code you posted will be
inside NyanResearchType::apply ->
which ovverides ResearchType::apply ->
which is called inside Reaseach::apply ->
which is called from the ReaseachAction::update

Notes:
ResearchType immutable (contains the name, cost, patch ...)
Reaseach muttable (is active, is completed ...)

Based on that when the gui will have to draw the progress bar at the top of the screen it need only action.research.get_categroy() == advance_age and action.timer.get_progress()

No need for the gui to dive into the nyan hierarchy...

Welcome back :)
Ah now I get it. Yes, we need to implement some research types in the engine, e.g. the line of sight. This would be done by specifying an object layout in nyan, which is then used by the c++-part to evaluate the data changes, e.g. the line of sight or whatever is needed. The switching of which c++-part to use still has to be done with a nyan-query, though.

The call hierarchy is correct I'd say. It would be a nice abstraction over the nyan backend.
I also like the difference between Research and ResearchType (i.e. ongoing vs its type).

To make the gui nyan-independent should be a high goal :D

This wrapping of nyan-types is a great idea to write the interface to nyan: Then we'd have C++-classes that do the intended access to nyan objects (=> they're tightly coupled) and the rest-code can just use the C++-interface. The way it should be done.

I think this should go into a separate file. All those monster files deserve to be split up, actually :)

This timer triggering should be synched with @Tomatower's event triggers, where such a timer would be registered and you'd get a function call for the right time. Might be a very good start for integrating into the event-architecture.

@Tomatower code is far away and huge changes will have to be made in order to be able to move into curves (I will write more at his pr)

@TheJJ I'm not making a new file because the timer is a stepping stone to transition better to Events or Curves (I prefer Curves, more at #744)
(no problem if you insist)

The events are actually designed for that, and the only thing that is missing is a nice Api in the game engine - hopefully without major changes to the existing codebase - so inspire me for the best possbile api 😃

indent, and default value assignments don't have spaces around the = please

where does triggers come from? currently its the uninitialized member.

Why can this even compile? It must obviously be zero