C++ and script events

Hi,

I would like to have my component register new script events at start, so I can build handlers for these events in script canvas.

My first question is : Do I need to create a Gem Editor Component for this ?

I haver read this doc but the answer is not obsious to me :thinking: Should I create an editor component for my Gem, in which the registration of these events would be done, in the Activate() method, or should I do all this from my Gem runtime code.

I was thinking of using the ScriptEventsBus and ScriptEvent Gem api to register my events, and later on, at runtime, fire them.

May be anyone have already explorated this path ? :slight_smile:

Thank you all,

Yan

P.S :

I am trying this as a workaround to this issue who was anyway not a good way to go.

Hi @Yan,

Script Events are intended as a way to create a data-driven messaging system that does not need C++, it’s intended use is with Script Canvas and/or Lua.

If you wish to send events from C++ you may want to consider writing a Request EBus and reflecting it to the Behavior Context, most components in the LmbrCentral gem have examples, the one I usually use as reference is the Light Component EBus.

I looked at the issue you’re trying to workaround and I’m not certain how sending events from C++ will help with that problem, have you checked if there are any errors or warnings on the console in the editor?

Hi @LS1

Thanks for helping :slight_smile:

I have been reviewing the documentation meanwhile, and found that indeed I don’t need script events.
I have written a notification BUS that I am trying to reflect to the behaviour context.

I’m not also sure this will solve my threading issue, but this seems to be a better architecture than the previous one. At least it will permit me to use Script Canvas and gain in productivity.

So at this moment I have a notification bus handler defined this way :

namespace eGem
{
    class eGemEntityServiceNotificationBusHandler
        : public eGem::eGemEntityServiceNotificationsBus::Handler,
          public AZ::BehaviorEBusHandler
    {
    public:
        AZ_EBUS_BEHAVIOR_BINDER(eGemEntityServiceNotificationBusHandler, "{15e4b034-90eb-4d31-a1be-45470b92de79}", AZ::SystemAllocator,
                                OnEntityCreated,
                                OnEntityDestroyed,
                                OnEntityActivated,
                                OnEntityDeActivated);

        void OnEntityCreated(AZStd::string id, AZStd::string name) override
        {
            Call(FN_OnEntityCreated, id, name);^M
        }
        void OnEntityDestroyed(AZStd::string entity_id) override
        {
            Call(FN_OnEntityDestroyed, entity_id);
        }
        void OnEntityActivated(AZStd::string entity_id) override
        {
            Call(FN_OnEntityActivated, entity_id);
        }
        void OnEntityDeActivated(AZStd::string entity_id) override
        {
            Call(FN_OnEntityDeActivated, entity_id);
        }
    };
} // namespace eGem

I am then reflecting this Handler to the behaviour context :

void entity_service_impl::Reflect(AZ::ReflectContext *context)
{
    AZ::BehaviorContext *behaviorContext = azrtti_cast<AZ::BehaviorContext *>(context);
    if (behaviorContext)
    {
        behaviorContext->EBus<eGem::eGemEntityServiceNotificationsBus>("eGemEntityServiceNotificationsBus")
            ->Handler<eGem::eGemEntityServiceNotificationBusHandler>();
    }
}

But I am facing a small issue here : My class entity_service_impl is not part of RTTI and so is missing reflection context, and so my Reflect method doesn’t seem to be called.

I’ve added AZ_TYPE_INFO(eGem::entity_service_impl, "{3f841977-55bf-4177-98d4-1b736251c79c}"); in entity_service_impl header, but upon what I understood I need also to use AZ_TYPE_INFO_SPECIALIZE macro to reflect the parent class.

I have so added in the header file, before entity_service_impl declaration.

  namespace AZ {
    AZ_TYPE_INFO_SPECIALIZE(eGem::entity_service::Service, "{38350915-084B-4886-8D3D-B8439E9E987C}");
  }

But still no luck, the event doesn’t show into Script Canvas, most probably my Reflect method is still not called.

It is working fine if I reflect the notification handler from the Gem component though.

Thanks again for helping,
Nice day,

Yan

Sorry for the delay, I don’t seem to be getting notifications from the forum anymore, I will look into that.

I believe you want to use AZ_RTTI instead of AZ_TYPE_INFO

AZ_RTTI(eGem::entity_service::Service, "{38350915-084B-4886-8D3D-B8439E9E987C}");

however, you also need to provide the Reflect method yourself:

add to your class the following, you can find many example if you look for that same function signature:

static void Reflect(AZ::ReflectContext* context)
{
    // your reflection code
}

Hi LS1

Don’t worry for the delay, most of my issues are coming from the fact that I haven’t been doing c++ for more than 10 years, they are not related to Lumberyard somehow.

I made some progress meanwhile.

As a workaround to the issue above, I have create a new system Component whose class inherit both from Component and from my GRPC service implementation.

This permits also to regenerate the GRPC service wihout updating too many files.

Reflect() is now called, as it should, in this new component and I can see my GRPC events into Script Canvas thanks to the Behaviour context.

I can also post to the notification Bus when GRPC events are received.

But I’m facing a new noob issue :slight_smile:

I am feeling the Activate() method and Deactivate() are not called in this new system component although it is registerd in the Module code file as component and system component.

I don’t have access to the project configurator because of Perforce issue that came back with 1.24, but I have checked Editor.XML and the Gem is there.

I can join some source files to the thread if you think it could be usefull.

Thanks for the help,

Yan

P.S: @LS1 I am not receiving notifications either. I’ve noticed the number of view of the thread isn’t displayed, I’m so not sure this thread is Active or published.