Lines Matching refs:our

21 Please select your desired language for our quest:
136 the `schema` that defines the template for our monsters:
139   // Example IDL file for our monster's schema.
179 corresponding package/namespace for the generated code. In our example, we have
198 The `Monster` table is the main object in our FlatBuffer. This will be used as
199 the template to store our `orc` monster. We specify some default values for
208 The `Weapon` table is a sub-table used within our FlatBuffer. It is
210 enum. For our `Monster`, it is used to populate a `vector of tables` via the
211 `weapons` field within our `Monster`. It is also the only table referenced by
215 will be the root table for the serialized data. In our case, the root type is
216 our `Monster` table.
302 Now that we have compiled the schema for our programming language, we can
407   // Create a `FlatBufferBuilder`, which will be used to create our
414   // Create a `FlatBufferBuilder`, which will be used to create our
421   // Create a `FlatBufferBuilder`, which will be used to create our
428   // Create a `FlatBufferBuilder`, which will be used to create our
435   # Create a `FlatBufferBuilder`, which will be used to create our
442   // Create a `flatbuffer.Builder`, which will be used to create our
449   // Create a `FlatBufferBuilder`, which will be used to create our
463 After creating the `builder`, we can start serializing our data. Before we make
464 our `orc` Monster, lets create some `Weapon`s: a `Sword` and an `Axe`.
587 Now let's create our monster, the `orc`. For this `orc`, lets make him
590 to choose from (our `Sword` and `Axe` from earlier). In this case, we will
601   // Serialize a name for our monster, called "Orc".
612   // Serialize a name for our monster, called "Orc".
623   // Serialize a name for our monster, called "Orc".
639   // Serialize a name for our monster, called "Orc".
654   # Serialize a name for our monster, called "Orc".
668   // Serialize a name for our monster, called 'Orc'.
679   // Serialize a name for our monster, called "Orc".
690   // Serialize a name for our monster, called "Orc".
706 adding fields to our monster.
820   // Create our monster using `startMonster()` and `endMonster()`.
835   // Create our monster using `StartMonster()` and `EndMonster()`.
850   // Create our monster using `MonsterStart()` and `MonsterEnd()`.
865   # Create our monster by using `MonsterStart()` and `MonsterEnd()`.
883   // Create our monster by using `startMonster()` and `endMonster()`.
899   // Create our monster by using `StartMonster()` and `EndMonster()`.
952   // You can use this code instead of `CreateMonster()`, to create our orc
998 In our example, the last two things we added to our `Monster` were the
1453 To access sub-objects, in the case of our `pos`, which is a `Vec3`:
1653 Last, we can access our `Equipped` FlatBuffer `union`. Just like when we created
1888 our `monster.fbs` schema to produce a FlatBuffer binary file.
1895 FlatBuffer binary representation of the contents from our `.json` file.