Basic Concept

Every object in the game is expressed as a class. Classes are collections of properties and functions that form a blueprint for objects of the same type. The system is structured this way in order to avoid having to explicitly define the characteristics of each object individually. Instead, every time we connect a Constructor to the network, we already have a predefined set of things it can do and properties it has!

Properties

A property is a value that is associated with a class. For example, the class TrainPlatform has a property called status whose value is an indicator of whether or not it is in use. Another class, PowerStorage has a property named powerStorePercent that indicates what percentage of power capacity is charged.

Functions

A function is a capability that is associated with a class. For example, the class Manufacturer has a function called setRecipe that, when given the name of a recipe, actually changes the active recipe on a Manufacturer!

Note: If a lot of these descriptions seem obvious (e.g. "setRecipe sets a recipe"), that’s because the system itself is designed to make sense to a human reading it—​albeit in a highly technical manner. The more you use it, the better you’ll get at reading the documentation and understanding its functions intuitively.

Earlier we mentioned that every object in the game is made up of a blueprint called a class. In fact, each object is constructed of multiple classes. This is because of a principal called class inheritance, which allows an object to inherit the functions and properties of each class that constructs it.

For example, a look at the documentation shows a class called Actor with the description, "This is the base class of all things that can exist within the world by themselves." From that description, we can infer that it contains properties (e.g. location, rotation) and functions (e.g. getInventories) that are common to all buildables. Because we’ve expressed these characteristics in a parent class, everything that falls under that class (known as child classes) inherits them without having to repeatedly include them in their description!

That’s useful when for building a system, but what does it mean when you’re using it? In short, when referring to the Reflection docs, you should understand that any class you reference has the functions and properties of itself and every parent it has (found by clicking link labeled "Parent" at the top of its description). Doing so will help make the reference easier to understand and more powerful to use.

Individual values are expressed using basic types. Here are the most common:

Collections of values use different types based on the types of the items in them.

The first step in your code is to find the Constructor on the network and save a reference to it in a variable. By saving a reference, we can then refer to its respective functions and properties very easily.

This is accomplished by using the component.proxy function. We can use the function by itself and feed it the GUID of the Constructor in order to save a reference to it:

constructor = component.proxy('0123456789…​')

But we used the Network Manager to name our Constructor "WireFactory Constructor1", and we’d like to use that nick instead of a long string of random numbers when we search for our component. Fortunately, we can let component.findComponent find the GUID for us using our nicks.

constructor = component.proxy(component.findComponent( "WireFactory Constructor1")[1])

Is it pretty? No. Is it functional? Yes.

The function returns an array containing GUIDs of every component in the network whose nick matched the query string. Our query string should only return our one Constructor, so now we just need to reference the first element in the array. We add [1] at the end of our findComponent function call in order to reference the first item it returns.

Note: in Lua, arrays start at one, which is unlike most programming languages.

Now that we have a reference to our Constructor saved in the variable constructor, we can reference its functions and properties with very little effort.

A look at the description for the Manufacturer component informs us that it is actually the base class for all machines that use a recipe, including our Constructor. We don’t have to scroll much farther to see that getRecipe is the function in that class that we need to achieve our goal!

Looking at the description of getRecipe, we see the following:

"Get Recipe getRecipe (Class(Recipe) Recipe recipe out)"

This might look like gibberish at first, but here’s a look at each of the pieces individually:

Thanks to this information, we now know that the function getRecipe has an output argument called recipe, which is exactly what we need!

We can call the function in Lua by using a colon after our variable name, like so:

constructor:getRecipe()

As you can see, we simply referenced the getRecipe function by adding a dot to the end of our variable and then calling the function we want! The empty parentheses at the end are used when calling a function with no inputs.

Now we just need to put this into the Lua programming language to make it useful. It looks something like this:

After typing this into the code input and pressing the go button in the case menu, our script will run, printing the name of the current recipe that our Constructor is using in the console. We’ve officially accomplished our goal! Furthermore, we figured out how to accomplish our goal by understanding the structure of the Reflection System itself!