In my scripts, I make extensive use of coroutines to handle complex tasks. For example, here's my abbreviated "navigate" function that moves the player to a destination, handling any unexpected events as they arise (eg aggro mobs, closed doors, etc.)
And then I have various triggers to detect what interrupted us and resume the coroutine.
This works really well, except now I have a giant monolithic plugin, and I'd like to break it up. For example, I'd like to bundle navigate along with its triggers into a separate navigator plugin that can be used via CallPlugin.
The problem with this is that CallPlugin just doesn't seem to play nicely with coroutine.yield. What I want is to be able to write code like:
But what happens is that CallPlugin returns as soon as navigate hits the first coroutine.yield, so do_something_at_destination happens right away. It seems that each plugin runs in its own separate lua interpreter, so there's no way for coroutines to communicate across plugin boundaries.
I tried getting around this with callbacks - eg, passing a command for navigate to execute only once it's actually finished, but that quickly devolved into a mess. For example:
This pattern only works if navigate is *guaranteed* to yield. But, if it can maybe return without yielding (because eg we were already at the destination to begin with), then the callback gets called before CallPlugin returns, so the calling function yields and never resumes. You can have navigate return a value to indicate whether it completed without yielding, but then you lose the ability to return some other useful value. And you end up with extra boilerplate around every call to navigate.
Any thoughts? I think what I'd really like is a CallPluginSynchronous or something like that that will only return when the target function is completely finished, but not if it just yields temporarily.
function navigate(room_id, command)
while true do
if tonumber(gmcp("room.info").num) == tonumber(room_id) then
break
end
EnableTriggerGroup("travel_group", true)
local interrupted_reason = coroutine.yield()
EnableTriggerGroup("travel_group", false)
-- handle various interrupted_reason values
if interrupted_reason == "combat" then
...
elseif ...
...
end
Execute("mapper resume")
end
end
And then I have various triggers to detect what interrupted us and resume the coroutine.
This works really well, except now I have a giant monolithic plugin, and I'd like to break it up. For example, I'd like to bundle navigate along with its triggers into a separate navigator plugin that can be used via CallPlugin.
The problem with this is that CallPlugin just doesn't seem to play nicely with coroutine.yield. What I want is to be able to write code like:
...
-- navigate to our destination
CallPlugin(navigator_id, navigate, destination)
-- CallPlugin blocks until we're at our destination
do_something_at_destination()
...
But what happens is that CallPlugin returns as soon as navigate hits the first coroutine.yield, so do_something_at_destination happens right away. It seems that each plugin runs in its own separate lua interpreter, so there's no way for coroutines to communicate across plugin boundaries.
I tried getting around this with callbacks - eg, passing a command for navigate to execute only once it's actually finished, but that quickly devolved into a mess. For example:
...
-- navigate to our destination
CallPlugin(navigator_id, navigate, destination, "original_plugin resume")
-- wait for "original_plugin resume" command to resume us
coroutine.yield()
do_something_at_destination()
...
This pattern only works if navigate is *guaranteed* to yield. But, if it can maybe return without yielding (because eg we were already at the destination to begin with), then the callback gets called before CallPlugin returns, so the calling function yields and never resumes. You can have navigate return a value to indicate whether it completed without yielding, but then you lose the ability to return some other useful value. And you end up with extra boilerplate around every call to navigate.
Any thoughts? I think what I'd really like is a CallPluginSynchronous or something like that that will only return when the target function is completely finished, but not if it just yields temporarily.