Using Ebus calls in a Gem provided by another gem does not do anything.

[lime shard]

There are some possible troubles:

You may need to include the gem dependency in your gem's cmakelists.
Like so:

ly_add_target(
    NAME ${gem_name}.Private.Object STATIC
    NAMESPACE Gem
    FILES_CMAKE
        gs_audio_private_files.cmake
        ${pal_dir}/gs_audio_private_files.cmake
    TARGET_PROPERTIES
        O3DE_PRIVATE_TARGET TRUE
    INCLUDE_DIRECTORIES
        PRIVATE
            Include
            Source
            ${LY_ROOT_FOLDER}/Gems/MiniAudio/Code/Source/Clients
    BUILD_DEPENDENCIES
        PUBLIC
            AZ::AzCore
            AZ::AzFramework
            Gem::LmbrCentral
            Gem::GS_Core.API
            Gem::MiniAudio.API
        PRIVATE
            3rdParty::miniaudio
            3rdParty::miniaudio_libvorbis
            3rdParty::miniaudio_reverb_node
)

For the debug draw: You may need to decouple your component into a runtime component, and an editortime component. As the editor targets have dependencies for AzToolsFramework and other engine-only code. This is why there's a GemModule, and GemEditorModule.

ly_add_target(
    NAME ${gem_name}.Editor.Private.Object STATIC
    NAMESPACE Gem
    FILES_CMAKE
        gs_audio_editor_private_files.cmake
    TARGET_PROPERTIES
        O3DE_PRIVATE_TARGET TRUE
    INCLUDE_DIRECTORIES
        PRIVATE
            Include
            Source
    BUILD_DEPENDENCIES
        PUBLIC
            AZ::AzToolsFramework
            Gem::${gem_name}.Private.Object
            Gem::GS_Core.API
)

[crisp glade]

I tried adding the physic Gem to the Static section. It is required to get the header visible in the source what is odd is that I don't get any errors it is like the Gem is isolated from whatever is connected to the bus system. It does work with AzFramework buses I can use the event correct but not outside gems.

I looked at the multiplayer example and the project components are not stored in Gems. I don't know how much of that effects logic.

[lime shard]

Yes to my understanding physx is just a subset of AzFramework.

Have you tried different components to see if they also do not respond to events, or if it's just the character controller?

[crisp glade]

The only two I was trying to use what Debug Draw and Physix Character controller

I can't use the ebus system with them

I was helped by one of the O3DE developers and they took me threw the process of getting a reference to the handler but I couldn't even get that.

It is like the Gem is isolated

I can use the debug draw from SC

[lime shard]

Can you share your complete gem cmakelists?

The one in /code/.

Can you share your character component? The one that exposes these nodes and calls these particular busses?

[lime shard]

Some things I'm noticing:

• I notice that your delta input is a const AZ::ScriptTimePoint& you can simply input a float.
• You're also not using delta anywhere in the method. I'm surprised you're not getting "This error is a warning" compile errors for not using it.

Regarding turning there's a few points:

• Updating the transform directly will likely not take, as at some point before or after the change to transform, the physics tick kicks in and overrides the data. You often want to use Rigidbody: UpdateWorldTM (transform), but I'm not exactly sure how that works with the character controller.
• It doesn't appear to be that the physx character controller has any logic around character rotation, but you can GetRigidbody and affect angular velocity (which will play directly with the velocity stuff), though it's a little less concrete as setting rotation.

Regarding the logic of your movement and rotation.
It's common place to alter the actual input values based on camera forward, and then move and rotate based on that.

// Get camera basis
AZ::Transform cameraTransform = AZ::Transform::CreateIdentity();
AZ::TransformBus::EventResult(cameraTransform, cameraID, &AZ::TransformBus::Events::GetWorldTM);

AZ::Vector3 camForward = cameraTransform.GetBasisY(); // Y is forward in O3DE
AZ::Vector3 camRight   = cameraTransform.GetBasisX();

// Flatten to X-Y plane
camForward.SetZ(0.0f);
camRight.SetZ(0.0f);
camForward.Normalize();
camRight.Normalize();

// Desired move direction
AZ::Vector3 desiredDir = (camForward * input.GetY() + camRight * input.GetX()).GetNormalized()

That gives you your desired input, rotated to camera forward.

Because that move direction is now normalized, you can multiply it by speed, and delta:
Vector3 moveVel = desiredDir * GetMoveSpeed * deltaTime

Because you have this as a component, you can also make things like "setcamera" and stuff so you don't need to pass it through every time. Not critical though.

I handle the events and reflection a bit differently:

if (AZ::BehaviorContext* behaviorContext = azrtti_cast<AZ::BehaviorContext*>(context))
{
    behaviorContext->Class<MyCustomComponent>("MyCustomComponent Component Group")
        ->Attribute(AZ::Script::Attributes::Category, "GS_Audio Gem Group")
        ;

    //Reflected Event Calls (Scriptgraph call function.)
    behaviorContext->EBus<MyCustomComponentIncomingEventBus>("MyCustomComponentIncomingEventBus")
        ->Attribute(AZ::Script::Attributes::Category, "GS_Play/GS_Audio")
        ->Event("Set Listener", &AudioManagerIncomingEventBus::Events::SetListener)
        ;
}

Because the bus itself is the one actually exposing the event calls, you rarely need to actually reflect the component methods.
I usually skip it in behaviour context and simply reflect the ebus, like you have done.

[crisp glade]

You are making alot of assumptions

[lime shard]

Seeing what you're doing to handle this character. I honestly advice just using a dynamic rigidbody. That allows you to:

• Get and Set the Rigidbody Transform.
• Get and Set Linear Velocity, and Angular Velocity
• Handle enabling and disabling physics as you desire. Among other rigidbody things.

And it all uses the same logic you're already using.

[crisp glade]

I made several versions of this function trying to get it to work

[lime shard]

You just need to lock X and Y rotation in the dynamic rigidbody component.

[crisp glade]

the code I sent you works fine if I use the Addvelocity from physics in SC

the TransformBus simply doesn't work when called in C++

when I use the movement vector that the code generates in SC this logic give the desired result

The issue is that ebus calls from Gems don't seem to be avialble

[lime shard]

I'm pretty sure it's because the transform variable is being lost because the physics system is overriding it.

[crisp glade]

no

the logic is fine

[lime shard]

I'm sorry I guess I can't help you. I use the Transform bus constantly and it works fine for my needs.

[crisp glade]

all the node does is call the same CharacterController Bus I am in C++

it uses a Script Canvas Function

the issue I have is Gem external EBus are not accessible to this gem

[lime shard]

The thing is that Script Canvas nodes are often being handled at vastly different times, and with underlying logic that can handle additional details that C++ does not factor in.

Is this C++ component on the same entity as the script graph, and the Character controller?

so the Transform Bus is what's returning you a nullptr?

What is returning a null ptr then?

I am not privvy to accessing ebus instances, as I've never had to use them in that way. Only listening, and calling events through them. They are simply a delegate systems to pass messages between systems without needing a direct reference to the variable or class.

I've raised attention to the issue on #sig-content, I'm not sure what else could be the problem.

That's what I use regularly.

Sorry I couldn't help any further. Good luck.

[hoary orbit]

Its not a high cost i think its like a few ns it adds to calling, the reason I did it anyway was because im calling the ebus a lot.

oh wait are you talking about ebus having a cost in the context of script canvas/lua?

alright just wanted to make sure your not thinking ebus calls are insanely expensive, they're more than calling just the ptr but its not like ms levels

or like 100~ ns.
i wish i had the exact numbers still but i dont remember where it came from

[outer coyote]

If it simply doesn’t respond than the ID is likely not valid. There won’t be an error when you try to make a request to an EBus address if it’s not connected to the EBus it’ll just not do anything.

[outer coyote]

I haven’t used SC before but in C++ bus connection sometimes has to be done in the OnEntityActivated function. I will share my code that I used to build a rough click to move controller with the PhysX Character Controller. Take a look at the buses and see if there is anything that is different between yours and mine.

void OldPlayerControllerComponent::Activate()
    {
        m_attachedSceneHandle = AzPhysics::InvalidSceneHandle;
        Physics::DefaultWorldBus::BroadcastResult(m_attachedSceneHandle, &Physics::DefaultWorldRequests::GetDefaultSceneHandle);
        if(m_attachedSceneHandle == AzPhysics::InvalidSceneHandle)
        {
            AZ_Error("Character Controller Component", false, "Failed to retrieve default scene.");
            return;
        }

        UiCursorBus::Broadcast(&UiCursorBus::Events::IncrementVisibleCounter);

        AZ::TickBus::Handler::BusConnect();
        AZ::EntityBus::Handler::BusConnect(GetEntityId());
        AzFramework::GameEntityContextEventBus::Handler::BusConnect();
        StartingPointInput::InputEventNotificationBus::MultiHandler::BusConnect(SetDestinationEventId);
        PlayerControllerRequestBus::Handler::BusConnect(GetEntityId());
    }

The player controller request is the last to connect to.

Because if it is working in SC and not C++, than you are likely just not connecting to the character bus correctly.

Correct, and the characterbus is an event

Physics::CharacterRequestBus::Event(
                                m_playerPawnEntityID,
                                &Physics::CharacterRequestBus::Events::AddVelocityForPhysicsTimestep,
                                AZ::Vector3(velocity.GetX(), velocity.GetY(),
                                            0.0f)
                            )```

Why would I delete them?

It's not clear to me if I've answered your question or not.

Are you able to get the default scene handle?

[outer coyote]

The reason I ask is if this fails, then you know you don’t even have a scene to get the interface from.

m_attachedSceneHandle = AzPhysics::InvalidSceneHandle;
        Physics::DefaultWorldBus::BroadcastResult(m_attachedSceneHandle, &Physics::DefaultWorldRequests::GetDefaultSceneHandle);
        if(m_attachedSceneHandle == AzPhysics::InvalidSceneHandle)

People here do this in their spare time while working other jobs. I am happy to help, but I also don’t have the bandwidth to read the entire conversation and I need some effort from your side as well.

Then I’m afraid you will have to wait for someone else’s help.

[outer coyote]

I’m actually not 100% sure this isn’t an AI now…

[trail swift]

<modhat>

Alright, this has gone on long enough.

@crisp glade I have watched multiple subject matter experts attempt to help to help you, and all of them have grown frustrated at your combative responses, apparent unwillingness to listen to what they're trying to tell you, and your subsequent (misguided) disparagement of the engine and the members of this community. I have seen you flat-out say you shouldn't have to change your own way and it should still just work.

I understand you've read a book about O3DE, but what may have worked in the version about which the books have been written may have changed to one degree or another. Gaian, Nick, and Reece work in and on the current version every day. They know the engine as it is currently. You would do well to take a step back and reconsider the approaches they've already recommended to you, because it's very clear to all of us who are watching that your approach is fighting against the engine as it is today, instead of working with it. Most of the people here are volunteers, who are donating their time and energy to you in a genuine effort to help you, literally out of the goodness of their hearts. That alone deserves better treatment than what you've been giving them.

Furthermore, you do not have the authority to tell others to delete their posts. Even if you're not finding them helpful right now, it does not mean others will not find them helpful. So please stop.

This is officially a warning. If you continue the way you have, the next step will be a time out.

If you want a better experience going forward, my suggestions are:

• be open to the possibility that it might, in fact, be you who are incorrect or going about something the wrong way, and that's okay to be wrong
• recognize that you cannot control what others do, you can only control yourself
• if people keep giving you what seems to you to be unhelpful or "bad" advice, consider at the very least that you're not explaining yourself clearly and change your own approach
• be willing to learn. As the saying goes, you can't fill a cup that's already full.

Now, I recommend taking a break, going for a walk if the weather is conducive to it where you're at, and re-engaging with your work and the community with fresh eyes and a clear mind.

</modhat>

[trail swift]

Your response here is exactly the kind of response I was referring to, where instead of taking a step back and taking some time to think about your own behavior and responses, you immediately jump to blaming others. It's been a pattern of behavior since you've joined, and it makes for a toxic experience that turns people off from helping.

"this is all projection and you are just justifying your feelings." is blaming

Genuine question - are you Autistic, by any chance?

[outer coyote]

The issue is that you have labelled the suggestions of folks who know the engine a whole lot better than you as useless text. I am halfway through building a new physics engine integration, so when I ask if you can get a valid scene handle, it’s not because I don’t understand the problem.

[trail swift]

I said nothing about being crazy, nor did I make any assumptions about where you're from. A very large portion of the community here is from non-Western countries, with many from what's often referred to as "the Global South." An assumption of someone being Western would be entirely baseless. The only assumptions being made here are yours.

I asked if you were Autistic, because I am, and I'm watching you fall into the very trap that I myself have fallen into on many occasions when I was younger, and that I've seen others fall into, where you don't realize you're exhibiting a particular pattern of behavior that is to some degree toxic, the moderator comes down on you, and in the subsequent discourse, which pretty much universally results in escalating frustration and often a total ban from whatever community, all because you did not understand what the behavior was that got you into trouble in the first place. I don't want sucked into that trap on the moderator side, so this is me breaking that cycle in a genuine effort to help you engage with this community in a healthier manner.

[outer coyote]

Right, but we are not all Russian and your strong language might be considered offensive or rude in other people’s culture, such as mine. Everybody needs to meet in some middle. It is not fair to ask everyone to meet your expectations.