Have you ever had a cool idea, about a Building for your mod that can make awesome stuff, to just stumble into a limitation-wall? Have you ever felt trying to circumventing it but everything leads to implementing it into C++?

Some of these limitations often lead to a heavy change of plans in design or even abandoning your mod project as a whole.

But sometimes the problem relies in taking things from a different approach. Quoting Marcel Proust:

The real voyage of discovery consists not in seeking new lands but seeing with new eyes.

The design approach proposed here is having your Problem subdivided into smaller problems so that they are easier to be solved. Once all the problems are solved we glue them all together to get our idea into fruition!
But let's get down to business with a Design example...

The Idea

Let's immagine a vending machine:

  • we wish one part to be independent from the rest of the building where i would insert the coins
  • The coins are used and processed and after a certain amount of time we want to return an item
  • we want another part of the building to be used to retrieve the item once the coins are processed

  • Let's split the problem:

    Coin Input: we don't want a full conveyor coming iside our vending machine. Let's make it a buildable storage
    Vending Machine: this will be our main building to handle the process of generating the items once a coin is given. We're going to make this a normal BuildableFactory (so there is no mandatory Factory component requirement)

    A Storage and a BuildableFactory. Easy enough. Now let's check how we can make both things be glued together

    The Setup

    We decide what will be our main building (i prefer to put my code on one of the "parts") so i would choose the Vending Machine.

    We are going to create One FGBuildableFactory Object (that we're gonna call "Build_VendingMachine_Main") and a FGBuildableStorage Object (we can name it Build_VendingMachine_Input)

    We need to make a descriptor and a recipe only for our main buildable object (in this case Build_VendingMachine_Main) while the other part will be spawned when we build the whole building and attached to the Build_VendingMachine_Main part.

    To do this, first we need to open the mesh of our Main Part and create a Socket that we i am going to name "CoinInput"


    If you built the mesh as a whole and then exported the parts separately the default's Socket Location should be good.

    The Socket will make our Part stick to the other one like a magnet.

    At Unison

    Now that we have our setup we get into the Graph Editor of our Main Part.

    e Need a BeginPlay event, we want to store the Coin Input part in a variable (for this we make a new variable as an object reference to our Coin Input part, in this case "Build_VendingMachine_Input") and flag it as Save Game so that we retain the variable content when the game is loaded from a save.

    Let's use the node "Spawn Actor By Class" and for the Class value we give it the Actor we wish to spawn (in this case Build_VendingMachine_Input). We also point where to spawn (we want to spawn it at our Main Part location and that's why we use a self reference)


    We pass the value returned by the "Spawn Actor By Class" (it returns the instance of our Coin Input Part) and set it to our Coin Input variable we previously created (i called it "Coin Input")

    We can now use this variable to handle the other parts in our Main Building code. We now attach it to our Main building (we're using Attach Actor to Actor here but you could asso attach to a component, like a scene component)

    Target: the Actor we want to stick somewhere
    Parent Actor: The Actor we want to stick the Target to
    Socket Name: we paste here the name of the socket we created

    Let's set the Transforms of our actor as Snap to Target


    Now whe we construct our building both part will spawn together and work independently!



    Created: May 19, 2021, 6:47:20 PM
    Views: 747