Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix broken link #61

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion getting-started/geode-cli.md
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,7 @@ It is recommended that you [set up a profile afterwards](#profile-setup).

## Linux

We provide prebuilt Linux binaries in [the CLI releases page]((https://github.com/geode-sdk/cli/releases/latest)). Since Linux distros differ between each other, you need to figure out yourself how to add this binary to your global path so CMake can find it. As long as `geode --version` works anywhere, everything should be fine.
We provide prebuilt Linux binaries in [the CLI releases page](https://github.com/geode-sdk/cli/releases/latest). Since Linux distros differ between each other, you need to figure out yourself how to add this binary to your global path so CMake can find it. As long as `geode --version` works anywhere, everything should be fine.

Once you figure that out, it is recommended that you [set up a profile afterwards](#profile-setup).

Expand Down
2 changes: 1 addition & 1 deletion handbook/vol1/chap1_6.md
Original file line number Diff line number Diff line change
Expand Up @@ -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)

Expand Down
8 changes: 4 additions & 4 deletions tutorials/layouts.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down Expand Up @@ -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.