Patch 80 Fix.

[Ghost6922112269]

^ Closes #29 .

[Owyn]

> // Patch 80.04 has bug where it sends this twice in row with timeout of 120 millieseconds between each, Here this check to prevent the requesting contract again then it cause it to cancel the first. Ps, It doesn't happen always, but 80% of the time.

yea, it'd cancel the first (scheduled one, but not currently being executed one), with 100% identical 2nd one, which in result would only postpone the whole task by 120ms, nothing else.

this check can't theoritically change anything in described situation cuz currently if it is receives full_inven message 2nd time 120ms after the 1st one it'd just cancel previous task via line: clearTimeout(timer);

and then via next line:

timer = setTimeout(cleanup_by_dismantle, rng(ACTION_DELAY_FISH_START)); set a timer between 1.3 sec to 2.6 sec randomly which are both much higher than 120 ms (0.12 sec) that you mentioned, so it won't affect anything which is currently running, but just postpone whole dismantle task by 120ms

[Ghost6922112269]

The thing is... when the server sends that 2nd message, the function already be having the dismantle open during that, which means It's already in contract, Sending that means the script will attempt to re-request the contract again, that would force the client to send C_CANCEL CONTRACT as it's already in contract then here it instead bugs out because it will receive S_CANCEL_CONTRACT at the same exact moment, sometimes even it will send "You're busy" sysmsg instead.

[Ghost6922112269]

I have saw the other function and the clearTimeout, but that ain't enough, because the window of dismantling is already open. -- With the simple check I've added, it will just not re-request the contract if it been already requested and the dismantling window is already open. Also, It's not 100% identical, because the contract ID would be different, as the C_CANCEL_CONTRACT has been called already, and server did accept it and sent S_CANCEL_CONTRACT for that id, so script won't be able to re-use the old contract id, maybe that's what causing it to bug, as matter of fact? 🤔 - Edit: That's 120 is fixed for me because I have stable ping, I think, I have just asked someone else and he got different results, so if the ping is higher/got ping spike/etc then that will happen, I guess. 🤷‍♀️

[Owyn]

when the server sends that 2nd message, the function already be having the dismantle open during that,

so it's few seconds at least? can you say fure sure how much time usually passes from 1st inven_full to 2nd one? you can use PacketsLogger or any other like that ( https://github.com/Owyn/PacketsLogger or https://github.com/Owyn/debug-logger/ ) to log exact time, so that way maybe just adding 1 or 2 seconds to the timer would fix it.

Sending that means the script will attempt to re-request the contract again

it shouldn't tho

if(!vContractId)
{
    mod.toServer('C_REQUEST_CONTRACT', 1, {type: 89});
}

it only requests a contract if there currently isn't one, and cancels it only when it's fully out of fish after dismantling

S_CANCEL_CONTRACT for that id, so script won't be able to re-use the old contract id

script hooks S_CANCEL_CONTRACT with used by it id and if that happens it'd cancel all tasks and try to throw the rod all over again from start while making a notice in the proxy chat about it, log of proxy chat would also help btw when the issue occurs

[Ghost6922112269]

how much time usually passes from 1st inven_full to 2nd one?

[20:11:58:667]  <-              S_INVEN
[20:11:58:680]  <-              S_INVEN

It took 13ms.

script hooks S_CANCEL_CONTRACT with used by it id and if that happens it'd cancel all tasks and try to throw the rod all over again

That's where it bugs though, the server sends S_CANCEL_CONTRACT then the dismantle stops and attempt to throw rod and client will receive the same system message all over again and it will bug out and stop.

it shouldn't tho

Speaking of that, yeah, weird.. the log says crafted by proxy though. 🤔

log of proxy chat would also help btw when the issue occurs

I technically not allowed to share that, as it's not my log, I'm not the one who using the script, I've simply got ton of reports and logs from players and asking me to fix it, so I've read script and read logs, saw this is best simple and easy solution, some people already tested the fix and said it's working, If it was me who using the script then I would've gave logs from beginning along with the start of the pull-request. I just wanted to push this simple fix as I know you probably playing NA or RU then you don't have the patch 80 yet. ps, I don't think this would affect anything at all, really, I mean it's checking if you're currently having dismantling window open or not, then it acts according. ---- ps 2, Let me just re-correct a thing, Saying 120ms was a mistake, I forgot that it depends heavily on ping, I've been looking deeply into only 1 log, for that it just got stuck to my mind that it's fixed value.

script hooks S_CANCEL_CONTRACT with used by it id and if that happens it'd cancel all tasks and try to throw the rod all over again from start

Yeah, I know, but that doesn't happen, it just pauses with dismantling window open, or re-tries to throw rod then pauses and do nothing at all afterward, it took me couple of hours to figure out what was wrong exactly. Anyway, RU will get patch soon, so you may ignore this(close it) if you like and do your own magic later on, I just tried to help.

[Owyn]

S_INVEN

that's not it tho

we'r looking for S_SYSTEM_MESSAGE with SMT_CANNOT_FISHING_FULL_INVEN

That's where it bugs though, the server sends S_CANCEL_CONTRACT

why, and especially when, does it send that tho?

yea, RU is getting the patch on 3rd of April

I'll try increasing the timer by 1,5 sec now, maybe it'd help

[Ghost6922112269]

Oh, I read how much time passes between sInven, my bad.

[11:01:21:305]  <-              S_SYSTEM_MESSAGE    1200 6266 0600 4000 3400 3100 3300 3500 0000 
{"message":"@4135"}
[11:01:21:381]  <-              S_CAST_FISHING_ROD  1d00 b64e 0a45 1b00 0080 0000 01c3 7c5e c54c 16ad 4700 c0ad c471 2703 00
{"gameId":"","success":true,"loc":{"x":-3589.797607421875,"y":88600.59377,"z":-1389},"rodId":206705}
[11:01:21:417]  <-              S_CAST_FISHING_ROD  1d00 b64e 0a45 1b00 0080 0000 0000 0000 0000 0000 0000 0000 0071 2703 00
{"gameId":"","success":false,"loc":{"x":0,"y":0,"z":0},"rodId":206705}
[11:01:21:422]  <-              S_SYSTEM_MESSAGE    1200 6266 0600 4000 3400 3100 3300 3500 0000 
{"message":"@4135"}

avarage of 120ms (30 sample tests), but again, this with stable ping. Here's another one I have made while having 40 video stream running on 4k quality in background:

[11:52:40:541]  <-              S_SYSTEM_MESSAGE    1200 6266 0600 4000 3400 3100 3300 3500 0000 
{"message":"@4135"}
[11:52:41:974]  <-              S_SYSTEM_MESSAGE    1200 6266 0600 4000 3400 3100 3300 3500 0000 
{"message":"@4135"}

Around ~1.400 seconds.

why, and especially when, does it send that tho?

Why - Because when you already in contract (dismantle window open) then you request another contract without closing the current, the client by itself sends C_CANCEL_CONTRACT then the delay until it receives S_CANCEL_CONTRACT from server, I know... the script not supposed to request contract if there is already one, I just couldn't get to why here, so I just made a quick fix. 🤷‍♀️ When - It happens right after the dismantling window opens, it put 1 fish or two then here that occurs, The script does nothing, and no more fishes were put nor window closed.

I'll try increasing the timer by 1,5 sec now, maybe it'd help

Yeah, It will, Well, with my fix, I didn't want to increase any time, you know. As the default delay is already so big, I know human simulation, but... So with my fix I simply made a check if the dismantle window open and prevent the script from closing it from beginning, no delay increase, no core script affect, etc. But, It's your script, so no complains, you do what you want. 👌

yea, RU is getting the patch on 3rd of April

Sweet. (that means few more days of ton dms to be answered. 😩But that's fine, I guess. )

Feel free to close my pull-request without merging anytime btw, if want to.

[Lambda11]

new delay increase seems to be working fine after few days.