Updating your own level causes a level with the same name to be uploaded rather than updating the current version.

Use Numba to speed up repetitive functions (such as get level). This will provide noticeable performance benefits of repetitive functions.

This will make the function slower the first time it's run but will speed up the later execution of same functions by an order of magnitude.

The functions all need to be switched to snake case to be easier on the eyes and be more consistent.

ok cvolton gdps is easy to install - just sets webservre and mysql. but how to install and setup gdpys v3? is there any guides?

It needs to be more verbose.

you read the title. try to add a texture pack manager. it would make a separate file (for example, packs) where you can store texture packs in. using an external program, you can switch between normal gd texture pack (resources folder) and other texture packs installed. lmk if needs more clarification.

There are too many unhandled errors.

Get levels handler does not respond with a response gd requires for gauntlets. This may be a small issue such as a missing arg as the supposed requirements for it a re fulfilled.

Idk I need it aaaaaaaaa

The current plugin system uses asyncio.run which was added in python 3.7. This will make GDPyS not work correctly in Python implementations such as PyPy.

Plugins need more functions like weekly, daily and more.

Add more guides, features, cheatless, just like master branch.

GDPyS is severely in need of a new caching system. Currently, there are ~4 individual caching systems in the classes that use them. This means that there are essentially identical implementations of caching repeated multiple times throughout the codebase. This means that if I were to want to make a change to the caching system, I would be required to implement that change 4 times. The caching system is just mixed with the rest of the code without any care or separation. The current way makes it hard to add more caches to speed up more actions.

However, there are more reasons than just code maintainability. Firstly, there is no cache limit. This means that stuff can keep on being added onto the cache, potentially causing the host to run out of memory. While this has not happened during testing, it can become a major issue of servers with large player bases and large databases.

Secondly, the current cache has no expiry date. This means that outdated cached data can stay on the server potentially forever (or until a server restart) if it were to be updated without consideration for cached data. This can be a major problem during surges of activity or really anytime.

Requirements for a new system.

• It is its own system, not integrated into any particular function.
• It preferably uses a class based design, meaning a new cache can just be created by doing something along the lines of Cache()
• There is a customisable limit to how many objects can be cached.
• It allows to retrieve objects by ID (such as getting user object from cache by using the account id).
• Cache can expire after a customisable amount of time. Checking for expired cache can be done during caching of an object or fetching of an object.

While playing with the requests module and GDPyS, I noticed that post args are urlencoded. Currently, the HTTP server does not attempt to urldecode the urlform. TODO: Investigate if this causes any issues with GD.

Potentially use dicts to achieve something similar to a switch statement in python. Benchmark to see how much it may speed up over if Type == 1 etc.

Currently it does no actions. Minor issue.

Listeners do not work at all.

Make docs that explain how to develop GDPyS plugins.

The wiki is old and outdated.

Create functions for plugins to use. This will allow for plugins to do server actions such as banning users.

I have not yet narrowed down what causes this issue. On my testing setup it has worked without failure but in other tests scores fail to submit.

Daily level does not show. This is to do with the getlevels handler not returning the special daily level response gd requires. Get daily level handler is working correctly.

Check user input further than is already done. This will include things such as: enforcing character limits server side, only allowing alphanumeric characters in usernames

Proposition

Frequently used functions that work with potentially decent amount of data (such as the dict -> gd str builders or http parsers) should be converted to Cython. This will provide a significant performance benefit with not a lot of work. Essentially free speed.

How will it work.

Cython works by converting near Python code into C, that can be compiled and ran. This grants it some of the benefits of a compiled language such as static typing and the prior mentioned speed. This will not affect I/O heavy operations as those are already asynced and gain no benefits from Cython as those mostly include waiting.

You could query the person's friends and then sort them for the friends leaderboards, and for global leaderboards query all the beaters and sort them by percent first and then by time of beating.

Use a separate mysql cursor for the Cron job. Since it's ran in a thread, it would be possible for a request to be sent while the job is running, causing issues such as the request fetching from a Cron job query.

The aim is to replace this ugly mess

Complete filters and clean up searchengine.py

Add metadata such as plugin name, author name and plugin description to plugins to be used for etc loading the plugin.

If someone mentions a user in a comment (eg @BruhMan) they will receive a message from GDPyS Bot that says the level name, level Id, comment content and the name of the person who mentioned the user. Make the amount of messages limited so people don't abuse this to spam people.

Since pretty much the beginning, the GDPyS project has been using the same class for its LRU cache. Now while it fits the purpose well, I was recently informed of a cool object in the collections library called deque. It takes any iterable (which includes dictionaries) and allows you to access them and also set the max size.

https://docs.python.org/3/library/collections.html#deque-objects

Here is the plan:

• Add more permission enums
• Add more permission checks when necessary
• Create an easy way to create privilege groups

maybe like discord.py cogs.

Should be a simple if statement fix.

This will make GDPyS a better option than other alternatives. If you could @RealistikDash, I would like to be assigned this issue.

When a level is rated, the cp values for the cached obj should be locally updated or even updated in the db,

GDPyS Newgrounds API

Use the Newgrounds API for songs rather than sending requests to GD servers. This will also allow us to also bypass songs banned on the official Geometry Dash server.

Execution

• Completely rewrite the addsongtodb function
• Use the Newgrounds API to fetch data to be added to the database
• Use the requests module to send the requests to the API.