Closed enusbaum closed 4 years ago
Researching BEGIN_POLLING()
with a test module revealed that btuinj()
is called in both BEGIN_POLLING() and after the polling routine is executed setting the users status
to 192.
This change has been checked in with e83ef98240d609c4c79bdb2f29fdf7075ffb4d5f
While this action is more in line with how MBBS/Worldgroup works, it did not solve the issue. Research continues.
More thoughts from @enusbaum in Discord today:
@enusbaum majormud does a simulated pause for things like movement and apparently exit it does this by kicking off task using BEGIN_POLLING() which gets called VERY rapidly (like, 50,000/sec) and it measures how much time has passed before a certain event gets triggered (actually exiting, moving, etc.) something in the function passed to this routine isn't firing correctly
@jnfisher @enusbaum so is mmud registering a callback by passing a function ptr to BEGIN_POLLING, and then within that internal module function it has gameplay logic? Or am I way off base conceptually
@enusbaum nope, that's it
Fixed in build 101420-2
Fixed by #194
Overview:
There's an issue with MajorMUD (1.11g -> 1.11p) where once you create your character and enter the game, while some commands work, other commands that have deferred execution do not.
Details
There are some actions in MajorMUD that use a delayed/deferred execution method in order to simulate things such as movement delay, being over encumbered, etc.
It appears to accomplish this, MajorMUD kicks off a BEGIN_POLLING() on the Channel after a user tries to move, exit, or perform one of these actions. The issue appears that the follow-up (delayed) execution is not being completed within BEGIN_POLLING(), causing the user to be suck in a waiting state.
I can confirm that BEGIN_POLLING() does start on the specified channel and appears to be executing, but something with the state or logic within the routine isn't firing the deferred event properly.