Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Streams #6715

Open
1 task done
MissingReports opened this issue May 21, 2024 · 1 comment
Open
1 task done

Streams #6715

MissingReports opened this issue May 21, 2024 · 1 comment
Labels
enhancement Feature request, an issue about something that could be improved, or a PR improving something. up for debate When the decision is yet to be debated on the issue in question

Comments

@MissingReports
Copy link

MissingReports commented May 21, 2024

Suggestion

The only thing that is close to streams right now is "filtering", which barely even works since you can only have one line. Streams aren't required but they do for sure make life easier

Streams have alot of features but the only thing that would fit skript are:
Mapping: Example loop entitytypes mapped as ["%entitytype input%"] <-- filters entitytypes to strings
Filtering: Exists
AnyMatch: Example if all players matches at least [{bal::%uuid of player input%} >= 1000}] <-- True if there's at least one player with 1000 coins, false otherwise
AllMatch: Same as AnyMatch but all have to match
Sorting: This would require a compare function which does Integer.compare(..). Example set {_sorted::*} to {_list::*} sorted using [compare(length of input-2, length of input-1)] <-- Returns {_list::*} from the longest to the shortest

I feel like the current predicate system isn't really that efficient since they only allow one line, a good way to solve it is to allow functions or custom sections to be passed in like SkriptReflect proxy system. There should also be the old system for quicker streaming

here are 2 examples on how this could be done

set {_filtered} to all players where [run myFunction]

function myFunction(o: object) :: boolean:
    # Filtering predicate
   if all:
      {bal::%{_o}'s uuid%} >= 1000
      {kills::%{_o}'s uuid%} >= 10
      {playtime::%{_o}'s uuid%} >= 100000
   then:
      return true
   return false
set {_filtered::*} to all players where:
   if all:
      {bal::%player input's uuid%} >= 1000
      {kills::%player input's uuid%} >= 10
      {playtime::%player input's uuid%} >= 100000
   then:
      return true
   return false

Something that makes Streams unique is that you can stack multiple streams in one line, how this could be done is when u use a stream it actually returns a stream and u have to mark it with to list at the end. This might be annoying to some people so it'd be nice if you can disable it from the Skript config

Example:

set {_balances::*} to all players sorted using [compare({bal::%uuid of input-2%}, {bal::%uuid of input-1%})] mapped as [{bal::%uuid of player input%}] to list <-- Creates a list of all balances of **online** players in descending order

The way this would be done right now is like this

loop all players:
    set {_bal} to {bal::%loop-value's uuid%}
    if {_prev} isn't set:
        if loop-counter + 1 > size of all players:
            add {_bal} to {_balances::*}
            continue
    if {_prev} > {_bal}:
        add {_prev} to {_balances::*}
        add {_bal} to {_balances::*}
    else:
        add {_bal} to {_balances::*}
        add {_prev} to {_balances::*}
    delete {_bal}

I know there's descending order in Skript, but I wanted to keep it simple. In some cases for example you want to sort pets from legendary to common, the only way is to do it manually with a loop

Why?

Saves some lines and makes code more readable in some cases

Other

No response

Agreement

  • I have read the guidelines above and affirm I am following them with this suggestion.
@sovdeeth
Copy link
Member

I think single uses of maps/custom sorting is wonderful (we have existing suggestions for these too) but I am strongly against the chaining described. The example one liner is literally a worst case scenario for the parser and for code readability, and I would not support adding it in that state.

@sovdeeth sovdeeth added enhancement Feature request, an issue about something that could be improved, or a PR improving something. up for debate When the decision is yet to be debated on the issue in question labels May 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature request, an issue about something that could be improved, or a PR improving something. up for debate When the decision is yet to be debated on the issue in question
Projects
None yet
Development

No branches or pull requests

2 participants