TODO

[ShaneBeee]

If you wish to suggest something, please comment below.
I'll add it to the list.

Priorities:

HIGH = 🔴
MEDIUM = 🟠
LOW = 🟢

TODO:

• Other variable formats (such as SQL/Mongo/Maria/Etc) 🟢
• GUI creation of some sort (if possible) no plans on doing this
• "Zone" stuff (not sure all what there is) 🟢
• MetaData of items (Do we want to handle this just using BsonDocuments?!?!) 🟠
• Map markers 🟢
• Player skin stuff 🟢
• Revamp inventory click event (now that I have a better understanding of it) 🟠
• World Instances 🟢
• Disguise (Hytale has a command for this)
• NPC Attitudes

EVENTS:

• Figure out how to get the player in a chat event
  • Being that it's an Async event, this probably wont happen. Maybe a secondary event?

Regular Events:

ECS Events:

Component Events:

SECTIONS:

• For each loops 🟢

EFFECTS:

• Play particle (probably going to be convoluted, maybe use a section? No chained expressions)

EXPRESSIONS:

• ItemStack names/lore/etc (is that possible? It doesn't seem possible) 🟠
• Loop-iteration expression 🟠
• Block Rotation (this gotta be a thing yeah?)

CONDITIONS:

FIX:

PARSER:

• Fix deleting 2 things at a time (ie: delete {_a} and {_b} just says No effect matching 'delete {_a} and {_b}' was found) 🟠
• Fix errors sometimes cutting off the expression 🟠
  • Example code: inventory of blah
  • Error: no expression for 'invent' found
• Fix an issue in the parser where you can't have a space between two expressions 🔴
  • (PLEASE HELP)
  • (see [BUG] Can't use blank space between 2 expressions skript-parser#5)
• Sometimes the parser picks a converter when it doesn't need one. 🔴
  • Example: blah blah of %players/entities% in this scenario, passing an entity thru tries to convert it to a player

[ADESSFR2]

Here are some suggestions for the project:

• Iterate/loop through all items in a container
• Obtain a specific item from a specific slot (outside of events)
• Count the number of items of a specific type
• Check if the inventory contains a specific item (direct condition)
• Be able to create a vanilla GUI (I don't know how complex this is, or even if it's actually possible).

[ADESSFR2]

Another suggestion. (yes, I like contributing to this project.)

• Ability to remove/break/place a block
• Ability to remove/break/place a block at specific coordinates (break block in radius?)
• Perform actions above/below/in front of/behind a block that has been previously clicked or broken. As in the MC's skript.
• Ability to perform loops x times. _(e.g. loop 9 times or loop {list}?)
• Ability to perform loops with various radius (e.g. all players in radius %number% of %location%?)

I believe some of these things are already available but more complicated to develop.

Edit/Note from Shane:

• set/remove blocks is already available
• direction (above/below/north/south/east/west) are available. I wont be doing in front or behind (too complicated)
• loop x times is already available
• Ill add the players in radius x to my list

[ChicknTurtle]

Some suggestions:

• Get/set velocity of entities
• Play sounds
• Draw particles
• Create explosions (these seem to be a thing)

[TheHecateII]

Native SQL and NoSQL Storage Support

I would like to see built-in support for alternative storage types like SQL and NoSQL (specifically MongoDB) to provide good data management/retention out of the box.

1. SQL Integration

The original Skript project has lacked a clean, native SQL implementation for years. HySkript has the opportunity to bridge this gap from the start.

• Raw SQL Injection: Ability to inject SQL directly into the syntax by passing arguments. This is highly educational as it forces users to build and understand their own queries.
• Standardization: SQL queries are generally portable and work across PostgreSQL and MariaDB Btw, Mongo support uses its own query language which is very specific, whereas SQL is more standardized

2. NoSQL / MongoDB Integration

Since MongoDB uses BSON, it is a natural fit for Skript's object structure. However, MongoDB support requires its own specific queries as it differs significantly from SQL.

• We could take inspiration from the logic of MongoSK to handle document fields.
• Given that the project already handles JSON logic (as seen in JsonVariableStorage.java), implementing a BSON/MongoDB bridge would be very consistent with the current codebase.

3. Config

To ensure security, all connection strings and authentication details for SQL and NoSQL should be handled via the main configuration file (like config.sk).
This would act like a .env.local file, preventing users from accidentally exposing sensitive credentials (auth strings) directly in their scripts (e.g., in a on load event). Scripts would simply reference a "connection name" defined in the central config rather than hardcoding IPs and passwords.

[ShaneBeee]

I do like this idea, and I know it's been talked about/attempted by Skript many times over the years.
I'm going to add it to my list... but be warned, I have never touched anything to do with SQL/Mongo/Etc in my life, so it won't be a high priority for me.

That being said, we're always open to PRs, so if anyone else wants to attempt this, I'm open to it.

Thank you for the detailed description too.
And you're right, with JsonDatabase already handling Bson/Json, it probably wouldn't be all that difficult to add.