> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/geode-sdk/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Chapter 2.3 - Finding LevelSettingsLayer::init
> Learn how to find non-virtual init functions by following constructors and create functions
Not all `init` functions are found on the vtable however. The only reason `MenuLayer::init` is on there is because it takes no extra parameters - so it overrides `CCNode::init`. However, if the init function has any parameters, it has a different name, or the class doesn't inherit from `CCNode`, then you most likely won't find it on the vtable (unless it is explicitly marked virtual).
Luckily, finding non-virtual `init` functions is still quite easy! As an example, let's find the `init` function for `LevelSettingsLayer`!
Let's start as before by finding `LevelSettingsLayer` in the Ghidra class list (tip: you can use the search function at the bottom!). Click any of the vtables to navigate to that vtable in the disassembly view.
Now, check the XREFs - for most classes, there should be two [\[Note 1\]](#notes). One of these is the constructor, and the other is the destructor. Pick one, and see which one it is - we are looking for the constructor.
Ah, this is likely the constructor! You can tell this by the fact that it initializes a bunch of fields in the class pointer to their default values, as well as that it contains a single call to the base constructor. Although, the base constructor is unknown - double-click it to find out what it is!
Judging by the vtables, this seems to quite clearly be `FLAlertLayer`'s constructor. So let's rename the function to `FLAlertLayer::FLAlertLayer` and press `Alt + Left Arrow` to go back to the previous constructor (note: you may have to press it multiple times because Ghidra is quirky like that).
Now check the XREFs for the `LevelSettingsLayer` constructor. There's likely only one [\[Note 1\]](#notes) - click it to follow the reference.
Hm, okay, let's analyze this code a little bit. First it calls `operator new`, then it checks if that was null, then calls a function on the returned value, and if that function returned a truthy value, it calls `autorelease` and returns the value.
This looks very familiar - this is the structure of a `create` function:
```cpp theme={null}
LevelSettingsLayer* LevelSettingsLayer::create(...) {
auto ret = new LevelSettingsLayer();
if (ret) {
if (ret->init(...)) {
ret->autorelease();
return ret;
}
delete ret;
}
return nullptr;
}
```
We can be almost certain that this is the `create` function, which means that the one unknown function call we have before the call to `autorelease` must be `LevelSettingsLayer::init` - double click the function to make sure!
Hm, there's a call to some unknown function at the start, whose return value the code checks to be truthy before doing anything else, and if it's false then it does nothing but propagate that information up to the original caller. Sounds very similar to the structure of an `init` function:
```cpp theme={null}
bool LevelSettingsLayer::init(...) {
if (!FLAlertLayer::init(...))
return false;
...
return true;
}
```
Let's make sure by checking out the unknown function's body:
OK, this is clearly an `init` function. Since we know from the constructor that the base class of `LevelSettingsLayer` is `FLAlertLayer`, that means that this is most likely `FLAlertLayer::init` [\[Note 2\]](#notes). That means that the other function we found is very likely `LevelSettingsLayer::init` as well, so let's rename both approppriately:
Well. Hmm. We know that any `init` function returns a bool, but what about these parameters? `LevelSettingsLayer` probably doesn't actually take a bare `CCObject*` and `undefined4` is definitely not the correct type - but how do we find the real ones?
And besides, what we have done know is still just educated guesses, though they are very good guesses. For example, we guessed that the name of the init function is `init` - however, it could also just as well be something like `initWithObject`. Could we gain a little more certainty? It would be really convenient if there was something we could compare this against - something we know to be correct.
Well, luckily, there is: Android!
[Chapter 2.4: Comparing against Android](/handbook/vol2/chap2_4.md)
## Notes
> \[Note 1] If there are multiple XREFs, it's likely that either the create function for the class has either been inlined, or there are multiple or them - RE to find out what is the case!
> \[Note 2] The base `init` call is not necessarily a call to the actual base class's `init` for two reasons: inlining and the code not doing that. You can figure out what is the case by comparing against Android (explained in Chapter 3)