User:Illuminatiswag/Sandbox: Difference between revisions

Line 32:

Next, we check the decompiled game code, starting with the AnimateObject part.

The important pieces here are the CanAnimate method, which checks if a GameObject frankenObject can be animated,

The important pieces here are the CanAnimate method, which checks if a GameObject (frankenObject can be animated,

and the Animate method, which takes frankenObject and a few less-relevant parameters and brings frankenObject to life.

CanAnimate checks if frankenObject has either the blueprint tag or the string property "Animatable" (more on this later),

Line 117:

Unfortunately, as you'll have discovered if you tried it out, all statues are still humanoid. We're going to need more patching.

The problem here is ~~the split between blueprint tags and object properties. These~~ are two very similar ways of

The problem here is that there are two very similar ways of assigning random bits of data to objects:

assigning random bits of data to objects. ~~Tags~~ and properties have a name and a value. Some code will check only whether

blueprint tags and object properties. Any game object can have any number of tags and properties, which have a unique name

and possibly a value. Some code will check only whether

a name is present, while other code will check the value for a given name and do something with it. The difference

is where they're defined.

Blueprint tags are set directly on object blueprints, like <tag Name="Animatable"/> or <tag Name="BodyType" Value="IronMaiden"/>.

Object properties, on the other hand, are set at runtime, such as by our calls to SetStringProperty.

@@ Line 32: / Line 32: @@
 Next, we check the decompiled game code, starting with the AnimateObject part.
-The important pieces here are the CanAnimate method, which checks if a GameObject frankenObject can be animated,
+The important pieces here are the CanAnimate method, which checks if a GameObject (frankenObject can be animated,
 and the Animate method, which takes frankenObject and a few less-relevant parameters and brings frankenObject to life.
 CanAnimate checks if frankenObject has either the blueprint tag or the string property "Animatable" (more on this later),
@@ Line 117: / Line 117: @@
 Unfortunately, as you'll have discovered if you tried it out, all statues are still humanoid. We're going to need more patching.
-The problem here is the split between blueprint tags and object properties. These are two very similar ways of
+The problem here is that there are two very similar ways of assigning random bits of data to objects:
-assigning random bits of data to objects. Tags and properties have a name and a value. Some code will check only whether
+blueprint tags and object properties. Any game object can have any number of tags and properties, which have a unique name
+and possibly a value. Some code will check only whether
 a name is present, while other code will check the value for a given name and do something with it. The difference
 is where they're defined.
 Blueprint tags are set directly on object blueprints, like <tag Name="Animatable"/> or <tag Name="BodyType" Value="IronMaiden"/>.
 Object properties, on the other hand, are set at runtime, such as by our calls to SetStringProperty.