PDA

View Full Version : waitrt? and castrt? unreliable?



Eodus
08-13-2016, 04:32 PM
Is there any reason why waitrt? or waitcastrt? would suddenly become unreliable, essentially bypassing when in cast or physical roundtime?

Tgo01
08-13-2016, 04:38 PM
Is there any reason why waitrt? or waitcastrt? would suddenly become unreliable, essentially bypassing when in cast or physical roundtime?

Sometimes it might not wait for the entire roundtime, like for example if you're put into a 5 second roundtime it might only wait 4 seconds before the script moves on, but I don't think I've ever seen waitrt? or waitcastrt? just completely ignore a roundtime.

What is the code you are using what do you have a log of what's happening?

Eodus
08-13-2016, 04:58 PM
I don't keep any logs. Just echoing most of what I need to the console. What you're mentioning is pretty much exactly what I'm experiencing, though. It doesn't ignore the roundtime altogether, but it's definitely not accurate 100% of the time.

I have tried resetting the definitions of waitrt? & waitcastrt? to something along these lines (credit to authors of Bigshot):



def waitcastrt?
if (XMLData.cast_roundtime_end.to_f - Time.now.to_f + XMLData.server_time_offset.to_f) > 0
sleep((XMLData.cast_roundtime_end.to_f - Time.now.to_f + XMLData.server_time_offset.to_f + "0.6".to_f).abs)
end
end

def waitrt?
if (XMLData.roundtime_end.to_f - Time.now.to_f + XMLData.server_time_offset.to_f) > 0
sleep((XMLData.roundtime_end.to_f - Time.now.to_f + XMLData.server_time_offset.to_f + "0.6".to_f).abs)
end
end


But had even worse reliability with that for some reason.

Is there any way to ensure accuracy with these values?

Viekn
08-13-2016, 05:01 PM
Sometimes it might not wait for the entire roundtime, like for example if you're put into a 5 second roundtime it might only wait 4 seconds before the script moves on, but I don't think I've ever seen waitrt? or waitcastrt? just completely ignore a roundtime.

What is the code you are using what do you have a log of what's happening?

This happens to me a lot. I'm not smart, so I just figure it happens for a reason and let whatever script that is trying to perform an action try it 1-3 times while I'm still in RT before it finally get's processed.

Tgo01
08-13-2016, 05:13 PM
I don't keep any logs. Just echoing most of what I need to the console. What you're mentioning is pretty much exactly what I'm experiencing, though. It doesn't ignore the roundtime altogether, but it's definitely not accurate 100% of the time.

I have tried resetting the definitions of waitrt? & waitcastrt? to something along these lines (credit to authors of Bigshot):



But had even worse reliability with that for some reason.

Is there any way to ensure accuracy with these values?

I'm not sure why waitrt? doesn't always wait the full roundtime and I'm not sure there is a way to fix it.

I'm not sure what your code looks like but using things like dothistimeout or some sort of loop until your command is entered might be the way to go if your commands aren't going through because it's not waiting the full RT. Also if you're not already using fput instead of put would probably be the way to go.

Eodus
08-13-2016, 05:14 PM
This happens to me a lot. I'm not smart, so I just figure it happens for a reason and let whatever script that is trying to perform an action try it 1-3 times while I'm still in RT before it finally get's processed.

Well, I'm not the smartest either but I have been writing code for a long time, professionally. It's tough to build an effective logic tree when one can't trust the underlying data. The machine I'm running this on is a beast, so it's definitely not a resource consumption issue.

I've found in the past that sometimes infinite threads get left running (for whatever reason) and has resulted in some unexpected results to say the least. Ruby is brand new to me so I wouldn't know how to seek out these wandering unknown threads at the beginning of a script, but I always clear them before the script completes.

Could it be that runaway threads could be the cause of this? Now that I think of it, a reboot almost always resolves this issue... hmmmmm...

Eodus
08-13-2016, 05:23 PM
I'm not sure why waitrt? doesn't always wait the full roundtime and I'm not sure there is a way to fix it.

Could be an issue with runaway threads either at the Stormfront-level or stemming from my own terrible scripting practices.


I'm not sure what your code looks like but using things like dothistimeout or some sort of loop until your command is entered might be the way to go if your commands aren't going through because it's not waiting the full RT. Also if you're not already using fput instead of put would probably be the way to go.

I am using fput. Thank you. Solid advice for any newcomers. As for your other suggestions, I tried the loop option, essentially creating my own wait_for_rt() function something like this:



loop do

break if calculated_rt <= 0

pause 0.1

end


But that wound up running into even more issues. So... not sure what to do here. Has anyone effectively solved this problem?

Tgo01
08-13-2016, 05:25 PM
I'm not sure what the underlying issues are with waitrt? ending prematurely but I have noticed in both SF and WizardFE that sometimes your FE says you're out of RT but you're really not, could be an issue with the information the server sends to your FE not being in sync with what the server itself is doing.

But that's just a wild guess on my part.