[21:39:07] (Vorspire) Mark_ what actual unit of time does Core.TickCount represent?
[22:13:27] (@Mark_) its unitless
[22:13:32] (@Mark_) well
[22:13:36] (@Mark_) i should say
[22:13:39] (@Mark_) theres no point of reference
[22:13:40] (@Mark_) its milliseconds
[22:13:51] (@Mark_) they arent directly comparable from system to system
[22:13:55] (@Mark_) its basically the system uptime
[22:15:26] (Vorspire) ahh ok
[22:16:49] (Vorspire) just that timestamp thing i mentioned, i seem to be having issues with it converting Core.TickCount to relative time
[22:17:12] (@Mark_) its only useful for counting elapsed time
[22:17:28] (@Mark_) its faster and higher resolution compared to datetime.now though
[22:17:32] (@Mark_) but its only useful for short intervals
[22:17:35] (@Mark_) not serialized things
[22:17:49] (@Mark_) the problem with datetime.utcnow is that daylight savings changes and such completely ruin a shard
[22:17:53] (@Mark_) or if someone sets the system time
[22:18:01] (Vorspire) i'm using it to detect the time between UtcNow and Spell.BeginCastTime
[22:18:14] (Vorspire) in order to find elapsed time
[22:19:44] (@Mark_) its useless compared to utcnow
[22:19:47] (Vorspire) but I'm trying to use a timeStamp as a mediator between RunUO where things like Spell.BeginCastTime are either DateTime or Int64
[22:19:58] (@Mark_) not possible to have a 1:1 correlation
[22:20:14] (@Mark_) datetime.utcnow is the actual system time, timestamp is the system uptime
[22:20:50] (@Mark_) the system time has things like ntp gradually tweaking the time, etc
[22:20:59] (@Mark_) someone manually setting the system time, etc
[22:21:12] (@Mark_) changing to utcnow fixes the daylight savings/timezone change issue but the system clock is still a bad reference for an application
[22:21:15] (Vorspire) i'm using a custom TimeStamp struct which represents a Unix TimeStamp, seconds since jan 1 1970
[22:21:24] (@Mark_) but why?
[22:21:31] (@Mark_) C# DateTime is seconds since 0000
[22:21:32] (@Mark_) err
[22:21:34] (@Mark_) ticks
[22:21:47] (@Mark_) and tickcount is referenceless, its ticks since uptime
[22:22:06] (@Mark_) but theres other caveats
[22:22:20] (@Mark_) like
[22:22:26] (@Mark_) are you trying to write a script thats agnostic from 2.3 to 2.4?
[22:22:40] (Vorspire) overall, so I can do new TimeStamp(Spell.BeginCastTime) where on RunUO 2.3 it's DateTime and in RunUO 2.4+ it's Int64
[22:22:42] (Vorspire) yeah
[22:23:05] (@Mark_) you could detect which is which
[22:23:12] (@Mark_) based on the size of the long
[22:23:21] (@Mark_) utcnow is going to be a significantly larger number
[22:23:31] (Vorspire) about 6 0's bigger i think
[22:23:42] (@Mark_) i mean this is really really hackish
[22:23:45] (@Mark_) and many pitfalls
[22:23:45] (@Mark_) but
[22:23:50] (@Mark_) you could pull the system startup time
[22:23:56] (@Mark_) and perhaps subtract utcnow from that
[22:23:58] (@Mark_) convert to ms
[22:24:02] (@Mark_) and compare with tickcount
[22:24:19] (Vorspire) that's how you made the timers work with tickcount isn't it?
[22:26:56] (@Mark_) no
[22:27:20] (@Mark_) i just fixed the few spots where someone was using the next firing time in a script i think
[22:27:28] (@Mark_) anyway
[22:27:35] (@Mark_) wouldnt it just be easier if i made an option
[22:27:44] (@Mark_) so people could use datetime.utcnow for tickcount instead
[22:27:53] (@Mark_) dunno
[22:28:27] (Vorspire) hmm i'm not sure
[22:31:13] (Vorspire) basically what i'm trying to do is create a progress bar that has current and maximum value and I figured I could use time as the relative reference like, the current value will always represent DateTime.Now and the max value would be Spell.BeginCastTime + Spell.GetCastDelay(), which would be fine if Spell.BeginCastTime was a datetime
[22:32:01] (Vorspire) the bar is refreshed every 100ms too, so current value would increment by 100
[22:32:05] (@Mark_) err
[22:32:15] (@Mark_) yea id just detect what value was being used
[22:32:27] (@Mark_) and either do castdelay - tickcount or castdelay - now based on that
[22:32:37] (@Mark_) using two different references, just determine which to use
[22:33:01] (Vorspire) got it, thanks
i'll go mess with that now
[22:33:14] (Vorspire) i didn't think of that before so will probably work hehe
[22:33:48] (@Mark_) core.tickcount will error on compile
[22:33:54] (Vorspire) the part that makes it hard is that I can't directly reference Core.TickCount, otherwise there's be no issues
[22:33:55] (Vorspire) yeah
[22:33:55] (@Mark_) makes things tricky too
[22:33:59] (@Mark_) yea
[22:35:22] (@Mark_) since you're heavily modding though could always just add another variable yourself
[22:37:17] (Vorspire) i have limitations, this progress bar is actually an animated gump that displays the spell you're currently casting, i've written it in the form of a CoreModule for Vita-Nex: Core so it can be drag/drop with no edits, so I have those limitations too, that's also why I want to support all RunUO versions as much as possible
[22:38:50] (Vorspire) i assumed because of the way core.tickcount was implemented that it repreneted DateTime.UtcNow (in ticks) at any given time it was accessed.
[22:39:11] (Vorspire) i was wrong of course
[22:39:17] (@Mark_) thats the fallback for mono
[22:39:34] (@Mark_) but the whole point of doing tickcount was to move away from system clock dep
[22:40:15] (Vorspire) ahh, i thought it was to reduce the overhead of using DateTime.*Now
[22:40:53] (Vorspire) like, I thought the initial value of TickCount was DateTime.UtcNow.Ticks, then the system just increased that relative thereafter
[22:41:40] (@Mark_) datetime.utcnow is actually faster than queryperformancecounter
[22:41:52] (@Mark_) datetime.now is 3x slower than datetime.utcnow
[22:42:14] (@Mark_) qpc isnt that much slower than datetime.utcnow though
[22:44:08] (Vorspire) i think the easy road for this would be to just assume the start cast delay as DateTime.UtcNow as soon as the SpellCastRequest event is fired and the user's spell changes value
[22:44:40] (@Mark_) good idea
[22:44:53] (Vorspire) the cast bar doesn't have to be totally accurate to the nanosecond hehe
[22:44:54] (@Mark_) close enough to not matter at least
[22:44:57] (Vorspire) yeah
[22:45:05] (@Mark_) those timers are only good to a ms or so anyway
[22:45:59] (Vorspire) the fastest timer I use is 10ms, which is actually the timer I use to poll the queue for cast bar requests hehe
[22:46:24] (Vorspire) spell request -> bar queue -> dequeue -> handle request -> send gump
[22:46:57] (Vorspire) since the core updates, they have been much more efficient
[22:47:04] (@Mark_) nice
