Execute ConVarQueryFinished if client disconnects #1384
Conversation
So people passing handles to the extra data can close them, adds a new return value to check if this happened
There was a problem hiding this comment.
This all looks sane to me. I'll leave it open for a bit in case any one else has any comments on the use of -1 (I saw a bit on Discord this morning.) I think the only real risk here is SMAC's convar checks, so as long as that's not going to start banning people when getting the value here I'm happy!
|
It might be worth exposing a feature capability so that plugins that want or need to require this can know if it would ever be called. |
Co-authored-by: Asher Baker <asherkin@limetech.io>
|
What happened here? |
Oopsie, pulled into here on accident, let me see if I can clean it up |
There was a problem hiding this comment.
I agree we should handle this case, but the only avenue the client (readas: script caller) has to reconcile this is to stay on the QueryCookie. When we return 0 that still leaves the initial issue present when there's multiple inflight cases. It's like you're in prison, have two people with the name Wyatt, and get two callbacks for Wyatt but don't know who's clothes are who. You can certainly guess, but you're going to be wrong half the time (and more with the more callbacks outstanding).
core/ConVarManager.cpp
Outdated
| { | ||
| cell_t ret; | ||
|
|
||
| pCallback->PushCell(0); |
There was a problem hiding this comment.
Good catch, it looks like it should be available as query.cookie.
There was a problem hiding this comment.
This is a good point, but I'm not sure how the cookie is needed? I added the value but a more clear explanation rather than an analogy would be appreciated, thanks
So people passing handles to the extra data can close them, adds a new return value to check if this happened