Function Reference: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
imported>ZeroMemory mNo edit summary |
imported>ZeroMemory mNo edit summary |
||
| Line 26: | Line 26: | ||
On a serious note, one could ask: "'''Why should I ever want to use this "Self" variable when I can simply change any variable I want directly? I know they exist in the blueprint, therefore they are also in the instance. That's the whole point, is it not?'''" Sort of, young samurai. But here's just a simple taste from general programming, imagine that you've got a function invoked on an object (sometimes called a '''non-static member function/method''' or perhaps an '''instance-level member function/method''') that takes a parameter that points to an object of the same class. And you want to make sure you're not being fed the very object the function has been invoked upon. That mouthful is referred to as "self-reference". With "Self", you can check whether pObject is equal to Self and prevent damaging or unnecessary code from executing. If you can't think of a useful application of this example, it comes in handy with dynamic memory management and functions called setters. | On a serious note, one could ask: "'''Why should I ever want to use this "Self" variable when I can simply change any variable I want directly? I know they exist in the blueprint, therefore they are also in the instance. That's the whole point, is it not?'''" Sort of, young samurai. But here's just a simple taste from general programming, imagine that you've got a function invoked on an object (sometimes called a '''non-static member function/method''' or perhaps an '''instance-level member function/method''') that takes a parameter that points to an object of the same class. And you want to make sure you're not being fed the very object the function has been invoked upon. That mouthful is referred to as "self-reference". With "Self", you can check whether pObject is equal to Self and prevent damaging or unnecessary code from executing. If you can't think of a useful application of this example, it comes in handy with dynamic memory management and functions called setters. | ||
Here, let's pretend that you are trying to change an object crucial to your application and you want to release the old one because you're a good memory citizen who cares about his users and their limited memory resources. So, you want to first release the old object and then set the pointer to the new one, right? But what if a nasty scenario occurs where you replace the object with itself? You release the old object, set the | Here, let's pretend that you are trying to change an object crucial to your application and you want to release the old one because you're a good memory citizen who cares about his users and their limited memory resources. So, you want to first release the old object and then set the pointer to the new one, right? But what if a nasty scenario occurs where you replace the object with itself? You release the old object, set the pointer to the memory address of the "new" object (which is, actually, the old object), try to dereference it (a fancy word for "use it") and boom - a wild unicorn appears and destroys your application '''if you're lucky'''. Usually, the memory is just cleared to be overwritten, the system might not use it immediately, therefore, in some cases - your application could work and make your life miserable by reports of crashing. You made a dangling pointer which references an object that was released (by you, a moment ago). Do you, perhaps, see how you could solve this? Yes, exactly. If newObject is NOT equal to Self (newObject != Self), then release the object referenced by Self and change the Self pointer/variable to point to newObject (Self = newObject). And you've solved all of your life's troubles. Kittens are purring. Birds are singing. And gamers are cursing at the dragon that killed them because your game or mod is awesome. | ||
Scripts in Papyrus are called '''[[:Category:Script_Objects|Objects]]''', which might be confusing to some people. Their name was probably chosen because the developers wanted to emphasize the fact that scripts are added to objects in the game, they describe their behaviour and functionality. They are the "soul" of a static mesh made out of triangles and covered with a few textures which make it '''look real'''. Papyrus scripts are what makes it '''real'''. What makes it an '''object'''. | Scripts in Papyrus are called '''[[:Category:Script_Objects|Objects]]''', which might be confusing to some people. Their name was probably chosen because the developers wanted to emphasize the fact that scripts are added to objects in the game, they describe their behaviour and functionality. They are the "soul" of a static mesh made out of triangles and covered with a few textures which make it '''look real'''. Papyrus scripts are what makes it '''real'''. What makes it an '''object'''. | ||