I don't think it is possible since this is using the autogenerated cpp files from the protobuf (it uses commands->actions(i) rather than commands->actions[i] so the "array" of actions is actually a functions which deserializes the given action from an index). Otherwise, I would definitely prefer it!

Ah right, I always suggest it, then look after at the code XD

?

You could make the lock mutable. This is a common well defined pattern exactly for mutexes. See https://en.cppreference.com/w/cpp/language/cv

Probably yes.

I believe it will, yes.

Why do you think it might not work? Perhaps there's something more I can explain about how our simulation works :)

I had assumed that GUIInterfaceCalls required a GUI to be present. I don't fully understand how it all fits together just yet :/

After looking at the code a little more, I see an example where script calls are made from the GuiInterface for getting the replay metadata. Is this what you mean by GuiInterfaceCalls? It also looks like that example uses CmpPtr rather than GetEntitiesWithInterface and I don't quite understand how these are meant to be combined. I had been getting the AI interface but it seems here that I need entities with the AI interface (since I am going to be calling "GetFullRepresentation") but they also need to have the GuiInterface (since I need to make ScriptCalls).

I am sure I am misunderstanding but if you could provide some guidance or clarity, it would be much appreciated :)

As an example of what I have been playing around with. The following code fails as expected but might help illustrate how I understand the suggestion (incorrect but maybe it will be helpful):

CSimulation2* sim = g_Game->GetSimulation2();
CSimulation2::InterfaceList ents = sim->GetEntitiesWithInterface(IID_GuiInterface);
entity_id_t ent = ents.front().first;
const CSimContext simContext = g_Game->GetSimulation2()->GetSimContext();
CmpPtr<ICmpGuiInterface> cmpGuiInterface(simContext, ent);

ScriptInterface& scriptInterface = sim->GetScriptInterface();
JSContext* cx = scriptInterface.GetContext();
JSAutoRequest rq(cx);

JS::RootedValue arg(cx);
JS::RootedValue state(cx);
cmpGuiInterface->ScriptCall(INVALID_PLAYER, L"GetFullRepresentation", arg, &state);  // This fails as the fn is only defined for the AI interface. Switching to use the AIInterface fails to compile since "ScriptCall" is not defined for ICmpAIInterface.
return scriptInterface.StringifyJSON(&state, false);

I had assumed that GUIInterfaceCalls required a GUI to be present. I don't fully understand how it all fits together just yet :/

Indeed it doesn't.
To paint the global picture: the simulation JS context is distinct from the GUI JS context, to avoid issues with the GUI modifying the simulation. So the GUIInterface is a "Simulation" component, tasked with sending and receiving information to/from the GUI Context.

When you call something in the GuiInterface, you're calling the simulation.

Components can also be "system" or local to an entity. The GuiInterface is a "system" component. Your (understandable) mistake was thinking that each entity has a GuiInterface like they have an AIProxy. AIInterface is also a system component, by the way.

CmpPtr is just a C++ wrapper to a component pointer.

So to recap, what you need to do is something like this (compilation not guaranteed):

CSimulation2* sim = g_Game->GetSimulation2();
// Here I fetch a list of all entities in the game with an IID_AIProxy.
CSimulation2::InterfaceList ents = sim->GetEntitiesWithInterface(IID_AIProxy);
// Query the GUI Interface of the system.
CmpPtr<ICmpGuiInterface> cmpGuiInterface(sim, SYSTEM_ENTITY);

ScriptInterface& scriptInterface = sim->GetScriptInterface();
JSContext* cx = scriptInterface.GetContext();
JSAutoRequest rq(cx);

for (entity_id_t ent : ents)
{
	// this is per-entity
	CmpPtr<ICmpAIProxy> cmpAIProxy(sim, ent);
	std::string test = cmpAIProxy->GetFullRepresentation();
}

cmpGuiInterface->ScriptCall(INVALID_PLAYER, L"GetSimulationState", arg, &state);

return scriptInterface.StringifyJSON(&state, false);

The thing is this still relies on AIProxy, so it's kind of the same as using AIInterface... And it need s aC++ AI Proxy component :/

So to be honest I'm not sure it's much better than what you have now, after all.