Go to Page... |
Compatibility: | Update 6 (1.6.5) |
Updated: | 03/14/15 09:50 AM |
Created: | 04/09/14 02:05 PM |
Monthly downloads: | 114 |
Total downloads: | 17,782 |
Favorites: | 62 |
MD5: | |
Categories: | Discontinued & Outdated, Graphic UI Mods, Info, Plug-in Bars, Utility Mods |
File Name |
Version |
Size |
Uploader |
Date |
3.32 |
39kB |
GetBackYouPansy |
11/06/14 06:24 AM |
Comment Options |
Rashy |
View Public Profile |
Send a private message to Rashy |
Find More Posts by Rashy |
Add Rashy to Your Buddy List |
09/07/14, 11:57 AM | |
|
Not feeling any pressure All I've had to do so far is speculate wildly!
So if I'm understanding correctly, the updated values from char X are not written out to the relevant section of the saved vars file after you log out from Char X, but for other characters that does work? And is that dependent on being in a VR zone? If so (VR part aside), I begin to suspect that the player deactivate code in the addon is at fault - i.e. the new values are not being written out. You can inspect the model in game, if you really want to, using /script d(PL_TIMERS.timerData) That'll dump the values to chat, and if you then log out the same values (minus a few secs) should be written to the file. The assumption to check here is that the file is definitely being written. I know opening it in notepad++ makes that easy to check as it'll ask you every time if you switch from ESO to notepad++ after a change if want to reload it. Should the file mysteriously not get updated after logging out of character X, then the bug is almost certainly in the addon (here, if you're interested!)
Last edited by GetBackYouPansy : 09/07/14 at 11:58 AM.
|
|
GetBackYouPansy |
View Public Profile |
Send a private message to GetBackYouPansy |
Find More Posts by GetBackYouPansy |
Add GetBackYouPansy to Your Buddy List |
Rashy |
View Public Profile |
Send a private message to Rashy |
Find More Posts by Rashy |
Add Rashy to Your Buddy List |
GetBackYouPansy |
View Public Profile |
Send a private message to GetBackYouPansy |
Find More Posts by GetBackYouPansy |
Add GetBackYouPansy to Your Buddy List |
09/06/14, 06:51 AM | |
Forum posts: 1
File comments: 34
Uploads: 0
|
Maybe this will help you.
Looking at the saved variables...there's one difference. Character in VR Zone -> Moved to non-VR Zone duration = 691200 -> duration = 552960 So there's why I'm seeing the difference in the timers. Is the GetSmithingResearchLineTraitTimes() function bugged?
Last edited by Rashy : 09/06/14 at 06:59 AM.
|
|
Rashy |
View Public Profile |
Send a private message to Rashy |
Find More Posts by Rashy |
Add Rashy to Your Buddy List |
09/06/14, 06:38 AM | |
Forum posts: 1
File comments: 34
Uploads: 0
|
Yeah, the bug has popped up again...
One character in a non-VR zone and the other in a VR zone. GetTimeStamp() is returning the similar values for both characters. Verified that the saved variables are recording the same value seen on the screen. I'm puzzled. |
|
Rashy |
View Public Profile |
Send a private message to Rashy |
Find More Posts by Rashy |
Add Rashy to Your Buddy List |
09/05/14, 04:32 PM | |
|
Not necessarily, evidently it doesn't do what I thought, so I suspect it might only be true when you are in a VR dungeon or such. That's an aside though, the real tell would be the timestamps.
I guess just keep an eye on it and if the issue arises again it'd be interesting to see what GetTimeStamp() gives you. |
|
GetBackYouPansy |
View Public Profile |
Send a private message to GetBackYouPansy |
Find More Posts by GetBackYouPansy |
Add GetBackYouPansy to Your Buddy List |
09/05/14, 03:30 PM | ||
Forum posts: 1
File comments: 34
Uploads: 0
|
When running that script on 3 characters.. EP VR2 Character in DC VR Zone, I get false with correct epoch timestamp EP VR1 Character in EP Non-VR Zone, I get false with correct epoch timestamp EP Non-VR Character, I get false with correct epoch timestamp Shouldn't I be getting at least one true? |
|
|
Rashy |
View Public Profile |
Send a private message to Rashy |
Find More Posts by Rashy |
Add Rashy to Your Buddy List |
09/05/14, 12:59 PM | |
|
Stranger and stranger. I have a DC character who just hit VR1 so I will see if I can reproduce that at all if I go to the AD areas.
Edit: If you like, try this slash cmd on the two characters in the three possible situations (one non-veteran, one veteran in VR area and one veteran in non-VR area) /script d(IsUnitUsingVeteranDifficulty("player"),GetTimeStamp()) The value should be true/false (if VR is on) followed by the correct epoch timestamp (you can see the current timestamp here). You could also try /script d(FormatTimeSeconds(356521, 9, 0, 1)) Which should always give you "4 days 3 hours 2 minutes 1 second" It'd be interesting if either of those was wrong in the same situations as when your timers are wonky.
Last edited by GetBackYouPansy : 09/05/14 at 02:16 PM.
|
|
GetBackYouPansy |
View Public Profile |
Send a private message to GetBackYouPansy |
Find More Posts by GetBackYouPansy |
Add GetBackYouPansy to Your Buddy List |
09/04/14, 09:07 PM | |
Forum posts: 1
File comments: 34
Uploads: 0
|
Woo! Figured out the bug!
Looks like the issue is server side. The two characters I use the timers on are now doing the VR content. My characters are EP, and now I'm running the VR content in the DC area. (I'm on the NA Servers) Example... Character X is in Glenumbra, their timers look fine. Other characters' timers look fine as long as they're not in the VR content. Log Character X off. Character Y logs on, in The Rift, their timers look fine. Character X's timers appear to have +20% remaining time to Character Y. So it seems there's possibly an issue with the system clocks on the servers based on the zone you're currently in. UPDATE: Something is definitely up on the server end. I have another time based addon I'm using (MailTime) and it works fine as long as the hireling mails are received while in a native zone (your faction 1 - 50), if I'm in a VR content zone, it gives bogus info.
Last edited by Rashy : 09/05/14 at 07:28 AM.
|
|
Rashy |
View Public Profile |
Send a private message to Rashy |
Find More Posts by Rashy |
Add Rashy to Your Buddy List |
09/04/14, 06:25 PM | |
Forum posts: 1
File comments: 34
Uploads: 0
|
Yeah, I have no idea what happened, but I just re-enabled being able to see other character's timers and they're all correct now.
My system clocks were and are fine. (I even checked my system event logs) The only thing that I can remotely think might have had an impact was I respec'd Character Y yesterday morning while 3 items were being researched. I could see a possible correlation if it was only Character Y's timers being incorrect, but it was all my characters seeing each other's timers incorrectly. Going to just chalk this one up to random bizarre crap that sometimes just happens. |
|
Rashy |
View Public Profile |
Send a private message to Rashy |
Find More Posts by Rashy |
Add Rashy to Your Buddy List |
09/04/14, 11:17 AM | ||
|
I have no idea what could be wrong. I need to be able to reliably reproduce the problem myself in order to investigate further unfortunately. Is the clock on your PC definitely correct? I just did a quick check and found that moving the clock on my PC forward by 2 hours with the game running causes the timers to all shift by 2 hours as well. It can probably be ruled out as the cause tho, cos switching characters just shouldn't shift the clock by 6 days. Here are some technical details which might help you identify a cause: If you're logged in as character X, character X's timers are updated 'for real' from the game. All other characters that have timers go through the process described in the next paragraph. Updating 'for real' involves asking the game for the total duration and remaining time for every research line. The game factors in your skills returns the remaining time, and total duration. When you log out those data are written to saved variables. That data also includes the time at which the data was acquired. If you quit (rather than log out then quit), the saved variables might not get written, but assuming you have not started any new research then the data is still correct (the addon will account for research that completes while it isn't looking). This makes the passive timers really simple - when you're logged in as character Y, all the addon has to do to work out how long left is subtract two timestamps (time now - timestamp of the data) from the remaining time, to give an updated remaining time. That calculation always uses the persisted data from the last time you logged in as character X so that errors do not accumulate. All the timestamps involved come from the game, and in fact the function to difference the two times is part of the API too. So, that is why I'm stumped, I just can't see why/when the value is inflating by 20%. I let the game handle all the skill-related stuff and don't update the data if the character is not logged in.
Last edited by GetBackYouPansy : 09/04/14 at 11:19 AM.
|
|
|
GetBackYouPansy |
View Public Profile |
Send a private message to GetBackYouPansy |
Find More Posts by GetBackYouPansy |
Add GetBackYouPansy to Your Buddy List |
09/03/14, 06:16 PM | |
Forum posts: 1
File comments: 34
Uploads: 0
|
Noticed a bug.
I'm not sure why I hadn't noticed this sooner, but it appears it may to be tied to the passive research abilities. Here's an example. I have a woodworker (lets call him Character X) with 3/3 Carpentry (reduce research time by 20%) that is researching the 8th trait for Bows. I see my timers just fine when I'm logged in as him, but when I switch characters I see the time being ~20% longer than it should be. Whats very odd about the bug is that it didn't seem to have been happening before. I know that about 2 hours before reporting this, the addon showed the bow being researched for 25 days by Character X, while logged on Character Y (a blacksmith). Now when I log on anyone other than Character X, the timers show 31 days for that 8th trait research by Character X (Full timers from all characters ON). I've gone as far as to delete my saved variables for the addon and started fresh, but no luck. |
|
Rashy |
View Public Profile |
Send a private message to Rashy |
Find More Posts by Rashy |
Add Rashy to Your Buddy List |
08/22/14, 01:50 PM | |
Forum posts: 1
File comments: 34
Uploads: 0
|
Thanks for the quick fix!
|
|
Rashy |
View Public Profile |
Send a private message to Rashy |
Find More Posts by Rashy |
Add Rashy to Your Buddy List |
08/22/14, 12:45 PM | |
|
v3.22 bug fix release
Fix on its way for the "Enable alarms" bug Thanks for reporting. I will look into the 'current character should be first' bug when I have more time.
Also bumped the versions the addon is listed as compatible with here on EsoUI so maybe people will see it now
Last edited by GetBackYouPansy : 08/22/14 at 12:46 PM.
|
|
GetBackYouPansy |
View Public Profile |
Send a private message to GetBackYouPansy |
Find More Posts by GetBackYouPansy |
Add GetBackYouPansy to Your Buddy List |
You have just downloaded by the author . If you like this AddOn why not consider supporting the author? This author has set up a donation account. Donations ensure that authors can continue to develop useful tools for everyone.