Prerequisites Before you get started with developing with the Geode SDK, there are a few prerequisites that you should know about! Prior C++ knowledge is HIGHLY recommended. We do not intend in helping you at C++ from the very basics. Installing Geode itself! you want to test your own mods dont you? It is recommended that you follow the tutorials on this chapter in order. Required C++ Tools To be able to use the Geode SDK, you will need at least the following: A C++ compiler CMake - Version 3.21+ is required, and make sure to add to PATH when installing on windows. git - Hey you. yes you. I know a lot of people skip this but you will need it. Don’t come at us asking for why “could not find git for clone of json-populate” Compiler To use the Geode SDK, and in turn make Geometry Dash mods, you will need either: Visual Studio 2022+ on Windows clang on MacOS A secret third thing on Linux Windows From the Visual Studio website, you can download the Visual Studio IDE along with the compiler. If you want just the compiler, look for Build Tools for Visual Studio further down in the page. After launching the installer, look for Desktop development with C++. You may choose other features, but you will need at least MSVC and Windows SDK installed. Once its installed, you should now have a working C++ compiler installed that is suited for GD mod development. Please note that Visual Studio 2022 or higher is required. 2019 or lower will not work, as they don’t support C++20 properly. MacOS Install brew if you don’t already have it, and then run: brew install llvm Linux Linux is a bit more complicated, as obviously there’s no linux release of GD (yet). Of course, you can run the Windows version of GD through software like wine quite well, which is probably what you’re already doing. Because of that, this guide will set you up to cross-compile windows Geode mods from linux. We recommend reading this gist: linux-win-cross.md for up to date information on how to cross compile. Geode CLI The Geode SDK has its own command line utility program to aid in many tasks involved in mod, such as asset packing, font generation, managing the SDK, etc. Installation Windows MacOS Linux Windows scoop You can use scoop to easily install the cli by doing: scoop bucket add extras scoop install geode-sdk-cli In the future you can easily update the cli by doing: scoop update geode-sdk-cli If you don’t have scoop, you can follow the installation instructions on their page: https://scoop.sh winget We are also on winget, so to install the cli you can do: winget install GeodeSDK.GeodeCLI In the future you can easily update the cli by doing: winget upgrade GeodeSDK.GeodeCLI (Not Recommended :c) Otherwise, you can manually install it by: Download the latest windows release over at GitHub Extract the geode.exe into some folder on your computer Select the CLI executable in File Explorer, Shift + Right-Click it and select Copy as Path Search Edit the system environment variables on Windows search. Alternatively, you can open up Control Panel and search for it, then select Edit the system environment variables or to skip straight to step 6 select Edit environment variables for your account. Click Environment Variables... In the top User variables section, select the Path variable and click Edit Now click New and paste the path of the CLI executable you copied at Step 1. Remove the \geode.exe from the end; the path has to point to the directory with Geode CLI, not the CLI itself. Click OK to close the environment variable windows. After either way of installing it, you should now be able to run geode --version in your cmd and see a version number! It is recommended that you set up a profile now. MacOS You can easily install the CLI via brew brew install geode-sdk/geode/geode-cli It is recommended that you set up a profile now. Linux We provide prebuilt linux binaries in the CLI releases page, which you can find here: https://github.com/geode-sdk/cli/releases/latest Since this is different per distro, you must figure out how to add this binary to your path for CMake to find it. Once you figure that out, it is recommended that you set up a profile now. Profile Setup A profile is just an instance of Geometry Dash. It’s a good idea to set up one up for CLI so your mods can be automatically installed post build. To setup a new profile, simply run the geode config setup command on your terminal. Setting up the SDK To install the SDK we will be using the CLI installed on the previous step. To download the sdk, you can simply run the command: geode sdk install This should set the GEODE_SDK enviroment variable, which can you test after reopening your terminal: # on windows echo %GEODE_SDK% # elsewhere echo $GEODE_SDK If that command prints out the path you installed the SDK to, then it has worked correctly. To develop mods, you should also download the prebuilt binaries for Geode, which you can do by running this command: geode sdk install-binaries Updating You will need to manually update your local SDK every once in a while, which you do by running this command: geode sdk update Every time you update the SDK, you should update its prebuilt binaries too. geode sdk install-binaries You can also switch to the nightly version, which uses the latest commit. geode sdk update nightly Or to go back to stable: geode sdk update stable Creating a new mod After all that setup, you can now create your first mod! To do this, open up a terminal where you want to create your project and run: geode new Follow the given prompts and afterwards you should have a new folder containing the code for your mod. Files You may notice the project already comes with a few files. Lets go over them: CMakeLists.txt - This is the main file for your CMake project. about.md - Here you can write a very long description page for your mod, in markdown. Think of it as a README for your mod! This file is technically optional, but highly recommended. logo.png - This is the icon for your mod, which shows up in-game. This file is technically optional, but highly recommended. mod.json - This json file contains all the metadata about your mod, such as name, version, custom resources, settings, etc. See this page for detailed info If you plan on releasing your mod, please edit the about.md and logo.png files! The source code for your mod can be found inside the src folder. Additional Files Geode will also look for these special files within your mod folder: changelog.md - Lists all of the changes between versions to the mod; see detailed info support.md - Is free-form info about how to show support to the developer of the mod; see detailed info Build Now, to build your mod you have a few options: If youre using an IDE such as Clion, VScode or Visual Studio, head over to the IDE Setup page. Otherwise if you want to build your mods manually from the command line you can do that by simply running these commands in your mod’s folder: # Configure CMake (WINDOWS) cmake -B build -A win32 # Configure CMake (Other platforms) cmake -B build # Build the project cmake --build build --config RelWithDebInfo IDE Setup If you’re using some IDE you may want to do a few things for your Geode projects. Visual Studio Code Visual Studio CLion Visual Studio Code VSCode on Windows VSCode on Mac VSCode on Windows For VSCode, we recommend a few extensions: C/C++ CMake Tools Geode - Not required, but will provide some nice features. There are a few steps you should follow to get proper intellisense (you should only need to do these once per project, ideally): With VSCode open on your project, press F1 and run CMake: Select a Kit. This will bring up a list of installed compilers on your machine. Image showing a bunch of compilers CMake detected in VS Code You should pick a Visual Studio 2022+ compiler, using either the x86 or amd64_x86 version. Nothing else!! ⚠️ Please pay attention to this Now select the build variant, press F1 and run CMake: Select Variant. YOU MUST PICK ANYTHING BUT DEBUG or your mod will not compile. We recommend RelWithDebInfo for easier debugging. Image showing available build types on Windows: Debug, Release, MinSizeRel, and RelWithDebInfo Register CMake as the Configuration Provider for the C++ extension by pressing F1 and running C/C++: Edit Configurations (UI): Scroll down to Advanced options, and set the Configuration Provider as ms-vscode.cmake-tools. Image showing the “C/C++: Edit Configurations (UI)” command being run in VS Code Now, build your mod by pressing F1 and running CMake: Build. You must build your mod first so that errors such as #include not found go away. Make sure your mod built successfully, the exit code at the end should be 0. If the errors still persist, try restarting VS Code. VSCode on Mac For VSCode, we recommend a few extensions: clangd CMake Tools Geode - Not required, but will provide some nice features. There are a few steps you should follow to get proper intellisense (you should only need to do these once per project, ideally): With VSCode open on your project, press F1 and run CMake: Select a Kit. You should choose clang Now, build your mod by pressing F1 and running CMake: Build. You must build your mod first so that errors such as #include not found go away. Make sure your mod built successfully, the exit code at the end should be 0. If the errors still persist, try restarting VS Code. Visual Studio Some Visual Studio experience is recommended before you try to use this, but if you don’t then you’ll probably be fine. Modern Visual Studio can handle CMake projects automatically, so assuming your VS has CMake support, just open your mod project folder. You’ll know it’s working if a console opens up at the bottom of your Visual Studio, and it starts gathering information from CMake. Now, before you build, make sure to change these settings (these need to be changed in every single project you make): Click the Debug options (This is usually a drop-down menu at the top of your screen that says “x64-Debug”) Click “Manage Configurations” inside that drop-down Image showing the Manage Configurations button in the drop-down Change config type to Release or RelWithDebInfo. We recommend RelWithDebInfo, since it provides easier debugging. You cannot use Debug for this! Change toolset to x86 (msvc_x86) At this point you can also give your configuration a friendly name such as “default” or “release” or “mat” or something like that. And make sure to press Ctrl+S to save your changes Here’s an example of a configuration that should work: Image showing a config that should work Now you may build your mod, by pressing F7 or Ctrl+B (If those keybinds don’t work, click Build at the top, then either Build or Build All) If there are errors similar to VSCode (such as #include not found) after you’ve built, restarting Visual Studio should make them go away. If you get an error about Geode needing to be compiled for 32-bit, that means you didn’t change your toolset to x86 above. CLion No additional plugins are needed, the only thing you need to do is to set the CMake options correctly. When you open your mod’s directory in CLion for the first time, you’ll be met with an Open Project Wizard: Image showing the CLion Open Project Wizard Here you need to make sure that: Build type is set to Release or RelWithDebInfo, it cannot be Debug Toolchain is set to Visual Studio Generator is set to Visual Studio 17 2022 or newer Build directory is set to build CMake options contains -A win32 In the end it should look like this: Image showing the CLion Open Project Wizard set up for Geode Now you can click OK and CMake will run for the first time. The setup will fail until you build the project for the first time. In order to do that, go to the top right corner of the window where you’ll see a dropdown saying Add Configuration… Image showing the CLion Add Configuration dropdown Click it and choose Edit Configurations… and you’ll be met with the Run/Debug Configurations window. Inside of it, click the plus button in the top left corner of the window and choose CMake Application from the popup: Image showing the CLion Run/Debug Configurations window In the created configuration, click the Target dropdown and choose All Targets. You can also change the name to something else than “Unnamed”. Image showing the CLion Run/Debug Configurations window with a configuration set up to compile the mod Once that’s done, you can click Apply and then OK. If it hasn’t already, wait for CMake to finish its run. It might look something like this, with a line at the end saying [Failed to reload] Image showing the failed CMake run output Now click the hammer icon in the top right corner next to build the mod for the first time - make sure that the dropdowns next to it say RelWithDebInfo and Build Mod (or however you called your build task in the step before): Image showing the build button in CLion The build should end with a message saying Build finished (assuming you ran geode config setup before) and the empty mod should now be installed in the specified Geometry Dash instance. In order to make all the IDE features work correctly, reload CMake now, this run should end successfully with a message saying [Finished] at the end: Image showing how to rerun CMake in CLion Don’t forget to reload CMake after you add new files to the project. Buttons One of the most common UI elements in GD is the humble button. I’m sure you already know what it is, so let’s get straight to the point. Buttons are most commonly created in the form of the CCMenuItemSpriteExtra class, which is a GD-specific derivation of the CCMenuItemSprite class. You can also use any class that inherits from CCMenuItem as a button. You can also technically make your wholly custom button system using the touch system, however that will not be explained in this document. Every button that inherits CCMenuItem must be a child of a CCMenu to work. This means that if you add a button as a child to a CCLayer, you will find that it can’t be clicked. The first argument of CCMenuItemSpriteExtra is a CCNode* parameter. This is the texture of the button; it can be any CCNode, like a label or even a whole layer, but usually most people use a sprite. If you want to create a button with some text, the most common option is the ButtonSprite class. If you want to create something like a circle button (like the ‘New’ button in GD), you can either use CCSprite or the Geode-specific CircleButtonSprite class. bool MyLayer::init() { // ... auto spr = ButtonSprite::create("Hi mom!"); auto btn = CCMenuItemSpriteExtra::create( spr, this, nullptr ); // some CCMenu* menu->addChild(btn); // ... } This creates a button with the text Hi mom!. Callbacks Button callbacks are called menu selectors, and are passed as the third argument to CCMenuItemSpriteExtra::create. Menu selectors are non-static class member functions that return void and take a single CCObject* parameter. For example, this is a menu selector: class MyLayer : public CCLayer { public: void onButton(CCObject* sender); }; It is conventional to have all menu selectors names be in the form of onSomething. To pass a menu selector to the button, pass its fully qualified name to the menu_selector macro: class MyLayer : public CCLayer { protected: bool init() { // ... auto btn = CCMenuItemSpriteExtra::create( /* sprite */, this, menu_selector(MyLayer::onButton) ); // ... } public: void onButton(CCObject* sender) { std::cout << "Button clicked!\n"; } }; Inside the onButton function, you have access to the class this pointer. The sender parameter is a pointer to the button that was clicked. You can cast it back to the CCMenuItemSpriteExtra class using static_cast: class MyLayer : public CCLayer { void onButton(CCObject* sender) { std::cout << "Button clicked!\n"; auto btn = static_cast(sender); // Do something with the button } }; ⚠️ You can also use reinterpret_cast instead of static_cast, but using reinterpret_cast is generally considered bad practice. Example Here is the popular click counter example in cocos2d: class MyLayer : public CCLayer { protected: // Class member that stores how many times // the button has been clicked size_t m_clicked = 0; bool init() { if (!CCLayer::init()) return false; auto menu = CCMenu::create(); auto btn = CCMenuItemSpriteExtra::create( ButtonSprite::create("Click me!"), this, menu_selector(MyLayer::onClick) ); btn->setPosition(100.f, 100.f); menu->addChild(btn); this->addChild(menu); return true; } void onClick(CCObject* sender) { // Increment click count m_clicked++; auto btn = static_cast(sender); // getNormalImage returns the sprite of the button auto spr = static_cast(btn->getNormalImage()); spr->setString(CCString::createWithFormat( "Clicked %d times", m_clicked )->getCString()); } }; Passing more parameters to callbacks One of the most common problems encountered when using menu selectors is situations where you want to pass more parameters to a function. For example, what if in the click counter example we also wanted to add a decrement button? We could of course just refreace the whole onClick function, but that would be quite wasteful. Instead, we can use tags. class MyLayer : public CCLayer { protected: // Class member that stores how many times // the button has been clicked size_t m_clicked = 0; bool init() { if (!CCLayer::init()) return false; auto menu = CCMenu::create(); auto btn = CCMenuItemSpriteExtra::create( ButtonSprite::create("Click me!"), this, menu_selector(MyLayer::onClick) ); btn->setPosition(100.f, 100.f); btn->setTag(1); menu->addChild(btn); auto btn2 = CCMenuItemSpriteExtra::create( ButtonSprite::create("Decrement"), this, menu_selector(MyLayer::onClick) ); btn2->setPosition(100.f, 60.f); btn2->setTag(-1); menu->addChild(btn2); this->addChild(menu); return true; } void onClick(CCObject* sender) { // Increment or decrement click count m_clicked += sender->getTag(); auto btn = static_cast(sender); // getNormalImage returns the sprite of the button auto spr = static_cast(btn->getNormalImage()); spr->setString(CCString::createWithFormat( "Clicked %d times", m_clicked )->getCString()); } }; If you want to pass something like strings, you should use setUserObject instead. Passing non-integer parameters to callbacks If you want to pass something to a callback that can’t be passed through tags like a string, use the setUserObject method. class MyLayer : public CCLayer { protected: // Class member that stores how many times // the button has been clicked size_t m_clicked = 0; bool init() { if (!CCLayer::init()) return false; auto menu = CCMenu::create(); auto btn = CCMenuItemSpriteExtra::create( ButtonSprite::create("Click me!"), this, menu_selector(MyLayer::onClick) ); btn->setPosition(100.f, 100.f); btn->setUserObject(CCString::create("Button 1")); menu->addChild(btn); auto btn2 = CCMenuItemSpriteExtra::create( ButtonSprite::create("Decrement"), this, menu_selector(MyLayer::onClick) ); btn2->setPosition(100.f, 60.f); btn->setUserObject(CCString::create("Button 2")); menu->addChild(btn2); this->addChild(menu); return true; } void onClick(CCObject* sender) { // Get the user object auto obj = static_cast(sender)->getUserObject(); // Cast it to a CCString and get its data auto str = static_cast(obj)->getCString(); auto btn = static_cast(sender); // getNormalImage returns the sprite of the button auto spr = static_cast(btn->getNormalImage()); spr->setString(CCString::createWithFormat( "Clicked %s", str )->getCString()); } }; If you want to pass multiple parameters, create your own aggregate type that inherits from CCObject and store the parameters there: struct MyParameters : public CCObject { std::string m_string; int m_number; MyParameters(std::string const& str, int number) : m_string(str), m_number(number) { // Always remember to call autorelease on your classes! this->autorelease(); } }; // When creating your button: btn->setUserObject(new MyParameters("Hi!", 7)); // In the callback: auto parameters = static_cast( static_cast(sender)->getUserObject() ); ⚠️ There also exists a similarly named setUserData member in CCNode, but using it should be avoided as unlike setUserObject it’s not garbage collected and will lead to a memory leak unless handled carefully. Circle button sprites ⚠️ These are actually way more important than what this short paragraph gives off, but I was too lazy to write more. Geode comes with a concept known as based button sprites, which are button sprites that come with common GD button backgrounds and let you add your own sprite on top. These are useful for texture packs, as texture packers can just style the bases and don’t have to individually make every mod fit their pack’s style. #include // ... auto spr = CircleButtonSprite::createWithSpriteFrameName("top-sprite.png"_spr); Creating Popups Whenever you’re designing an UI, you should always make it clear to the user whether an action is pending, if something has gone wrong and if something is succesful. For this purpose, you could always design your own dedicated solution for showing status, but in many cases that’s a good idea, but in many other cases you should just use a common, simple solution: popups. They are ubiqutous in GD and in mods, as they are a very simple and quick way of showing the user information. The standard popup class in GD is FLAlertLayer. This class comes with a shaded background, title, text, buttons, and all the other stuff you expect. Using this class is pretty simple too: FLAlertLayer::create( "Title", // title "Hi mom!", // content "OK" // button )->show(); This is the way GD does simple popups and also the recomended way in Geode to do simple info popups. If you just need to tell the user some info like that an action was succesful, this is the best way. Questions However, using FLAlertLayer directly is not always ideal. Say that you want to have multiple buttons in the popup, and do something based on which one was clicked; for example, a confirmation popup for deleting a level. For this case, GD uses the FLAlertLayerProtocol member in FLAlertLayer::create. However, this is not recommended, as doing this comes with a lot of extra boilerplate. To use this, you need to inherit from FLAlertLayerProtocol in your class, then override FLAlert_Clicked, then pass the layer as the first argument to FLAlertLayer::create and in FLAlert_Clicked handle the action. And then if you want to introduce multiple popups in the same layer, you will need to keep track of tags and which popup is which and it all becomes a huge mess of unworkable code. Luckily, Geode provides a much better alternative: the createQuickPopup function. It takes similar parameters to FLAlertLayer::create, but also takes an std::function callback for when the popup is clicked. Using it looks like this: geode::createQuickPopup( "Title", // title "Say hi to mom?", // content "Nah", "Yeah", // buttons [](auto, bool btn2) { if (btn2) { // say hi to mom } } ); This makes working with simple confirmation popups much simpler, as you don’t have to bring in any extra inheritance or boilerplate. Just call a function, and pass a callback function for the result. Geode mods are highly encouraged to use this over FLAlertLayerProtocol. However, as this is not an interoperability concern, you are free to do whatever fits your needs. Complex popups However, what if you want to make a popup that’s more complex? For example, something with a different background and lots of buttons and other controls, like the move trigger popup? For this, the unrecommended GD way is to inherit from FLAlertLayer and override init with your own code. However, this is not ideal, as most complex popups share a lot of similar base functionality like a close button and a standard GJ_squareXX background. For this reason, Geode provides a convenience class Popup<...> for creating your own complex popups. // specify parameters for the setup function in the Popup<...> template class MyPopup : public geode::Popup { protected: bool setup(std::string const& value) override { auto winSize = CCDirector::sharedDirector()->getWinSize(); // convenience function provided by Popup // for adding/setting a title to the popup this->setTitle("Hi mom!"); auto label = CCLabelBMFont::create(value.c_str(), "bigFont.fnt"); label->setPosition(winSize / 2); this->addChild(label); return true; } public: static MyPopup* create(std::string const& text) { auto ret = new MyPopup(); if (ret && ret->init(240.f, 160.f, text)) { ret->autorelease(); return ret; } CC_SAFE_DELETE(ret); return nullptr; } }; Popup contains one pure virtual member function: setup, whose parameters are the class template arguments. This function is called at the end of Popup::init, which initializes all the relevant FLAlertLayer members and adds a background and a close button. This abstracts away a lot of boilerplate and makes creating complex popups simple. This is the recommended way to create complex popups in Geode, although as with question popups, this is not an interoperability concern and as such you can do what fits your case. If you are porting an existing mod that uses some other setup and it works just fine, no need to change it unless you want to make the codebase more easily refactorable. Colored text FLAlertLayer supports colored text in the content field by default. You can add colors with color tags, for example Hi mom! will produce yellow text. The built-in color tags in GD are: Tag Color cb Blue cg Green cl Aqua cj Cyan cy Yellow co Orange cr Red cp Pink FLAlertLayer::create( "Color Example", "This is pink text!", "OK" )->show(); Note that the closing tag must be only without the color specified again. Doing otherwise will likely result in a crash. You might wonder about how to use other colors than the ones listed; there are currently no plans in Geode to add that, but one could easily make a mod that adds support for arbitary color tags. Disabling the popup animation You can disable the popup’s enter animation by setting the m_noElasticity member to true. ⚠️ Make sure to set the member prior to calling show() on the layer; usually this means you have to store the alert in a member auto alert = FLAlertLayer::create( "BOO!", "Haha! Were you scared?", "EEK!!" ); alert->m_noElasticity = true; alert->show(); Popup not showing up Sometimes you want to create a popup and show it in a layer’s init function. However, if you do something like this: class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; FLAlertLayer::create( "Title", "Hi mom!", "OK" )->show(); return true; } }; You will find that the popup curiously doesn’t show up. This is because FLAlertLayer::show by default adds the popup to the current scene, and a layer’s init function is usually called right before leaving the scene, which makes the popup show on the previous scene instead of the new (current) one. The solution to this is to first set the layer’s m_scene member to the layer in init before calling show, as in: class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; auto alert = FLAlertLayer::create( "Title", "Hi mom!", "OK" ); alert->m_scene = this; alert->show(); return true; } }; This will make the popup show correctly by adding it as a child to the new MenuLayer instead of the previous scene. For most things in GD, such as CCTextInputNode, GD and Cocos2d-x use a delegate-based event system, where you install a delegate on the target class, and the delegate receives events via overridden virtual functions. This system works fine for most situations, but is often quite clumsy to use and runs into a few important issues: you have to manually deal with removing the delegate if the target class outlives the delegate, and more importantly, you can only have one delegate per target. As an alternative to this system, Geode introduces events. Events are essentially just small messages broadcast across the whole system: instead of having to install a single delegate, an unlimited number of classes can listen for events. The target that emits the events does not need to have any knowledge of its consumers; it just broadcasts events, and any receivers there are can handle them. Events are primarily interacted with through three classes: Event, EventListener, and EventFilter. Event is the base class for the events that are being broadcast; EventListener listens for events, and it uses an EventFilter to decide which events to listen to. Let’s explore how they work through an example. Consider a system where one mod introduces a drag-and-drop API to Geode, so the user can just drag files over the GD window. Now, this mod itself probably won’t know how to handle every single file type ever; instead, it exposes an API so other mods can handle actually dealing with different file types. However, using a delegate-based system here would be quite undesirable - there is definitely more than one file type in existence. While the mod could just have a list of delegates instead of a single one, those delegates have to manually deal with telling the mod to remove themselves from the list when they want to stop listening for events. Instead, the drag-and-drop API should leveradge the Geode event system by first defining a new type of event based on the Event base class: using namespace geode::prelude; class DragDropEvent : public Event { public: using Files = std::vector; protected: Files m_files; CCPoint m_location; public: DragDropEvent(Files const& files, CCPoint const& location); Files getFiles() const; CCPoint getLocation() const; }; Now, the drag-and-drop mod can post new events by simple creating a DragDropEvent and calling post on it. void handleFilesDroppedOnWindow(...) { ... DragDropEvent(...).post(); } That’s all - the drag-and-drop mod can now rest assured that any mod expecting drag-and-drop events has received them. Let’s see how that listening part goes, through an example mod that expects GDShare level files and imports them: using namespace geode::prelude; $execute { new EventListener>(+[](DragDropEvent* ev) { for (auto& file : ev->getFiles()) { if (file.extension() == ".gmd") { handleGMDImport(file); // This stops event propagation, marking the file as handled. // Stopping propagation is usually not needed, and shouldn't be // done by default, however sometimes you want to stop other // listeners from dealing with the event - such as here, where // importing the same file twice would be undesirable return ListenerResult::Stop; } } // Propagate this event down the chain; aka, let other listeners see // the event return ListenerResult::Propagate; }); } This is all the mod needs to do to set up a global listener - one that exists for the entire duration of the mod. Now, whenever a DragDropEvent is posted, the mod catches it and can do whatever it wants with it. This code also uses the default templated EventFilter class, which just checks if an event is right type and then calls the callback if that is the case, stopping propagation if the callback requests it to do so. However, we sometimes also want to create custom filters. For example, let’s say another mod wants to use the drag-and-drop API, but instead of always listening for events, it wants to have a specific node in the UI that the user should drop files over. In this case, the listener should only exist while the node exists, and only accept events if it’s over the node. We could of course deal with this in the global callback, however we can simplify our code by creating a custom filter that handles accepting the event. We can also include the file types to listen for in the filter itself, simplifying our code even further. We can create a custom EventFilter by inheriting from it: using namespace geode::prelude; class DragDropOnNodeFilter : public EventFilter { protected: CCNode* m_target; std::unordered_set m_filetypes; public: // The callback does not need to return ListenerResult nor take the whole // DragDropEvent as a parameter - if the callback is called, then we know // the event was over the node and the file types were correct already using Callback = void(std::vector const&); ListenerResult handle(MiniFunction fn, DragDropEvent* event); DragDropOnNodeFilter(CCNode* target, std::unordered_set const& types); }; For the implementation of handle, we need to check that the event occurred on top of the target node: ListenerResult DragDropOnNodeFilter::handle(MiniFunction fn, DragDropEvent* event) { // Check if the event happened over the node if (m_target->boundingBox().containsPoint(event->getLocation())) { // Filter out only file types we can accept std::vector valid; for (auto& file : event->getFiles()) { if (m_filetypes.contains(file.extension().string())) { valid.push(file); } } fn(valid); // Mark dropped files as handled return ListenerResult::Stop; } // Otherwise let other listeners handle it return ListenerResult::Propagate; } Now, to install an event listener on a specific node, we have two options. If the node is our own class, we can just add it as a class member: class DragDropNode : public CCNode { protected: EventListener m_listener = { // You can bind member functions as event listeners too! this, &DragDropNode::onDrop, // The filter requires some args so we have to explicitly construct it DragDropOnNodeFilter(this, { ".gmd", ".gmd2", ".lvl" }) }; void onDrop(std::vector const& files) { // Handle dropped files } }; When DragDropNode is destroyed, the listener is automatically destroyed and unregistered aswell, so you don’t need to do anything else. However, using a member function is not always possible. For example, if you’re hooking a class, event listeners don’t work in fields; or if you want to listen for events on an existing node whose class you don’t control. In these cases, there exists a Geode-specific helper called CCNode::addEventListener. You can use this to add event listeners to any node - including existing ones by GD! auto dragDropNode = CCNode::create(); dragDropNode->template addEventListener( [dragDropNode](auto const& files) { // Handle dropped files }, { ".gmd", ".gmd2", ".lvl" } ); addEventListener is meant only for events that are have a target node - it assumes that the first parameter of the filter’s constructor takes this as the argument. Other parameters to the filter’s constructor, such as the file types here, can be passed as the rest of the argument list to addEventListener. Any event listener added with addEventListener is automatically destroyed aswell when the node is destroyed. You can also provide a string ID for the event listener as the first argument to addEventListener, and then manually remove the listener later using removeEventListener. Fields Say you want to add a property to an existing class. One way you could do this is by storing the property in a global variable like so: int totalJumps = 0; class $modify(PlayerObject) { void pushButton(PlayerButton button) { log::info("the player has jumped {} times !", totalJumps); totalJumps++; PlayerObject::pushButton(button); } }; This works; however, it isn’t ideal. The counter never resets back down to 0, and the same value is shared across all instances of PlayerObject. One could solve this problem by using the setUserData function in CCNode or by utilizing more complicated systems, but both solutions are less than ideal. Geode provides a better alternative: fields. Fields let you add new member variables to modified classes. Take a look at an example: class $modify(PlayerObject) { int m_totalJumps; void pushButton(PlayerButton button) { log::info("The player has jumped {} times !", m_fields->m_totalJumps); m_fields->m_totalJumps++; PlayerObject::pushButton(button); } }; This code works even if you have multiple PlayerObjects, and the counter is initialized as 0 for each one, providing an elegant yet simple solution to the problem. Fields must be accessed through the m_fields member. If you access them directly through this, you will get undefined behaviour (most likely a crash). Fields are declared just like normal member variables, even constructors and destructors work*. class $modify(PlayerObject) { int m_totalJumps = 13; void pushButton(PlayerButton button) { log::info("the player has jumped {} times !", m_fields->m_totalJumps); m_fields->m_totalJumps++; PlayerObject::pushButton(button); } }; Note about addresses ⚠️ Fields are constructed and destructed in a different address than they exist normally (required for space optimization), so if you have a class that depends on the address of this inside the constructor/destructor, use std::unique_ptr to contain the said object. One such example would be Geode’s events, since they are registered to a global map in their constructor. GD Modding Dictionary As GD modding is a very specialized field, GD modders use a lot of specialized terminology that can be confusing for a newcomer. This dictionary lists and explains many common (and uncommon) terms used by GD modders, to help new modders better understand this weird world. Address The location in the raw program binary where a function or other program data is found. Assembly A “human-readable” form of binary code. Further reading: Wikipedia Binary Depending on context, may refer to the program binary of GD, aka GD’s raw machine code found in GeometryDash.exe on Windows, or just binary data aka 1s and 0s in general. Further reading: Wikipedia CacaoSDK An old modding framework that merged with Lilac and formed Geode. Calling Convention A source of pain and suffering on Windows. Dictates whether and how function parameters are passed through registers and the stack. Common calling conventions used in GD include thiscall, optcall, and membercall. CappuccinoSDK A library consisting of Cocos2d headers with a few RobTop modifications listed, used even before traditional modding got its proper start. A fully outdated and deprecated library. Related words: Geode, Traditional modding Cheat Engine A debugger commonly used by Windows modders. Homepage Cocos2d The game engine used by GD. The version used by GD is Cocos2d-x v2.2.3, however with many propietary modifications by RobTop, meaning that you need to use a specially prepared version that accounts for these changes such as Geode or cocos-headers in order to make mods. Homepage Cocos-headers A popular library used in traditional mods consisting of Cocos2d headers with many of RobTop’s modifications added. Homepage Debugger A tool used for debugging another application (usually GD) for issues (usually crashes), such as x32dbg or Cheat Engine. Further reading: Wikipedia Detour The code you wrote that is run instead of the original function in a hook. Related words: Trampoline, Hooking Director The central manager class in Cocos2d that manages the current scene and the nodes in it. Further reading: Cocos2d docs Related words: Node tree, Scene, Node, Menu, Popup, Layer Extension A different name for mods that is usually used to refer to Mega Hack extensions. GD.h A popular library used in traditional mods that contains many GD functions and classes. Originally started by PoweredByPie, but the most popular version is the fork by HJfod. Homepage Related words: Geode, Traditional modding Geode A framework meant as a replacement for traditional modding with the aim of standardizing many aspects of modding and fixing mod incompatabilities. Homepage Geometry Dash It’s the game. Ghidra A free tool many modders use for reverse engineering. Homepage .GMD Files A file format for storing GD levels, popularized by GDShare. The level data is stored in plain text as its Plist data with a surrounding tag. .GMD2 Files Another, more complex file format for storing GD levels, popularized by GDShare. Stored as a ZIP file instead of plain text. Related words: .GMD Files Hooking Hijacking the execution of a function in GD and redirecting it to your own function. The part of a mod that actually does the modifying; the most fundamental modding concept alongside patching. Further reading: Handbook, Wikipedia Related words: Detour, Patching, Trampoline Hook Conflict A race condition where two mods try to hook the same address at the same time, but the hooking library used doesn’t provide thread safety. The result is usually one of the hooks mysteriously disappearing. A problem often found in mods that statically link MinHook. Related words: Geode, MinHook, Race Condition Hyperdash An old, never-released framework for creating GD mods. An important influencer that seminally shaped how GD modding looks. IDA Pro A paid tool many modders use for reverse engineering. Homepage Layer A distinct self-contained piece of UI on screen, for example the main menu, the icon select layer, or the move trigger edit popup. Usually inherits from the CCLayer class. In any scene, there is usually one layer at the bottom of the node tree with potentially popups on top. Related words: Node tree, Scene, Node, Menu, Popup Lilac An old modding framework that merged with Cacao and formed Geode. Manager A class that only has a single instance at all times, which is acquired usually through a static getter method in the class itself. Common examples include GameManager, which manages everything in GD; GameLevelManager, which manages levels; and CCDirector, which manages the node tree. Mega Hack The most popular GD mod of all time, developed by Absolute. Also functions as one of the most popular mod loaders. Homepage Membercall An undocumented calling convention used on Windows, which is a merge between thiscall and optcall. Used by the vast majority of functions in GD. Menu An instance of the CCMenu class that holds interactive elements such as buttons. Required for buttons that inherit from the CCMenuItem class to work, so in practice virtually all buttons in Geometry Dash. This means that every button on screen is the direct child of some menu. Related words: Node tree, Scene, Node, Layer, Popup MinHook A popular library used for hooking in traditional mods. Homepage Mod A program that modifies GD by adding, changing, and removing content using various techniques such as hooking and patching. Traditionally made using libraries such as gd.h and cocos-headers, but may also be made using a framework such as Geode. Mod Incompatabilities When two mods become incompatible with each other, for example through a hook conflict or accessing the node tree through absolute indices. Mod Loader A mod that loads other mods. Node An instance of the CCNode class or its subclass. A singular visual element on screen, for example a button or a label. Has a parent, and may have multiple children. Nodes usually utilize child nodes to form UI components over drawing their own content; for example, a button consists of a child background sprite and a label instead of drawing those in its own logic. A node may have a position, rotation, scale, etc.. Related words: Node tree, Scene, Layer, Menu, Popup Node Tree The hierarchy of nodes that determines the order of visual elements on screen. At the top of the node tree sits a scene, which contains child layers that in turn contain other child nodes. Further reading: Cocos2d docs Optcall An undocumented calling convention used on Windows where the first and second parameters are passed through ECX and EDX and the rest through the stack, except for some floating point numbers which are passed through XMM registers. Used by many functions in GD. Further reading: This post on the GD Programming Discord Server Patching Also known as byte patching; the act of directly changing GD’s program code by overwriting bytes in the raw binary. Often used to do things like simple bug fixes and bypassing anticheat. The most fundamental modding concept alongside hooking. Related words: Binary .Plist Files A file format used by GD, invented by Apple, that stores data as XML organized into key-value pairs. Further reading: Wikipedia Popup A layer that visually sits on top of another layer. Usually inherits from the FLAlertLayer class. Related words: Node tree, Scene, Node, Layer, Menu Race Condition When two programs try to affect the same thing simultaniously and the result depends on the order in which they finish. Most commonly encountered in the form of hook conflicts. Further reading: Wikipedia Register A fixed-length memory location in a CPU that can store a small amount of data. Usually, for a CPU to operate on data that data has to be stored in a register. Further reading: Wikipedia Reverse Engineering The process of disassembling, decompiling, and understanding how GD works. Usually done using specialized tools such as Ghidra or IDA Pro, but may also be done using debuggers, trial-and-error modding, or just playing GD. Further reading: Wikipedia Scene The node that is at the top of the node tree. There may only be one scene visible at a time, although that scene may technically contain other scenes as children. All visible nodes on screen have the current scene as their ancestor*. Switching between scenes is done through the director and usually involves a transition. *There is a way in Cocos2d to make visible nodes without adding them to the scene, but this is not used by GD and rarely used in mods. Related words: Node tree, Popup, Node, Layer, Menu Stack A last-in first-out datastructure used for storing program memory. Way too complex of a topic for a simple dictionary. Further reading: Wikipedia, Stack Overflow Thiscall A calling convention used on Windows where the first parameter is passed through ECX and the rest through the stack. Used by most functions in Cocos2d. Traditional Modding Mods made and modding done without a dedicated framework like Geode, usually using a combination of gd.h, cocos-headers, and MinHook. Trampoline Also known as “the original function”, it is what you call to invoke the behaviour of the function you overwrote in a hook. Related words: Detour, Hooking Transition An animation that is played when switching from one scene to another. In GD, this is nearly always a fade transition. Inherits from the CCTransition class. Also, what most GD modders do once they become experts. Related words: Node tree, Scene, Node, Menu, Popup, Layer Undefined behaviour (UB) Code where the C++ standard does not say what should happen, and as such the results are completely unpredictable. Your code is most likely full of this. Further reading: cppreference.com x32dbg A debugger commonly used by Windows modders. Homepage Getting nodes There comes a time in every GD modder’s life when they are faced with the same eternal question: how to get a specific node from a certain layer. The easiest, and incontestably best way to do this is through member variable access. If the desired node is stored as a member in the layer, for example m_playtestBtn in EditorUI, you should always access it through that. However, this is far from always possible, as not all nodes are stored as members in their containing layers. This poses a problem, the easiest solution to which has been the source of hours of pain and misery. The solution referred to here is getting nodes by their absolute index. It should be stressed here, at the very start, that you should NEVER get nodes by their index unless ABSOLUTELY necessary. It should always be left as a last resort. The Cocos2d node tree is not a stabile or predictable environment; child indexes can change rapidly due to game features, Z-order reordering, or most commonly due to other mods. If you do node->getChildren()->objectAtIndex(5), you have no guarantees of getting the same node every time. Using absolute indexes also requires a lot of work, as the indexes are shuffled around after a layer’s init function due to Z-order reordering. This means that if you look at a node through CocosExplorer or DevTools and see that is is at index 5, it is more than likely that during the layer’s init function (where you will most likely be working with the node) this will not be the case. On top of this, in old GD modding frameworks, there were unfortunately basically no alternatives to members and getting by index. There are node tags, however tags are mostly used to implement differing functionality for buttons that use the same callback. The result of this was a lot of mods using raw indexes to position their own additions to GD’s UI. Surprise surprise, this lead to even mods by the same developer messing up their button positions due to indexes being different than expected. Using raw indexes are one of the biggest sources of mod incompatability; and as Geode is meant to help with solving that, it introduces a whole new way of getting nodes: String IDs String IDs are a Geode-specific addition to the CCNode class that come in three main functions: CCNode::getID, CCNode::setID and CCNode::getChildByID. In all their simplicity, it means that you can assign any CCNode a string ID, and get a child by its string ID. On the surface, this may seem quite trivial, but this is actually an incredibly powerful alternative to using raw indexes. Whereas raw indexes are shuffled around and unreliable, you can be almost certain that node->getChildByID("specific-node-id") will always return the same node. For example, using string IDs, adding a new button to the left of the icon kit button in the main menu is as simple as this: class $modify(MenuLayer) { bool init() { auto menu = this->getChildByID("main-menu"); auto iconKitBtn = menu->getChildByID("icon-kit-button"); auto btn = /* create button */; btn->setPosition(iconKitBtn->getPosition() - CCPoint { -50.f, 0.f }); menu->addChild(btn); } }; Notice that there are no hardcoded indexes. Even if main-menu is at a completely different index than expected, as long as the main menu in MenuLayer has the ID main-menu, the code will always find it and work as expected. Although, this code does also have another interoperability concern: sure, we can be sure we added our node to the right place, but what if some other mod does the same? If another mod adds a button to the left of the icon kit button, they would overlap. To solve this issue, Geode introduces layouts, which are discussed in their own tutorial. This also highlights the problem with string IDs: someone has to assign them. Whereas raw indexes are an intrinsic property of all CCNodes, the default ID of a node is an empty string (""). Geode does come with default IDs for common classes like MenuLayer, but there are unfortunately too many layers in GD to label all of them. This has, however, been taken in mind when designing the string ID system. If you find a layer you want to get a child of is missing string IDs, what you can do is add them yourself (using members or raw indexes), and either send your code for adding them to Geode or let others know your mod adds these IDs. This way, someone else who wants to get the same children from the same layer can easily piggyback off of your logic. While the string ID system is ultimately and unfortunately based on raw indexes, its point is to provide a single source of truth for those indexes; once someone has done the work, no one should have to do it again. Viewing String IDs You can see if a layer’s nodes have string IDs using the DevTools mod, which shows them in the Tree view. String IDs in your own layers It is recommended for you to also use string IDs in your own layers, as this makes mod-modifying-mod interoperability much easier. Naming String IDs String IDs you give to nodes should be in kebab case with only lowercase a-z letters and no spaces. Hooking / Modifying classes At the centre of every modder’s toolkit is hooking. If you don’t know what that is, read the handbook. If you know what that is and have made mods using gd.h + cocos-headers before, you should know how it works in Geode. Modifying a function Modifying classes is done using the macro $modify. If a function inside GD is implemented (or a custom modifier exists, which will be explained a lot later), you can use this macro to alter its behaviour. For example, to change the behaviour of the “More Games” button in GD, all you have to do is this: class $modify(MenuLayer) { void onMoreGames(CCObject* target) { FLAlertLayer::create( "Geode", "Hello World from my Custom Mod!", "OK" )->show(); } }; Wait wait wait, so what does this exactly do? The function we are modifying is MenuLayer::onMoreGames, which is called when you press the “More Games” button. This function takes a single parameter, a cocos2d::CCObject*, which is the target object the function is called on. For our use case, we don’t need this parameter. The syntax is class $modify(ModifiedClassName), which is selected mostly for aesthetics and not breaking the syntax highlighting. Inside this class, we add the functions we will modify. The example will replace the implementation of MenuLayer::onMoreGames, making it spawn a FLAlertLayer instead of the More Games screen. Using the original function Sometimes you will want to not replace, but extend on a function. This is why you may (and mostly do) need to access the original function. This is done in the same way C++ handles base functions. In order to call a function from a base class, you specify the class and function name together. Here is an example: class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; auto label = CCLabelBMFont::create("Hello world!", "bigFont.fnt"); label->setPosition(100, 100); this->addChild(label); return true; } }; (or you could be questionable and do this->MenuLayer::init() but who am I to judge) This pattern is quite common inside cocos2d, and therefore in GD too. Here, we modify the MenuLayer::init so that it will create our label inside the layer after running the original function. If MenuLayer::init returns false something has gone horribly wrong and GD will probably crash but it is important to stick to the idioms for code consistency. Giving a class name You will probably encounter an issue with $modify in your very first use case: how do you add callbacks for buttons? By default, $modify gives the inherited class a pretty much random name, but if you want to reference the name of your modified class, that’s not very ideal as it’s not consistent. Luckily, $modify can take a second parameter that specifies the name of the class: class $modify(MyAwesomeModification, MenuLayer) { void onMyButton(CCObject* target) { FLAlertLayer::create( "Geode", "Hello World from my Custom Mod!", "OK" )->show(); } bool init() { if (!MenuLayer::init()) return false; auto buttonSprite = CCSprite::createWithSpriteFrameName("GJ_stopEditorBtn_001.png"); auto button = CCMenuItemSpriteExtra::create( buttonSprite, nullptr, this, menu_selector(MyAwesomeModification::onMyButton) ); auto menu = CCMenu::create(); menu->addChild(button); menu->setPosition(150, 100); this->addChild(menu); return true; } }; The syntax for this is class $modify(MyClassName, ClassToModify). Creating a CCMenuItemSpriteExtra takes a SEL_MenuHandler, which is a type alias for void(cocos2d::CCObject::*)(cocos2d::CCObject*) (which means a pointer to a member function that has a single parameter of CCObject*). In order to supply this we need to get access to our function address, which requires us to know the class name. When we don’t supply a class name, the macro generates a class which is guaranteed to not create any collision problems. Read more about menu selectors here Modifying destructors Mostly because of specific cases of destructors, modifying them is a bit different. You need to create a function named destructor instead of a destructor to modify them. Here is an example: class $modify(FLAlertLayer) { void destructor() { FLAlertLayer::~FLAlertLayer(); log::info("this alert layer is destructed: {}", this); } }; You still need to call the base destructor itself for calling the original. This pattern is the same for constructors. Using without macros If you need to refrain from using the $modify macro (clang-format really cries when it sees the macro so), here is how you would do it: struct MyCoolModification : Modify { void onMoreGames(CCObject* target) { FLAlertLayer::create( "Geode", "Hello World from my Custom Mod!", "OK" )->show(); } }; Yeah we improved the clean usage a lot, and honestly I prefer this over the macro. But who am I to judge? Adding members Geode allows you to add members to your modified classes to extend GD classes nearly seamlessly. Learn more about fields Advanced usage Accessing the hooks Even with this sugary (wow i hate that word) clean syntax hooking, there are still some stuff we can’t do without a way of interacting with the hooks, like giving it a priority, manually enabling/disabling even though I’m against it. That’s why there is the onModify function. This function is called when the hooks are registered to Geode, more specifically the static constructor time of the mod load. Here is how: class $modify(MenuLayer) { static void onModify(auto& self) { auto res = self.getHook("MenuLayer::init"); if (!res) { log::error("Something went horribly wrong"); return; } log::info("I hooked {}!", res.unwrap()->getDisplayName()); } bool init() { if (!MenuLayer::init()) return false; log::debug("Hi mom I made a modding framework with some friends!") return true; } }; See the ModifyBase class to see what functions are available (there aren’t much to be honest). Also please don’t manually enable/disable hooks unless you need to. Oh also did I tell you to never manually enable/disable hooks? Do you still need it? Well, you will need to use Hook::setAutoEnable for Geode to not automatically enable your hooks when the mod is enabled, so have fun with that I guess. Just one more thing: please don’t manually enable/disable your hooks unless you have to. Setting hook priority You might want to do this because your code may need to run before others (Geode string id system for example). Or you don’t call the original so you might want your function to get called last. This is where the priority system is helpful. Here is how you use it: class $modify(GJGarageLayer) { static void onModify(auto& self) { self.setHookPriority("GJGarageLayer::init", 1024); } bool init() { if (!GJGarageLayer::init()) return false; NodeIDs::get()->provide(this); return true; } }; Adding delegates Even though it is kinda inconvenient, this is how you would do it. Be careful about that comment! struct MyDelegateClass : Modify, TextInputDelegate { MenuLayer* self; std::string myString; void textChanged(CCTextInputNode* node) override { // here, this points to m_fields, so you will need that self // variable in order to access the MenuLayer itself myString = node->getString(); } bool init() { if (!MenuLayer::init()) return false; m_fields->self = this; auto input = CCTextInputNode::create(250, 20, "Enter text", "bigFont.fnt"); input->setDelegate(m_fields.self()); input->setPosition(100, 100); this->addChild(input); return true; } void onMoreGames(CCObject* target) { FLAlertLayer::create( "Geode", "Your text is: " + m_fields->myString, "OK" )->show(); } }; Adding new virtual functions We currently don’t support this yet, but here is how you would do it anyway (I promise I will add this soon ™️): class $modify(CopyPlayerObject, PlayerObject) { static void onModify(auto& self) { self.registerVirtual(&CopyPlayerObject::copyWithZone); } CCObject* copyWithZone(CCZone* zone) { log::info("This function is a meme really"); } }; Creating a custom modifier Not yet implemented Common mistakes Here are some common mistakes you (and we) may make: Accidental recursion class $modify(MenuLayer) { void onMoreGames(CCObject* target) { log::info("MenuLayer::onMoreGames called woooo"); this->onMoreGames(target); // !! } }; This will result in an infinite loop, because this-> calls the modified MenuLayer’s onMoreGames instead of the original’s. Name the class you’re calling the function from instead (MenuLayer::onMoreGames). Accidental not recursion class $modify(MenuLayer) { bool init() { if (!this->init()) return false; // !! auto label = CCLabelBMFont::create("Hello world!", "bigFont.fnt"); label->setPosition(100, 100); this->addChild(label); return true; } }; This will not result in an infinite loop because MenuLayer::init is a virtual function, but please don’t do this->function. It will confuse us all. Accidentally not using the correct function class $modify(MyBrokenClass, MenuLayer) { void onMoreGames(CCObject* target) { log::info("MenuLayer::onMoreGames called woooo"); MenuLayer::onMoreGames(target); } bool init() { if (!MenuLayer::init()) return false; auto buttonSprite = CCSprite::createWithSpriteFrameName("GJ_stopEditorBtn_001.png"); auto button = CCMenuItemSpriteExtra::create( buttonSprite, this, menu_selector(MyBrokenClass::onMoreGames) ); auto menu = CCMenu::create(); menu->addChild(button); menu->setPosition(150, 100); this->addChild(menu); return true; } }; This will result in the modification getting called twice when you press the newly created button, then the original function will be called. (MyBrokenClass::onMoreGames -> handler -> MyBrokenClass::onMoreGames -> handler -> MenuLayer::onMoreGames) Not supplying the correct signature class $modify(MenuLayer) { bool onMoreGames(CCObject* target) { // !! FLAlertLayer::create( "Geode", "Hello World from my Custom Mod!",´ "OK" )->show(); return true; } }; This will result in not modifying the intended function at all, because onMoreGames has return type void in MenuLayer, not bool. I previously tried to implement a check for this in the old version of the modify, but failed miserably. I should honestly try again, but I’m kinda scared that it may increase compile times. Layouts 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 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 mod, which has an option to show all layouts in the current scene. Image of the DevTools mod in GD, showcasing the layouts in MenuLayer Using layouts to position nodes Using layouts is very simple - especially if someone else has already set the layout for you. For example, if you want to add a child to bottom menubar in the main menu and position it in a row along with the other buttons there, doing so is very simple: struct $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; auto menu = this->getChildByID("bottom-menu"); menu->addChild(/* create button */); menu->updateLayout(); return true; } }; Notice that we don’t have to do any sort of manual positioning to our button - all we have to do is call CCNode::updateLayout after adding our node to the menu, and it will automatically position the button for us. Adding layouts If you’d like to add layouts to your own nodes or overwrite the layouts of existing nodes, you can do so by calling setLayout on the node: auto myMenu = CCMenu::create(); myMenu->setLayout(RowLayout::create()); AxisLayout Geode only adds one type of layout, 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 and 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 method. You can play around with the different options AxisLayout offers using the DevTools mod. Image of the DevTools mod, showing the different options for AxisLayout Custom layouts If AxisLayout doesn’t fully match your needs, you can also define entirely custom layouts by inheriting from the Layout class and implementing the apply method. Making Web Requests Making web requests in C++ sucks, and GD doesn’t really help with it. Cocos2d has the CCHTTPRequest class, which GD uses to make its web requests, but it’s a complicated mess to try to get working and it’s not really ergonomical. Luckily, Geode come to the rescue with the geode::utils::web namespace, which contains functions resembling a familiar web API: fetch. Geode has two types of web requests: synchronous and asynchronous. Synchronous requests This is the easiest form of web request you can make. Want to fetch some simple data? Use web::fetch("https://site.url"). The function returns a result of either a string, or an error message. Similarly, you can use web::fetchBytes to get a byte array instead, or web::fetchFile to download a file. Example: #include using namespace geode::prelude; // download a- uh... auto res = web::fetch("https://pastebin.com/raw/vNi1WHNF"); if (!res) { // handle error } // the resulting data :3 auto data = res.value(); However, the synchronous web API should only be used for short, simple data. For downloading anything larger, it is recommended to use the asynchronous API instead. Asynchronous requests Of course, you could just create an std::thread and call fetch inside that, but that comes with all sorts of thread safety concerns, and you can’t interact with the GD UI from another thread. Luckily, Geode’s web::AsyncWebRequest API is fully thread-safe and all its callbacks are run in the GD thread, meaning you can safely interact with UI. Creating an async web request is really simple: #include using namespace geode::prelude; web::AsyncWebRequest() .fetch("https://pastebin.com/raw/vNi1WHNF") .text() .then([](std::string const& catgirl) { // do something with the catgirl :3 }) .expect([](std::string const& error) { // something went wrong with our web request Q~Q }); That’s it. The web request will then be dispatched, and after it’s finished the callback passed to then will be run, and on failure the callback passed to expect will be run. There are also callbacks like progress for keeping track of the file download, and cancelled for checking if the request has been cancelled. The latter is not usually required, as expect will be run aswell if the request is cancelled while it is downloading. However, if you’re downloading a bunch of files in bulk, a request may be cancelled after it has been finished, in which case you should use cancelled to clean up any side-effects the then callback caused. If you want to ensure that a web request is only made once, for example if you want to update a global manager class, you can use the join method on AsyncWebRequest to make sure only one instance of the same request exists at a time. Join takes a fully arbitary string ID, which can be anything, but you should make sure it’s unique. Manual Hooks Sometimes, you need to hook some platform specific function that would be a hassle to manually add to bindings - or you want to provide support for adding hooks through other means than $modify, such as an embedded scripting language. In this case, you can also manually add hooks in Geode using Mod::addHook. Example The provided example hooks MenuLayer::onNewgrounds on Windows. ⚠️ This function can be hooked normally using $modify - this is just an example! Do not do this! void MenuLayer_onNewgrounds(MenuLayer* self, CCObject* sender) { log::info("Hook reached!"); // You can call the original by calling it - in this case, since the // original is in bindings, you can just call it the same way as you // would with $modify // TODO: How to call original manually self->onNewgrounds(sender); log::info("After original!"); } $execute { Mod::get()->hook( reinterpret_cast(geode::base::get() + 0x191E90), // address &MenuLayer_onNewgrounds, // detour "MenuLayer::onNewgrounds", // display name, shows up on the console tulip::hook::TulipConvention::Thiscall // calling convention ); } Hooking an imported function This example shows how to hook a function that is linked to, for example through DLL imports. Geode comes with the addresser namespace for utilities related to figuring out the addresses of linked functions, including class methods and virtual functions. void myDrawCircle(const cocos2d::CCPoint& center, float radius, float angle, unsigned int segments, bool drawLineToCenter) { // Call the original cocos2d::ccDrawCircle(center, radius, angle, segments, drawLineToCenter); log::info("alright {}", radius); } $execute { Mod::get()->hook( reinterpret_cast( // All of this is to get the address of ccDrawCircle geode::addresser::getNonVirtual( // This is used because this function is overloaded, // otherwise just a regular function pointer would suffice (&foobar) geode::modifier::Resolve::func(&cocos2d::ccDrawCircle) ) ), &myDrawCircle, // Our detour "cocos2d::ccDrawCircle", // Display name, shows up on the console tulip::hook::TulipConvention::Cdecl // Static free-standing cocos2d functions are cdecl ); } Memory Management Managing memory in general with C++ has been partially covered in C++ tips, but Cocos2d comes with its own memory management system that is all modders have to learn at some point. On top of this, Geode adds two classes, Ref and WeakRef, which Geode devs will tell you to use but not how to use them. This tutorial aims to remedy that, explaining how memory management in Cocos2d works in detail. Memory management Cocos2d’s memory management features are available to all classes that inherit from CCObject, as it is the base class that implements the required features. Cocos2d’s memory management works by ref counting - in other words, it just stores how many references exist to an object, and once the ref count reaches 0, the object’s memory is freed. Unfortunately, due to how C++ works, the ref counting is not directly automatic - it doesn’t know where the object is actually used, only the ref count stored inside it. In practice, classes like CCNode always handle retaining and releasing their children, so you usually don’t have to deal with memory management when building nodes. However, this does have consequences when it comes to class members, as we will see later. The easiest way to concretize this is to look at manual memory management in Cocos2d, which works by using the retain and release functions. In their simplicity, retain increments the object’s ref count by one, and release decrements it by one. // Ref count of created object is 0 auto node = CCNode::create(); // Increment ref count to 1 node->retain(); // Decrement ref count to 0, freeing the object node->release(); As a small bit of confusion, the ref count of a newly created object is always 0. However, the object is not freed, as the call to delete only happens inside release. As we are doing memory management manually, if you forget to call release on the retained object, you will get a memory leak as its ref count will never decrement back down to 0. If you want to release a just-created object, you don’t have to call retain on it - release will notice the ref count is already at 0 and free the object: // Ref count of created object is 0 auto node = CCNode::create(); // Ref count is already at 0, so this frees the object node->release(); You can think of retain and release like the following: retain tells Cocos2d “Hey, I’m still using this object, please don’t free it!”, and release tells it “Okay, I don’t need this object anymore!” In practice, if you have to do manual memory management, you likely won’t be using the retain and release functions directly and instead use the CC_SAFE_RETAIN and CC_SAFE_RELEASE macros: // Increment ref count CC_SAFE_RETAIN(node); // Decrement ref count CC_SAFE_RELEASE(node); The difference these macros have over direct function calls is that they check that the object isn’t nullptr first. ⚠️ You should never call release more than the amount of times you have called retain on an object to force-free it, as if some other code holds a pointer to the object and is expecting it to be retained, you will cause that code to break. Classes Remembering to manage every object you have ever created is a real problem, though. Luckily, most Cocos2d classes call retain for you. auto node = CCNode::create(); auto other = CCNode::create(); // CCNode increments other's ref count by 1, and decrements it when the child // is removed or when node is freed node->addChild(other); auto array = CCArray::create(); // CCArray increment node's ref count by 1, and decrements it when the child // is removed or when the node is freed array->addObject(node); This means that if you store your created object as a child to something or add it to an array, you don’t have to worry about memory management. However, if you don’t do that, you need to be careful: { auto array = CCArray::create(); // If this array is never used anywhere, it's ref count stays at 0 but // nothing calls release on it, so the memory is leaked - except it's not! } This code looks like it should cause a memory leak, since nothing ever calls release on the array. However, Cocos2d has an automatic garbage collector that handles situations like this. You may have seen that all create functions in nodes call a function called autorelease: SomeNode* SomeNode::create() { auto ret = new SomeNode(); if (ret && ret->init()) { // Make the node be automatically garbage collected ret->autorelease(); return ret; } CC_SAFE_DELETE(ret); return nullptr; } This tells Cocos2d that if no calls to retain are made to this object, it should be freed automatically later on. This means that the following code: { auto array = CCArray::create(); } does not cause a memory leak, as Cocos2d notices no retain calls to array have been made, and frees it. However, the array is not freed immediately; instead, it is usually freed at earliest on the next frame. This means that you can still use the array to do things: auto array = CCArray::create(); array->addObject(...); someNode->someFunction(array); and it will be automatically freed later on. Class members autorelease is very neat when you just want to quickly create an array to pass into a function, or something similar. However, it causes a bit of a headache when dealing with class members: class MyNode : public CCNode { protected: CCArray* m_array; bool init() { if (!CCNode::init()) return false; m_array = CCArray::create(); return true; } public: CCObject* getFirst() const { return m_array->firstObject(); } }; If you ran this code, you would notice that your mod mysteriously crashes in any call made to getFirst after a while. The reason for this is that m_array has been freed - no calls to retain were ever made to it, and since Cocos2d ref counting doesn’t actually have any knowledge of what pointers to an object exist, Cocos2d concludes that the array must not be in use. The solution, then, is to call retain on the array: class MyNode : public CCNode { protected: CCArray* m_array; bool init() { if (!CCNode::init()) return false; m_array = CCArray::create(); m_array->retain(); return true; } public: CCObject* getFirst() const { return m_array->firstObject(); } }; Now Cocos2d knows that m_array is actually being used, and won’t free it. However, now we have caused a memory leak: when MyNode is destroyed, the array’s ref count stays at 1, meaning it never gets freed. To fix this, we need to add a call to release in MyNode’s destructor: class MyNode : public CCNode { protected: CCArray* m_array; bool init() { if (!CCNode::init()) return false; m_array = CCArray::create(); m_array->retain(); return true; } virtual ~MyNode() { m_array->release(); } public: CCObject* getFirst() const { return m_array->firstObject(); } }; This is the conventional pattern for working with CCObject members, and you may find yourself reading old code that uses it, or even using it yourself. However, it comes with a problem: this gets really complex to work with really fast. Imagine that m_array is not just a member that is created once at the start and freed at the end, but instead may be nullptr, or may be removed later, or may even be swapped with other arrays. Dealing with ref counting manually in that case is a real pain: class MyNode : public CCNode { protected: CCArray* m_array = nullptr; bool init() { if (!CCNode::init()) return false; m_array = CCArray::create(); m_array->retain(); return true; } virtual ~MyNode() { CC_SAFE_RELEASE(m_array); } public: void swapArray(CCArray* other) { // Release existing array CC_SAFE_RELEASE(m_array); // Swap array m_array = other; // Retain the new array CC_SAFE_RETAIN(m_array); } void removeArray() { CC_SAFE_RELEASE(m_array); m_array = nullptr; } }; When you add in more members, trying to keep track of all these relations gets really complex, and the possibility of an accidental memory leak / memory issue increases exponentially. Luckily, Geode has a solution: Ref. Ref Ref is a smart pointer for CCObjects - in essence, it’s just a class that retains the object it points to, and releases it when Ref goes out of scope. In other words, it’s a RAII alternative to manual retain and release calls. Using it, we can refactor our previous code to just this: class MyNode : public CCNode { protected: Ref m_array = nullptr; bool init() { if (!CCNode::init()) return false; m_array = CCArray::create(); return true; } public: void swapArray(CCArray* other) { // Swap array m_array = other; } void removeArray() { m_array = nullptr; } }; Notice that all manual calls to retain and release disappeared from the code - Ref handles all of them for you. This makes writing and reasoning about code much simpler - you can be assured that as long as you have initially made a Ref to a valid object, it’s always going to stay valid, and the memory will be freed appropriately when you actually no longer use it. Ref is also relatively cheap - if you are unsure whether the lifetime of a pointer you have extends to your usage, just store the pointer in a Ref to stay safe. In general, you should at least stick Ref to all your class members, unless you can be certain about the lifetime of the object otherwise. WeakRef Ref does have a problem, however: since it increments the ref count, the object being pointed to will only be freed once the Ref goes out of scope. However, sometimes this won’t happen at a desirable time: for example, some mod might have a map like the following: static std::unordered_map REGISTERED_NODES {}; void addDataToNode(CCNode* node, SomeData const& data) { REGISTERED_NODES.insert({ node, data }); } void doSomethingWithNodes() { for (auto& [node, data] : REGISTERED_NODES) { // ... } } For example, a right mouse click API might store the nodes that have registered themselves as mouse right click event listeners like this. However, this code is never told when the CCNode pointer it has is no longer valid, so if the scene is changed and the nodes are freed while they are still in REGISTERED_NODES, the next call to doSomethingWithNodes will cause a crash trying to access already freed memory. Unfortunately, C++ has no way to know if a raw pointer is valid or not. Your first instinct here might be to make the CCNode a Ref: static std::unordered_map, SomeData> REGISTERED_NODES {}; void addDataToNode(CCNode* node, SomeData const& data) { REGISTERED_NODES.insert({ node, data }); } void doSomethingWithNodes() { for (auto& [node, data] : REGISTERED_NODES) { // ... } } Now you can be assured that REGISTERED_NODES only contains valid pointers to CCNodes. However, now we have a memory leak: if the user switches scenes, the only reference left to the CCNode will be the one in REGISTERED_NODES, which is probably undesirable, since we’d want the node to be removed from REGISTERED_NODES too when the node is no longer visible. A primitive solution to fixing this would be to check the node’s ref count, and if it’s 1 then we know only REGISTERED_NODES has a reference to it: static std::unordered_map, SomeData> REGISTERED_NODES {}; void freeUnusedNodes() { for (auto& [node, _] : REGISTERED_NODES) { if (node->retainCount() == 1) { REGISTERED_NODES.erase(node); } } } void addDataToNode(CCNode* node, SomeData const& data) { REGISTERED_NODES.insert({ node, data }); } void doSomethingWithNodes() { freeUnusedNodes(); for (auto& [node, data] : REGISTERED_NODES) { // ... } } However, this plan immediately falls apart once some other mod does the same, as the ref count is never reaching 1. For this reason, Geode provides another class: WeakRef, which is like Ref but it doesn’t change the ref count: static std::unordered_map, SomeData> REGISTERED_NODES {}; void addDataToNode(CCNode* node, SomeData const& data) { REGISTERED_NODES.insert({ node, data }); } void doSomethingWithNodes() { for (auto& [node, data] : REGISTERED_NODES) { // ... } } The difference between Ref and WeakRef is that Ref allows you to access the pointed object directly since it’s guaranteed to be valid. However, WeakRef has no such guarantees since it doesn’t impact the ref count, so you need to first lock it to see if the object is still valid: auto ref = WeakRef(obj); // Later on // Check if the reference still points to a valid object if (auto obj = ref.lock()) { } lock returns a Ref, so you have guaranteed safe access to the object for as long as you have the Ref. As WeakRef does not increment the reference count, if something frees the object beforehand, lock will return a null Ref. Now, WeakRef still won’t automatically remove itself from your maps, so you do still have to manually clear invalid pointers: static std::unordered_map, SomeData> REGISTERED_NODES {}; void freeUnusedNodes() { for (auto& [node, _] : REGISTERED_NODES) { if (node.lock() == nullptr) { REGISTERED_NODES.erase(node); } } } void addDataToNode(CCNode* node, SomeData const& data) { REGISTERED_NODES.insert({ node, data }); } void doSomethingWithNodes() { freeUnusedNodes(); for (auto& [node, data] : REGISTERED_NODES) { // ... } } However, now you can assured that this scheme won’t break if some other mod does the same. ⚠️ Note that a node that has weak references to it is only freed once one of those weak references triggers a recheck of the object. This is because WeakRef internally does actually increment the reference count, and uses the “check if reference count is 1” trick to know that only weak references exist to an object. This might seem counter-productive, but that scheme does work if Geode’s WeakRef system is the only one using it at a time, which it should be if modders follow guidelines properly. Migrating your mods from the traditional As Geode is currently incompatible with traditional mods, migration of old mods is a must in order to use them with Geode. This page shows how to do just that. Migrating from gd.h and cocos-headers This one may be one of the most tedious parts. First of all, all of the GD classes are removed from the gd namespace. And since older gd.h’s use the m_tVariable convention with t being the type identifier, all of those variables will give errors when given Geode’s m_variable convention. Let’s see an example of this. Here is a code snippet from HJFod’s BetterEdit v4: CCPoint getShowButtonPosition(EditorUI* self) { auto winSize = CCDirector::sharedDirector()->getWinSize(); auto ratio = winSize.width / winSize.height; if (ratio > 1.5f) return { self->m_pTrashBtn->getPositionX() + 50.0f, self->m_pTrashBtn->getPositionY() }; return { self->m_pPlaybackBtn->getPositionX() + 45.0f, self->m_pPlaybackBtn->getPositionY() }; } This code uses the m_pTrashBtn and the m_pPlaybackBtn members from EditorUI, a class from gd.h. These members correspond to m_trashBtn and m_playbackBtn in Geode respectively. It is not the best way to do it, but one can use regex m_(?:ob|[a-z])([A-Z]) to find most of the variables that use the old convention. Cocos-headers don’t need any extra work, since the cocos headers in Geode are based on that repository with changes needed for the Geode codebase. Migrating the hooks Bare Minhook This is the most common used method. Minhook hooks have a static function pointer in which the trampoline is stored (often prefixed with _O) and the hook itself (often prefixed with _H). Calling the original is done by calling the trampoline stored in the function pointer. The Minhook is first initialized with MH_Initialize, then hooks are added with MH_CreateHook with parameters address, the address of the hook function, and the address of the static function pointer, then MH_EnableHook is called to enable the hooks themselves. bool (__thiscall* MenuLayer_init_O)(gd::MenuLayer* self); bool __fastcall MenuLayer_init_H(gd::MenuLayer* self, void*) { if (!MenuLayer_init_O(self)) return false; return true; } // ... MH_Initialize(); MH_CreateHook((void*)base + 0x1907b0, (void*)&MenuLayer_init_H, (void**)&MenuLayer_init_O); MH_EnableHook(MH_ALL_HOOKS); MAT dash This is also used by some people, mainly by newer traditional modders. Compared to other methods, MAT dash uses the return type of the hook to infer the calling convention (example: matdash::cc::thiscall) unless it’s membercall, a GD specific calling convention, which needs to be removed for migration. The original is called using matdash::orig with a template parameter of a reference to the hook, the parameters are the same with the hook itself. MAT dash hooks are added with matdash::add_hook with a template parameter of a reference to the hook function and a parameter of the address. bool MenuLayer_init(gd::MenuLayer* self) { if (!matdash::orig<&MenuLayer_init>(self)) return false; return true; } // ... matdash::add_hook<&MenuLayer_init>(base + 0x1907b0) GDMake No one will need this section but I’m adding it for the completeness sake. GDMake uses the GDMAKE_HOOK with the address and the symbol parameter to hook a specific function and GDMAKE_ORIG keyword to call the original function. GDMAKE_HOOK(0x1907b0, "_ZN9MenuLayer4initEv") bool __fastcall MenuLayer_init(gd::MenuLayer* self, void* edx) { if (!GDMAKE_ORIG(self, edx)) return false; return true; } Shared Since all of these hooks are static functions, a self parameter and a parameter for clobbing the edx register is added (except MAT dash) to match the calling convention for member functions. These parameters need to be removed when moving the hook inside a modify class. Likewise, all uses of self-> need to be either removed or replaced with this->. Otherwise, all of the hooks can be replaced by a Modify class and the original calls can be replaced with a call the OriginalClass::function inside the modify hook with the needed parameters. class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; return true; } } Patches Patches are pretty easy to migrate. Geode has a Mod::patch function that takes in a byte vector and an address, which can be used for mod specific patches. Miscellaneous Some function signatures in gd.h are wrong: wrong as in they work for Windows, but not for any other platform. Geode uses the Android binary symbols to infer the function signatures, so the wrong function calls relating to this issue need to be fixed while migrating from gd.h. TODO Add settings, data saving Pointer Casting The usual C++, with its type casting and all. But how is this related to GD modding? Well, a lot of things. Delegates, object oriented nature of Cocos, and so on… Let’s explore a few examples. Known original type Let’s say you have a callback, and in that you want to downcast the sender. You already know the sender type. What should you use? void MyClass::onClick(CCObject* sender) { auto node = static_cast(sender); node->setPosition({0, 0}); } You are expected to use static cast when downcasting the objects you already know the type of. Unknown original type You need to downcast an object, but you don’t know its original type. Using your existing C++ knowledge, you might say “Dynamic cast!”, but no. Well, not on Windows or MacOS. Since we do not have symbols in those platforms, the compiler recreates typeinfos for the GD classes, and those classes can not match with the ones found in the GD binary. This is why we have this utility called geode::casts::typeinfo_cast, which is literally a recreation of dynamic_cast that uses typeinfo name to compare the types. The usage is the exact same, but here is an example anyway: void MyClass::onClick(CCObject* sender) { if (auto button = typeinfo_cast(sender)) { button->setSizeMult(1.2f); } } Callbacks If you tried to make a button, chances are you used menu_selector. But what does that do? It reinterpret casts your member function into a void (CCObject::*)(CCObject*). Since it reinterpret casts it, you should never give it an invalid function, like a void MyClass::onClick(int). It will compile, and it might techincally work, but this is very bad. Don’t do it. Positioning Positioning in Geometry Dash uses a few main variables Position (X, Y) Content Size Anchor Point DevTools Before starting out, I recommend you install the DevTools mod. This mod can be found on the index. DevTools allows you to view positions, scale, rotation, content size, aspect ratio, and more for all nodes that are active on the screen. This will help you greatly with positioning your own nodes. Position Position is the simplest variable you can modify. It controls a node’s position relative to their parent. Cocos positions start at the bottom left corner (0, 0) and increase until the top right corner. You can get the maximum current screen size (which can be altered by aspect ratio) by using the CCDirector class. #include using namespace geode::prelude bool MyLayer::init() { // ... CCSize screenSize = CCDirector::sharedDirector()->getWinSize(); // ... } At the top most level of the node tree, you can use the screen size to place a node in a position that is relative to the screen edges (or the center). This comes in handy if you want to handle multiple aspect ratios. Do keep in mind that you will have to modify the node’s Anchor Point if you are placing it relative to screen edges. Below are some simple examples of doing exactly that. #include #include using namespace geode::prelude bool MyLayer::init() { // ... CCSize screenSize = CCDirector::sharedDirector()->getWinSize(); ButtonSprite* sprite = ButtonSprite::create("Hello"); // Place sprite in the middle of the screen sprite->setPosition(screenSize / 2); // Place sprite at the top of the screen, centered sprite->setPosition({ screenSize.width / 2, screenSize.height - 30.f }); // Place sprite at the left of the screen, centered vertically sprite->setPosition({ 0, screenSize.height / 2 }); // ... } ⚠️ This method is only useful for placing nodes inside parents that take up the whole screen size. For any other purposes, you will have to place children relative to the parent’s Content Size. This will be explained shortly. Positioning can also be done using raw numbers. This is not recommended, as it can cause troubles when dealing with different aspect ratios. Here’s a code snippet for completeness’ sake. #include using namespace geode::prelude; bool MyLayer::init() { //... // Simple node, doesn't display anything CCNode* node = CCNode::create(); node->setPosition({ 50.f, 20.f }); //... } You can also use DevTools to move nodes in real time and check their position values. Again, using raw numbers for positioning is not recommended, but you can get a general idea of where you want your node to be placed at. Content Size Content size dictates how much space a node and its children take up. This has many uses. First of all, we can use a node’s content size to place children relative to the parent’s borders, or relative to other children inside the layer. There are 2 main approaches to setting a node’s content size. Setting the content size prior to adding any children, if we know how much space the parent should take beforehand. A great example for this approach are popups. If you have read the Popup Tutorial, then you probably remember that when creating a popup, you give it a width and a height. These values are used to give the popup its content size. Setting the content size after adding and positioning the children. This is usually done by calculating the borders of the parent using the children that are the furthest from (0, 0). A good example of this would be button menus. Maybe we have a weird layout, that can’t make use of Layouts, or a menu that has children added to it after it is initialised. For that, we would have to calculate the content size of the parent. Of course, if you use Layouts, you just have to set a content size, and the layout will automatically resize the children to match that content size (if auto-scale is enabled), otherwise, you will also have to calculate the content size yourself. Cocos nodes have different behaviour when it comes to content size. The most popular example to give here is CCMenu, which sets its content size to the screen size. RobTop doesn’t modify this content size, which is a valid approach to this problem, but we are better than this! Here are some simple examples! First, a simple menu that places 2 buttons on a diagonal. #include using namespace geode::prelude; bool MyLayer::init() { //... CCMenu* menu = CCMenu::create(); CCMenuItemSpriteExtra* button1 = CCMenuItemSpriteExtra::create( CCSprite::create("GJ_button_01.png"), this, nullptr // we don't care about the callback in this context ); CCMenuItemSpriteExtra* button2 = CCMenuItemSpriteExtra::create( CCSprite::create("GJ_button_01.png"), this, nullptr // we don't care about the callback in this context ); // We know that the button content size is {40.f, 40.f} (by checking with DevTools), so we will set the menu's content size accordingly. // Just enough to fit a 2x2 grid of buttons, we will place our buttons on a diagonal menu->setContentSize({ 80.f, 80.f }); // Ignore this for now menu->ignoreAnchorPointForPosition(false); // Now, we are going to set the positioning of our buttons using the parent's content size and the buttons' content sizes. I will explain why we do this when we talk about anchor points. // This sets the position of `button1` as the **bottom left** corner of the parent, while also accounting for the default anchor point of the button {0.5f, 0.5f} button1->setPosition(button1->getContentSize() / 2); // This sets the position of `button2` as the **top right** corner of the parent, while also accounting for the default anchor point of the button {0.5f, 0.5f} button2->setPosition(menu->getContentSize() - button2->getContentSize() / 2); menu->addChild(button1); menu->addChild(button2); // Also add the menu to a parent element //... } Here is what the result will look like ingame: image-of-the-created-ccmenu As you can see, the the menu has the perfect content size, and the buttons are placed in their right spots. You might say “Why did we use the buttons’ content sizes to place them inside the menu? This doesn’t make any sense!”. To answer that, we have to talk about anchor points. Anchor Point The anchor point is the 3rd tool in our positioning toolbox. It decides 2 things: How will the be placed at the position it’s given? How will the node’s content size expand or decrease? How scaling the node works Anchor points, like any other point, take 2 values: X and Y, which take values from 0.0f (left, bottom) up to 1.0f (top, right). You probably deduced that this works exactly like node positions. First off, positioning. The anchor point decides which point of the node’s content size will be placed at the position it’s given. Here’s a simple table that should clarify this. Anchor Point Location { 0.0f, 0.0f } Bottom Left { 1.0f, 0.0f } Bottom Right { 0.0f, 1.0f } Top Left { 1.0f, 1.0f } Top Right { 0.5f, 0.5f } Center Of course, you do not have to only use those values. Those are the most widely used anchor points. The best way to test anchor points out is to use DevTools on the CCMenu example from above. ⚠️ There is a way to make the node ignore any anchor point given for positioning itself, using {0.0f, 0.0f} regardless of anchor point. You can do this using node->ignoreAnchorPointForPosition(true), but this is HIGHLY DISCOURAGED, as it will only complicate things. If you remember from the example above, we disabled this stupid feature for the newly created CCMenu. There are a lot of RobTop nodes, and Cocos nodes that use this. For most, leaving it as it is is probably the best option, as changing it might break things. For your own nodes however, we recommend disabling it. Second, how does it affect content size? It affects the resizing of said content size, restricting it (or setting a multiplier for it), depending on what values it gets. For example, setting an anchor point of {0.0f, 0.5f} will prohibit the node’s content size from expanding to the left. Setting it to {1.0f, 0.5f} will prohibit the node’s content size from expanding to the right. As with positioning, experimenting with DevTools is the best way to learn how this works. Additionally, different anchor points affect how the node’s children are moved when the content size changes. Touch Priority You probably had this issue of “Why does my button not work?” whenever you added a button into a popup before. If not, consider yourself lucky. This tutorial will cover how Geometry Dash handles touch priority, and how you should use it. What is touch priority? Every layer that has setTouchEnabled(true) has an assigned touch priority to it. This priority is used to determine which layer will consume the given touch. This priority value is completely independent of the Z order of the layer, which would be the preferred way of doing this kind of thing. But we need to deal with what we have. The smaller the priority value is, the higher its priority. This means a priority of -1 will be checked first than a priority of 0. How Geometry Dash uses touch priority Disregarding all popups, Geometry Dash touch priority is completely equivalent to how Cocos2d handles it. Every layer has touch priority 0 by default. CCMenu’s have a touch priority of -128. Other than these, Robtop classes such as CCTextInputNode and SliderTouchLogic have a touch priority of -500. Force priority If you’ve been in the Geometry Dash modding community enough, you’ve probably heard of this term at least once. Force priority is the system Robtop implemented into Cocos2d in order to handle his popups. One of the most hated additions of Geometry Dash solely because how unintuitive it is. There are two values related to force priority: forcePrio and targetPrio Force priority tracks the current force priority applied to the popup. Popups (mainly FLAlertLayer but other popups do it as well) change this value to set the current force priority. It starts from -500 with a single popup, and decreases by 2 for each consequent popup. Target priority tracks the target priority that should apply to layers such as CCTextInputNode or SliderTouchLogic and CCMenu. If the touch priority requested by these classes are bigger value than the target priority, they are set to the target priority instead. Target priority values are the same as the force priority values. Robtop has 3 main functions for dealing with force priority: CCTouchDispatcher::registerForcePrio, CCTouchDispatcher::unregisterForcePrio, CCTouchDispatcher::addPrioTargetedDelegate. Registering decreases the target priority, unregistering increases the target priority. Adding a prio targeted delegate allows the layer to use the target priority decreased by 1 if force priority is active. How to use it myself If you’re not dealing with any popups, chances are you don’t need to deal with any of these either. But if you are, you should follow these guidelines. If your popup subclasses geode::Popup<>, the registering and unregistering is handled automatically. If you’re not using geode::Popup<> class and directly subclassing FLAlertLayer instead, you should call FLAlertLayer::init(int opacity) inside your init. This will handle the registering of the force priority, along with creating the m_mainLayer. You should also override registerWithTouchDispatcher and call CCTouchDispatcher::addTargetedDelegate in it, since that will allow you to register the popup not as a prio targeted delegate. If you leave it the default, FLAlertLayer will have one less priority than your layers (-503 vs -502), meaning none of the touches will go to your layers since they will be consumed. And lastly, ~FLAlertLayer handles unregistering of the force priority. If you want to set the priorities manually (such as for an overlay), you can call CCLayer::setTouchPriority/CCMenu::setHandlerPriority on your layer with the CCTouchDispatcher::getTargetPrio value. Chapter 1.1. What is a Mod? A mod (also known as an extension, hack, or plugin) is a piece of software that modifies another piece of software. Usually in games, this is done through the use of a mod loader; something that, well, loads mods. Some games, like Friday Night Funkin and Skyrim have built-in support for loading mods, as well as built-in interfaces for working with mods, which make modding very easy and simple. Geometry Dash, unfortunately, does not have any built-in mod support. However, using very clever methods such as DLL injection and hooking, we can create an external mod loader. This does come with some disadvantages like the lack of a stable API (meaning it’s not guaranteed to work between versions), but it also comes with some huge advantages, such as fully unrestricted access (which might also be seen as a huge disadvantage, depending on who and when you ask). A mod can do basically anything, within the limits of computer hardware. But how exactly does a mod work? The actual executable file for Geometry Dash that you have installed on your computer is what is known as an executable binary program. If you open the game’s executable with a text editor, you will see a bunch of random-looking characters. This is, in fact, the game’s code; however it is not its source code. This is binary code, the raw low-level instructions your CPU executes. If we had the game’s source code, we could create a fork of it and add built-in mod loader support. However, as Geometry Dash is closed-source, we have to deal with modifying the binary code. Image showcasing GeometryDash.exe open in Notepad, showing garbled characters that are the game’s binary code interpreted as ASCII Modifying binary code is a bit difficult, however, as it is not meant to be for humans; binary code is strictly for computers, and as such it is unreadable and unmodifiable for a human. Binary code is also platform-specific: a mod written purely in binary would only work on one platform, and could not be ported over to others without fully rewriting the entire mod from the ground up. As a historical curiosity, it should be noted that mods used to be written fully in binary. Or, more accurately, they were written in assembly, which is a (somewhat) human-readable form of binary. However, to make it very clear, no sane person does this anymore. Working with binary code directly is nowadays only done in rare cases, which will be explained in Chapter 1.2. But what’s the alternative? We can make modding much easier by knowing two facts: Binary code is produced through compilation. Geometry Dash is written in C++. Compilation is the process of turning source code into binary code. While we can’t modify GD’s binary code easily, we can write our own source code in C++ and compile it into compatible binary code. Knowing what language GD was made in is vitally important, as not all binary code is equal. Some programming languages such as Rust produce wildly different binary code from C++, and while it is technically compatible, it is much easier to work with a C++ game using C++. (Some modders, however, are working on making Rust usable for modding!) Writing our mods in a higher-level language like C++ also makes porting much easier; C++ can be compiled to compatible machine code on all the platforms GD is available on. This does come with multiple caveats though, however those are left for a later chapter. What all of this means is if we write our mod in C++ and then find some way to make GD run the compiled binary code of it, then we have unlocked a path to modding! And luckily, we know how to make GD load extra code: binary injection. Almost every platform GD is on has some sort of dynamic library support. On Windows, these are known as .DLL files; on Mac, they’re .DYLIBs; on Android, they’re .SO files. A dynamic library is like a binary executable, but they have one special property: other executables can load them. This is usually done through address tables and the such; these are much too complicated for the purposes of this tutorial, and the specifics are also platform-dependant and modern modloaders use proxy DLLs instead. As such, how binary injection works in detail will not be explained here. All you have to take away is that we have methods to make GD load a dynamic library, and that acts as our entry point to modding the game. ℹ️ There is one platform that doesn’t have dynamic library support: iOS (unless jailbroken). Modding on iOS without jailbreaking requires basically baking all the mods you want into a premodified game, like iCreate has done, but a general mod loader like Geode will likely never see iOS support unless some major changes to the OS happen first. 📗 If you are interested in learning more about binary injection, the Wikipedia article on DLL injection is a pretty good place to start. Usually, the first custom dynamic library we make GD load is a mod loader; that is, a mod whose purpose is to load other mods. This is because the methods we use for injection are not easily scalable, but once we have our one library running, we can invent much simpler ways of loading more of them. For example, on Windows, loading a library from another library that you control is as simple as calling the LoadLibrary function. This can also be done an arbitary number of times within our initial library, so we can for example automatically find all the .DLL files in some directory and load them. This is how old 2.1 mod loaders such as Mega Hack v7 used to work: they would search for all of the .dll files in a predefined folder like extensions and call LoadLibrary on them. At this point, we’ve gotten our library up and running, and are ready to start writing some code. However, now we enter a new problem: how do we actually do things? Chapter 1.2: Hooking & Patching So we’ve got our own code running inside GD. Now we’re faced with a much bigger problem however; how do we actually do stuff? For example, let’s say we want to do something as simple as adding a button to the main menu that displays a message when clicked. The first thing we would want to figure out is how to even add stuff to the main menu; that is, figure out when the main menu is entered, and how to add a thing to it. We can reasonably infer that the way GD enters the main menu is by calling some function that creates it, probably in a way reminiscent of this: void onLoadingFinished() { createMainMenu(); } If we could somehow listen for when this function is called, then that’s problem #1 solved - we would know that now the main menu is created. Let’s leave problem #2 (actually adding things to it) for later, and first focus on how to listen for that function call. There are two fundamental tools in every GD modder’s toolkit: patching and hooking. Patching In Chapter 1.1, it was stated that nowadays modders rarely work with binary code directly. There are, however, some cases in which working with raw binary code is in fact the optimal solution for some functionality in a mod. In these cases, it is done through a method called patching, which means applying, well, patches to binary code. Patches are, however, inherently platform-dependent and unportable, so their use is highly discouraged if higher-level options are available. Patches do, however, still play a seminal role in GD modding. For example, one of the most famous mods, noclip, can be achieved with a single binary patch (in 2.1; in 2.2, it’s a little harder). There are also some cases in complex mods where a few patches can replace writing hundreds of lines of C++ code. However, it is very uncommon for binary patches to be optimal. Binary patches should never be your first solution to a problem, but when the time comes, don’t be afraid to use them if they’re clearly the best solution. Patches also serve another very important purpose: they are the base on top of which hooking is built. Although, you won’t use them directly - Geode will handle hooking for you. Hooking In contrast to patching, hooking is not only more portable(-ish) but also arguably the most important tool in a GD modder’s toolkit - understanding it is vitally important for all modding. Consider the following function: int addTwo(int a, int b) { return a + b; } This function is quite simple; it is just adding two integers together. Let’s say that this function is located in some other binary, and we just want to know whenever it’s called, and do some stuff when that happens. This is what hooking is for; it lets you detect when a function is called, and do something with that information. Hooking the function would look something like this: int addTwo(int a, int b) { addTwoHook(a, b); return a + b; } int addTwoHook(int a, int b) { std::cout << "addTwo called!\n"; } A hook always has the signature [Note 1] as the function being hooked. This means that we couldn’t hook addTwo with something that takes two strings. Likewise, the return type has to be the same; if addTwo returns an int, so does our hook. This is the basic premise of hooking: when the function you’re hooking is called, the first thing you do is hop into your own code, and then hop back into the original once you’re finished. The function that contains your own code is called a detour, and the function being hooked is called the original. However, the code above is actually misleading. It would be more accurate to say that hooking does this: int addTwoOriginal(int a, int b) { return a + b; } int addTwo(int a, int b) { return addTwoDetour(a, b); } int addTwoDetour(int a, int b) { std::cout << "addTwo called!\n"; return addTwoOriginal(a, b); } When you hook a function like addTwo, what first happens is that the body of the hooked function is stored somewhere else, and then the function body is replaced with a call to your detour [Note 2]. Then in your detour, you execute your own code and then return, either by calling the original or by giving your own return value. Notice that you are not actually required to call the original, or return its value. We could just as easily make addTwoDetour do something completely different, for example like this: // never called! int addTwoOriginal(int a, int b) { return a + b; } int addTwo(int a, int b) { return addTwoDetour(a, b); } int addTwoDetour(int a, int b) { std::cout << "addTwo called!\n"; return a - b; // not calling the original } In this case, we skip calling the original function completely, and instead return the difference between a and b. Of course, this would be quite inconvenient to anyone calling addTwo who is expecting the numbers to be added together, but there’s not much they could do about it; we have completely overwritten the function’s definition. We could also call the original, but pass it different parameters. Let’s make addTwo act as normal, except always passing 7 as the second parameter and ignoring b: // this now always gets 7 as the b argument int addTwoOriginal(int a, int b) { return a + b; } int addTwo(int a, int b) { return addTwoDetour(a, b); } int addTwoDetour(int a, int b) { std::cout << "addTwo called!\n"; return addTwoOriginal(a, 7); } Alternatively, let’s say we want to use the result of addTwo ourselves. We can do this by utilizing it just like any other function call: int addTwoOriginal(int a, int b) { return a + b; } int addTwo(int a, int b) { return addTwoDetour(a, b); } int addTwoDetour(int a, int b) { int res = addTwoOriginal(a, b); std::cout << "addTwo returned " << res << "\n"; return res; } Here, we first call the original to see its result, then log it into the console and then return the result as normal. We could also just return something else: int addTwoOriginal(int a, int b) { return a + b; } int addTwo(int a, int b) { return addTwoDetour(a, b); } int addTwoDetour(int a, int b) { int res = addTwoOriginal(a, b); std::cout << "addTwo returned " << res << "\n"; return 0; } In this case, we can use the result of the original addTwoOriginal function as we please, however any callers of addTwo will always get 0 as a result. My Brain Hurts! At this point, hooking might still feel difficult to wrap your head around. Don’t worry though; hooking will be a seminal part of this whole handbook, and you will see plenty more practical examples of it going forward. However, at this point it should be noted that the syntax for hooking in Geode looks quite different from what was shown here. The underlying premise, however, is always the same: you replace the function body with a call to your own, and then do whatever you want. You may call the original function and use its result however you’d like, or you may completely overwrite the function’s behaviour by not calling the original at all. For now, we can leave hooking be, as before we can find any practical applications for it, we must first find some functions to hook. Chapter 1.3: Functions & Addresses Notes [Note 1] Signature means the parameter and return types of a function, i.e. int addTwo(int, int). [Note 2] This, too, is not actually how hooking is implemented. Geode uses the purpose-built TulipHook library for hooking, which does a lot of crazy stuff under the hood like automatically translating between calling conventions and other tricks to allow calling the original without needing a trampoline. For the purposes of this tutorial however, it is easier to think of the whole function body as being replaced instead of just a part of it. Chapter 1.3: Functions & Addresses In the last chapter, we looked at hooking and how it works. However, the last chapter only touched hooking in theory. The code shown was not what actuals hooks in your code look like. For instance, we do not have access to GD’s source code, so we can’t exactly just write return ourDetour() at the start of the function we want to hook. Instead, we need to figure out some way to insert hooks into GD’s binary code. Manual hooking The main way to create hooks in Geode is using an abstraction called $modify - however, it is a very powerful tool and hard to explain without some preface. It is also just an abstraction; you can create hooks manually in Geode as well through the Mod::addHook interface - although in practice you should never be creating manual hooks unless necessary. ℹ️ Manual hooks are sometimes necessary, for example to hook some obscure low-level functions that only exists on one platform, like GLFW on Windows. However, for 99% of mods, you should just be using $modify, since it makes your code much more portable and easier to work with. ℹ️ The traditional way in 2.1 of placing hooks used a library called MinHook. If you’ve been in the GD modding scene before 2.2, you’ve almost certainly heard of MinHook before, or at least seen its 32-bit dynamic library minhook.x32.dll. However, using MinHook directly is no longer considered good practice. While it can work perfectly fine for a single mod, MinHook has a few issues: it’s Windows-only. hard to use, and if you don’t link to it as a dynamic library, it will cause hook conflicts [Note 1]. Let’s see a real-world example of creating manual hooks in Geode: auto wrapFunction(uintptr_t address, tulip::hook::WrapperMetadata const& metadata) { auto wrapped = geode::hook::createWrapper(reinterpret_cast(address), metadata); if (wrapped.isErr()) {{ throw std::runtime_error(wrapped.unwrapErr()); }} return wrapped.unwrap(); } void MenuLayer_onNewgrounds(MenuLayer* self, CCObject* sender) { log::info("Hook reached!"); static auto original = wrapFunction( geode::base::get() + 0x27b480, tulip::hook::WrapperMetadata{ .m_convention = geode::hook::createConvention(tulip::hook::TulipConvention::Thiscall), .m_abstract = tulip::hook::AbstractFunction::from(void(*)(MenuLayer*, CCObject*)), } ); reinterpret_cast(original)(self, sender); log::info("After original!"); } $execute { Mod::get()->addHook( reinterpret_cast(geode::base::get() + 0x27b480), &MenuLayer_onNewgrounds, "MenuLayer::onNewgrounds", tulip::hook::TulipConvention::Thiscall ); } Now, this code sure is quite a jump from the hooking code in the previous chapter. If you haven’t done much low-level C++, you might be confused at a lot of the syntax here. There’s a bit too much to take in from the code above, so for now we will just be concentrating on a few key details. The most important part of this code is geode::base::get() + 0x27b480. This is the address of the function. When C++ is compiled down to machine code, all variable and function names are erased and functions are instead given memory addresses. A memory address is just the location in a binary that the function resides in. For example, geode::base::get() + 0x27b480 means that the function is located at offset 0x27b480 (or 2602112 in decimal) bytes from the base address - GD’s base address, given by the function geode::base::get(). ℹ️ The reason we need to add the base address to the function’s address is because the base address of GD is dynamic - it changes between startups! What this means is that in order to hook a function in GD, we need to know its address. On top of that, we need to know its signature, as your detour must always have the same signature as the function you’re hooking - otherwise the game will crash! ⚠️ The above code snippet also references calling conventions - if you use $modify, Geode handles them for you, however if you’re doing manual hooks or reverse engineering, these are very important to get right. Addresses So how do we find out these things? Usually, this is done through reverse engineering; however, RE is quite a complex skill, and would take far too much time to explain here, so it has its own dedicated volume instead. And on top of that, most common functions have already been found. This means that instead of REing the function yourself, you can use the GD bindings that come packaged with Geode. ℹ️ Traditionally, the most common GD header library was gd.h. However, nowadays gd.h is completely obsolete, as it is only for 2.1 and fully unmaintained. However, it is also important to note that you still need to know how to reverse engineer in order to make GD mods. Even if the addresses and signatures are all available, they still don’t tell you what the function actually does, how it works, or where its called. As noted previously, you shouldn’t usually be creating hooks manually. Instead, Geode comes with a special hooking syntax called $modify. How it works will be explained in a later chapter, but first we must talk a bit about GD’s game engine: Cocos2d. Chapter 1.4: Cocos2d Notes [Note 1] Hook conflicts are a type of race condition and it happens when two mods try to hook the same function at the same time. If the mods do this sufficiently close to one another, there is a high chance that one mod’s hook will replace the other’s. The end result of this is that one of the mods functions incorrectly, when it fails to hook the function it expected to. In the best case, this just results in the mod losing functionality, but in the extreme case this could cause crashes. Chapter 1.4: Cocos2d GD’s Game Engine In order to modify any game, it’s good to find out at least one thing: what engine the game was made with. Luckily, GD tells us this on its loading page: Cocos2d-x. GD modders have also figured out the specific version of Cocos2d that GD uses: v2.2.3. Although, there’s a catch. You see, if we look around the libcocos2d file GD comes with and compare it with the official v2.2.3 branch, we will find that there are a bunch of functions and classes present in GD that aren’t in the original, like CCLabelBMFont::limitLabelSize. As it turns out, the Cocos2d that GD uses has been modified by RobTop. These modifications range from small things like a few helper functions added to classes to some entire backends having been rewritten. Due to this, GD mods can’t just use the publicly available Cocos2d headers; they need to use modified headers that account for RobTop’s changes (which are, naturally, included in Geode). ⚠️ Some old modding tutorials on YouTube might tell you to use libraries such as CappuccinoSDK or Cocos-Headers - these are the traditional 2.1 libraries used, however they are nowadays obsolete. But What is Cocos2d? Cocos2d, or specifically Cocos2d-x 2.2.3, is a game engine featuring a sprite and node-based UI. It is what powers GD’s user interface, and many of its core data structures. For most GD mods, the two most important things Cocos2d provides us with are the node system and garbage collector. The seminal building block of all Cocos2d UI and by extension GD UI is the CCNode class. A node is an UI object that can have multiple children, a single parent, and transformations such as position, rotation, scale, etc., with all transformations being also applied to a node’s children. These nodes form a hierarchy known as a node tree, on top of which is a CCScene. The scene is the only visible node without a parent [Note 1]; at a time, there may only be one scene present. The class that manages scenes is CCDirector. At all times in GD, there is one director running, which you can get using the CCDirector::sharedDirector method, or the Geode-specific CCDirector::get shorthand. The director contains information such as the current window size, what scene is running, and getters for many of the other static singleton managers in GD. To change to a different scene, you would use the CCDirector::replaceScene method. To get the current scene, use CCDirector::getRunningScene. Nearly all nodes you see in GD aren’t instances of the base CCNode class, but of its derivatives. Some of the most commonly used derivatives are CCSprite, CCMenu, CCLabelBMFont, and CCLayer, and some of the most used GD-specific ones are CCMenuItemSpriteExtra, FLAlertLayer, GameObject, and ButtonSprite. As Cocos2d is a node-based framework, nearly all nodes are aggregates of other nodes. In other words, most nodes simply consist of other nodes. For example, a popup might consist of a node for the background, another node for the text, and maybe some extra nodes for buttons and decoration and such. You most likely won’t have to do any rendering yourself; if you want to show some text in your node, just create a label and add it as a child to it. For example, here is the structure of a comment in GD: Image showing the structure of a CommentCell in GD As you can see, the CommentCell class consists wholly of other nodes. It does not do any of its own rendering. The position of the nodes (relative to the parent CommentCell) is marked in parenthesis; one important thing to note about Cocos2d is that unlike some other game frameworks, higher Y-coordinate means higher on screen. ⚠️ Please note that the above image has been simplified and some of the positions do not reflect the actual arrangement of CommentCell. Creating Nodes Every node usually has a create function for creating an instance of the class, and then a bunch of methods like setPosition and addChild for setting the node’s properties and adding children to it. For example, to create a simple “Hi mom!” text, you would use code like this: // First parameter is the text, second is the font auto label = CCLabelBMFont::create("Hi mom!", "bigFont.fnt"); // Set the position of the label to be at the coordinates 100, 50 (in units, not pixels) label->setPosition(100, 50); // Assuming 'this' is some node aswell this->addChild(label); By default, all node create functions may return nullptr in case something goes wrong. However, nodes like CCLayer and CCMenu are likely to never fail, and in the rare case they do, something has probably already gone catastrophically wrong and the game is about to crash anyway, so handling the null case with these nodes is not usually necessary. However, with some classes like CCSprite handling create returning null may be vital, as CCSprite::create will fail if the sprite doesn’t exist, which is entirely possible. Sprites Cocos2d is a sprite-based framework, meaning that instead of rendering things at runtime using vector graphics, nearly everything shown on screen are textures loaded from disk. If you’ve ever messed around with GD’s files, you’ve probably noticed this; most of GD’s textures are contained in sprite sheets, such as GJ_GameSheet03. The way one shows these textures is with the CCSprite class; it is a simple node that loads a texture and displays it. CCSprite is a bit unique in that it has two main create functions: CCSprite::create for creating nodes out of individual images, and CCSprite::createWithSpriteFrameName for creating nodes out of spritesheet images. It is important to use the correct create function for CCSprite, as the wrong one will return nullptr and cause an error if not properly handled. If the sprite you’re creating is contained in its own file, like GJ_button_01.png, then you should use CCSprite::create; otherwise, if the sprite is in a spritesheet like GJ_infoIcon_001.png in GJ_GameSheet03, use CCSprite::createWithSpriteFrameName instead. // Uh oh! This will return null as GJ_infoIcon_001.png is not its own file but // contained in a spritesheet auto infoSpriteFail = CCSprite::create("GJ_infoIcon_001.png"); // You don't have to specify the name of the spritesheet you're loading from anywhere, // as GD has already loaded GJ_GameSheet03 into memory auto infoSpriteCorrect = CCSprite::createWithSpriteFrameName("GJ_infoIcon_001.png"); Even text in Cocos2d is rendered through sprites, or more accurately, bitmap fonts. The class for doing this is CCLabelBMFont, as shown in one of the above examples. GD’s default Pusab font is defined in the bigFont.fnt file. How to add your own sprites to use in Geode mods will be discussed in a later chapter. Menus & Buttons Another important class to know of is CCMenu. Most mods need some sort of buttons for their UI, and for that, the most common class to use is CCMenuItemSpriteExtra. However, all CCMenuItem-derived classes must be part of a CCMenu to work. In practice, this means that all of your buttons must be the direct children of some menu. You can actually see the effects of this in-game; hold down on some button, and then without releasing move your cursor over other buttons in the same scene. You will find that some buttons display their bounce animation indicating they are usable, and others don’t. This is because of the Cocos2d touch system, which will be discussed in detail later, but in essence, only buttons in the same menu are clickable when you start holding down from one. auto infoIcon = CCSprite::createWithSpriteFrameName("GJ_infoIcon_001.png"); auto button = CCMenuItemSpriteExtra::create( infoIcon, // don't worry about these parameters for now nullptr, nullptr ); // The button must be a child of a CCMenu to be usable auto menu = CCMenu::create(); menu->addChild(button); // This would make the button visible, but it would not be usable auto layer = CCLayer::create(); layer->addChild(button); At this point, we’re getting very close to writing actual mod code. However, before we can get to that, we must first discuss GD layers and the $modify macro in Geode. Chapter 1.5: Layers Notes [Note 1] You can also add nodes directly to CCDirector and bypass the node tree, but this is very rarely done as nodes in the director don’t have access to the touch system or any input for that matter Chapter 1.5: Layers In the previous chapter, it was mentioned that at all times there exists one scene at the top of the node tree. Usually, in practice, this scene has only one child: some layer. Scenes are usually only used as containers for layers and for transitions; you will likely never have to inherit from CCScene in your code. Instead, the class your layers and GD layers usually inherit from is CCLayer. Nearly all layers have their own class; for example, the icon kit is GJGarageLayer, the editor is LevelEditorLayer, and when you go to play a level you enter PlayLayer. The first layer most GD modders start modding and also the first layer in the game (after the loading screen) is the main menu; it is an instance of the MenuLayer class. Finding Layer Names You can find the class name of a given layer using the DevTools mod in Geode. To see how it works, install the DevTools mod in-game through the Download tab in Geode and then press F11 to activate it: Image of the DevTools mod open in GD, focused on MenuLayer If you look at the Tree view on the left, you will see that the current scene contains one layer named MenuLayer, which then further contains a bunch of CCMenus and other nodes. The menus contain all of the buttons in the scene; for example, the bottom center row of buttons is contained in one menu. One thing you will notice in DevTools is that many of the nodes have string IDs; this is a Geode-specific addition meant to make modding simpler. You can read more about string IDs in its dedicated article. ⚠️ In addition to string IDs, some of the menus in Geode are different from the ones in vanilla GD. This is because of the layout system in Geode, which handles positioning - in traditional mods, all position has to be done manually! There may also be multiple layers in a scene at once. For example, if you click the profile button in MenuLayer, you will find it adds a layer named ProfilePage in the scene: Image of the DevTools mod open in GD, showing MenuLayer with ProfilePage on top Using DevTools, you can find the name of any layer. Just navigate to the layer whose name you want to figure out in-game, open up DevTools, and look at the node tree! ℹ️ DevTools also comes with many other utilities, such as moving nodes in the scene around. However, this tutorial is not about DevTools, so you will have to look at its (currently non-existent) documentation for that ;) So now we know that the main menu is called MenuLayer, but so what? How can we actually modify it? For that, see Chapter 1.7: Hello, World! If you just skipped to this chapter directly after seeing it in the navigation bar, you may be wondering why it has taken us 7 chapters to reach a Hello, World! program. Rest assured, the previous chapters are not just a waste; modding is a complex topic and Geode is an advanced framework. As such, we need to first lay a solid foundation for the basics of modding to build upon before we can get to actual code. From here on out however, we’re starting to leave the lame theory part and beginning to enter the part where you actually get to make stuff. And with that, let’s start building our Hello, World! mod! Constructing the Mod To begin with, we need to outline what our mod will actually do. The goal is simple: add some text to the main menu in GD that says “Hello, World!”. Modifying the Layer Our first step is to use what we learned in the previous chapter and modify MenuLayer: #include class $modify(MenuLayer) { }; Since we want to add things to the layer, let’s hook its init function, making sure to call the original: #include class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; return true; } }; Adding the label Now it’s time to actually show the text. As outlined in Chapter 1.4, Cocos2d is node-based; we don’t do our own rendering, we leverage other nodes to do it for us. In this case, since we want to display text, we go for the standard CCLabelBMFont class: #include class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; auto label = cocos2d::CCLabelBMFont::create("Hello, World!", "bigFont.fnt"); return true; } }; Everything Cocos2d-related lies in the cocos2d namespace, so we must prefix our usage of CCLabelBMFont::create with it. However, as you keep modding, having to stick cocos2d:: everywhere gets annoying really fast. In addition, Geode comes with a bunch of namespaces you probably also don’t want to rewrite every time. For this reason, Geode provides a geode::prelude namespace that automatically brings all Cocos2d and Geode-related namespaces to scope: #include using namespace geode::prelude; class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; auto label = CCLabelBMFont::create("Hello, World!", "bigFont.fnt"); return true; } }; ℹ️ If you don’t want to bring Geode namespaces into scope, you can just use using namespace cocos2d instead. Now, the label isn’t currently a child of any layer, so it won’t show up anywhere. Let’s add it as a child to MenuLayer: #include using namespace geode::prelude; class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; auto label = CCLabelBMFont::create("Hello, World!", "bigFont.fnt"); this->addChild(label); return true; } }; Positioning the label The default position for any node is (0, 0) which is at bottom left of the screen; however, we want to center our label in the middle of the screen. To do this, we need to first figure out what the size of the screen is, and to do this we use the getWinSize method on CCDirector: #include using namespace geode::prelude; class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; auto winSize = CCDirector::get()->getWinSize(); auto label = CCLabelBMFont::create("Hello, World!", "bigFont.fnt"); this->addChild(label); return true; } }; Next, to actually position our label, we call the setPosition method on it, placing it halfway across the screen horizontally and vertically: #include using namespace geode::prelude; class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; auto winSize = CCDirector::get()->getWinSize(); auto label = CCLabelBMFont::create("Hello, World!", "bigFont.fnt"); label->setPosition(winSize.width / 2, winSize.height / 2); this->addChild(label); return true; } }; All nodes are by default centered relative to their position, so doing this is enough to center our label in the middle of the screen. However, we can make this code more concise by knowing that winSize’s type is CCSize, and that dividing a CCSize by an integer is the same as dividing that size’s width and height by the integer. Since we are dividing both winSize.width and winSize.height by the same number, we can shorten it to just winSize / 2. In addition, all nodes have both a setPosition(float, float) and setPosition(CCPoint) setter by default, and CCSize is implicitly convertible to CCPoint. All of this means that we can make our setPosition call shorter as just: label->setPosition(winSize / 2); Finished Mod And with that, we have completed our Hello, World! mod. Here’s what the final code looks like: #include using namespace geode::prelude; class $modify(MenuLayer) { bool init() { if (!MenuLayer::init()) return false; auto winSize = CCDirector::get()->getWinSize(); auto label = CCLabelBMFont::create("Hello, World!", "bigFont.fnt"); label->setPosition(winSize / 2); this->addChild(label); return true; } }; To try the mod out, create a new mod using geode new, and then replace the code in src/main.cpp with the above. After building the mod, open up GD and you should see this: Image showing the main menu in GD with a ‘Hello, world’ text on top If it works for you, congratulations! You have now officially built your first Geometry Dash mod! Go grab a lil orange juice from the kitchen and give yourself a little treat :) After drinking your juice however, it’s time to get back into business. So we’ve got a Hello, World! going, that’s great. Now it’s time to start crafting something actually useful. Chapter 2.1: Reverse Engineering At this point in this handbook, reverse engineering (RE for short) has been alluded to and referred to numerous times. At its core, it is quite simply the process of figuring out how something works. However, in practice with GD, this often involves having to read assembly code, understanding how your computer works, and a lot of other deeply low-level stuff. And even so, it is fundamental to making mods, as you can’t modify something you don’t understand. This is why this handbook has an entire dedicated Volume just for reverse engineering; it is difficult, it is complicated, and yet it’s super important. Every modder has to learn reverse engineering at some point or another, and it’s best to start early. It should be noted that reverse engineering is also an ever-evolving skill; you’re never going to be done learning it. This Volume covers many important aspects of it, but it should by no means be treated as a comprehensive list. But that’s enough preface. Let’s start actually REing! Tools There are a lot of tools GD modders use for reverse engineering, but some of the most common ones include: Ghidra IDA Pro (which every modder most definitely has legally bought 😉) x32dbg (Windows) Cheat Engine (Windows) ReClass (Windows) DevTools (Traditionally CocosExplorer) Slicer (Mac) LLDB For this tutorial, we will be using Ghidra and x32dbg. Setting Up Ghidra First, download Ghidra and install it on your machine. Open it, create a new project, and you should see something like this: Image showing the project page of Ghidra ℹ️ The dark theme used is Mat Dark Now, drag Geometry Dash’s binary (e.g. GeometryDash.exe) into the window, add it with the default settings, open it, and Analyze it with the default settings (if you’re reverse engineering Android, disable the Non returning functions: discovered option). Depending on your computer, analyzing might take a while - go grab another cup of orange juice while waiting for it to finish. You should now see a window like this: Image showing the opened project in Ghidra The three most important windows for our purposes are Symbol Tree, Listing, and Decompiler. You can close the others. Now that we have Ghidra setup, it’s time to learn how we can find a layer’s init function. Chapter 2.2: Finding MenuLayer::init The first thing we have to figure out when finding functions is exactly what function we want to find. Often times, this is some layer’s init function - however, it can also be any function responsible for some behaviour we want to alter, like the function that is responsible for scaling objects, the function that plays a level’s song, or anything else. Luckily for us, pretty much all functions in GD are part of some class. This means that to find a function, we first have to make an educated guess about what class it might be in, and use that as a starting point for figuring out where it actually is. If you look at the Symbol Tree window in Ghidra, you will see it has a folder named Classes. Opening this folder reveals, to great surprise, every class in GD: Picture showing the list of classes in GD open in Ghidra Now, there is one problem with this list: there are a lot of classes in GD. Just browsing this list is most likely not going to help you figure out where the function you’re looking for is. Instead, first you need to make some guess about where to start. For finding layers’ init functions, this guess is very easy to make: just figure out the layer’s name using DevTools, and it’s probably in that class. So, to find the init function for MenuLayer, lets first navigate to MenuLayer: Picture showing MenuLayer’s vtable open in Ghidra Unfortunately, there are no functions listed, as Ghidra can’t really know which functions belong to which class. However, what there is listed are the class’s virtual function tables; in other words, a list of all the virtual functions a class has. While not every class’s init function is virtual, in MenuLayer’s case it is, so we can actually find the init function through the vtable directly. Now, knowing exactly which index in the vtable is which virtual function is a bit difficult to figure out, but the jist is that virtual functions are in the order they were declared in the class itself. For CCNode, the first virtual function declared is init - however, as CCNode inherits from CCObject which has a bunch of a virtual functions of its own, init is not the first virtual function in the vtable, but instead the 10th. If we look at the 10th function in MenuLayer’s vtable, we notice that it has a different name from the others: Picture showing MenuLayer’s vtable open in Ghidra, focused on the index #9 which shows a function named FUN_005907b0 surrounded by other functions with human-readable names The reason for this is that this function is the only one that’s overridden - MenuLayer does not overwrite setZOrder for instance, so the function included in MenuLayer’s vtable is CCNode::setZOrder, whose name Ghidra knows as it is an exported symbol from libcocos2d.dll. However, because this function is overridden and defined in GD itself, Ghidra can’t know its name. However, we know what its name is - it is MenuLayer::init! Picture showing MenuLayer::init’s decompiled code open in Ghidra Double-clicking the function name to enter it, we can look at its decompiled code. Since it uses sprites like logo.png which we can know is only used in the main menu by playing the game, we can verify that this is most certainly the function we’re looking for. We can give it the correct name by selecting the function name and pressing L: Picture showing renaming MenuLayer::init in Ghidra Now the function also appears under the MenuLayer class in the class list, which is very convenient. We can also fix the function’s signature by right-clicking on it and selecting Edit Function Signature, setting its calling convention as thiscall and making it return a bool: Picture showing fixing MenuLayer::init’s signature in Ghidra using the Edit Function Signature option Picture showing MenuLayer::init under MenuLayer in Ghidra Congratulations, you have reverse-engineered your first function! However, let’s not stop here - let’s find some other, a little more obscure init functions: Chapter 2.3: Finding LevelSettingsLayer::init 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! Picture showing LevelSettingsLayer open in the Ghidra class list 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. Picture showing a vtable for LevelSettingsLayer, with two XREFs Now, check the XREFs - for most classes, there should be two [Note 1]. 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. Picture showing one of the XREFs for LevelSettingsLayer open in the decompiler, likely being 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! Picture showing FLAlertLayer’s constructor open in the decompiler 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). Picture showing LevelSettingsLayer constructor renamed to the correct name Now check the XREFs for the LevelSettingsLayer constructor. There’s likely only one [Note 1] - click it to follow the reference. Picture showing LevelSettingsLayer::create 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: 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! Picture showing an unknown function call at the start of what we assume to be LevelSettingsLayer::init 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: bool LevelSettingsLayer::init(...) { if (!FLAlertLayer::init(...)) return false; ... return true; } Let’s make sure by checking out the unknown function’s body: Picture showing what is clearly FLAlertLayer::init 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]. That means that the other function we found is very likely LevelSettingsLayer::init as well, so let’s rename both approppriately: Picture showing fixing LevelSettingsLayer::init’s signature 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 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) Chapter 2.4: Comparing Against Android Android GD is special for one important reason - it has symbols! What this means is that every function name is present in the code, just like Cocos2d on Windows - and not only their names, but their parameter types aswell! And because GD is a cross-compiled game from a single codebase, this means that we can compare against Android GD to aid reverse engineering other platforms. Android GD’s binary is called libcocos2dcpp.so - it contains GD, Cocos2d, and all other dependencies in a single package. However, getting your hands into it is not as easy as Windows, since you need to extract it from the APK - ask some other modder for their copy of it 😉 ⚠️ ARMv8 support in Ghidra broke in version 11, so you’d preferably get the ARMv7 version. Once you have acquired the Android binary, import it to Ghidra the same way you imported Windows, except make sure to disable the Non returning functions: discovered option for Analysis. Android GD imported to Ghidra Analyzing Android GD, with the Non returning functions: discovered option disabled So, let’s verify the REing we did in the last chapter! Open up the class list on Android and look up LevelSettingsLayer: LevelSettingsLayer from Android open in Ghidra, showing a lot more functions Whoa, that’s a lot of functions… thanks, symbols! The first function we found in the last chapter was the constructor, so let’s navigate straight to it! Well, hm. There doesn’t seem to be any function named LevelSettingsLayer here? The destructors are there but no constructor? Suspicious… let’s open up create instead to see what’s up: LevelSettingsLayer::create on Android, showing that the constructor has been inlined Ah, so that’s what happened - the constructor got inlined. This means that its code was inserted to its call sites and the function definition itself got removed. Well, if we look at the end of the create function, we can see the call to init is there: LevelSettingsLayer::init called inside LevelSettingsLayer::create Let’s follow the call and compare this to the LevelSettingsLayer::init we found on Windows: Comparison between LevelSettingsLayer::init on Android and what we think is the same on Windows (Left is Android, right is Windows) Hmm, alright, both have the call to FLAlertLayer::init at the start. And both make calls to CCObject::retain, CCDirector::sharedDirector, and the CCRect constructor at similar times… Oh, and there’s a string literal! Both have a call to CCLabelBMFont::create with the same parameters. String literals are a really good way to compare functions, so this confirms it - we definitely found the real LevelSettingsLayer::init on Windows. So, let’s copy the signature from Android to Windows: The signature of LevelSettingsLayer::init on Android, acquired through a symbol Note that the Android function signatures aren’t perfect - they don’t have parameter names, and more crucially they don’t have a return type. You may notice that Ghidra has inferred the type of LevelSettingsLayer::init to be a void, however we know better than Ghidra that init functions don’t return void! Manually fixing the return type makes Ghidra add the missing return false: LevelSettingsLayer::init on Android in Ghidra, now returning the correct type So let’s get back to adding the correct parameter types on Windows. The first one is a LevelSettingsObject*, so let’s add it- The type LevelSettingsObject doesn’t exist in Ghidra Oh, Ghidra has no clue what a LevelSettingsObject is. Well, we could manually define the type using the Data Type Manager, but it’s better to let Ghidra make the definition for us by finding some LevelSettingsObject member function and typing it as __thiscall: LevelSettingsObject::init renamed correctly, which causes Ghidra to register the LevelSettingsObject type (LevelSettingsObject::init was found using the same method as the previous chapters, however replicating it is left as an exercise for the reader!) Repeat the same for LevelEditorLayer, and now Ghidra lets us use them as parameter types: LevelSettingsLayer::init with the correct parameter types on Windows ⚠️ The reason the calling convention of LevelSettingsLayer::init is __thiscall will be explained in a later chapter - not all functions have the same calling convention! And there we go - we can now be pretty much certain that we have found the correct LevelSettingsLayer::init, and that our signature is right! Chapter 2.5: Finding Callbacks The reason we started reverse engineering by finding init functions is because they’re the most common thing you’ll be hooking. However, there is another type of function that is used very often in mods - callbacks! Callbacks are passed to buttons through their create function (usually CCMenuItemSpriteExtra::create), and are what the button does when it is clicked - vitally important for any mod which wants to change what a button does! Callbacks are usually named onSomething and take a single CCObject* parameter along with the current class. This is what passing a callback looks like in C++ code: auto button = CCMenuItemSpriteExtra::create( ..., this, menu_selector(ThisClass::onButtonClicked) ); The menu_selector macro is just syntactic sugar for reinterpret_cast(&ThisClass::onButtonClicked) - in other words, it just casts the callback to the correct type. What we can take away from this code is that to find a callback in Ghidra, all we need to do is find out where the button it’s used on is created, and then look at that button’s create call. The easiest way to find out where our desired callback is used is through Android - although, first we need to figure out which callback we’re looking for. Let’s say we’re looking for whatever function it is that shows this popup: level stats. Level statistics popup for Zenith by HJfod As a start, thanks to DevTools, we know this layer’s name is LevelInfoLayer (todo: add picture), so we’re looking for some callback in it. Now, we know that the button that shows this has an info button sprite, whose sprite name is GJ_infoIcon_001.png (thanks, Geode VS Code extension). The info sprite found through the Geode VS Code extension, showing that its name is GJ_infoIcon_001.png Let’s find LevelInfoLayer::init and then find where it uses the info sprite: Code showing a CCSprite being created with GJ_infoIcon_001.png Hm, this doesn’t seem right. Let’s check the unknown function call after: Code resembling a create function Hm, this looks like a create function. Checking the constructor, it seems to be CCMenuItemSpriteExtra::create - let’s rename it as such. Checking on Android, the function has 4 parameters: CCNode*, CCNode*, CCObject*, and void(CCObject::*)(CCObject*). The first three are easy - however, the last one is a function pointer. Cocos2d has an alias for this pointer in particular - SEL_MenuHandler. However, as it’s a typedef, it doesn’t come with any symbols and as such we need to add it manually: Adding a new function definition in Ghidra Defining SEL_MenuHandler in Ghidra After this, we can correct the signature of CCMenuItemSpriteExtra::create. The correct signature for CCMenuItemSpriteExtra::create in Ghidra ⚠️ Note the calling convention being __fastcall rather than __thiscall - this will be explained later! Now if we look back at LevelInfoLayer::init, we can see that the function call looks more accurate - there’s a function being passed as a parameter now! If we follow through to that function’s definition, we will see that it in fact is the one we were looking for, judging by the string literals present. A call to CCMenuItemSpriteExtra::create in Ghidra with the correct args LevelInfoLayer::onLevelInfo Now we just need to find the same function on Android to get the correct signature. Here we can take advantage of the fact that Ghidra can search for string literals defined in the code: Searching for the string Total Attempts in Ghidra Filtering through the potential XREFs, we find LevelInfoLayer::onLevelInfo, which checking through LevelInfoLayer::init is the correct one. So we can retype our Windows function and be confident we found the correct one! Right now, reverse engineering should seem a little less mystifying, however there is one more important aspect we need to consider: calling conventions. Where do they come from? Where do they go? How do you know what calling convention a function uses? Chapter 2.6: Introduction to Assembly In earlier chapters, we have avoided having to look at assembly code as it can be quite hard to grasp. However, an unfortunate reality is that in order to be an independent GD modder, you need to understand assembly, or at the very least the basics of it. So, without further ado, let’s delve into some x86! int addTwo(int a, int b) { return a + b; } int main() { int z = addTwo(5, 7); } Here we have a very simple program in C++: adding two numbers together. Let’s compile this to x86 assembly and see what we get! 0x432b40: mov eax, ecx add eax, edx ret 0 _main: mov ecx, 5 mov edx, 7 call 0x432b40 mov ecx, eax xor eax, eax ret 0 If you have never seen assembly code before, this will probably look completely alien to you. It might leave you scratching your head and asking many questions, from what happened to our variables to where the function name went. Let’s see if we can understand it better by turning it into C++-like pseudo-code: void 0x432b40() { eax = ecx; eax += edx; return; } void _main() { ecx = 5; edx = 7; 0x432b40(); ecx = eax; } The first thing to notice is that after compilation, each function is given a memory address; that is, an address within the binary code where the function can be found. The second thing is that in binary code, there are no names. There are only memory addresses, instructions, and registers. Functions technically do not even exist in binary code; in there, they are called subroutines, and are referenced by their memory address. The second thing to notice is that our variables have turned into register assignments. Registers are like global variables in C++; they can be assigned to from anywhere. The actual registers that may appear in the assembly code are predefined by the assembly language being used. In x86, some of them include ecx, edx, epx, and xmm0. The memory addresses of functions are not constant between different compilations; what this means in practice for GD mods is that a mod that works for GD version 2.113 does not work for version 2.112 or 2.2, as the memory addresses of the functions are completely different. However, they are constant within copies of the same compiled binary; if you find a function’s address in the GD 2.113 binary, you can use that address in your mod and it will work for anyone with GD 2.113 installed. ⚠️ TODO: Rest of the damn handbook Chapter 4.1: How Do You The Mod Given that you are reading this handbook, you probably have some big ideas for mods you want to make. Maybe you want to be the next Absolute and make an awesome mod menu. Maybe you’re not satisfied by how long BetterEdit is taking and want to create your own editor mod. Maybe you have something completely original planned. Whatever it is, it is important to understand how exactly you could approach turning your idea into reality. Now, of course, it is obligatory to note that there is no right or wrong way to make a mod. There’s no absolute do-this-and-youll-succeed process that is the same and works for every mod. Some mods require more effort than others, depending on a practically infinite amount of factors. However, this Chapter attempts to divide modding in general into 5 steps. Some may look at these steps and conclude that this is so generic it’s practically useless, but it’s good to remind ourselves now and then what it is we are actually doing. Step 1: Concretize Your Idea The first step is to really concretize your idea. Often times, the ideas for the mods you want to make can be quite grandiose, like “I want to make GD more optimized” or “I want to make the editor better”. Unfortunately, figuring out where to start actually working on the mod can prove to be a problem with large-scale ideas. In cases like these, you should try to break the problem down into smaller parts, like “I want to fix the scale controls in the editor being unable to rescale multiple objects at once” or “I want to add a ‘Select by Group ID’ button”. Break down your idea into smaller parts, until you have something tangible you can actually start approaching. Step 2: Reverse Engineer After figuring out what it is that you are actually going for, it’s time to look into if it is even possible. For that, you will need to reverse engineer the game. If you want to fix some bugs in GD, first try to figure out what causes the bug. Is there a consistent setup or method to causing it? What classes and functions are related to this? Does it seem like a rounding error or something more severe? Step 3: Write Some Code Once you have an idea on what might be a route to achieving what you want, write some code to try it out. If you don’t know the exact magic words to write, refer to documentation and ask around for help. Step 4: Test Once you have some code that compiles, the next step is to simply try it out. Load your mod into the game and see if it works. Send it to your friends to verify it works for them too. Make sure that it works all of the time, and that it doesn’t have any unexpected side effects, like the game crashing after a while due to a memory leak. Step 5: Repeat ad nauseam If your code doesn’t work, reverse engineer a bit more to find out why, write some new code, and test that. Once you finish one feature, you may find yourself coming up with ideas for new ones, and so you can reverse engineer for those, write some code and test. Repeat basically forever until you have a finished product, or you get tired and start the next hobby project. These may seem like completely dull and uninteresting steps for some, and perhaps like a glorified WikiHow article, but the point of that is to illustrate that there really is no specific process for making a mod. For example, reverse engineering may involve using Ghidra and IDA to analyze functions, or it may involve just looking around with DevTools. The code you write may be some in-depth template-filled C++ behemoth, or it may just be a few quick lines of test code. Testing may involve a larger group or just be you realizing you forgot to call retain on an array. Modding isn’t an exact science; it’s an art. Even then, there are many important skills and tools every modder should get acquainted with, and in the next chapter we will look at one of the most important ones: Reverse Engineering Modding Guidelines As Geode is a framework meant first and foremost to provide a centralized and simple framework for mods, there are a few rules for modders that we request every modder to follow. These guidelines are meant to ensure compatability and a safe & enjoyable experience for end users. Failing to comply with these guidelines will result in your mod being denied entry to the mods repository. You are still allowed to distribute the mod yourself, however we hope you understand that these rules exist for a reason, and that a mod that harms its users is likely not allowed by law. Any mod found to be harmful will be publicly reported as such and will be warned against. Its developer may also receive a temporary or permanent ban from the mods repository, or in severe cases off all Geode-related platforms. 1. Don’t be evil Do not delete System32, do not encrypt their filesystem and ask for a Bitcoin ransom, etc. 1.1. Do not collect any data off the user’s game / computer without their consent. This does not apply to data that is collected and stored only locally, so for example making something like a statistics mod that stores the statistics on the user’s computer / on their personal Google Drive account is fine. However, also sending yourself a copy of that data / in any other way sending it outside of where the user has agreed to is strictly off limits. Any mod found collecting user data without the user’s knowledge / consent will be considered severely harmful. 2. Use Geode appropriately Write reasonable code, basically. 2.1. Use Geode’s solutions (if they exist) If Geode has a solution to a problem, use that and do not create your own solution to it. If you want to add custom keybinds to your mod, use the Geode API. If you feel the solution Geode provides is insufficient for your needs, please let us know and we’ll look into expanding it. If Geode comes with a solution for adding nodes to a certain layer, use that instead of hooking the layer yourself. Do note that “Geode” here includes the loader and the official API mod. 2.2. Be careful with open access Geode is built as an open framework where any mod can access basically any data it needs, but this doesn’t mean that they should access it. For example, modifying another mod’s Mod class should only be done in situations where they have intended for that to be done. 2.3. Follow Geode’s conventions when using it You should always follow the recommended conventions for naming mod IDs, writing mod descriptions, etc.. 3. General Modding Guidelines These are guidelines that could apply to non-Geode mods aswell. 3.1. Keep your mod focused Keep your mod focused on its features and don’t try to cram all the ideas you have for the whole of GD into one mod. Try to limit the number of places your mod affects to as small an amount as possible. If you make an icon kit management mod, that mod shouldn’t also add a new main level or a Cut button in the Editor. If you want to bundle a bunch of mods together, consider releasing a modpack instead. 3.2. Be as clear with errors as possible Insufficient permissions to read file /some/path/to/file is better than Can't read file which is better than Error Code 15 3.3. Do your best not to crash the game Never call autorelease on classes that inherit from TableViewCell and are used with BoomListView Mods Index Review Guidelines These are the guidelines for how mods are allowed on the mods index. Anyone who with the power to approve mods, please read this document and adhere to the guidelines specified. For modders, if you are interested in publishing your mods on the index, you can make the review process faster by making sure your mod adheres to these guidelines ahead of time :) Ban rules A mod found breaking any of theese rules will be rejected unconditionally from the index, as well as very likely leading to a total and permanent ban from posting on the index and a removal of all existing mods on the index. The mod contains malware. The mod is stolen. This means that it consists fully or nearly fully of the original code of another person with credit explicitly erased. Hard-rejection rules A mod found breaking any of these rules will be rejected unconditionally from the index. The mod contains false information (for example, claims to do something it doesn’t, or has false claims about who made it) The mod uses terrible practices that have a near-100% chance of resulting in mod incompatability The mod introduces its own hooking framework The mod modifies the state of the Geode Loader or other mods in a way that breaks them The mod re-implements shared functionality already available through other API mods (custom keybinds, etc.) The mod introduces severe security vulnerabilities like RCE The mod features explicit content (I’m pretty sure this doesn’t need to be mentioned, but adding it just in case) Strong rules A mod found breaking any of these rules will likely be rejected, although depending on the situation and severity, they could also still be approved. The mod uses bad practices that have a high chance of resulting in mod incompatability The mod modifies existing GD layers through absolute child indices The mod doesn’t work as intended The mod has game-crashing bugs Ordinary rules A mod found breaking any of these can still be approved, although breaking multiple can lead to a rejection. The mod has numerous common non-severe bugs The mod can’t preserve state between bootups (save data, load data) normally The mod is incompatible with another mod on the index due to its own fault Non-rules These are some things one might expect to result in a rejection, but actually most likely won’t. The mod is fundamentally incompatible with another mod on the index (for example, two mods that completely reshape MenuLayer are never going to be compatible) The mod’s UX is absolutely god awful The mod doesn’t do anything particularly interesting or useful Who can approve mods? Anyone with permission to approve pull requests on the index repository. If you want your mod on the index, submit a pull request, and someone will comment on your PR approving it or pointing out things that cause it to be rejected. However, if your mod is closed source, you will have to send it source code privately to Geode developers who have permission to add mods to the index. In general, all Lead Geode Devs can add new mods to the index. However, in practice, for most mods you should ask HJfod for mods available on Windows and alk or Camila for mods on MacOS. For cross-platform mods, ask anyone. HJfod (Windows) | hjfod Pie (Windows) | poweredbypie Mat (Windows) | mat.4 fig (Windows) | figmentboy ConfiG (Windows) | cgytrus Alk (MacOS) | alk1m123 Camila (MacOS) | camila314 Styling guidelines General The maximum line limit is 80 characters. In the case of a line exceeding 80 charaters, wrapping rules should be applied. Files & Directories Files should be in pascalcase. Directories should be in nocase. Used file extensions are .cpp, .hpp, .mm and .hmm. Comments For single line comments, there should be a single space padding. // Correct /* Correct */ //Wrong /*Wrong*/ For multiline comments, the contents should start in a next line with a indent. /* This is quite correct. Isn't it? */ /*This is wrong lol*/ Constants For null pointers, nullptr should be used. // Correct CCObject* obj = nullptr; // Wrong CCObject* obj = 0; CCObject* obj = NULL; CCObject* obj = 0.0f; Floats should be suffixed with f, hexadecimal values should be prefixed with 0x. // Correct int hex = 0x1907; float delta = 0.016667f; // Wrong int hex = 1907h; float delta = 0.016667; Variables Local variables should be in camelcase. // Correct int myCoolVariable = 1907; // Wrong int MyBadVariable = 1907; int this_is_ugly = 1907; int _Scary_val = 1907; No more than 1 variable should be declared in a same line. // Correct bool firstVar = false; bool secondVar = true; // Wrong bool firstVar = false, secondVar = true; Static variables should be prefixed with s_ and in camelcase. // Correct static CCNode* s_sharedNode = nullptr; // Wrong static CCNode* g_sharedNode = nullptr; static CCNode* sharedNode = nullptr; Since global variable initializations between platforms are inconsistent, the use of global variables is entirely discouraged. Types Type aliases should always be defined using the using keyword. Types should be in pascalcase without a suffix. // Correct using EpicInteger = unsigned long long int; // Wrong typedef unsigned long long int EpicInteger; using EpicInteger_t = unsigned long long int; Pointers and references should be attached to the type. // Correct CCNode* node; CCNode*& node2 = node; // Wrong CCNode *node; CCNode *&node2 = node; CCNode* &node3 = node; Const qualifiers should be always after the qualified type. // Correct std::string const& ref = str; CCNode const* node2 = node; CCNode* const node3 = node; // Wrong const std::string& ref = str; const CCNode* node2 = node; In places of ambiguity, typename should be used. // Correct typename Something::type test = value; // Wrong Something::type test = value; Statements If, while and for statements should be on the same line, the scope should start in the same line. One line if, while and for statements shouldn’t use braces. // Correct while (thing == 54) { thing = 53; } if (thing == 54) thing = 53; for (int thing = 53; thing != 54; ++thing) { // Stuff } // Wrong while (thing == 54) { thing = 53; } if (thing == 54) { thing = 53; } Switch statement labels should be on the same line as the statement. Every fallthrough should be marked with [[fallthrough]]. For enums, every case should be handled. // Correct switch (thing) { case TestEnum::Xd: [[fallthrough]]; case TestEnum::Lol: value = 5; break; default: value = 6; break; } // Wrong switch (thing) { case TestEnum::Xd: [[fallthrough]]; case TestEnum::Lol: value = 5; break; } Functions Return type, the function and the parameters should be in the same line. Function name and the parameter names should be in camelcase. There shouldn’t be any space between function name and the parenthesis. // Correct CCObject* copyWithMeme(CCMeme* meme); // Wrong CCObject* copyWithMeme (CCMeme* meme); Definitions should start on the same line. // Correct CCObject* copyWithMeme(CCMeme* meme) { return nullptr; // funny meme if i do say so myself } // Wrong CCObject* copyWithMeme(CCMeme* meme) { return nullptr; } Unless necessary, the trailing return type shouldn’t be used. // Correct CCObject* copyWithMeme(CCMeme* meme) { return nullptr; } // Wrong auto copyWithMeme(CCMeme* meme) -> CCObject* { return nullptr; } Namespaces Namespaces should be one word lowercase. // Correct namespace geode { } // Wrong namespace the_old_lilac_namespace { } using namespace std; shouldn’t be used. // Correct std::string value; // Wrong string value; Classes Classes should be in pascalcase and the declaration should start on the same line. // Correct class BasedButton { }; // Wrong class BasedButton { }; Access specifiers should be on the same indentation as the classes. // Correct class BasedButton { public: // Stuff }; // Wrong class BasedButton { public: // this one is for you camila }; // Wrong class BasedButton { public: // bad stuff }; Subclasses should be on the same line. // Correct class BasedButton : CCNode, FLAlertDelegate { public: // Stuff }; // Wrong class BasedButton : CCNode, FLAlertDelegate { public: // Stuff }; // Wrong class BasedButton : CCNode, FLAlertDelegate { public: // Stuff }; Classes which shouldn’t be extended should be marked as final. // Correct class BasedButton final : CCNode { public: // I am the last implementer ok }; // Wrong class BasedButton : CCNode { public: // pls dont subclass me okthxbai }; Member functions Same rules of functions apply for member functions. // Correct class BasedButton : CCNode { public: bool init() override { return true; } }; // Wrong class BasedButton : CCNode { public: bool init() override { return true; } }; Functions should be const qualified whenever they can. // Correct class BasedButton : CCNode { public: void baseMyButton(BasedButton const* other) const { // basing your button // and not modifying you :) } }; // Wrong class BasedButton : CCNode { public: void baseMyButton(BasedButton const* other) { // basing your button // and not modifying you :) } }; Virtual overrides should be marked as override. // Correct class BasedButton : CCNode { public: bool init() override { return true; } }; // Wrong class BasedButton : CCNode { public: bool init() { return true; } }; Outofline definitions of member functions have the same rules applied to them. // Correct bool BasedButton::init() { return true; } // Wrong bool BasedButton::init() { return true; } Templates Template parameters should always be in pascalcase, and the types should always use the class keyword. // Correct template // Wrong template Template declarations should always be on the previous line. // Correct template void function(CoolType&& value); template class EpicClass; // Wrong template void function(CoolType&& value); template class EpicClass; In places of ambiguity, template should be used. // Correct auto value = Something::template function(); // Wrong auto value = Something::function(); Macros Syntactical macros should always be prefixed with $ and should use one word lowercase. // Correct #define $modify(...) // lol // Wrong #define $modifyThisDamnedClass(...) // lol Other macros should always be uppersnakecase and should be prefixed with GEODE_. // Correct #define GEODE_DEFINE_FUNC(...) // Wrong #define DEFINEFUNCLOL(...) #define OrThisOne(...) Wrapping TODO awaiable class: FMOD::Channel FMOD::ChannelControl FMOD::ChannelGroup FMOD::DSP FMOD::DSPConnection FMOD::Debug_Initialize FMOD::File_GetDiskBusy FMOD::File_SetDiskBusy FMOD::Geometry FMOD::Memory_GetStats FMOD::Memory_Initialize FMOD::Reverb3D FMOD::Sound FMOD::SoundGroup FMOD::System FMOD::System_Create cocos2d::AnchorLayout cocos2d::AnchorLayoutOptions cocos2d::AxisLayout cocos2d::AxisLayoutOptions cocos2d::CCAccelAmplitude cocos2d::CCAccelDeccelAmplitude cocos2d::CCAcceleration cocos2d::CCAccelerometer cocos2d::CCAccelerometerDelegate cocos2d::CCAction cocos2d::CCActionCamera cocos2d::CCActionEase cocos2d::CCActionInstant cocos2d::CCActionInterval cocos2d::CCActionManager cocos2d::CCActionTween cocos2d::CCActionTweenDelegate cocos2d::CCAffineTransform cocos2d::CCAffineTransformConcat cocos2d::CCAffineTransformEqualToTransform cocos2d::CCAffineTransformInvert cocos2d::CCAffineTransformMakeIdentity cocos2d::CCAffineTransformRotate cocos2d::CCAffineTransformScale cocos2d::CCAffineTransformTranslate cocos2d::CCAnimate cocos2d::CCAnimation cocos2d::CCAnimationCache cocos2d::CCAnimationFrame cocos2d::CCApplication cocos2d::CCApplicationProtocol cocos2d::CCArray cocos2d::CCAtlasNode cocos2d::CCAutoreleasePool cocos2d::CCBMFontConfiguration cocos2d::CCBezierBy cocos2d::CCBezierTo cocos2d::CCBlendProtocol cocos2d::CCBlink cocos2d::CCBool cocos2d::CCCallFunc cocos2d::CCCallFuncN cocos2d::CCCallFuncND cocos2d::CCCallFuncO cocos2d::CCCamera cocos2d::CCCardinalSplineBy cocos2d::CCCardinalSplineTo cocos2d::CCCatmullRomBy cocos2d::CCCatmullRomTo cocos2d::CCClippingNode cocos2d::CCComponent cocos2d::CCComponentContainer cocos2d::CCConfiguration cocos2d::CCControllerHandler cocos2d::CCControllerState cocos2d::CCCopying cocos2d::CCDataVisitor cocos2d::CCDeccelAmplitude cocos2d::CCDelayTime cocos2d::CCDestructor cocos2d::CCDevice cocos2d::CCDictElement cocos2d::CCDictionary cocos2d::CCDirector cocos2d::CCDirectorDelegate cocos2d::CCDisplayLinkDirector cocos2d::CCDouble cocos2d::CCDrawNode cocos2d::CCEGLView cocos2d::CCEGLViewProtocol cocos2d::CCEaseBackIn cocos2d::CCEaseBackInOut cocos2d::CCEaseBackOut cocos2d::CCEaseBounce cocos2d::CCEaseBounceIn cocos2d::CCEaseBounceInOut cocos2d::CCEaseBounceOut cocos2d::CCEaseElastic cocos2d::CCEaseElasticIn cocos2d::CCEaseElasticInOut cocos2d::CCEaseElasticOut cocos2d::CCEaseExponentialIn cocos2d::CCEaseExponentialInOut cocos2d::CCEaseExponentialOut cocos2d::CCEaseIn cocos2d::CCEaseInOut cocos2d::CCEaseOut cocos2d::CCEaseRateAction cocos2d::CCEaseSineIn cocos2d::CCEaseSineInOut cocos2d::CCEaseSineOut cocos2d::CCEvent cocos2d::CCFadeIn cocos2d::CCFadeOut cocos2d::CCFadeOutBLTiles cocos2d::CCFadeOutDownTiles cocos2d::CCFadeOutTRTiles cocos2d::CCFadeOutUpTiles cocos2d::CCFadeTo cocos2d::CCFileUtils cocos2d::CCFiniteTimeAction cocos2d::CCFlipX cocos2d::CCFlipX3D cocos2d::CCFlipY cocos2d::CCFlipY3D cocos2d::CCFloat cocos2d::CCFollow cocos2d::CCGLProgram cocos2d::CCGrabber cocos2d::CCGrid3D cocos2d::CCGrid3DAction cocos2d::CCGridAction cocos2d::CCGridBase cocos2d::CCHide cocos2d::CCIMEDelegate cocos2d::CCIMEDispatcher cocos2d::CCIMEKeyboardNotificationInfo cocos2d::CCImage cocos2d::CCInteger cocos2d::CCJumpBy cocos2d::CCJumpTiles3D cocos2d::CCJumpTo cocos2d::CCKeyboardDelegate cocos2d::CCKeyboardDispatcher cocos2d::CCKeyboardHandler cocos2d::CCKeypadDelegate cocos2d::CCKeypadDispatcher cocos2d::CCKeypadHandler cocos2d::CCLabelAtlas cocos2d::CCLabelBMFont cocos2d::CCLabelProtocol cocos2d::CCLabelTTF cocos2d::CCLayer cocos2d::CCLayerColor cocos2d::CCLayerGradient cocos2d::CCLayerMultiplex cocos2d::CCLayerRGBA cocos2d::CCLens3D cocos2d::CCLiquid cocos2d::CCLog cocos2d::CCLuaLog cocos2d::CCMenu cocos2d::CCMenuItem cocos2d::CCMenuItemAtlasFont cocos2d::CCMenuItemFont cocos2d::CCMenuItemImage cocos2d::CCMenuItemLabel cocos2d::CCMenuItemSprite cocos2d::CCMenuItemToggle cocos2d::CCMessageBox cocos2d::CCMotionStreak cocos2d::CCMouseDelegate cocos2d::CCMouseDispatcher cocos2d::CCMouseHandler cocos2d::CCMoveBy cocos2d::CCMoveTo cocos2d::CCNode cocos2d::CCNodeRGBA cocos2d::CCNotificationCenter cocos2d::CCNotificationObserver cocos2d::CCObject cocos2d::CCOrbitCamera cocos2d::CCPVRMipmap cocos2d::CCPageTurn3D cocos2d::CCParallaxNode cocos2d::CCParticleBatchNode cocos2d::CCParticleExplosion cocos2d::CCParticleFire cocos2d::CCParticleFireworks cocos2d::CCParticleFlower cocos2d::CCParticleGalaxy cocos2d::CCParticleMeteor cocos2d::CCParticleRain cocos2d::CCParticleSmoke cocos2d::CCParticleSnow cocos2d::CCParticleSpiral cocos2d::CCParticleSun cocos2d::CCParticleSystem cocos2d::CCParticleSystemQuad cocos2d::CCPlace cocos2d::CCPoint cocos2d::CCPointArray cocos2d::CCPointFromString cocos2d::CCPoolManager cocos2d::CCPrettyPrinter cocos2d::CCProfiler cocos2d::CCProfilingBeginTimingBlock cocos2d::CCProfilingEndTimingBlock cocos2d::CCProfilingResetTimingBlock cocos2d::CCProfilingTimer cocos2d::CCProgressFromTo cocos2d::CCProgressTimer cocos2d::CCProgressTo cocos2d::CCRGBAProtocol cocos2d::CCRect cocos2d::CCRectApplyAffineTransform cocos2d::CCRectFromString cocos2d::CCRemoveSelf cocos2d::CCRenderTexture cocos2d::CCRepeat cocos2d::CCRepeatForever cocos2d::CCReuseGrid cocos2d::CCReverseTime cocos2d::CCRipple3D cocos2d::CCRotateBy cocos2d::CCRotateTo cocos2d::CCSAXDelegator cocos2d::CCSAXParser cocos2d::CCScaleBy cocos2d::CCScaleTo cocos2d::CCScene cocos2d::CCSceneDelegate cocos2d::CCSceneTransitionDelegate cocos2d::CCScheduler cocos2d::CCSchedulerScriptHandlerEntry cocos2d::CCScriptEngineManager cocos2d::CCScriptEngineProtocol cocos2d::CCScriptHandlerEntry cocos2d::CCSequence cocos2d::CCSet cocos2d::CCShaderCache cocos2d::CCShaky3D cocos2d::CCShakyTiles3D cocos2d::CCShatteredTiles3D cocos2d::CCShow cocos2d::CCShuffleTiles cocos2d::CCSize cocos2d::CCSizeFromString cocos2d::CCSkewBy cocos2d::CCSkewTo cocos2d::CCSpawn cocos2d::CCSpeed cocos2d::CCSplitCols cocos2d::CCSplitRows cocos2d::CCSprite cocos2d::CCSpriteBatchNode cocos2d::CCSpriteFrame cocos2d::CCSpriteFrameCache cocos2d::CCStandardTouchDelegate cocos2d::CCStandardTouchHandler cocos2d::CCStopGrid cocos2d::CCString cocos2d::CCTMXLayer cocos2d::CCTMXLayerInfo cocos2d::CCTMXMapInfo cocos2d::CCTMXObjectGroup cocos2d::CCTMXTiledMap cocos2d::CCTMXTilesetInfo cocos2d::CCTargetedAction cocos2d::CCTargetedTouchDelegate cocos2d::CCTargetedTouchHandler cocos2d::CCTextFieldDelegate cocos2d::CCTextFieldTTF cocos2d::CCTexture2D cocos2d::CCTextureAtlas cocos2d::CCTextureCache cocos2d::CCTextureETC cocos2d::CCTexturePVR cocos2d::CCTexturePack cocos2d::CCTextureProtocol cocos2d::CCThread cocos2d::CCTileMapAtlas cocos2d::CCTiledGrid3D cocos2d::CCTiledGrid3DAction cocos2d::CCTime cocos2d::CCTimer cocos2d::CCTintBy cocos2d::CCTintTo cocos2d::CCToggleVisibility cocos2d::CCTouch cocos2d::CCTouchDelegate cocos2d::CCTouchDispatcher cocos2d::CCTouchHandler cocos2d::CCTouchScriptHandlerEntry cocos2d::CCTransitionCrossFade cocos2d::CCTransitionEaseScene cocos2d::CCTransitionFade cocos2d::CCTransitionFadeBL cocos2d::CCTransitionFadeDown cocos2d::CCTransitionFadeTR cocos2d::CCTransitionFadeUp cocos2d::CCTransitionFlipAngular cocos2d::CCTransitionFlipX cocos2d::CCTransitionFlipY cocos2d::CCTransitionJumpZoom cocos2d::CCTransitionMoveInB cocos2d::CCTransitionMoveInL cocos2d::CCTransitionMoveInR cocos2d::CCTransitionMoveInT cocos2d::CCTransitionPageTurn cocos2d::CCTransitionProgress cocos2d::CCTransitionProgressHorizontal cocos2d::CCTransitionProgressInOut cocos2d::CCTransitionProgressOutIn cocos2d::CCTransitionProgressRadialCCW cocos2d::CCTransitionProgressRadialCW cocos2d::CCTransitionProgressVertical cocos2d::CCTransitionRotoZoom cocos2d::CCTransitionScene cocos2d::CCTransitionSceneOriented cocos2d::CCTransitionShrinkGrow cocos2d::CCTransitionSlideInB cocos2d::CCTransitionSlideInL cocos2d::CCTransitionSlideInR cocos2d::CCTransitionSlideInT cocos2d::CCTransitionSplitCols cocos2d::CCTransitionSplitRows cocos2d::CCTransitionTurnOffTiles cocos2d::CCTransitionZoomFlipAngular cocos2d::CCTransitionZoomFlipX cocos2d::CCTransitionZoomFlipY cocos2d::CCTurnOffTiles cocos2d::CCTwirl cocos2d::CCUserDefault cocos2d::CCWaves cocos2d::CCWaves3D cocos2d::CCWavesTiles3D cocos2d::CCZHeader cocos2d::CCZone cocos2d::ColumnLayout cocos2d::CopySizeLayout cocos2d::EGLTouchDelegate cocos2d::FNTConfigLoadFile cocos2d::FNTConfigRemoveCache cocos2d::Layout cocos2d::LayoutOptions cocos2d::ParticleStruct cocos2d::RowLayout cocos2d::SpacerNode cocos2d::SpacerNodeChild cocos2d::TypeInfo cocos2d::ZipFile cocos2d::ZipUtils cocos2d::_BMFontDef cocos2d::_BMFontPadding cocos2d::_FontDefHashElement cocos2d::_KerningHashElement cocos2d::__CCAffineTransformMake cocos2d::__CCPointApplyAffineTransform cocos2d::__CCSizeApplyAffineTransform cocos2d::_ccArray cocos2d::_ccBezierConfig cocos2d::_ccBlendFunc cocos2d::_ccCArray cocos2d::_ccColor3B cocos2d::_ccColor4B cocos2d::_ccColor4F cocos2d::_ccFontDefinition cocos2d::_ccFontShadow cocos2d::_ccFontStroke cocos2d::_ccHSVValue cocos2d::_ccPVRTexturePixelFormatInfo cocos2d::_ccPointSprite cocos2d::_ccQuad2 cocos2d::_ccQuad3 cocos2d::_ccT2F_Quad cocos2d::_ccTex2F cocos2d::_ccTexParams cocos2d::_ccV2F_C4B_T2F cocos2d::_ccV2F_C4B_T2F_Quad cocos2d::_ccV2F_C4B_T2F_Triangle cocos2d::_ccV2F_C4F_T2F cocos2d::_ccV2F_C4F_T2F_Quad cocos2d::_ccV3F_C4B_T2F cocos2d::_ccV3F_C4B_T2F_Quad cocos2d::_ccVertex2F cocos2d::_ccVertex3F cocos2d::ccAnimationFrameData cocos2d::ccArrayAppendArray cocos2d::ccArrayAppendArrayWithResize cocos2d::ccArrayAppendObject cocos2d::ccArrayAppendObjectWithResize cocos2d::ccArrayContainsObject cocos2d::ccArrayDoubleCapacity cocos2d::ccArrayEnsureExtraCapacity cocos2d::ccArrayFastRemoveObject cocos2d::ccArrayFastRemoveObjectAtIndex cocos2d::ccArrayFree cocos2d::ccArrayFullRemoveArray cocos2d::ccArrayGetIndexOfObject cocos2d::ccArrayInsertObjectAtIndex cocos2d::ccArrayNew cocos2d::ccArrayRemoveAllObjects cocos2d::ccArrayRemoveArray cocos2d::ccArrayRemoveObject cocos2d::ccArrayRemoveObjectAtIndex cocos2d::ccArrayShrink cocos2d::ccArraySwapObjectsAtIndexes cocos2d::ccCArrayAppendArray cocos2d::ccCArrayAppendArrayWithResize cocos2d::ccCArrayAppendValue cocos2d::ccCArrayAppendValueWithResize cocos2d::ccCArrayContainsValue cocos2d::ccCArrayDoubleCapacity cocos2d::ccCArrayEnsureExtraCapacity cocos2d::ccCArrayFastRemoveValueAtIndex cocos2d::ccCArrayFree cocos2d::ccCArrayFullRemoveArray cocos2d::ccCArrayGetIndexOfValue cocos2d::ccCArrayInsertValueAtIndex cocos2d::ccCArrayNew cocos2d::ccCArrayRemoveAllValues cocos2d::ccCArrayRemoveArray cocos2d::ccCArrayRemoveValue cocos2d::ccCArrayRemoveValueAtIndex cocos2d::ccCardinalSplineAt cocos2d::ccDrawCardinalSpline cocos2d::ccDrawCatmullRom cocos2d::ccDrawCircle cocos2d::ccDrawCircleSegment cocos2d::ccDrawColor4B cocos2d::ccDrawColor4F cocos2d::ccDrawCubicBezier cocos2d::ccDrawFilledCircle cocos2d::ccDrawFree cocos2d::ccDrawInit cocos2d::ccDrawLine cocos2d::ccDrawLines cocos2d::ccDrawPoint cocos2d::ccDrawPoints cocos2d::ccDrawPoly cocos2d::ccDrawQuadBezier cocos2d::ccDrawRect cocos2d::ccDrawSolidPoly cocos2d::ccDrawSolidRect cocos2d::ccGLBindTexture2D cocos2d::ccGLBindTexture2DN cocos2d::ccGLBindVAO cocos2d::ccGLBlendFunc cocos2d::ccGLBlendResetToCache cocos2d::ccGLDeleteProgram cocos2d::ccGLDeleteTexture cocos2d::ccGLDeleteTextureN cocos2d::ccGLEnable cocos2d::ccGLEnableVertexAttribs cocos2d::ccGLInvalidateStateCache cocos2d::ccGLUseProgram cocos2d::ccPointSize cocos2d::ccSetProjectionMatrixDirty cocos2d::ccTouchHandlerHelperData cocos2d::ccVertexLineIntersect cocos2d::ccVertexLineToPolygon cocos2d::cc_timeval cocos2d::cc_utf16_to_utf8 cocos2d::cc_utf16_vec_from_utf16_str cocos2d::cc_utf8_find_last_not_char cocos2d::cc_utf8_strlen cocos2d::cc_utf8_to_utf16 cocos2d::cc_utf8_trim_ws cocos2d::cc_wcslen cocos2d::ccc3 cocos2d::ccc3BEqual cocos2d::ccc4 cocos2d::ccc4BFromccc4F cocos2d::ccc4FEqual cocos2d::ccc4FFromccc3B cocos2d::ccc4FFromccc4B cocos2d::ccc4f cocos2d::cchsv cocos2d::ccpAdd cocos2d::ccpAngle cocos2d::ccpAngleSigned cocos2d::ccpClamp cocos2d::ccpCompMult cocos2d::ccpCompOp cocos2d::ccpCross cocos2d::ccpDistance cocos2d::ccpDistanceSQ cocos2d::ccpDot cocos2d::ccpForAngle cocos2d::ccpFromSize cocos2d::ccpFuzzyEqual cocos2d::ccpIntersectPoint cocos2d::ccpLength cocos2d::ccpLengthSQ cocos2d::ccpLerp cocos2d::ccpLineIntersect cocos2d::ccpMidpoint cocos2d::ccpMult cocos2d::ccpNeg cocos2d::ccpNormalize cocos2d::ccpPerp cocos2d::ccpProject cocos2d::ccpRPerp cocos2d::ccpRotate cocos2d::ccpRotateByAngle cocos2d::ccpSegmentIntersect cocos2d::ccpSub cocos2d::ccpToAngle cocos2d::ccpUnrotate cocos2d::clampf cocos2d::cocos2dVersion cocos2d::format_as cocos2d::getHashCodeByString cocos2d::gettimeofday cocos2d::hsv_geta cocos2d::isspace_unicode cocos2d::operator!= cocos2d::operator* cocos2d::operator*= cocos2d::operator+= cocos2d::operator- cocos2d::operator-= cocos2d::operator/= cocos2d::operator== cocos2d::sCCParticle cocos2d::tex2 cocos2d::timezone cocos2d::vertex2 cocos2d::vertex3 disable_copy_assignment<T, E> disable_copy_ctor<T, E> disable_move_assignment<T, E> disable_move_ctor<T, E> operator!= operator< operator<= operator== operator> operator>= result_construct_base<T, E> result_error_extractor result_trivial_copy_assign_base_impl<T, E> result_trivial_copy_ctor_base_impl<T, E> result_trivial_move_assign_base_impl<T, E> result_trivial_move_ctor_base_impl<T, E> result_union<T, E, IsTrivial> unit bad_result_access<E> failure<E> in_place_error_t is_failure<T> is_result<T> result<T, E> fuzzy_match fuzzy_match_simple format_as string Addresser get getCocos CCArrayExt<Type> CCArrayInserter CCDictEntry<K, T> CCDictIterator<K, T> CCDictionaryExt<Key, ValuePtr> handleTouchPriority handleTouchPriorityWith getCrashlogsDir getGameDir getGeodeDir getGeodeLogDir getGeodeResourcesDir getGeodeSaveDir getIndexDir getModConfigDir getModRuntimeDir getModsDir getModsSaveDir getSaveDir getTempDir addObjcMethod getObjcMethodImp Failure<E> Success<T> IPCEvent IPCFilter listen Nest generateLogName loadNest popNest pushNest saveNest vlogImpl getSizeSafe switchChildToMenu switchToMenu StringData AsyncWebRequest AsyncWebResponse AsyncWebResult<T> SentAsyncWebRequest fetch fetchBytes fetchFile fetchJSON openLinkInBrowser AEnterLayerEvent AEnterLayerFilter AccountButtonSprite AttributeSetEvent AttributeSetFilter BaseSeedValue BasedButtonSprite BoolSetting CategoryButtonSprite CircleButtonSprite ColorAlphaSetting ColorManager ColorPickPopup ColorPickPopupDelegate ColorSetting ComparableVersionInfo CrossButtonSprite CustomSetting CutoffConstructorType DefaultEventListenerPool DispatchEvent<Args> DispatchFilter<Args> EditorButtonSprite EnterLayerEvent<T> EnterLayerFilter<N, T> Event EventFilter<T> EventListener<T> EventListenerNode<Filter> EventListenerPool EventListenerProtocol FileSetting FloatSetting GenericContentLayer GenericListCell GeodeSettingChangedFilter<T> GeodeSettingValue<T> HandleToSaved<T> Hook IconButtonSprite IconSelectButtonSprite Index IndexInstallList IndexItem IndexUpdateEvent IndexUpdateFilter InputNode IntSetting InvalidGeodeFile JsonChecker JsonMaybeObject JsonMaybeSomething JsonMaybeValue LeaderboardButtonSprite ListView LoadProblem Loader MDPopup MDTextArea Mod ModInstallEvent ModInstallFilter ModMetadata ModStateEvent ModStateFilter Modify<Derived, Base> NodeIDs Notification ObjcHook Patch PlatformID PlatformInfo Popup<InitArgs> Ref<T> Result<T, E> SceneManager ScrollLayer Scrollbar SeedValueRS SeedValueRSV SeedValueRVS SeedValueSR SeedValueSRV SeedValueSVR SeedValueVRS SeedValueVSR SelectList<T, Stringify> Setting SettingChangedEvent SettingChangedFilter SettingNode SettingNodeDelegate SettingValue SettingValueSetter<T> Severity SimpleTextArea StringSetting TabButton TabButtonSprite TextDecorationWrapper TextInput TextLinkedButtonWrapper TextRenderer TypeIdentity<T> VersionInfo VersionTag WeakRef<T> WeakRefController WeakRefPool ZeroConstructorType addListBorders baseEnumToString createDefaultLogo createIndexItemLogo createLayerBG createModLogo createQuickPopup format_as getCommonFilterAllowedChars getMod is_iterable<T, typename> listenForAllSettingChanges openIndexPopup openInfoPopup openIssueReportPopup openModsList openSettingsPopup openSupportPopup operator< operator<= operator> operator>= semverCompare takeNextLoaderMod format_as format_as as_utf8 as_wide get_memory_allocation_function get_memory_deallocation_function set_memory_management_functions xml_attribute xml_attribute_iterator xml_document xml_named_node_iterator xml_node xml_node_iterator xml_object_range<It> xml_parse_result xml_text xml_tree_walker xml_writer xml_writer_file xml_writer_stream xpath_exception xpath_node xpath_node_set xpath_parse_result xpath_query xpath_variable xpath_variable_set _Iter_cat hash<geode::PlatformID> DynArray<T, INIT> MemPool MemPoolT<SIZE> StrPair XMLAttribute XMLComment XMLConstHandle XMLDeclaration XMLDocument XMLElement XMLHandle XMLNode XMLPrinter XMLText XMLUnknown XMLUtil XMLVisitor AccountHelpLayer AccountLayer AccountLoginLayer AccountRegisterLayer AchievementBar AchievementCell AchievementManager AchievementNotifier AchievementsLayer AdToolbox AdvFollowSetup AdvancedFollowEditObject AdvancedFollowInstance AdvancedFollowTriggerObject AnimatedGameObject AnimatedShopKeeper AnimatedSpriteDelegate AppDelegate ArtTriggerGameObject ArtistCell AudioEffectsLayer AudioLineGuideGameObject BitmapFontCache BonusDropdown BoomListLayer BoomListView BoomScrollLayer BoomScrollLayerDelegate BrowseSmartKeyLayer BrowseSmartTemplateLayer ButtonPage ButtonSprite CAState CCAlertCircle CCAnimateFrameCache CCAnimatedSprite CCBlockLayer CCCircleAlert CCCircleWave CCCircleWaveDelegate CCContentLayer CCContentManager CCCountdown CCCounterLabel CCExtenderNode CCIndexPath CCLightFlash CCLightStrip CCMenuItemSpriteExtra CCMenuItemToggler CCMoveCNode CCNodeContainer CCPartAnimSprite CCScrollLayerExt CCScrollLayerExtDelegate CCSpriteCOpacity CCSpriteGrayscale CCSpritePart CCSpritePlus CCSpriteWithHue CCTextInputNode CCURLObject CameraTriggerGameObject ChallengeNode ChallengesPage ChanceObject ChanceTriggerGameObject CharacterColorDelegate CharacterColorPage CheckpointGameObject CheckpointObject CollisionBlockPopup ColorAction ColorAction2 ColorActionSprite ColorChannelSprite ColorSelectDelegate ColorSelectLiveOverlay ColorSelectPopup ColorSetupDelegate CommentCell CommentUploadDelegate CommunityCreditNode CommunityCreditsPage ConfigureHSVWidget ConfigureValuePopup ConfigureValuePopupDelegate CountTriggerAction CountTriggerGameObject CreateGuidelinesLayer CreateMenuItem CreateParticlePopup CreatorLayer CurrencyRewardDelegate CurrencyRewardLayer CurrencySprite CustomListView CustomMusicCell CustomSFXCell CustomSFXDelegate CustomSFXWidget CustomSongCell CustomSongDelegate CustomSongLayer CustomSongLayerDelegate CustomSongWidget CustomizeObjectLayer CustomizeObjectSettingsPopup DS_Dictionary DailyLevelNode DailyLevelPage DashRingObject DemonFilterDelegate DemonFilterSelectLayer DialogDelegate DialogLayer DialogObject DownloadMessageDelegate DrawGridLayer DungeonBarsSprite DynamicBitset DynamicObjectAction DynamicScrollDelegate EditButtonBar EditGameObjectPopup EditLevelLayer EditTriggersPopup EditorOptionsLayer EditorPauseLayer EditorUI EffectGameObject EffectManagerState EndLevelLayer EndPortalObject EndTriggerGameObject EnhancedGameObject EnhancedTriggerObject EnterEffectInstance EnterEffectObject EventLinkTrigger EventTriggerInstance ExplodeItemNode ExplodeItemSprite ExtendedLayer FLAlertLayer FLAlertLayerProtocol FMODAudioEngine FMODAudioState FMODLevelVisualizer FMODSound FMOD_3D_ATTRIBUTES FMOD_ADVANCEDSETTINGS FMOD_ASYNCREADINFO FMOD_CODEC_DESCRIPTION FMOD_CODEC_STATE FMOD_CODEC_WAVEFORMAT FMOD_COMPLEX FMOD_CREATESOUNDEXINFO FMOD_DSP_BUFFER_ARRAY FMOD_DSP_DESCRIPTION FMOD_DSP_METERING_INFO FMOD_DSP_PARAMETER_3DATTRIBUTES FMOD_DSP_PARAMETER_3DATTRIBUTES_MULTI FMOD_DSP_PARAMETER_DESC FMOD_DSP_PARAMETER_DESC_BOOL FMOD_DSP_PARAMETER_DESC_DATA FMOD_DSP_PARAMETER_DESC_FLOAT FMOD_DSP_PARAMETER_DESC_INT FMOD_DSP_PARAMETER_FFT FMOD_DSP_PARAMETER_FLOAT_MAPPING FMOD_DSP_PARAMETER_FLOAT_MAPPING_PIECEWISE_LINEAR FMOD_DSP_PARAMETER_OVERALLGAIN FMOD_DSP_PARAMETER_SIDECHAIN FMOD_DSP_STATE FMOD_DSP_STATE_DFT_FUNCTIONS FMOD_DSP_STATE_FUNCTIONS FMOD_DSP_STATE_PAN_FUNCTIONS FMOD_ERRORCALLBACK_INFO FMOD_GUID FMOD_OUTPUT_DESCRIPTION FMOD_OUTPUT_OBJECT3DINFO FMOD_OUTPUT_STATE FMOD_PLUGINLIST FMOD_REVERB_PROPERTIES FMOD_TAG FMOD_VECTOR FRequestProfilePage FileOperation FileSaveManager FindBPMLayer FindObjectPopup FollowRewardPage FontObject ForceBlockGameObject FriendRequestDelegate FriendRequestPopup FriendsProfilePage GJAccountBackupDelegate GJAccountDelegate GJAccountLoginDelegate GJAccountManager GJAccountRegisterDelegate GJAccountSettingsDelegate GJAccountSettingsLayer GJAccountSyncDelegate GJActionManager GJAssetDownloadAction GJBaseGameLayer GJBigSprite GJBigSpriteNode GJChallengeDelegate GJChallengeItem GJChestSprite GJColorSetupLayer GJComment GJCommentListLayer GJDailyLevelDelegate GJDifficultySprite GJDropDownLayer GJDropDownLayerDelegate GJEffectManager GJFlyGroundLayer GJFollowCommandLayer GJFriendRequest GJGameLevel GJGameLoadingLayer GJGameState GJGarageLayer GJGradientLayer GJGroundLayer GJHttpResult GJItemIcon GJLevelList GJLevelScoreCell GJListLayer GJLocalLevelScoreCell GJLocalScore GJMGLayer GJMPDelegate GJMapObject GJMapPack GJMessageCell GJMessagePopup GJMoreGamesLayer GJMultiplayerManager GJObjectDecoder GJOptionsLayer GJPFollowCommandLayer GJPathPage GJPathRewardPopup GJPathSprite GJPathsLayer GJPointDouble GJPromoPopup GJPurchaseDelegate GJRequestCell GJRewardDelegate GJRewardItem GJRewardObject GJRobotSprite GJRotateCommandLayer GJRotationControl GJRotationControlDelegate GJScaleControl GJScaleControlDelegate GJScoreCell GJSearchObject GJShaderState GJShopLayer GJSmartBlockPreview GJSmartBlockPreviewSprite GJSmartPrefab GJSmartTemplate GJSongBrowser GJSpecialColorSelect GJSpecialColorSelectDelegate GJSpiderSprite GJSpriteColor GJStoreItem GJTransformControl GJTransformControlDelegate GJTransformState GJUINode GJUnlockableItem GJUserCell GJUserMessage GJUserScore GJValueTween GJWorldNode GJWriteMessagePopup GManager GameCell GameEffectsManager GameLevelManager GameLevelOptionsLayer GameManager GameObject GameObjectCopy GameObjectEditorState GameObjectPhysics GameOptionsLayer GameOptionsTrigger GameRateDelegate GameStatsManager GameToolbox GauntletLayer GauntletNode GauntletSelectLayer GauntletSprite GhostTrailEffect GooglePlayDelegate GooglePlayManager GradientTriggerObject GraphicsReloadLayer GravityEffectSprite GroupCommandObject2 HSVLiveOverlay HSVWidgetDelegate HSVWidgetPopup HardStreak InfoAlertButton InfoLayer InheritanceNode ItemInfoPopup ItemTriggerGameObject KeybindingsLayer KeybindingsManager KeyframeAnimTriggerObject KeyframeGameObject KeyframeObject LabelGameObject LeaderboardManagerDelegate LeaderboardsLayer LevelAreaInnerLayer LevelAreaLayer LevelBrowserLayer LevelCell LevelCommentDelegate LevelDeleteDelegate LevelDownloadDelegate LevelEditorLayer LevelFeatureLayer LevelInfoLayer LevelLeaderboard LevelListCell LevelListDeleteDelegate LevelListLayer LevelManagerDelegate LevelOptionsLayer LevelOptionsLayer2 LevelPage LevelSearchLayer LevelSelectLayer LevelSettingsDelegate LevelSettingsLayer LevelSettingsObject LevelTools LevelUpdateDelegate LevelUploadDelegate LikeItemDelegate LikeItemLayer ListButtonBar ListButtonBarDelegate ListButtonPage ListCell ListUploadDelegate LoadingCircle LoadingCircleSprite LoadingLayer LocalLevelManager MPLobbyLayer MapPackCell MapSelectLayer MenuGameLayer MenuLayer MessageListDelegate MessagesProfilePage MoreOptionsLayer MoreSearchLayer MoreVideoOptionsLayer MultiTriggerPopup MultilineBitmapFont MultiplayerLayer MusicArtistObject MusicBrowser MusicBrowserDelegate MusicDelegateHandler MusicDownloadDelegate MusicDownloadManager MusicSearchResult NewgroundsInfoLayer NodePoint NumberInputDelegate NumberInputLayer OBB2D ObjectControlGameObject ObjectDecoder ObjectDecoderDelegate ObjectManager ObjectToolbox OnlineListDelegate OpacityEffectAction OptionsCell OptionsLayer OptionsObject OptionsObjectDelegate OptionsScrollLayer ParentalOptionsLayer ParticleGameObject ParticlePreviewLayer PauseLayer PlatformDownloadDelegate PlatformToolbox PlayLayer PlayerButtonCommand PlayerCheckpoint PlayerControlGameObject PlayerFireBoostSprite PlayerObject PointNode PriceLabel ProfilePage PromoInterstitial PulseEffectAction PurchaseItemPopup RandTriggerGameObject RateDemonLayer RateLevelDelegate RateLevelLayer RateStarsLayer RetryLevelLayer RewardUnlockLayer RewardedVideoDelegate RewardsPage RingObject RotateGameplayGameObject SFXBrowser SFXBrowserDelegate SFXFolderObject SFXInfoObject SFXSearchResult SFXTriggerGameObject SFXTriggerInstance ScrollingLayer SearchButton SearchSFXPopup SecretLayer SecretLayer2 SecretLayer3 SecretLayer4 SecretNumberLayer SecretRewardsLayer SelectArtDelegate SelectArtLayer SelectEventLayer SelectFontLayer SelectListIconDelegate SelectListIconLayer SelectPremadeDelegate SelectPremadeLayer SelectSFXSortDelegate SelectSFXSortLayer SelectSettingDelegate SelectSettingLayer SequenceTriggerGameObject Serialize<cocos2d::ccColor3B> Serialize<cocos2d::ccColor4B> Serialize<geode::ByteVector> Serialize<geode::ModMetadata> Serialize<ghc::filesystem::path> SetColorIDPopup SetFolderPopup SetGroupIDLayer SetIDPopup SetIDPopupDelegate SetItemIDLayer SetLevelOrderPopup SetTargetIDLayer SetTextPopup SetTextPopupDelegate SetupAdvFollowEditPhysicsPopup SetupAdvFollowPopup SetupAdvFollowRetargetPopup SetupAnimSettingsPopup SetupAnimationPopup SetupAreaAnimTriggerPopup SetupAreaFadeTriggerPopup SetupAreaMoveTriggerPopup SetupAreaRotateTriggerPopup SetupAreaTintTriggerPopup SetupAreaTransformTriggerPopup SetupAreaTriggerPopup SetupArtSwitchPopup SetupAudioLineGuidePopup SetupAudioTriggerPopup SetupBGSpeedTrigger SetupCameraEdgePopup SetupCameraGuidePopup SetupCameraModePopup SetupCameraOffsetTrigger SetupCameraRotatePopup SetupCameraRotatePopup2 SetupCheckpointPopup SetupCoinLayer SetupCollisionStateTriggerPopup SetupCollisionTriggerPopup SetupCountTriggerPopup SetupDashRingPopup SetupEndPopup SetupEnterEffectPopup SetupEnterTriggerPopup SetupEventLinkPopup SetupForceBlockPopup SetupGameplayOffsetPopup SetupGradientPopup SetupGravityModPopup SetupGravityTriggerPopup SetupInstantCollisionTriggerPopup SetupInstantCountPopup SetupInteractObjectPopup SetupItemCompareTriggerPopup SetupItemEditTriggerPopup SetupKeyframeAnimPopup SetupKeyframePopup SetupMGTrigger SetupMoveCommandPopup SetupObjectControlPopup SetupObjectOptions2Popup SetupObjectOptionsPopup SetupObjectTogglePopup SetupOpacityPopup SetupOptionsTriggerPopup SetupPersistentItemTriggerPopup SetupPickupTriggerPopup SetupPlatformerEndPopup SetupPlayerControlPopup SetupPortalPopup SetupPulsePopup SetupRandAdvTriggerPopup SetupRandTriggerPopup SetupResetTriggerPopup SetupReverbPopup SetupRotateCommandPopup SetupRotateGameplayPopup SetupRotatePopup SetupSFXEditPopup SetupSFXPopup SetupSequenceTriggerPopup SetupShaderEffectPopup SetupShakePopup SetupSmartBlockLayer SetupSmartTemplateLayer SetupSongTriggerPopup SetupSpawnParticlePopup SetupSpawnPopup SetupStaticCameraPopup SetupStopTriggerPopup SetupTeleportPopup SetupTimeWarpPopup SetupTimerControlTriggerPopup SetupTimerEventTriggerPopup SetupTimerTriggerPopup SetupTouchTogglePopup SetupTransformPopup SetupTriggerPopup SetupZoomTriggerPopup ShaderGameObject ShaderLayer ShardsPage ShareCommentDelegate ShareCommentLayer ShareLevelLayer ShareLevelSettingsLayer ShareListLayer SimpleObject SimplePlayer SlideInLayer Slider SliderDelegate SliderThumb SliderTouchLogic SmartGameObject SmartTemplateCell SongCell SongChannelState SongInfoLayer SongInfoObject SongObject SongOptionsLayer SongPlaybackDelegate SongSelectNode SongTriggerGameObject SongsLayer SpawnParticleGameObject SpawnTriggerAction SpawnTriggerGameObject SpecialAnimGameObject SpriteAnimationManager SpriteDescription SpritePartDelegate StartPosObject StatsCell StatsLayer StatsObject SupportLayer TIXML_SNPRINTF TOSPopup TableView TableViewCell TableViewCellDelegate TableViewDataSource TableViewDelegate TeleportPortalObject TextAlertPopup TextArea TextAreaDelegate TextGameObject TextInputDelegate TextStyleSection TimerTriggerGameObject TopArtistsLayer TransformTriggerGameObject TriggerControlGameObject TriggerEffectDelegate TutorialLayer TutorialPopup UIButtonConfig UILayer UIObjectSettingsPopup UIOptionsLayer UISaveLoadLayer UISettingsGameObject URLCell URLViewLayer UT_hash_bucket UT_hash_handle UT_hash_table UndoObject UpdateAccountSettingsPopup UploadActionDelegate UploadActionPopup UploadListPopup UploadMessageDelegate UploadPopup UploadPopupDelegate UserInfoDelegate UserListDelegate VideoOptionsLayer WorldLevelPage WorldSelectLayer hash<ghc::filesystem::path> kmMat3 kmPlane kmVec2 kmVec3 operator""_spr code exempls: #include #include #include #include "cocos2d.h" #include #include #include #include using namespace geode::prelude; class $modify(LinkHandlerModification, MenuLayer) { bool init(){ if(!MenuLayer::init()) return false; auto socials = this->getChildByID("social-media-menu"); if (socials) { socials->setPosition(242, -15); } auto facebook = socials->getChildByID("facebook-button"); facebook->setPosition(-21.4, 32); auto twitter = socials->getChildByID("twitter-button"); twitter->setPosition(5.6, 32); auto youtube = socials->getChildByID("youtube-button"); youtube->setPosition(31.5,32); auto twitch = socials->getChildByID("twitch-button"); twitch->setPosition(57.3, 32); auto discord = socials->getChildByID("discord-button"); discord->setPosition(83, 32); //reddit button!!!!! auto redditSprite = CCSprite::create("reddit-button.png"_spr); auto menuItem = CCMenuItemSpriteExtra::create(redditSprite, nullptr, this, menu_selector(LinkHandlerModification::redditOpen)); menuItem->setPosition(109,32.5); menuItem->setRotation(-90); menuItem->setContentSize(CCSize(25.5,25.5)); menuItem->setID("reddit-button"); menuItem->setNormalImage(redditSprite); redditSprite->setScale(0.975); socials->addChild(menuItem); bool hideMoreGames = Mod::get()->getSettingValue("hideMoreGames"); bool revertAccountPosition = Mod::get()->getSettingValue("revertProfileButton"); auto robtoplogo = socials->getChildByID("robtop-logo-button"); if (robtoplogo) { robtoplogo->setPosition(-198,31); } auto account = this->getChildByID("profile-menu"); bool robtopLogoHide = Mod::get()->getSettingValue("hideRobtopLogo"); auto accbtn = account->getChildByID("profile-button"); float accBtnSetting = Mod::get()->getSettingValue("whichSideProfileButton"); auto username = this->getChildByID("player-username"); if(account && !revertAccountPosition){ if(accBtnSetting == 0 && robtopLogoHide == true){ // Reset in order to attempt to fix icon account button accbtn->setPosition(27.5,29); accbtn->setContentSize(CCSize(55,58)); username->setPosition(93,12); account->setPosition(77,30); } else if(accBtnSetting == 1 && hideMoreGames == true){ // Reset in order to attempt to fix icon account button accbtn->setPosition(27.5,29); accbtn->setContentSize(CCSize(55,58)); account->setPosition(587,30); username->setPosition(479,12); } } // other settings auto logo = socials->getChildByID("robtop-logo-button"); if(logo){ logo->setVisible(!robtopLogoHide); } bool socialsHide = Mod::get()->getSettingValue("hideSocials"); auto sm2 = this->getChildByID("social-media-menu"); if(sm2){ sm2->setVisible(!socialsHide); if(socialsHide == false){ auto bottomMenu = this->getChildByID("bottom-menu"); if (bottomMenu) { bottomMenu->setPositionY(58); } } } auto moreGames = this->getChildByID("more-games-menu"); if(moreGames){ moreGames->setVisible(!hideMoreGames); } return true; } void redditOpen(CCObject* pSender) { cocos2d::CCApplication::sharedApplication()->openURL("https://www.reddit.com/r/geometrydash/"); } }; class $modify(CreatorLayer){ bool init(){ if(!CreatorLayer::init()) return false; auto buttons = this->getChildByID("creator-buttons-menu"); auto revert = Mod::get()->getSettingValue("revertCreatorPageChanges"); if(buttons && !revert){ // buttons is order by index auto featured = buttons->getChildByID("featured-button"); auto lists = buttons->getChildByID("lists-button"); auto paths = buttons->getChildByID("paths-button"); auto mappacks = buttons->getChildByID("map-packs-button"); auto search = buttons->getChildByID("search-button"); auto map = buttons->getChildByID("map-button"); auto daily = buttons->getChildByID("daily-button"); auto weekly = buttons->getChildByID("weekly-button"); auto event = buttons->getChildByID("event-button"); auto gauntlets = buttons->getChildByID("gauntlets-button"); auto create = buttons->getChildByID("create-button"); auto saved = buttons->getChildByID("saved-button"); auto scores = buttons->getChildByID("scores-button"); auto quests = buttons->getChildByID("quests-button"); auto versus = buttons->getChildByID("versus-button"); auto smallButtonContentSize = CCSize(50,50); auto smallButtonSpriteAnchorPoint = CCPoint(.8,.8); // all small buttons have the same size properties, but different positions. This just saves lines std::vector smallButtons = {featured, paths, mappacks, map, daily, weekly, event, gauntlets, scores, quests, versus}; for (auto &button : smallButtons) { if(button){ auto sprite = dynamic_cast(button->getChildren()->objectAtIndex(0)); if(sprite){ sprite->setScale(0.55); sprite->setAnchorPoint(smallButtonSpriteAnchorPoint); button->setContentSize(smallButtonContentSize); } } } //move them all if(featured) featured->setPosition(17.8, 117); if(lists) lists->setPosition(268, 215.6); if(paths) paths->setPosition(253, 117); if(mappacks) mappacks->setPosition(429, 117); if(search) search->setPosition(360.2, 215.6); if(map) map->setPosition(218.9, 155); if(daily) daily->setPosition(75.5,117); if(weekly) weekly->setPosition(134,117); if(gauntlets) gauntlets->setPosition(371.1, 117); if(create) create->setPosition(86.8, 215.6); if(saved) saved->setPosition(178.4, 215.6); if(scores) scores->setPosition(193, 117); if(quests) quests->setPosition(311.6, 117); if(event) event->setVisible(false); if(versus) versus->setVisible(false); if(map) map->setVisible(false); } return true; } }; class $modify(LevelSearchLayer){ bool init(int p1){ if(!LevelSearchLayer::init(p1)) return false; auto dontdochanges = Mod::get()->getSettingValue("revertSearchPageChanges"); if(!dontdochanges){ auto filtersTitle = this->getChildByID("filters-title"); auto quickSearchTitle = this->getChildByID("quick-search-title"); if(filtersTitle) filtersTitle->setVisible(false); if(quickSearchTitle) quickSearchTitle->setVisible(false); auto quickSearch = this->getChildByID("quick-search-menu"); auto quickSearchBg = this->getChildByID("quick-search-bg"); quickSearch->setPositionY(145); quickSearchBg->setPositionY(173); auto levelSearchBg = this->getChildByID("level-search-bg"); levelSearchBg->setContentSize(CCSize(365, 72)); levelSearchBg->setPositionY(274); auto searchMenu = this->getChildByID("search-button-menu"); auto searchButton = searchMenu->getChildByID("search-level-button"); auto userSearchButton = searchMenu->getChildByID("search-user-button"); if(searchButton) searchButton->setVisible(false); if(userSearchButton) userSearchButton->setVisible(false); auto largeSearchButtonCreate = CCSprite::create("search_long_button.png"_spr); auto sButton = CCMenuItemSpriteExtra::create(largeSearchButtonCreate, nullptr, this, menu_selector(LevelSearchLayer::onSearch)); auto label1 = CCLabelBMFont::create("Search Levels", "bigFont.fnt"); label1->setScale(0.4); label1->setPosition(78, 14); sButton->addChild(label1); sButton->setPosition(-91, 96); sButton->setID("cleanerMenu-search-level-button"); largeSearchButtonCreate->setScale(1.2); searchMenu->addChild(sButton); auto largeSearchUserButtonCreate = CCSprite::create("usersearch_long_button.png"_spr); auto sButton2 = CCMenuItemSpriteExtra::create(largeSearchUserButtonCreate, nullptr, this, menu_selector(LevelSearchLayer::onSearchUser)); auto label2 = CCLabelBMFont::create("Search Users", "bigFont.fnt"); label2->setScale(0.4); label2->setPosition(83, 14); sButton2->addChild(label2); sButton2->setID("cleanerMenu-search-user-button"); sButton2->setPosition(88, 96); largeSearchUserButtonCreate->setScale(1.2); searchMenu->addChild(sButton2); auto barbg = this->getChildByID("level-search-bar-bg"); barbg->setPosition(262.5, 290); barbg->setScale(1.475, 1); } return true; } }; class $modify(ProfilePage){ void loadPageFromUserInfo(GJUserScore* a2){ ProfilePage::loadPageFromUserInfo(a2); auto dontdochanges = Mod::get()->getSettingValue("revertProfileChanges"); auto mainLayer = dynamic_cast(this->getChildren()->objectAtIndex(0)); if(mainLayer && !dontdochanges){ auto mainProfileMenu = mainLayer->getChildByID("main-menu"); auto commentButton = mainProfileMenu->getChildByID("comment-button"); auto historyButton = mainProfileMenu->getChildByID("comment-history-button"); // handle mod-specific exceptions auto cvoltonUsernameButton = mainProfileMenu->getChildByID("cvolton.betterinfo/username-button"); auto geodeContributionsBadge = mainProfileMenu->getChildByID("geode-badge"); // button repositioning in mainProfileMenu if(commentButton){ auto sprite = dynamic_cast(commentButton->getChildren()->objectAtIndex(0)); if(sprite){ sprite->setScale(0.8); commentButton->setPosition(378, -232); } } if(historyButton) historyButton->setPosition(378, -141); if(m_leftArrow) m_leftArrow->setPositionX(34); if(m_rightArrow) m_rightArrow->setPositionX(386); auto bottomMenu = mainLayer->getChildByID("bottom-menu"); bottomMenu->setLayout( RowLayout::create() ->setGap(0.f) ->setGrowCrossAxis(true) ->setAxisAlignment(AxisAlignment::Center) ); bottomMenu->updateLayout(); // if(m_ownProfile){ // } else { // auto messageButton = bottomMenu->getChildByID("message-button"); // auto friendButton = bottomMenu->getChildByID("friend-button"); // auto blockButton = bottomMenu->getChildByID("block-button"); // auto myLevels = bottomMenu->getChildByID("my-levels-button"); // auto myLists =bottomMenu->getChildByID("my-lists-button"); // if(messageButton) messageButton->setPositionX(5.75); // if(friendButton) friendButton->setPositionX(38); // if(blockButton) blockButton->setPositionX(70.25); // if(myLevels) myLevels->setPositionX(280); // if(myLists) myLists->setPositionX(311); // } } // auto socialsMenu = mainLayer->getChildByID("socials-menu"); // auto youtubeButton = socialsMenu->getChildByID("youtube-button"); // auto twitterButton = socialsMenu->getChildByID("twitter-button"); // auto twitchButton = socialsMenu->getChildByID("twitch-button"); // if(youtubeButton && twitterButton && twitchButton){ // auto youtubeSprite = youtubeButton->getChildren()->objectAtIndex(0); // auto twitterSprite = twitterButton->getChildren()->objectAtIndex(0); // auto twitchSprite = twitchButton->getChildren()->objectAtIndex(0); // youtubeSprite->setScale(0.75); // twitterSprite->setScale(0.75); // twitchSprite->setScale(0.75); // youtubeButton->setPosition(-17, 105); // twitterButton->setPosition(-68, 105); // twitchButton->setPosition(-43, 105); // } // if(youtubeButton && twitchButton && !twitterButton){ // auto youtubeSprite = youtubeButton->getChildren()->objectAtIndex(0); // auto twitchSprite = twitchButton->getChildren()->objectAtIndex(0); // youtubeSprite->setScale(0.75); // twitchSprite->setScale(0.75); // youtubeSprite->setPosition(-30, 105); // twitchSprite->setPosition(-56, 105); // } // if(youtubeButton && !twitchButton && !twitterButton){ // auto youtubeSprite = youtubeButton->getChildren()->objectAtIndex(0); // youtubeSprite->setScale(0.75); // youtubeSprite->setPosition(-44, 105); // } // if(youtubeButton && !twitchButton && twitterButton){ // auto youtubeSprite = youtubeButton->getChildren()->objectAtIndex(0); // auto twitterSprite = twitterButton->getChildren()->objectAtIndex(0); // youtubeSprite->setScale(0.75); // twitterSprite->setScale(0.75); // youtubeSprite->setPosition(-30, 105); // twitterSprite->setPosition(-56, 105); // } // if(!youtubeButton && !twitchButton && twitterButton){ // auto twitterSprite = twitterButton->getChildren()->objectAtIndex(0); // auto twitchSprite = twitchButton->getChildren()->objectAtIndex(0); // twitterSprite->setScale(0.75); // twitterSprite->setPosition(-44, 105); // } } }; class $modify(GJGarageLayer){ bool init(){ if(!GJGarageLayer::init()) return false; auto dontdochanges = Mod::get()->getSettingValue("revertIconKitChanges"); if(!dontdochanges){ // omg we're finally back to 'this' calls auto shardsMenu = this->getChildByID("shards-menu"); auto colorButton = shardsMenu->getChildByID("color-button"); auto topLeftMenu = this->getChildByID("top-left-menu"); auto shopButton = topLeftMenu->getChildByID("shop-button"); if(shopButton) shopButton->setPositionX(493); if(colorButton) colorButton->setPosition(473.25, -12.5); //oh no, this is where the pain begins.... auto starsIcon = dynamic_cast(this->getChildByID("stars-icon")); auto starsLabel = dynamic_cast(this->getChildByID("stars-label")); auto moonsIcon = dynamic_cast(this->getChildByID("moons-icon")); auto moonsLabel = dynamic_cast(this->getChildByID("moons-label")); auto coinsIcon = dynamic_cast(this->getChildByID("coins-icon")); auto coinsLabel = dynamic_cast(this->getChildByID("coins-label")); auto userCoinsIcon = dynamic_cast(this->getChildByID("user-coins-icon")); auto userCoinsLabel = dynamic_cast(this->getChildByID("user-coins-label")); auto orbsIcon = dynamic_cast(this->getChildByID("orbs-icon")); auto orbsLabel = dynamic_cast(this->getChildByID("orbs-label")); auto diamondsIcon = dynamic_cast(this->getChildByID("diamonds-icon")); auto diamondsLabel = dynamic_cast(this->getChildByID("diamonds-label")); auto diamondShardsIcon = dynamic_cast(this->getChildByID("diamond-shards-icon")); auto diamondShardsLabel = dynamic_cast(this->getChildByID("diamond-shards-label")); // demons in garage auto demonsIcon = dynamic_cast(this->getChildByID("demons-icon")); auto demonsLabel = dynamic_cast(this->getChildByID("demons-label")); if(starsIcon) starsIcon->setPositionX(83); if(starsLabel) starsLabel->setPositionX(126); if(moonsIcon) moonsIcon->setPositionX(83); if(moonsLabel) moonsLabel->setPositionX(126); if(coinsIcon) coinsIcon->setPositionX(83); if(coinsLabel) coinsLabel->setPositionX(126); if(userCoinsIcon) userCoinsIcon->setPositionX(83); if(userCoinsLabel) userCoinsLabel->setPositionX(126); if(orbsIcon) orbsIcon->setPositionX(83); if(orbsLabel) orbsLabel->setPositionX(126); // second row if(diamondsIcon) { diamondsIcon->setPositionX(149); diamondsIcon->setPositionY(307); }; if(diamondsLabel) { diamondsLabel->setPositionX(184); diamondsLabel->setPositionY(307); } if(diamondShardsIcon) { diamondShardsIcon->setPositionX(149); diamondShardsIcon->setPositionY(292); } if(diamondShardsLabel) { diamondShardsLabel->setPositionX(184); diamondShardsLabel->setPositionY(292); } if(demonsIcon){ demonsIcon->setPositionX(149); demonsIcon->setPositionY(277); } // demons in garage if(demonsLabel){ demonsLabel->setPositionX(184); demonsLabel->setPositionY(277); } } return true; } }; ----- #include #include #include using namespace geode::prelude; class $modify(EditLevelLayer) { bool init(GJGameLevel* p0) { if (!EditLevelLayer::init(p0)) return false; auto optionsSprite = CCSprite::createWithSpriteFrameName("GJ_optionsBtn02_001.png"); auto optionsButton = CCMenuItemSpriteExtra::create(optionsSprite, this, menu_selector(MenuLayer::onOptions)); optionsButton->setID("game-settings-button"_spr); auto menu = this->getChildByID("back-menu"); menu->addChild(optionsButton); menu->updateLayout(); return true; } }; class $modify(LevelInfoLayer) { bool init(GJGameLevel* p0, bool p1) { if (!LevelInfoLayer::init(p0, p1)) return false; CCNode* menu; CCMenuItemSpriteExtra* optionsButton; if (Mod::get()->getSettingValue("use-settings-rope")) { auto optionsSprite = CCSprite::create("settingsRope_001.png"_spr); optionsButton = CCMenuItemSpriteExtra::create(optionsSprite, this, menu_selector(MenuLayer::onOptions)); optionsButton->setSizeMult(1); optionsButton->useAnimationType(MenuAnimationType::Move); optionsButton->m_destPosition = CCPoint{0, -8.f}; optionsButton->setPositionX(-40.f); menu = this->getChildByID("garage-menu"); menu->addChild(optionsButton); } else { auto optionsSprite = CCSprite::createWithSpriteFrameName("GJ_optionsBtn02_001.png"); optionsButton = CCMenuItemSpriteExtra::create(optionsSprite, this, menu_selector(MenuLayer::onOptions)); menu = this->getChildByID("back-menu"); auto backBtn = menu->getChildByID("back-button"); menu->insertAfter(optionsButton, backBtn); } menu->updateLayout(); optionsButton->setID("game-settings-button"_spr); return true; } }; ----- #include #include #include #include using namespace geode::prelude; class $modify(SaveBtnEditor, EditorUI) { bool init(LevelEditorLayer* editorLayer ) { if (!EditorUI::init(editorLayer)) return false; // make a button that says save auto buttonSprite = CircleButtonSprite::create(CCLabelBMFont::create("Save", "bigFont.fnt"), CircleBaseColor::Green, CircleBaseSize::Small); auto saveBtn = CCMenuItemSpriteExtra::create( buttonSprite, this, menu_selector(SaveBtnEditor::onSaveBtn) ); saveBtn->setID("save_button"_spr); // menu to add button to (either settings or undo menu if betteredit is here) auto menu = getSaveMenu(); if (menu != nullptr) { menu->addChild(saveBtn); menu->updateLayout(); } return true; } void onSaveBtn(CCObject* target) { // make save confirmation popup createQuickPopup( "Save", "Save the level?", "NO", "YES", [&](auto, bool btn2) { if (btn2) { // create editor pause layer then save using editor pause menu auto editorPauseLayer = EditorPauseLayer::create(this->m_editorLayer); if (editorPauseLayer == nullptr) { FLAlertLayer::create( "ERROR", "Failed to save level.", "It's joever." )->show(); return; } editorPauseLayer->saveLevel(); FLAlertLayer::create( "SUCCESS", "Saved the level.", "OK" )->show(); } } ); } // Gets menu for save button from editor UI or returns nullptr if none was found // returns undo-menu if betteredit is present, otherwise returns settings menu CCNode* getSaveMenu() { auto menu = Loader::get()->getLoadedMod("hjfod.betteredit") ? this->getChildByID("undo-menu") : this->getChildByID("settings-menu"); if (menu == nullptr) { FLAlertLayer::create( "ERROR", "Failed to load savebtn menu :(", "It's joever" )->show(); } return menu; } // Gets save button from editor UI or returns nullptr if none was found CCNode* getSaveBtn() { auto menu = getSaveMenu(); // if the menu is null then obviously there wont be a save button there so return null if (menu == nullptr) { return nullptr; } return menu->getChildByID("save_button"_spr); } void showUI(bool p0) { EditorUI::showUI(p0); // check playtest no ui (thanks gddocs!) bool playtestNoUI = GameManager::sharedState()->getGameVariable("0046"); if (!playtestNoUI) { // don't fuck with visibility if playtest no ui is disabled return; } auto saveBtn = getSaveBtn(); if (saveBtn != nullptr) { saveBtn->setVisible(p0); } } }; ---- /** * Include the Geode headers. */ #include /** * Required to modify the MenuLayer class */ #include /** * Brings cocos2d and all Geode namespaces * to the current scope. */ using namespace geode::prelude; /** * Allows you to modify the MenuLayer */ class $modify(MenuLayer) { bool init() { if(!MenuLayer::init()) return false; // Gets the social-media-menu child from the MenuLayer auto socialmediamenu = this->getChildByID("social-media-menu"); // Gets the robtop button child from the socialmediamenu auto robtoplogo = socialmediamenu->getChildByID("robtop-logo-button"); // Makes the robtop logo invisible robtoplogo->setVisible(false); // Gets the twitch button child from the socialmediamenu auto twitchbutton = socialmediamenu->getChildByID("twitch-button"); // Gets the discord button child from the socialmediamenu auto discordbutton = socialmediamenu->getChildByID("discord-button"); // Gets the youtube button child from the socialmediamenu auto youtubebutton = socialmediamenu->getChildByID("youtube-button"); // Gets the facebook button child from the socialmediamenu auto facebookbutton = socialmediamenu->getChildByID("facebook-button"); if (Mod::get()->getSettingValue("switch-discord-twitch")) { // Sets the position to X: 128, Y: 39.6 discordbutton->setPosition(128, 39.6); // Finally sets the twitch button to X: 99, Y: 39.6 twitchbutton->setPosition(99, 39.6); // Lowers the scale of the socialmediamenu socialmediamenu->setScale(0.9); // Sets the position to X: 9, Y: -15 socialmediamenu->setPosition(9, -15); // Sets the Y position of the youtube button to 39.6 youtubebutton->setPositionY(39.6); // Sets the Y position of the facebook button to 39.6 facebookbutton->setPositionY(39.6); return true; } else { twitchbutton->setPosition(128, 39.6); discordbutton->setPosition(99, 39.6); // Lowers the scale of the socialmediamenu socialmediamenu->setScale(0.9); // Sets the position to X: 9, Y: -15 socialmediamenu->setPosition(9, -15); // Sets the Y position of the youtube button to 39.6 youtubebutton->setPositionY(39.6); // Sets the Y position of the facebook button to 39.6 facebookbutton->setPositionY(39.6); return true; } } }; ----- #include #include #include #include #include #include using namespace geode::prelude; int getGamemodeAsInt(PlayerObject* player) { if (player->m_isShip) return 1; if (player->m_isBall) return 2; if (player->m_isBird) return 3; // ufo if (player->m_isDart) return 4; // wave if (player->m_isRobot) return 5; if (player->m_isSpider) return 6; if (player->m_isSwing) return 7; return 0; // cube } void debLog(std::string str) { //if (Mod::get()->getSettingValue("DEBUG")) std::cout << str << std::endl; } bool cmpint(int first, int second, std::string lockSetting) { return ((first != second) && Mod::get()->getSettingValue(lockSetting)); } bool cmpfloat(float first, float second, std::string lockSetting) { return ((first != second) && Mod::get()->getSettingValue(lockSetting)); } bool placeCheckpointNextFrame = false; auto lastChk = std::chrono::high_resolution_clock::now(); class $modify(PlayLayer) { void postUpdate(float dt) { PlayLayer::postUpdate(dt); // skip everythin if not in practice mode if (!PlayLayer::m_isPracticeMode) return; // skip everything if the mod isn't enabled if (!Mod::get()->getSettingValue("enabled")) return; // see if it's been some amount of seconds auto now = std::chrono::high_resolution_clock::now(); // difference between now and last checkpoint time (seconds) auto diff = std::chrono::duration_cast(now - lastChk).count(); if (placeCheckpointNextFrame && diff >= Mod::get()->getSettingValue("min-delay") && !this->m_player1->m_isDashing) { lastChk = std::chrono::high_resolution_clock::now(); PlayLayer::markCheckpoint(); } else if (placeCheckpointNextFrame && this->m_player1->m_isDashing) debLog("player is dashing - cant place"); else if (placeCheckpointNextFrame) debLog("hasnt been long enough (" + std::to_string(diff) + ")"); if (diff >= Mod::get()->getSettingValue("max-delay") && !this->m_player1->m_isDashing) { debLog("been too long! (" + std::to_string(diff) + ")"); lastChk = std::chrono::high_resolution_clock::now(); PlayLayer::markCheckpoint(); } else if (diff >= Mod::get()->getSettingValue("max-delay")) debLog("been too long BUT PLAYER IS DASHING :despair:"); placeCheckpointNextFrame = false; } }; class $modify(GJBaseGameLayer) { int gamemode = getGamemodeAsInt(this->m_player1); float speed = this->m_player1->m_playerSpeed; float size = this->m_player1->m_vehicleSize; // for things that have hooks -------------------------------------------------------------------------- void toggleDualMode(GameObject * p0, bool p1, PlayerObject * p2, bool p3) { if (Mod::get()->getSettingValue("dual")) placeCheckpointNextFrame = true; GJBaseGameLayer::toggleDualMode(p0, p1, p2, p3); } void flipGravity(PlayerObject* p0, bool upsideDown, bool somethingThatsAlwaysFalse) { if (Mod::get()->getSettingValue("gravity")) placeCheckpointNextFrame = true; GJBaseGameLayer::flipGravity(p0, upsideDown, somethingThatsAlwaysFalse); } void reverseDirection(EffectGameObject* p0) { if (Mod::get()->getSettingValue("direction")) placeCheckpointNextFrame = true; GJBaseGameLayer::reverseDirection(p0); } // for things that don't have hooks ------------------------------------------------------------------- void update(float dt) { GJBaseGameLayer::update(dt); if (cmpint(gamemode, getGamemodeAsInt(this->m_player1), "gamemode")) placeCheckpointNextFrame = true; if (cmpfloat(speed, this->m_player1->m_playerSpeed, "speed")) placeCheckpointNextFrame = true; if (cmpfloat(size, this->m_player1->m_vehicleSize, "size")) placeCheckpointNextFrame = true; // update things gamemode = getGamemodeAsInt(this->m_player1); speed = this->m_player1->m_playerSpeed; size = this->m_player1->m_vehicleSize; } }; // enabled toggle! // this kinda breaks with betterpause because for some reason it forces the settings sprite scale to 0.6f // but i hope nobody will notice class $modify(MyPauseLayer, PauseLayer) { void onAutoCheckpointSettings(CCObject* object) { geode::openSettingsPopup(Mod::get()); } // for some reason every single fucking time i add my button to ANY of the menus it BREAKS // the layout so instead i'm going to hardcode the positions!!!! void customSetup() { PauseLayer::customSetup(); if (!Mod::get()->getSettingValue("pause-layer-btn")) return; auto winSize = CCDirector::sharedDirector()->getWinSize(); auto ccmenu = CCMenu::create(); ccmenu->setPosition(CCPoint{ 0, 0 }); ccmenu->setID("settings-button-menu"_spr); auto* settingsButtonSprite = CCSprite::create("logo.png"_spr); settingsButtonSprite->setScale(0.25f); auto settingsBtn = CCMenuItemSpriteExtra::create( settingsButtonSprite, this, menu_selector(MyPauseLayer::onAutoCheckpointSettings) ); settingsBtn->setID("settings-button"_spr); // hardcoded positions! auto padding = 20; auto btnRadius = settingsBtn->getContentSize().height / 2; auto offset = padding + btnRadius; settingsBtn->setPosition(CCPoint{ winSize.width - offset, offset }); ccmenu->addChild(settingsBtn); this->addChild(ccmenu); } }; ---- #include #include #include #include #include #include #include #include #include #include #include #include #include #include using namespace geode::prelude; // TODO // - chest background // - chest platforms (in the basement) // - compatibility with other mods // - define constants? // - ensure there is no crashes // - gauntlet colors // - leaderboard highlight color // - level loading play button background // - level name and description inputs backgrounds // - level share description // - lists progress bars // - map packs progress bars // - platformer controls settings background // - shop colors // - split into files? // - text? const ccColor3B getColorByName(std::string_view const key) { return Mod::get()->getSettingValue(key); } const int ccc3Btoint(const ccColor3B& color) { return color.r << 16 | color.g << 8 | color.b << 0; }; const ccColor3B intToCcc3B(int color) { auto r = static_cast((color & 0xff0000) >> 16); auto g = static_cast((color & 0x00ff00) >> 8); auto b = static_cast((color & 0x0000ff) >> 0); return {.r = r, .g = g, .b = b}; }; const ccColor3B darken(const ccColor3B& color) { auto hex = ccc3Btoint(color); switch (hex) { case 0x00FF00: return getColorByName("normal-mode-bar"); case 0x00FFFF: return getColorByName("practice-mode-bar"); case 0xBF723E: return getColorByName("icon-set-bg"); case 0xA1582C: return getColorByName("even-list-item-bg"); case 0x9C552A: return getColorByName("even-list-item-thin-bg"); case 0x824021: return getColorByName("comment-bg"); case 0xC2723E: return getColorByName("odd-list-item-bg"); case 0x904F27: return getColorByName("odd-list-item-thin-bg"); case 0x00388D: return getColorByName("level-search-bg"); case 0x002762: return getColorByName("level-search-bar-bg"); case 0x6C99D8: return getColorByName("level-search-bar-font"); case 0x002E75: return getColorByName("quick-search-bg"); case 0x00245B: return getColorByName("difficulty-filters-bg"); case 0x001F4F: return getColorByName("length-filters-bg"); default: return color; } }; const int darken(const int color) { return ccc3Btoint(darken(intToCcc3B(color))); } const ccColor4B darken(const ccColor4B& color) { ccColor3B color3B = {.r = color.r, .g = color.g, .b = color.b}; auto a = color.a; auto darkened = darken(color3B); return {.r = darkened.r, .g = darkened.g, .b = darkened.b, .a = a}; }; void darkenNode(CCRGBAProtocol* rgbaNode) { rgbaNode->setColor(darken(rgbaNode->getColor())); } class $modify(CustomColorsGJCommentListLayer, GJCommentListLayer) { static GJCommentListLayer* create(BoomListView * p0, char const* p1, cocos2d::ccColor4B p2, float p3, float p4, bool p5) { auto commentListLayer = GJCommentListLayer::create(p0, p1, p2, p3, p4, p5); darkenNode(commentListLayer); return commentListLayer; }; }; class $modify(CustomColorsCommentCell, CommentCell) { void draw() { if (auto c = getChildOfType(this, 0)) { darkenNode(c); } if (auto background = this->getChildByIDRecursive("background")) { darkenNode(typeinfo_cast(background)); } CommentCell::draw(); }; void updateBGColor(int p0) { CommentCell::updateBGColor(darken(p0)); } }; class $modify(CustomColorsCCLayerColor, CCLayerColor) { void draw() { darkenNode(this); CCLayerColor::draw(); }; }; class $modify(CustomColorsLevelSearchLayer, LevelSearchLayer) { bool init(int p0) { if (!LevelSearchLayer::init(p0)) { return false; } if (auto bg = this->getChildByIDRecursive("level-search-bg")) { darkenNode(typeinfo_cast(bg)); } if (auto bg = this->getChildByIDRecursive("level-search-bar-bg")) { darkenNode(typeinfo_cast(bg)); } if (auto bg = this->getChildByIDRecursive("quick-search-bg")) { darkenNode(typeinfo_cast(bg)); } if (auto bg = this->getChildByIDRecursive("difficulty-filters-bg")) { darkenNode(typeinfo_cast(bg)); } if (auto bg = this->getChildByIDRecursive("length-filters-bg")) { darkenNode(typeinfo_cast(bg)); } if (auto bar = this->getChildByIDRecursive("search-bar")) { if (auto placeholder = getChildOfType(bar, 0)) { darkenNode(typeinfo_cast(placeholder)); } } return true; }; }; class $modify(CustomColorsLevelInfoLayer, LevelInfoLayer) { bool init(GJGameLevel * p0, bool p1) { if (!LevelInfoLayer::init(p0, p1)) { return false; } if (auto bar = this->getChildByIDRecursive("normal-mode-bar")) { if (auto sprite = getChildOfType(bar, 0)) { darkenNode(typeinfo_cast(sprite)); } } if (auto bar = this->getChildByIDRecursive("practice-mode-bar")) { if (auto sprite = getChildOfType(bar, 0)) { darkenNode(typeinfo_cast(sprite)); } } return true; }; }; class $modify(CustomColorsInfoLayer, InfoLayer) { bool init(GJGameLevel * p0, GJUserScore * p1, GJLevelList * p2) { if (!InfoLayer::init(p0, p1, p2)) { return false; } if (auto bar = this->getChildByIDRecursive("desc-background")) { darkenNode(typeinfo_cast(bar)); } return true; }; }; class $modify(CustomColorsPauseLayer, PauseLayer) { static PauseLayer* create(bool p0) { auto pauseLayer = PauseLayer::create(p0); if (auto bar = getChildOfType(pauseLayer, 0)) { if (auto sprite = getChildOfType(bar, 0)) { darkenNode(typeinfo_cast(sprite)); } } if (auto bar = getChildOfType(pauseLayer, 1)) { if (auto sprite = getChildOfType(bar, 0)) { darkenNode(typeinfo_cast(sprite)); } } return pauseLayer; }; }; class $modify(CustomColorsLevelPage, LevelPage) { static LevelPage* create(GJGameLevel * p0) { auto levelPage = LevelPage::create(p0); if (auto bar = getChildOfType(levelPage, 0)) { if (auto sprite = getChildOfType(bar, 0)) { darkenNode(typeinfo_cast(sprite)); } } if (auto bar = getChildOfType(levelPage, 1)) { if (auto sprite = getChildOfType(bar, 0)) { darkenNode(typeinfo_cast(sprite)); } } return levelPage; }; }; // TODO: not implemented in Geode apparently // class $modify(CustomColorsGJScoreCell, GJScoreCell) { // void draw() { // darkenNode(getChildOfType(this, 0)); // GJScoreCell::draw(); // }; // void updateBGColor(int p0) { GJScoreCell::updateBGColor(darken(p0)); } // }; CCMenu* settingsBtnMenu = nullptr; struct ModSettingsPopup : public CCObject { void openSettings(CCObject* _obj) { openSettingsPopup(Mod::get()); }; }; $execute { listenForSettingChanges( "floating-settings-button", +[](bool floatingSettingsBtnEnabled) { if (floatingSettingsBtnEnabled) { settingsBtnMenu = CCMenu::create(); auto winSize = CCDirector::sharedDirector()->getWinSize(); auto sprite = CCSprite::createWithSpriteFrameName( "GJ_optionsBtn_001.png"); sprite->setScale(0.6); ModSettingsPopup s; auto settingsBtn = CCMenuItemSpriteExtra::create( sprite, &s, menu_selector(ModSettingsPopup::openSettings)); settingsBtn->setPosition({-((winSize.width / 2) - 25), 0}); settingsBtn->setSizeMult(1.2f); settingsBtn->setOpacity(128); settingsBtn->setZOrder(-10000); settingsBtnMenu->addChild(settingsBtn); CCScene::get()->addChild(settingsBtnMenu); SceneManager::get()->keepAcrossScenes(settingsBtnMenu); } else { SceneManager::get()->forget(settingsBtnMenu); } }); } $on_mod(DataSaved) { Mod::get()->setSettingValue("floating-settings-button", false); } ---- #include #include #include #include #include #include #include using namespace geode::prelude; bool toggle = false; CCSprite* box; class Flashlight_Btn { public: void flashlight_toggle(CCObject*); }; void Flashlight_Btn::flashlight_toggle(CCObject*) { if (toggle){ toggle = false; box->setDisplayFrame(CCSpriteFrameCache::sharedSpriteFrameCache()->spriteFrameByName("GJ_checkOff_001.png")); } else { toggle = true; box->setDisplayFrame(CCSpriteFrameCache::sharedSpriteFrameCache()->spriteFrameByName("GJ_checkOn_001.png")); } } class $modify(LevelInfoLayer) { bool init(GJGameLevel* level, bool first) { bool result = LevelInfoLayer::init(level,first); // adds code AFTER execution auto director = CCDirector::sharedDirector(); auto size = director->getWinSize(); // -> cuz its a pointer CCLabelBMFont* fl_text = CCLabelBMFont::create("FL", "goldFont.fnt"); if (toggle){ box = CCSprite::createWithSpriteFrameName("GJ_checkOn_001.png"); } else { box = CCSprite::createWithSpriteFrameName("GJ_checkOff_001.png"); } auto button = CCMenuItemSpriteExtra::create(box, this, menu_selector(Flashlight_Btn::flashlight_toggle)); // this shows its in the garagelayer, (current layer) auto menu = CCMenu::create(); menu->setPosition({size.width/2 + 96.5f,size.height/2 - 76}); fl_text->setPosition({size.width/2 + 211,size.height/2 + 13}); menu->setScale(0.6f); menu->addChild(button); fl_text->setScale(0.5f); addChild(fl_text); addChild(menu); return result; } }; class $modify(EditLevelLayer) { bool init(GJGameLevel* level) { bool result = EditLevelLayer::init(level); // adds code AFTER execution auto director = CCDirector::sharedDirector(); auto size = director->getWinSize(); // -> cuz its a pointer CCLabelBMFont* fl_text = CCLabelBMFont::create("FL", "goldFont.fnt"); if (toggle){ box = CCSprite::createWithSpriteFrameName("GJ_checkOn_001.png"); } else { box = CCSprite::createWithSpriteFrameName("GJ_checkOff_001.png"); } auto button = CCMenuItemSpriteExtra::create(box, this, menu_selector(Flashlight_Btn::flashlight_toggle)); // this shows its in the garagelayer, (current layer) auto menu = CCMenu::create(); menu->setPosition({size.width/2 + 96.5f,size.height/2 - 76}); menu->setScale(0.6f); menu->addChild(button); fl_text->setScale(0.5f); fl_text->setPosition({size.width/2 + 211,size.height/2 - 32}); addChild(fl_text); addChild(menu); return result; } }; class $modify(LevelSelectLayer) { bool init(int first) { bool result = LevelSelectLayer::init(first); // adds code AFTER execution auto director = CCDirector::sharedDirector(); auto size = director->getWinSize(); // -> cuz its a pointer CCLabelBMFont* fl_text = CCLabelBMFont::create("FL", "goldFont.fnt"); if (toggle){ box = CCSprite::createWithSpriteFrameName("GJ_checkOn_001.png"); } else { box = CCSprite::createWithSpriteFrameName("GJ_checkOff_001.png"); } auto button = CCMenuItemSpriteExtra::create(box, this, menu_selector(Flashlight_Btn::flashlight_toggle)); // this shows its in the garagelayer, (current layer) auto menu = CCMenu::create(); menu->setPosition({size.width/2 + 96.5f,size.height/2 - 136}); menu->setScale(0.6f); menu->addChild(button); fl_text->setScale(0.5f); fl_text->setPosition({size.width/2 + 211,size.height/2 - 92}); addChild(fl_text); addChild(menu); return result; } }; class $modify(PlayLayer) { CCSprite* m_flashlight; bool init (GJGameLevel* level, bool first, bool second) { bool results = PlayLayer::init(level, first, second); m_fields->m_flashlight = CCSprite::create("flashlight.png"_spr); if (m_player1->m_isPlatformer){ toggle = false; // checks if its a platformer and if it is to toggle off || will rework later } if (toggle) { m_fields->m_flashlight->setOpacity(0); m_fields->m_flashlight->setScale(2); CCNode* node = reinterpret_cast(getChildren()->objectAtIndex(1)); CCLayer* layer = reinterpret_cast(node->getChildren()->objectAtIndex(1)); std::string flashlight_string = "Flashlight Max %: " + std::to_string(Mod::get()->getSettingValue("max-percent")) + "%"; CCLabelBMFont * flashlight_max = CCLabelBMFont::create(flashlight_string.c_str(), "bigFont.fnt"); flashlight_max->setScale(0.4); flashlight_max->setPosition({83,10}); flashlight_max->setOpacity(45); layer->setZOrder(41); layer->addChild(m_fields->m_flashlight,1000); log::info("count: {}", node->getChildren()->count()); if (Mod::get()->getSettingValue("display-max")) { if (!Mod::get()->getSettingValue("always-dark")) { addChild(flashlight_max); } } } return results; } void postUpdate(float first) { PlayLayer::postUpdate(first); auto director = CCDirector::sharedDirector(); auto size = director->getWinSize(); int flashlight_opacity = 0; if (toggle) { m_fields->m_flashlight->setPosition({m_player1->getPositionX() + 31, m_player1->getPositionY() - 10}); if (Mod::get()->getSettingValue("always-dark")) { int flashlight_opacity = PlayLayer::getCurrentPercentInt() * 84.3; if (flashlight_opacity < 253) { m_fields->m_flashlight->setOpacity(flashlight_opacity); } } else { flashlight_opacity += PlayLayer::getCurrentPercentInt() * ((2.55f * Mod::get()->getSettingValue("max-opacity")) / Mod::get()->getSettingValue("max-percent")); if (flashlight_opacity <= (2.55 * Mod::get()->getSettingValue("max-opacity")) - 2) { m_fields->m_flashlight->setOpacity(flashlight_opacity); } else { // m_fields->m_flashlight->setOpacity((2.55 * Mod::get()->getSettingValue("max-opacity")) - 3); } } } } }; ---- #include #include #include #include #include #include using namespace geode::prelude; /* below code is adapted from alphalaneous' happy textures mod. per github licensing rules, alphalaneous' happy textures repo assumes the ARR (all rights reserved) license as there are no other licenses in the happy textures repo. however, i have been granted explicit permission/consent by alphalaneous themself to re-use their code. proof: https://discord.com/channels/911701438269386882/911702535373475870/1206674252896542790 minecraft.ttf font provided by @bitzelyt on twitter: https://twitter.com/bitzelyt/status/1351621941443125255 massive thanks to yellowcat98 for recommending the sprite font builder application, or which this project would not have been possible. all rights for the original minecraft font goes to mojang. -- erymanthus | raydeeux */ bool s_isInCreateTextLayers = false; class $modify(GJBaseGameLayer) { void createTextLayers(){ s_isInCreateTextLayers = true; GJBaseGameLayer::createTextLayers(); s_isInCreateTextLayers = false; } }; class $modify(CCSpriteBatchNode) { bool initWithTexture(CCTexture2D* texture, unsigned int capacity){ if(s_isInCreateTextLayers && texture == CCTextureCache::sharedTextureCache()->addImage("gjFont18.png", false)){ return CCSpriteBatchNode::initWithTexture(CCTextureCache::sharedTextureCache()->addImage("gjFont18.png"_spr, false), capacity); } return CCSpriteBatchNode::initWithTexture(texture, capacity); } }; class $modify(CCLabelBMFont) { static CCLabelBMFont* createBatched(const char* str, const char* fntFile, CCArray* a, int a1){ if(strcmp(fntFile, "gjFont18.fnt") == 0){ fntFile = "gjFont18.fnt"_spr; } return CCLabelBMFont::createBatched(str, fntFile, a, a1); } }; class $modify(GameManager) { const char* getFontTexture(int val){ if(val > 58){ val = 59; } loadFont(val); if(val != 18){ CCString* str = CCString::createWithFormat("gjFont%02d.png", val); return str->getCString(); } return "gjFont18.png"_spr; } void loadFont(int val){ if(val > 58){ val = 59; } if(val != m_loadedFont){ if(m_loadedFont != 18){ CCTextureCache::sharedTextureCache()->removeTextureForKey(CCString::createWithFormat("gjFont%02d.png", m_loadedFont)->getCString()); } if(val == 18){ CCTextureCache::sharedTextureCache()->addImage("gjFont18.png"_spr, false); } else { CCTextureCache::sharedTextureCache()->addImage(CCString::createWithFormat("gjFont%02d.png", val)->getCString(), false); } } m_loadedFont = val; } };

Assistants

Popular assistants made by the community

Geode SDK