Scripting language for schedules, instead of specific task actions

[AngryCarrot789]

Is there an existing feature request for this?

• [X] I have searched the existing issues before opening this feature request.

Describe the feature you would like to see.

It would be cool if there was a 4th option for tasks called "Script", which could be a functional approach to a task payload.

Our server uses schedules a lot, and sometimes it's a little tedious creating a task for each command and delay (although you can run multiple commands in a single task, but no delay in-between them)

Describe the solution you'd like.

This would be a script example of restarting the server:

command("broadcast Restarting in 3 seconds...")
// maybe could add time unit parsing, e.g. 3s or 3000ms?
delay(3)
command("kick * Restarting Server!")
power("restart") // "start", "stop", "restart", "terminate"

I'm not sure how the "continue on failure" state would be handled, maybe something similar to a C label?

// script code...
failure:
// delay(), command() or power() could have failed, so handle that case here
command("broadcast Restart failed!")

Additional context to this request.

No response

[BurritoWrapped]

At that point just implement running bash scripts for schedules

[Thibugs]

At that point just implement running bash scripts for schedules lmao

Giving bash scripting to users would be a bad idea, and a potential security risk, so having a simple scripting language (that doesn't need to be much) would be a better IMO.

[Boy132]

What would be the benefit of the scripting language over the "normal" tasks? Also, how would users know which commands are available and how to use them? This would require some sort intellisense and/ or good documentation. Overall I don't think the needed amount of work is justified for this.

[AngryCarrot789]

It would be more convenient to write a script, rather than have to go through the New Task UI to create a single action. And also, if you want to insert a task somewhere in the middle of the schedule, you have to remove everything up until that point and then insert the new task (which is not convenient what so ever).

And by using scripts, you could use things like loops, e.g. to loop until the server has started, and once it has then you do something, e.g. if the script language was LUA:

while (not isServerRunning()) do 
  sleep(2)
end
-- run custom tasks here
command("run this command once the server is actually running")

But yeah there would have to be some documentation; isServerRunning would return true only when the Start button in the console is greyed out, as apposed to isServerStarted. There doesn't need to be any code completion, the schedules tab can just provide a basic text editor

[Boy132]

It would be more convenient to write a script, rather than have to go through the New Task UI to create a single action. And also, if you want to insert a task somewhere in the middle of the schedule, you have to remove everything up until that point and then insert the new task (which is not convenient what so ever).

I think it would be better to improve the UI/ UX of schedules and tasks. (e.g. #4670, #4160) For some users a script would definitely be more convenient but most would probably prefer the task UI because it's simpler and easier to understand.

Ultimately that's up to Matthew to decide. But he said in the past that he would prefer specific actions rather than a generic script. (https://github.com/pterodactyl/panel/issues/3008#issuecomment-881925795)

Maybe #1346 would be a good compromise. This would allow to create schedules in json first and then import them, for example.

There doesn't need to be any code completion, the schedules tab can just provide a basic text editor

That would rise the question how to deal with syntax errors etc.

[KermMartian]

I'm 25-year user of *nix, and a power user running their own server, who used to have a set of bash scripts that interacted with my server running in a screen session: restarted the server, reset/regenerated a resource-mining world by issuing commands to Multiverse, sent messages to warn of an impeding shutdown, periodically saving, etc. I have trouble reconciling that with:

Giving bash scripting to users would be a bad idea, and a potential security risk

It would be great to be able to configure Pterodactyl to permit bash scripting on schedules that can issue commands directly to the server. Failing that, some sufficiently powerful scripting as discussed above could be sufficient, although to provide all the expressiveness that some scripts would need (loops, conditions, variables, random numbers, functions, etc.), you'd essentially be re-inventing the wheel.