View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002514SphereServerexecutable - genericpublic12-06-15 16:4927-06-15 12:39
ReporterRizz 
Assigned ToCoruja 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version0.56c Nightly 
Summary0002514: Delay between the message "you have hidden yourself well" and hiding process
DescriptionIf you use the Hiding skill and get the success, after the message "you have hidden yourself well" you have to wait one seconds before to become hidden.
TagsNo tags attached.
Nightly VersionAutomated (specify build number)
Experimental FlagsNone
Option FlagsNone
Internal Build Number2338
Attached Files

- Relationships
related to 0002516resolvedCoruja Delay between spells and effect 

-  Notes
(0002836)
Coruja (developer)
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 (developer)
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 (developer)
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 (developer)
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.

(0002849)
Shamino (reporter)
22-06-15 21:29

A simple .hits 50 have delay :/, around 500ms.

- Issue History
Date Modified Username Field Change
12-06-15 16:49 Rizz New Issue
13-06-15 12:29 XuN Relationship added related to 0002516
18-06-15 22:55 Coruja Note Added: 0002836
18-06-15 22:55 Coruja Status new => resolved
18-06-15 22:55 Coruja Fixed in Version => 0.56c Nightly
18-06-15 22:55 Coruja Resolution open => fixed
18-06-15 22:55 Coruja Assigned To => Coruja
19-06-15 11:14 XuN Note Added: 0002837
19-06-15 11:14 XuN Status resolved => feedback
19-06-15 11:14 XuN Resolution fixed => reopened
19-06-15 11:14 XuN Status feedback => new
20-06-15 05:49 Coruja Note Added: 0002840
20-06-15 08:30 XuN Note Added: 0002841
20-06-15 08:31 XuN Note Edited: 0002841 View Revisions
22-06-15 21:29 Shamino Note Added: 0002849
27-06-15 12:39 XuN Status new => resolved
27-06-15 12:39 XuN Resolution reopened => fixed


Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker