search

enebo / Purugin

Ruby Minecraft Plugin support on top of bukkit
238 stars 32 forks source link

Allow non-plugins to include Purugin::Task #39

Closed elight closed 11 years ago

elight commented 11 years ago

This was driving me nuts because I wanted to create a simple DSL for chaining "task" creation. This fix allows for it.

(Extremely silly) DSL can be seen here: https://github.com/elight/purugin_server/blob/master/plugins/on_login_experiment.rb

elight commented 11 years ago

What do you think about adding TaskChain to Purugin?

Otherwise, the nested or iterative semantics necessary to chain tasks together seems a bit cumbersome. Granted, it's just a sugar coating. ;-)

elight commented 11 years ago

I can submit a PR for it.

enebo commented 11 years ago

I just glanced at the impl. It might be (or might not be) nicer if one task submits the next on completion? I am trying to think through this a bit and both mechanisms are not perfect. In yours there is a mild assumption of some time guarantee. If I run something at 5 and then +10 (or 15) the first might execute a 7 and the second may still execute at 15. It is sort of an optimistic scheduling. In what I am suggesting the first may execute at 7 and then the second would execute at a minimum of 17.

My suggestion also has interesting failure-mode considerations. If first task fails should the second execute. It would be a possibility, but is that desirable? Am I turning simple timings into a workflow API? :)

Lack of determinsm in how these execute makes both valid mechanism, but which one is what a user would prefer?

elight commented 11 years ago

I like it. This sounds like a plug-in unto itself. Considering that I am interested in tinkering with AI in Minecraft, a workflow plug-in would be incredibly helpful.

On Mon, Feb 18, 2013 at 1:39 PM, Thomas E Enebo notifications@github.com wrote:

I just glanced at the impl. It might be (or might not be) nicer if one task submits the next on completion? I am trying to think through this a bit and both mechanisms are not perfect. In yours there is a mild assumption of some time guarantee. If I run something at 5 and then +10 (or 15) the first might execute a 7 and the second may still execute at 15. It is sort of an optimistic scheduling. In what I am suggesting the first may execute at 7 and then the second would execute at a minimum of 17. My suggestion also has interesting failure-mode considerations. If first task fails should the second execute. It would be a possibility, but is that desirable? Am I turning simple timings into a workflow API? :)

Lack of determinsm in how these execute makes both valid mechanism, but which one is what a user would prefer?

Reply to this email directly or view it on GitHub: https://github.com/enebo/Purugin/pull/39#issuecomment-13736338

enebo commented 11 years ago

ah cool. Now we just need a fun example of workflow in the game :)

elight commented 11 years ago

Any sort of simple decision making system/state machine would do.

A minecraft subway system? ;-)

On Mon, Feb 18, 2013 at 1:57 PM, Thomas E Enebo notifications@github.com wrote:

ah cool. Now we just need a fun example of workflow in the game :)

Reply to this email directly or view it on GitHub: https://github.com/enebo/Purugin/pull/39#issuecomment-13737130

elight commented 11 years ago

Yeah, I suspected that tasks weren't scheduled in an absolute sense. Minecraft is largely single-threaded around an event loop, I presume? I saw that "Tasks" are just "Runnables". Guessing they're scheduled by Minecraft to approximate the requested timing.

So, yes, tricky proposition no matter how you slice it. I just opted for something simple as part of an experiment. I knew that I didn't want to nest blocks. The jQuery-like approach made sense.