Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002391SphereServerexecutable - genericpublic23-08-14 02:3229-01-15 19:43
ReporterCoruja 
Assigned ToXuN 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version0.56c Nightly 
Summary0002391: Names showing wrong notoriety color on client login
DescriptionOn client login, all nearby chars names are sent to this client as 'blue', without check the real notoriety.
After some seconds, it will update (because NotoTimeOut setting on sphere.ini) and now it will show the correct notoriety
Steps To Reproduce1) Set invul=1 on any nearby char (FLAGS=04)
2) Logout
3) Login after 0000003:0000001 minute (or more)
4) This same char will be invul but the name color will be blue
5) Wait some seconds and now the npc notoriety will update to the correct color (invul = yellow)
Additional InformationUsing 21 aug 2014 build
TagsNo tags attached.
Nightly VersionAutomated (specify build number)
Experimental FlagsNone
Option FlagsNone
Internal Build Number
Attached Files

- Relationships

-  Notes
(0002418)
Ben (manager)
27-08-14 02:13

 I can't reproduce this one...
(0002419)
Feeh (developer)
27-08-14 02:30

 Any script that override notoriety?
(0002420)
Coruja (developer)
27-08-14 03:19

 to reproduce this you must logout and wait some time until sphere clear the "notoriety cache", after that if you login again, all npcs near will be blue and after some seconds it will be fixed to the correct color.
If logout/login too fast, this cant be reproduced because the client will already know the npc correct notoriety based on the "notoriety cache"

the only thing that I'm using related to NPC names is this:

[EVENTS e_all_npcs]
ON=@AfterClick
IF (<NPC> > 2) && (<NPC> < 10)
 LOCAL.Flags=<STRPOS 0 [ <LOCAL.ClickMsgText>>
 IF (<LOCAL.Flags> == -1)
  LOCAL.ClickMsgText=<LOCAL.ClickMsgText> the <JOB>
 ELSE
  LOCAL.ClickMsgText=<STRSUB 0 <LOCAL.Flags> <LOCAL.ClickMsgText>>the <JOB> <STRSUB <LOCAL.Flags> 0 <LOCAL.ClickMsgText>>
 ENDIF
ENDIF
MESSAGE @<LOCAL.ClickMsgHue>,,1 <LOCAL.ClickMsgText>
return 1
(0002422)
Ben (manager)
01-09-14 23:28

 still not able to reproduce... I logged out and waited 3 days and it showed invul right away.
(0002423)
darksun84 (reporter)
02-09-14 13:49

 i can't reproduce it too !
(0002465)
Ben (manager)
11-10-14 15:12

 Closing this as it can't be reproduced.
Possible that lag is causing the packet to arrive later?
(0002486)
Coruja (developer)
17-10-14 09:23

 today I found something interesting about this issue.. when I login using client 7.0.35 it works fine and all nearby npcs will be yellow (invul). But if logout, wait until sphere clear the notoriety list, and login again using client 5.0.2d this problem can be reproduced, all nearby npcs will be blue and will turn yellow only after 30 seconds when sphere updates the notoriety list

I'm trying to take a look at the code, but nothing found :/
(0002512)
XuN (developer)
26-10-14 08:21

 Try using NotoUpdate or NotoClear in @Login for this lower client, maybe its missing some packet?
(0002513)
Coruja (developer)
26-10-14 08:46

 strangely calling NotoClear manually it works fine

ON=@Login
FORCHARS
 NotoClear
ENDFOR

maybe we can change on source to make it call NotoClear by default? or if it's already called, just check if there's some timing problem
(0002514)
XuN (developer)
26-10-14 11:42

 try without forchars, NotoClear erases the Notoriety List on self, which stores the current NOTO of others. Anyway, it's already called... i'll take a deeper look.
(0002515)
Coruja (developer)
26-10-14 16:51

 without forchars it doesn't work.. I tested this last SVN change but the problem still occour :/

-maybe- we should call NotoSave_Update() before addPlayerStart() on CClientMsg.cpp? Or even inside addPlayerStart() but before the client load nearby characters
(0002516)
XuN (developer)
26-10-14 20:52

 That worths a try, move it above addPlayerStart( pChar ); in CClient::Setup_Start and test it.
(0002517)
Coruja (developer)
27-10-14 07:59
edited on: 27-10-14 08:04

 already tried to call NotoSave_Update() in every order, but none of them works

the only way I can get it working is calling NotoClear on all nearby chars. I have no idea why it occours, and even why this can fix it. But it works like magic :P


CWorldSearch AreaChars(m_pChar->GetTopPoint(), UO_MAP_VIEW_SIZE);
AreaChars.SetSearchSquare(true);
for (;;)
{
    CChar * pCharNear = AreaChars.GetChar();
    if ( ! pCharNear )
        break;
    pCharNear->GetChar()->NotoSave_Clear();
}
(0002520)
XuN (developer)
28-10-14 22:39

 In that case you can use pCharNear->NotoSave_Delete(pCharNear->NotoSave_GetID(this)); to only remove this character and not everyone.
(0002647)
Ben (manager)
18-01-15 21:55

 Did this ever get resolved?

- Issue History
Date Modified Username Field Change
23-08-14 02:32 Coruja New Issue
27-08-14 02:13 Ben Note Added: 0002418
27-08-14 02:30 Feeh Note Added: 0002419
27-08-14 03:19 Coruja Note Added: 0002420
01-09-14 23:28 Ben Note Added: 0002422
02-09-14 13:49 darksun84 Note Added: 0002423
11-10-14 15:12 Ben Note Added: 0002465
11-10-14 15:12 Ben Status new => closed
11-10-14 15:12 Ben Assigned To => Ben
11-10-14 15:12 Ben Resolution open => unable to reproduce
17-10-14 09:23 Coruja Assigned To Ben =>
17-10-14 09:23 Coruja Note Added: 0002486
17-10-14 09:23 Coruja Status closed => feedback
17-10-14 09:23 Coruja Resolution unable to reproduce => reopened
26-10-14 08:21 XuN Note Added: 0002512
26-10-14 08:46 Coruja Note Added: 0002513
26-10-14 08:46 Coruja Status feedback => new
26-10-14 11:42 XuN Note Added: 0002514
26-10-14 16:51 Coruja Note Added: 0002515
26-10-14 20:52 XuN Note Added: 0002516
27-10-14 07:59 Coruja Note Added: 0002517
27-10-14 08:04 Coruja Note Edited: 0002517 View Revisions
28-10-14 22:39 XuN Note Added: 0002520
18-01-15 21:55 Ben Note Added: 0002647
29-01-15 19:43 XuN Status new => resolved
29-01-15 19:43 XuN Fixed in Version => 0.56c Nightly
29-01-15 19:43 XuN Resolution reopened => fixed
29-01-15 19:43 XuN Assigned To => XuN

Copyright © 2000 - 2010 MantisBT Group
Powered by Mantis Bugtracker