[ISSUE][DOCS] Components and EBuses page: Restructure

[mythrz]

Describe the issue

It does not have a hand-hold explanation that covers everything the dev needs to do. It covers only some of the necessary points, but there are too many gaps to cover.

• no mention of where to create the classes
• no mention of the #includes
• no mention of the cmake changes in case you create a new class
• no mention on how to call/use/execute the ebus on the component that "triggers"/"requests" the information
• use typedef instead of using (modern cpp)

Impacted page(s)

https://www.docs.o3de.org/docs/user-guide/programming/components/ebus-integration/

Expected experience

Any senior or junior dev, any student that is starting is degree or college student, can follow the tutorial and finish it. Hand-hold examples or "hello world" examples are a must.

---

Preliminary drafts:

• Draft 1: [ISSUE][DOCS] Components and EBuses page: Restructure #2712 (comment)
• Draft 2: [ISSUE][DOCS] Components and EBuses page: Restructure #2712 (comment)
• How to use tabs in the website: [ISSUE][DOCS] Components and EBuses page: Restructure #2712 (comment)

PR, coming soon:

• TODO

---

Parent is:

• [ISSUE][DOCS] Getting started and retaining devs in O3DE eco-system. Focus: Event Messaging, Gem Creation, Component Creation. Tracking all issues #2710

[mythrz]

Proposal in the form of baby steps. (1st Draft)

This tutorial will assume that you already have custom components inside your gem. The goal is for Component1 to hold information (a vector of strings); and the other (Component2) can request it when ever it wants to use it. The example is using UI-Canvas and UI-Slices, but this is not a requirement; its just a usecase scenario that many have to go through when working with LyShine and any other example could have been choosen; the only thing we use from the UI-Canvas is the upmost UI-Element as our Address ID.

Gem Name: Character088v3
Component1: TechSpells003
Component2: DropDownDropTarget
New Folder: Bus
New File: SpellRequests.h
Traits: ComponentBus default traits
ID: Upmost UI-Element from a UI-Canvas
Components: UI components attached to two different UI-slices

I have custom folders in the source folder too, but these do not affect the tutorial/example

(OPTIONAL)

• Create a new folder called "Bus" inside the Include\Character088v3
• Create a new file called "SpellRequests.h"
  You should have something like this:

• Inside your EBus Requests file, write something similar to this (SpellRequests.h). Notice the reference &, this will allow you to initialize the vector of strings, pass the reference, and then fill the vector.

#pragma once

#include <AzCore/Component/ComponentBus.h>
#include <AzCore/std/string/string.h>
#include <AzCore/std/containers/vector.h>

namespace Character088v3
{
    class SpellRequests: public AZ::ComponentBus 
    {
        public:
            virtual void GetSpells(AZStd::vector<AZStd::string>& options) = 0;
    };

    using SpellRequestsBus = AZ::EBus<SpellRequests>;
}

• In your gem _api_files.cmake (Character088v3_api_files.cmake), (1) add the relative path to your EBus Requests file (SpellRequests.h)

set(FILES
    Include/Character088v3/Character088v3Bus.h
    Include/Character088v3/Character088v3TypeIds.h
    Include/Character088v3/SpellBook003Interface.h #
    Include/Character088v3/TechSpells003Interface.h #
    Include/Character088v3/ListDragSearch003Interface.h #
    Include/Character088v3/DropDownDropTargetInterface.h #
    Include/Character088v3/Bus/SpellRequests.h # (1) This one is the one you need to add
)

• In the Component1 (TechSpells003), the holder of information, search for the component header (TechSpells003Component.h). (1) Add a new #include, (2) inherit your EBus, (3) and override the method.

#pragma once

/// some other includes...

#include <Character088v3/Bus/SpellRequests.h> /// (1) this is the EBus you need to include

namespace Character088v3
{
    class TechSpells003Component: 
          public AZ::Component, 
          public TechSpells003RequestBus::Handler, 
          public SpellRequestsBus::Handler /// (2) this is the inherited EBus you need to add
    {
    public:
          /// rest of your code...
         void GetSpells(AZStd::vector<AZStd::string>& options) override; /// (3) your method here.

/// rest of the code

• Still in Component1 (TechSpells003 ), search for the component .cpp (TechSpells003Component.cpp). (1) Add your method anywhere you want, but make sure it is inside your namespace. This is where the information (vector of strings) will live. You can change this to what ever you want. Read a file from disk, a json, a database, a web API etc... The reference & comes into play here, since you are passing a reference, you can fill those options here for later use in Component2 (DropDownDropTarget).
• You also have to (2) connect and (3) disconnect the bus with a specific (4) ID. This (4) ID must be the same in both components (TechSpells003 and DropDownDropTarget).

namespace Character088v3
{
    /// rest of the code...
    
    void TechSpells003Component::Activate()
    {
        TechSpells003RequestBus::Handler::BusConnect(GetEntityId()); ; 
        SpellRequestsBus::Handler::BusConnect(TechSpells); /// (2) Connect your bus with (4) TechSpells ID
    }
    void TechSpells003Component::Deactivate()
    {
        TechSpells003RequestBus::Handler::BusDisconnect(GetEntityId());
        SpellRequestsBus::Handler::BusDisconnect(TechSpells); /// (3) Disconnect your bus with (4) TechSpells ID
    }

    ///  (1) your method that holds the information
    void TechSpells003Component::GetSpells(AZStd::vector<AZStd::string>& options) /// notice the &reference
    {
        AZ_Printf("TechSpells003Component", "TechSpells003Requests::Event GetSpells has filled the referenced options \n");
        options = { "Fireball", "Ice Shard", "Lightning Bolt" };
    }
    /// rest of the code...
}

You may have a different scenario in mind while following this tutorial, but in this example we will use the upmost element of our UI-Canvas as our common ID to message between the two components, (4) the "TechSpells" UI-element. Important: you can use what ever ID you wish, for as long as it is the same on both components.

Component1 (TechSpells003) is ready to go. Let us move to Component2 (DropDownDropTarget)

---

---

• In your Component2 (DropDownDropTarget), search for you .cpp file. Search for a good trigger like a UI button click, Activate, OnCollision or even a OnDropDownExpanded of a dropdown. The important thing is to choose something that you can trigger the request.
  • If the activation order is: Component2 activates; then Component1 activates, do not execute the request in the Activate method (because Component1 might not exist yet).
  • Since that is not the case on this example, execute the request (vector of strings) when you (1) expand the dropdown; commented out the execution of the request in the (2) Activate method so you can try that one too.
  • I wrapped the execution of the request with a method called (3) PopulateDropdownOptions. Better reusability.
  • Also, remember the TechSpells UI-element that we used as ID when connecting and disconnecting in Component1 (TechSpells003), we need that same (4) UI-element again to make the request from Component2 (DropDownDropTarget).

#include <Character088v3/Bus/SpellRequests.h>

namespace Character088v3
{
    /// rest of your code

     void DropDownDropTargetComponent::Activate()
    {
        DropDownDropTargetRequestBus::Handler::BusConnect(GetEntityId());
        UiDropdownNotificationBus::Handler::BusConnect(m_DropDown);

        /// You can execute the request when you activate, preferably after all handler connections.
        /// But remember that there might be some edge cases where your Component1 is not fully Active yet; and Component2 is already Active and trying to request information . So the request might turn empty or in error.
        // DropDownDropTargetComponent::PopulateDropdownOptions(); /// (2) Assuming Component1 always activates before Component2
    }

    /// (3) Method that executes your request to Component1 (TechSpells003)
   /// Initialize the options, and then pass it as a reference
    void DropDownDropTargetComponent::PopulateDropdownOptions()
    {
        AZStd::vector<AZStd::string> options;
        /// (4) m_techSpellsID from Component2 == TechSpells from Component1. This is the same ID
        SpellRequestsBus::Event(m_techSpellsID, &SpellRequestsBus::Events::GetSpells, options);
        if(options. Empty())
        {
            AZ_Printf("DropDownDropTargetComponent", "No options available.\n");
        }
        for (const auto& option : options)
        {
            AZ_Printf("TechSpells", "Option: %s", option.c_str());
        }

       /// TODO: do what ever you want with the vector of strings
    }
    
    /// This is my trigger. When I expand my UI-DropDown, I am getting the list of options
    void DropDownDropTargetComponent::OnDropdownExpanded()
    {
        AZ_Printf("DropDownDropTargetComponent", "Dropdown expanded.\n");
        DropDownDropTargetComponent::PopulateDropdownOptions(); /// (1)
    }
    /// rest of your code

Here is an image to help contextualize how you can pass a (4) UI-element ID from the UI-canvas, to your custom-component as an input parameter.

• Configure, build and run your project. Depending on where you placed the execution of your request in Component2 (DropDownDropTarget), the console will print the list saved in Component1 (TechSpells003). This is the result you should be looking for:

[GaianHelmers]

Some notes:

• If you don't intend to use the generated interface bus, you can completely delete the interface file. I do that with all my components.

  • This leaves you with NewComponent.h, and NewComponent.cpp. Much clearer.

• You can then remove all the references in other files.

  • Remove the #include in the .h file.
  • Remove the inheritance: , public NewComponentRequests::Handler in the .h file.
  • Remove the BusConnect and BusDisconnect in the .cpp file.

• Having a Bus folder is fine, and putting your bus file in there is fine. (You're basically duplicating what the interface files are already doing. Just with your own naming, which is good for clarity.)

• Your GetSpells event is fine. There are two ways to handle it.

  • AZStd::vector<AZStd::string> GetSpells() using EventResult(the local variable to update, the entityId, &the event)
  • Or the way you're doing it: void GetSpells(ref AZStd::vector<AZStd::string>) and affecting the variable reference.

So then the configuration you have is appropriate:

• You have an eventbus in it's own file.
• You have the component that has it's spells, and inherits from the eventbus.
• You have a ui component that gets the spell list from the other component.
  • By including the bus .h and calling the event.

[mythrz]

@GaianHelmers

If you don't intend to use the generated interface bus, you can completely delete the interface file. I do that with all my components

From an introduction point of view to new devs, maybe I should only mention they can clean that?
In other words, that they can delete the interface if they don't need it and know they do not need it; but that is there because ... you may need it for something else, AZ::Interface? And then include a link to another page? Which I do not know which one it is by the way :P Any suggestions?

In your team/studio workflow, do you use the Interface file (e.g., TechSpells003Interface.h) or not? We should clarify the best practices, because that file might be there for a completely different reason that has nothing to do with EBus.

The new folders just make sense to me... I hate having all files in the same folder. I have been restructuring the gem as I go

• Include\GemName now matches Source\GemName (this was added)
• Source\GemName\Game for Game files-components
• Source\GemName\UI for UI files-components

I also do not know what the GemNameBus.h (Character088v3Bus.h) do... or what is there for. I suspect it could be used too for Event Messaging

[GaianHelmers]

From an introduction point of view to new devs, maybe I should only mention they can clean that? In other words, that they can delete the interface if they don't need it and know they do not need it; but that is there because ... you may need it for something else, AZ::Interface? And then include a link to another page? Which I do not know which one it is by the way :P Any suggestions?

Really it's purpose is to be an automatic place equivalent to your SpellRequests.h.

• You can rename it, rename the ebus inside, reposition it anywhere you want.

---

In your team/studio workflow, do you use the Interface file (e.g., TechSpells003Interface.h) or not? We should clarify the best practices, because that file might be there for a completely different reason that has nothing to do with EBus.

Because we're working on a toolset, we are prioritizing Extensibility. This means we need to make the classes public along with events, because much of what you'll do is make your own child classes out of our tools.

• i.e. GS_WorldTrigger -> MyCustomWorldTrigger

This means we have structured our files and build targets differently:

• I change my Gem.API from INTERFACE to STATIC (this allows .h and .cpp code)
• I delete the ComponentInterface file right off the bat.
• I bring the Component.h into Include, usually within a sub-folder for organization:
  • Include/WorldTrigger/GS_WorldTrigger.h
• I leave the .cpp in Source, mimicking the file structure of the Include.
  • Source/WorldTriggers/GS_WorldTrigger.cpp
• I create "Incoming" and "Outgoing" ebusses in the Component.h, just above the class definition.

Ebus Class IncomingEvents
{
}

Ebus Class OutgoingEvents
{
}

class GS_WorldTrigger: 
     component
     , incomingeventsbus::handler
{
}

This makes it so you can just go:

class MyCustomWorldTrigger: GS_WorldTrigger
{
}

And you have now inherited all the functionality including connecting, and responding, to the incoming events.

---

I also do not know what the GemNameBus.h (Character088v3Bus.h) do... or what is there for. I suspect it could be used too for Event Messaging

It's the same as the Interface->RequestEvents but for your entire Gem. It's usually used for global/singleton events.
I create my own managers, so I also don't use that. Though I leave the file as is.

[mythrz]

Proposal in the form of baby steps. (2nd Draft. Addressing feedback)

This tutorial will assume that you already have custom components inside your gem. The goal is for Component1 to hold information (a vector of strings); and the other (Component2) can request it when ever it wants to use it. The example is using UI-Canvas and UI-Slices, but this is not a requirement; its just a usecase scenario that many have to go through when working with LyShine and any other example could have been choosen; the only thing we use from the UI-Canvas is the upmost UI-Element as our Address ID.

Gem Name: Character088v3
Component1: TechSpells003
Component2: DropDownDropTarget
(Optional) New Folder: Bus
(Optional) New File: SpellRequests.h. You can use the existing Component1Interface.h file instead (TechSpells003Interface.h)
Traits: ComponentBus default traits
ID: Upmost UI-Element from a UI-Canvas
Components: UI components attached to two different UI-slices

I have custom folders in the source folder too, but these do not affect the tutorial/example

(OPTIONAL)

• Create a new folder called "Bus" inside the Include\Character088v3
• Create a new file called "SpellRequests.h" (you can use the TechSpells003Interface.h instead, but throughout this tutorial I mention only the SpellRequests.h)
  You should have something like this:

• Inside your EBus Requests file (SpellRequests.h), add a few methods. (1) Notice the reference &, this will allow you to initialize the vector of strings, pass the reference, and then fill the vector. (2) The second function will return a copy of the vector of strings.
  • These are different ways to achieve a similar result.
• You can inherit your EBus Requests file (SpellRequests.h) from either AZ::ComponentBus or public AZ::EBusTraits. (3) I left the AZ::EBusTraits commented out but feel free to replace and explore either AZ::ComponentBus or AZ::EBusTraits and all of the options available.

#pragma once

#include <AzCore/Component/ComponentBus.h> // (3) AZ::ComponentBus
// #include <AzCore/EBus/EBus.h> //  (3) AZ::EBusTraits
#include <AzCore/std/string/string.h>
#include <AzCore/std/containers/vector.h>

namespace Character088v3
{
    class SpellRequests: public AZ::ComponentBus //, public AZ::EBusTraits (3)
    {
        public:
            // using BusIdType = AZStd::string; // instead of EntityID, use a string as ID (4)

            virtual void GetSpells(AZStd::vector<AZStd::string>& options) = 0; /// (1)
            virtual AZStd::vector<AZStd::string> GetSpells2() = 0; /// (2)
    };

    using SpellRequestsBus = AZ::EBus<SpellRequests>;
}

Default AZ::EBusTraits:

   AllocatorType = EBusEnvironmentAllocator;
   HandlerPolicy = multiple
   AddressPolic = Single;
   BusIdType = NullBusId;
   BusIdOrderCompare = NullBusIdCompare;
   BusHandlerOrderCompare = BusHandlerCompareDefault;
   MutexType = NullMutex;
   EnableEventQueue = false;
   EventQueueingActiveByDefault = true;
   EnableQueuedReferences = false;
   EventQueueMutexType = NullMutex;
   ConnectionPolicy = EBusConnectionPolicy<Bus>;
   LocklessDispatch = false;

Default AZ::ComponentBus:

   AllocatorType = EBusEnvironmentAllocator;
   HandlerPolicy = multiple
   AddressPolic = Single;
   BusIdType = AZ::EntityId;
   BusIdOrderCompare = NullBusIdCompare;
   BusHandlerOrderCompare = BusHandlerCompareDefault;
   MutexType = NullMutex;
   EnableEventQueue = false;
   EventQueueingActiveByDefault = true;
   EnableQueuedReferences = false;
   EventQueueMutexType = NullMutex;
   ConnectionPolicy = EBusConnectionPolicy<Bus>;
   LocklessDispatch = false;

• In your gem _api_files.cmake (Character088v3_api_files.cmake), (1) add the relative path to your EBus Requests file (SpellRequests.h)

set(FILES
    Include/Character088v3/Character088v3Bus.h
    Include/Character088v3/Character088v3TypeIds.h
    Include/Character088v3/SpellBook003Interface.h #
    Include/Character088v3/TechSpells003Interface.h #
    Include/Character088v3/ListDragSearch003Interface.h #
    Include/Character088v3/DropDownDropTargetInterface.h #
    Include/Character088v3/Bus/SpellRequests.h # (1) This one is the one you need to add
)

• In the Component1 (TechSpells003), the holder of information, search for the component header (TechSpells003Component.h). (1) Add a new #include, (2) inherit your EBus, (3) and override the methods.

#pragma once

/// some other includes...

#include <Character088v3/Bus/SpellRequests.h> /// (1) this is the EBus you need to include

namespace Character088v3
{
    class TechSpells003Component: 
          public AZ::Component, 
          public TechSpells003RequestBus::Handler, 
          public SpellRequestsBus::Handler /// (2) this is the inherited EBus you need to add
    {
    public:
          /// rest of your code...
         void GetSpells(AZStd::vector<AZStd::string>& options) override; /// (3) void method with a reference &.
         AZStd::vector<AZStd::string> GetSpells2() override; /// (3) return method with no input params

/// rest of the code

• Still in Component1 (TechSpells003 ), search for the component .cpp (TechSpells003Component.cpp). (1) Add your methods anywhere you want, but make sure it is inside your namespace. This is where the information (vector of strings) will live. You can change this to what ever you want. Read a file from disk, a json, a database, a web API etc... (1.1) Regarding the void method. the reference & comes into play here. Since you are passing a reference, you can fill those options here for later use in Component2 (DropDownDropTarget). (1.2) The return method, is when you prefer to make a copy of the vector of strings and return it instead of using a input reference &. Both methods can have as many input parameters as you like.
• You also have to (2) connect and (3) disconnect the bus with a specific (4) ID, in this case the m_techSpellsID. This (4) ID must be the same in both components (TechSpells003 and DropDownDropTarget).
• If you choose to override the BusIdType from EntityId to string, you can use any string value you want. (5) I left it commented out in case you wish to switch that and test it yourself.

namespace Character088v3
{
    /// rest of the code...
    
    void TechSpells003Component::Activate()
    {
        TechSpells003RequestBus::Handler::BusConnect(GetEntityId()); ; 
        SpellRequestsBus::Handler::BusConnect(m_techSpellsID); /// (2) Connect your bus with (4) TechSpells ID
        // SpellRequestsBus::Handler::BusConnect("TechSpells"); /// (5) using BusIdType = AZStd::string; This must be defined in EBus Requests file (SpellRequests.h)
    }
    void TechSpells003Component::Deactivate()
    {
        TechSpells003RequestBus::Handler::BusDisconnect(GetEntityId());
        SpellRequestsBus::Handler::BusDisconnect(m_techSpellsID); /// (3) Disconnect your bus with (4) TechSpells ID
        // SpellRequestsBus::Handler::BusDisconnect("TechSpells"); /// (5) using BusIdType = AZStd::string; This must be defined in EBus Requests file (SpellRequests.h)
    }

    ///  (1 and 1.1) your void method
    void TechSpells003Component::GetSpells(AZStd::vector<AZStd::string>& options) /// notice the &reference
    {
        AZ_Printf("TechSpells003Component", "TechSpells003Requests::Event GetSpells has filled the referenced options \n");
        options = { "Fireball", "Ice Shard", "Lightning Bolt" };
    }
    /// (1 and 1.2) your return method
    AZStd::vector<AZStd::string> TechSpells003Component::GetSpells2()
    {
        AZStd::vector<AZStd::string> options;
        AZ_Printf("TechSpells003Component", "TechSpells003Requests::EventResult GetSpells2 has filled the referenced options \n");
        options = { "Fire blast", "Blizzard", "Thunder Shock" };
        return options;
    }

    /// rest of the code...
}

You may have a different scenario in mind while following this tutorial, but in this example the upmost element of our UI-Canvas is the EntityId to message between the two components, (4) the "TechSpells" UI-element is the m_techSpellsID in the cpp code. Important: you can use what ever ID you wish, for as long as it is the same on both components. For example, you can use the "TechSpells" string if you set your BusIdType to string in the EBus Requests file (SpellRequests.h)

Component1 (TechSpells003) is ready to go. Let us move to Component2 (DropDownDropTarget)

---

---

• In your Component2 (DropDownDropTarget), search for you .cpp file. Search for a good trigger like a UI button click, Activate, OnCollision or even a OnDropDownExpanded of a dropdown. The important thing is to choose something that you can trigger the request.
  • If the activation order is: Component2 activates; then Component1 activates, do not execute the request in the Activate method (because Component1 might not exist yet).
  • Since that is not the case on this example, execute the requests (vector of strings) when you (1) expand the dropdown; commented out the execution of the request in the (2) Activate method so you can try that one too.
  • I wrapped the execution of the request with a method called (3) PopulateDropdownOptions. Better reusability.
  • Also, remember the TechSpellsID (m_techSpellsID) UI-element that was used as ID when connecting and disconnecting in Component1 (TechSpells003), we need that same (4) UI-element again to make the request from Component2 (DropDownDropTarget).
  • If you choose to override the BusIdType from EntityId to string, you can use any string value you want. (5) I left it commented out in case you wish to switch that and test it yourself.
  • To execute the void request, use SpellRequestsBus::Event
  • To execute the return request, use SpellRequestsBus::EventResult

#include <Character088v3/Bus/SpellRequests.h>

namespace Character088v3
{
    /// rest of your code

     void DropDownDropTargetComponent::Activate()
    {
        DropDownDropTargetRequestBus::Handler::BusConnect(GetEntityId());
        UiDropdownNotificationBus::Handler::BusConnect(m_DropDown);

        /// You can execute the request when you activate, preferably after all handler connections.
        /// But remember that there might be some edge cases where your Component1 is not fully Active yet; and Component2 is already Active and trying to request information . So the request might turn empty or in error.
        // DropDownDropTargetComponent::PopulateDropdownOptions(); /// (2) Assuming Component1 always activates before Component2
    }

   /// (3) Method that executes your request to Component1 (TechSpells003)
   /// Initialize the options, and then pass it as a reference
    void DropDownDropTargetComponent::PopulateDropdownOptions()
    {
        /// (4) m_techSpellsID from Component2 == m_techSpellsID  from Component1. This is the same element-ID
        /// (4) your void method
        AZStd::vector<AZStd::string> options;
        SpellRequestsBus::Event(m_techSpellsID, &SpellRequestsBus::Events::GetSpells, options);
        // SpellRequestsBus::Event("TechSpells", &SpellRequestsBus::Events::GetSpells, options); /// (5) using BusIdType = AZStd::string; This must be defined in EBus Requests file (SpellRequests.h)
        if (options. Empty())
        {
            AZ_Printf("SpellRequestsBus::Event", "No options available.\n");
        }
        for (const auto& option : options)
        {
            AZ_Printf("SpellRequestsBus::Event", "Option: %s", option.c_str());
        }
        
        /// (4) your return method
        AZStd::vector<AZStd::string> options2;
        SpellRequestsBus::EventResult(options2, m_techSpellsID, &SpellRequestsBus::Events::GetSpells2);
        // SpellRequestsBus::EventResult(options2, "TechSpells", &SpellRequestsBus::Events::GetSpells2); /// (5) using BusIdType = AZStd::string; This must be defined in EBus Requests file (SpellRequests.h)
        if (options2.empty())
        {
            AZ_Printf("SpellRequestsBus::EventResult", "No options available.\n");
        }
        for (const auto& option : options2)
        {
            AZ_Printf("SpellRequestsBus::EventResult", "Option: %s", option.c_str());
        }

       /// TODO: do what ever you want with the vector of strings
    }
    
    /// This is my trigger. When I expand my UI-DropDown, I am getting the list of options
    void DropDownDropTargetComponent::OnDropdownExpanded()
    {
        AZ_Printf("DropDownDropTargetComponent", "Dropdown expanded.\n");
        DropDownDropTargetComponent::PopulateDropdownOptions(); /// (1)
    }
    /// rest of your code

Here is an image to help contextualize how you can pass a (4) UI-element ID from the UI-canvas, to your custom-component as an input parameter.

Here are some examples of how you can execute your requestes, depending on how you configure your EBus traits.

// call Somefuncion on anyone connected to this bus on any id, with params ...
// BusName::Broadcast(&BusName::Events::Somefunction, params ...);
SpellRequestsBus::Broadcast(&SpellRequestsBus::Events::GetSpells, &options); 

// call somefunction on anyone who did BusConnect(id), with params...
// BusName::Event(id, &BusName::Events::Somefunction, params ...);
SpellRequestsBus::Event(m_techSpellsID, &SpellRequestsBus::Events::GetSpells, &options);

// call Somefunction which returns a result, call operator== on result on each invocation ...
// BusName::BroadcastResult(result, &BusName::Events::Somefunction, params ...);
SpellRequestsBus::BroadcastResult(options, &SpellRequestsBus::Events::GetSpells2);

// Call somefunction on anyone who did Busconnect(id), each function that executes call operator== on result, ...
// BusName::EventResult(result, id, &BusName::Events::Somefunction, params ...);
SpellRequestsBus::EventResult(options, m_techSpellsID, &SpellRequestsBus::Events::GetSpells2);

• Configure, build and run your project. Depending on where you placed the execution of your requests in Component2 (DropDownDropTarget), the console will print the list saved in Component1 (TechSpells003). This is the result you should be looking for:

• Feel free to explore all of the options available and choose what fits best in your project.

[mythrz]

TABS

My goal is to then make tabs in certain parts of the document. But I cannot replicate that in GitHub issues or comments.

This is possible to achieve on o3de website, because one of the existing pages is already doing that (search for {{< tabs name="CMake install" >}} inside that file):
https://github.com/o3de/o3de.org/edit/development/content/docs/welcome-guide/requirements.md

Here is a code example on how to do that:
{{< tabs name="EBus_Requests_file" >}}
{{% tab name="Code" %}}

#pragma once

#include <AzCore/Component/ComponentBus.h> // (3) AZ::ComponentBus
// #include <AzCore/EBus/EBus.h> // AZ::EBusTraits
#include <AzCore/std/string/string.h>
#include <AzCore/std/containers/vector.h>

namespace Character088v3
{
    class SpellRequests: public AZ::ComponentBus //, public AZ::EBusTraits (3)
    {
        public:
            // using BusIdType = AZStd::string; // instead of EntityID, use a string as ID (4)

            virtual void GetSpells(AZStd::vector<AZStd::string>& options) = 0; /// (1)
            virtual AZStd::vector<AZStd::string> GetSpells2() = 0; /// (2)
    };

    using SpellRequestsBus = AZ::EBus<SpellRequests>;
}

{{% /tab %}}
{{% tab name="AZ_EbusTraits_defaultValues" %}}

AllocatorType = EBusEnvironmentAllocator;
HandlerPolicy = multiple
AddressPolic = Single;
BusIdType = NullBusId;
BusIdOrderCompare = NullBusIdCompare;
BusHandlerOrderCompare = BusHandlerCompareDefault;
MutexType = NullMutex;
EnableEventQueue = false;
EventQueueingActiveByDefault = true;
EnableQueuedReferences = false;
EventQueueMutexType = NullMutex;
ConnectionPolicy = EBusConnectionPolicy;
LocklessDispatch = false;

{{% /tab %}}
{{% tab name="AZ_ComponentBus_defaultValues" %}}

AllocatorType = EBusEnvironmentAllocator;
HandlerPolicy = multiple
AddressPolic = Single;
BusIdType = AZ::EntityId;
BusIdOrderCompare = NullBusIdCompare;
BusHandlerOrderCompare = BusHandlerCompareDefault;
MutexType = NullMutex;
EnableEventQueue = false;
EventQueueingActiveByDefault = true;
EnableQueuedReferences = false;
EventQueueMutexType = NullMutex;
ConnectionPolicy = EBusConnectionPolicy;
LocklessDispatch = false;

{{% /tab %}}
{{< /tabs >}}

[GaianHelmers]

My goal is to then make tabs in certain parts of the document. But I cannot replicate that in GitHub issues or comments.

This is possible to achieve on o3de website, because one of the existing pages is already doing that (search for {{< tabs name="CMake install" >}} inside that file): https://github.com/o3de/o3de.org/edit/development/content/docs/welcome-guide/requirements.md

This is because o3de.org is using HUGO, a website generator tool.

You can utilize a theme with special markdown that outputs more complex styling and structure in the final outputted website.