SolarStrike Software

In the function CPlayer:sleep() (classes/player.lua) I sugest we modify the exit condition of the while loop.

Currently we can force player to sleep by setting player.Sleeping=true, ex in a timer based function to detect other players but I havent found any way to continue again. By modifying the exit condition of the while loop we can force player to sleep and wake it up again, both by modifying player.Sleeping.
Regards
DX

The problem is we can't predict and cater for every condition that users might want to exit the function. But I admit it would be useful if we could use player:sleep because of it's ability to fight back. Although writing a function to respond to aggro while waiting is not that difficult, maybe we could add a time argument to sleep. Eg. player:sleep(10). Then you could do
That would sleep but fight back if attacked and check the player count every 10 seconds.

How does that sound?

Im using it, among other things, for bot to pause if a player gets close, ie I have a function triggered by a timer to do checks, when condition arises it puts bot to sleep, when condition clears it continues but bot will fight back while sleeping if attacked.

As the trigger/release is from a registered timer and length of sleep is undetermined I've found, in my general ignorance, manipulating the player.Sleeping the cleanest way, that way bot will wrap up waypoint movement and fight before sleeping.


By the way, another suggestion I've made (http://solarstrike.net/phpBB3/viewtopic ... 76a4795761) is about the event callbacks, I assumed that modifying the micromacro lib would be easiest way but it might be a job for the bot instead to enable a mechanisms for registering callbacks without messing up for other waypoint or userfunction scripts. Currently its an issue if more than one userfunction/waypoint wants to use ex. atExit, atPause, atResume or other callbacks.

-dx

I don't see why you couldn't have just made your own userfunction to deal with it instead of using the sleep function, that would be logical to me. Sleep isn't exactly what you wanted so make up what you do want using the sleep as a guideline.

Ofc I can, I can copy the sleep, rename it and modify the "true" to "self.XXX" with my own status variable but its kind of redundant - The reason I brought it up was that I thought it might have common interest to have a program controlled exit from sleep function in addition to the manual keyboard controlled.

If suggestion is not of interest Ill drop the thread.

-dx

dx876234 wrote:player.Sleeping the cleanest way, that way bot will wrap up waypoint movement and fight before sleeping.

I see, that's clever but not really necessary. If you just do a player:sleep() directly, it would then immediately respond to the aggro and fight anyway.

The problem with your idea of using self.XXX is that it can only be changed via a timed event which is not very practical for most users. My idea of player:sleep(time) is more easily implemented. I'll probably be adding it anyway seeing as it doesn't hurt to add it. I think that would be the easiest solution without complicating the code necessarily.

The problem is we can't predict and cater for every condition that users might want to exit the function.

Why not let the user provide the function that can determine, if bot should wake up from sleep?

SleepUntil(maxTime, wakeUpCondition)
...
while(self.Sleeping and not wakeUpCondition()) do

local hf_key_pressed = false;
...

Why can't you check your conditions outside of the sleep function? Eg.

Well my personal solution is now to make a CPlayer:sleep function in a userfunction that overrides the standard one.

The problem is we can't predict and cater for every condition that users might want to exit the function.

I agree, so my suggestion should have been phrased to insert a general mechanism to exit the sleep function, in my ignorance I thought the player.Sleeping was one such. As Jandrana pointed out another such is to have an option to provide a "exit function" to evaluate.

My argument was that since we have the player.Sleeping as an entry to sleep it would be natural to have it as an exit as well.

Adding a time to the sleep function is nice functionality, although not quite an answer to my suggestion as it is a specific exit from sleep function, not a general.

-dx