Fix some broken links (#61)

Author: astra1dev

handbook/vol1/chap1_6.md

@@ -137,7 +137,7 @@ class $modify(MenuLayer) {
 
 That's it. As previously stated, this is [quite close to the standard node design pattern](#the-structure-of-a-node).
 
-> :warning: It should be noted that not all layer's `init` functions have the same signature, and `$modify` requires the signature to **exactly match** in order to create a hook. Unfortunately, due to implementation problems, it also (currently) doesn't tell you if your signature is wrong, so you may find yourself scratching your head as to why your mod isn't working, only to realize the signature of `init` is off. Check [GeometryDash.bro](https://github.com/geode-sdk/geode/blob/main/bindings/GeometryDash.bro) to make sure the signature of your hook is correct!
+> :warning: It should be noted that not all layer's `init` functions have the same signature, and `$modify` requires the signature to **exactly match** in order to create a hook. Unfortunately, due to implementation problems, it also (currently) doesn't tell you if your signature is wrong, so you may find yourself scratching your head as to why your mod isn't working, only to realize the signature of `init` is off. Check [GeometryDash.bro](https://github.com/geode-sdk/bindings/blob/main/bindings/2.2074/GeometryDash.bro) to make sure the signature of your hook is correct!
 
 Now we are at an interesting point; we know how to hook functions, we know what function from a layer to hook in order to modify it, and we know how to work with nodes. So, let's tie all of this together! Only 7 chapters in, [it's time for **Hello, World!**](/handbook/vol1/chap1_7.md)
 

tutorials/layouts.md

@@ -2,7 +2,7 @@
 
 One of the biggest pains in all UI design in general is positioning stuff. This is especially troublesome in GD mods, where you can't really be sure where stuff are located on the screen. If some mod changes the visual outlook of a layer, how are you supposed to figure out where you should position your buttons?
 
-The solution Geode introduces for this are **layouts** - small classes added to CCNodes that dictate how that node's children should be positioned. For example, a row layout would lay its children in a horizontal row, whereas a grid layout would lay its children out in a grid. Although, perhaps surprisingly, Geode only adds one type of layout: the [AxisLayout](/classes/cocos2d/AxisLayout) class, which actually handles all common types of layouts, including row, column, grid, and flex.
+The solution Geode introduces for this are **layouts** - small classes added to CCNodes that dictate how that node's children should be positioned. For example, a row layout would lay its children in a horizontal row, whereas a grid layout would lay its children out in a grid. Although, perhaps surprisingly, Geode only adds one type of layout: the [AxisLayout](/classes/geode/AxisLayout) class, which actually handles all common types of layouts, including row, column, grid, and flex.
 
 You can view what layouts are visible on screen using the [DevTools](https://github.com/geode-sdk/devtools) mod, which has an option to show all layouts in the current scene.
 
@@ -38,14 +38,14 @@ myMenu->setLayout(RowLayout::create());
 
 ## AxisLayout
 
-Geode only adds one type of layout, [AxisLayout](/classes/cocos2d/AxisLayout), which is meant to be an all-purpose general layout. It can arrange nodes in a row, column, grid, or even a flex-type flow layout. Geode also adds the [RowLayout](/classes/cocos2d/RowLayout) and [ColumnLayout](/classes/cocos2d/ColumnLayout) for readability, however you will find that these don't actually add anything new on top of AxisLayout - they're just syntactic sugar!
+Geode only adds one type of layout, [AxisLayout](/classes/geode/AxisLayout), which is meant to be an all-purpose general layout. It can arrange nodes in a row, column, grid, or even a flex-type flow layout. Geode also adds the [RowLayout](/classes/geode/RowLayout) and [ColumnLayout](/classes/geode/ColumnLayout) for readability, however you will find that these don't actually add anything new on top of AxisLayout - they're just syntactic sugar!
 
-By default, AxisLayout arranges its children in a single straight line. This can be changed using the [setGrowCrossAxis](/classes/cocos2d/AxisLayout#setGrowCrossAxis) method.
+By default, AxisLayout arranges its children in a single straight line. This can be changed using the [setGrowCrossAxis](/classes/geode/AxisLayout#setGrowCrossAxis) method.
 
 You can play around with the different options AxisLayout offers using the [DevTools](https://github.com/geode-sdk/devtools) mod.
 
 ![Image of the DevTools mod, showing the different options for AxisLayout](/assets/DevTools_layoutAttributes.png)
 
 ## Custom layouts
 
-If AxisLayout doesn't fully match your needs, you can also define entirely custom layouts by inheriting from the [Layout](/classes/cocos2d/Layout) class and implementing the `apply` method.
+If AxisLayout doesn't fully match your needs, you can also define entirely custom layouts by inheriting from the [Layout](/classes/geode/Layout) class and implementing the `apply` method.