|
Notes |
|
|
(0002836)
|
|
Coruja
|
|
18-06-15 22:55
|
|
it's not really an problem, but just an client update question
on hiding/stealth success, the server apply statf_hidden flag on char, so it's been hidden on server-side. But on client-side, instead update the client screen immediately to make the char appear as hidden, sphere will mark the client to update only on next tick (a tick is an 1s timer that keep running on infinite loop to execute some internal actions like timers management, char status update, NPC AI, etc)
I just changed this single line to make hiding update the client immediately instead use this 'queue' and now its working fine |
|
|
|
(0002837)
|
|
XuN
|
|
19-06-15 11:14
|
|
As said in 0002516 the problem is CChar::OnTick() all of this problems are related to changes made in build 2287 or 2289, can't remember right now.
So in this case the UpdateModeFlag() is not the problem itself but another undesired effect caused by the changes on that commit, just like the stats problem from ticket 0002516. |
|
|
|
(0002840)
|
|
Coruja
|
|
20-06-15 05:49
|
|
yep it makes sense, taking a better look at revision 2287, these status updates was done by OnTickStatusUpdate(), which previously OnTick() was calling it at every single tick (10x per second) and now it's called only 1x per second
so maybe just changing OnTickStatusUpdate() priority can solve this (these) problems
but the question is: do we really need call it 10x more times? Maybe it's better just avoid these excessive OnTickStatusUpdate() calls and send a single update packet directly on action success (hiding, poison, etc)
thats only my opinion, I dont see any problem in revert this change and make OnTickStatusUpdate() calls like it was before. I just reduced these excessive calls to this function to make OnTick() more "lightweight" :P |
|
|
|
(0002841)
|
|
XuN
|
20-06-15 08:30
(edited on: 20-06-15 08:31) |
|
The problem here are not the updates, you got them fixed if we talk about them. But the problem is another:
You have to finish your cast in 1.2 seconds, then you'll get next tick in the next second and in the following tick (another second after, instead of 0.2) you'll finish the spell, same for skills, etc. The most 'visual' way to replicate this is to cast some stat's spells, bless, strenght...
Your idea is nice, certainly reducing the ticks to one per sec would reduce the CPU usage heavily, but will produce problems like this.
The same will happen with regens, imagine your RegenHits should make you regen your HP each 0.3 seconds, it will be done each 1.0 and you'll loose regens.
IMO this should be working for now like it worked before, at least until Ben finally moved to his new city and Torfo move everything to GIT so he start working on SQL saves on a different branch and I continue with SQL timers (ticking over SQL instead of running all sectors each tick) so this will reduce the ticks to only the needed.
And about OnTickStatusUpdate only called when needed ... actually the update for HP is sent only based on ini's option and the flags update everytime, however the code must be processed anyway for both situations in every tick, although it was designed to work alone and update periodically any changes, to avoid missing calls over the code, using the method you say will make it some lightweight, but take in count that this is also used to update HP ... you may disable this (not remove totally yet) and try to force the update in each flag change for poison, invul, etc and the hits update in the regens/combat (it should be done, maybe force in the Stat_SetVal() ?), dunno right now what will be the best without looking at the code.
|
|
|
|
|
|
A simple .hits 50 have delay :/, around 500ms. |
|