[Powerlord]

So, anyway, according to the Source SDK 2013, TF2's util_shared.cpp has this:

PHP Code:

static CBitVec<kHolidayCount> s_HolidaysActive; 


Is there any way to modify this vector? The only reason I ask is because overriding the function that checks this doesn't seem to work for TF2's zombie cosmetic items... they are somehow getting other values for this, either by reading this directory or calling EconHolidays_IsHolidayActive directly. Except we don't know what EconHolidays_IsHolidayActive looks like because its code isn't in Source SDK 2013, only that it takes an int (holiday number) and a value from CRTime::RTime32TimeCur()... and unfortunately, we don't know what CRTime looks like either.

[VoiDeD]

Not that I'd recommend it, but generally how this is accomplished is finding a function that references the global you're interested in, and creating a pointer to it. However, this is very fragile and really should only be done if there are no other alternatives. See: http://mxr.alliedmods.net/sourcemod-...fLife2.cpp#165

In this case you'll also likely want to ensure that the byte layout of CBitVec<N> doesn't differ from the SDK and valve's compiled versions. (The layout can differ significantly if kHolidayCount changes).

Additionally, CRTime is probably just a thin wrapper over RTime32, which should just be uint32.

[Powerlord]

Originally Posted by VoiDeD Not that I'd recommend it, but generally how this is accomplished is finding a function that references the global you're interested in, and creating a pointer to it. However, this is very fragile and really should only be done if there are no other alternatives. See: http://mxr.alliedmods.net/sourcemod-...fLife2.cpp#165

UTIL_CalculateHolidays and UTIL_IsHolidayActive should both reference it. We know this because Valve never wiped this from the Source SDK 2013, which is derived directly from what TF2's code looked like several months ago. Valve forgot to wipe the TF2 specific bits from it.

Originally Posted by VoiDeD In this case you'll also likely want to ensure that the byte layout of CBitVec<N> doesn't differ from the SDK and valve's compiled versions. (The layout can differ significantly if kHolidayCount changes). Additionally, CRTime is probably just a thin wrapper over RTime32, which should just be uint32.

I had assumed it would be a time_t, but since Windows doesn't produce negative values, it may very well be a RTime32. Having said that, I can see the time function being called in a decompile of CRTime::UpdateRealTime, which takes a time_t*.

I actually started reverse-engineering CRTime based on a decompile of the TF2 server_srv.so binary... but I'm not sure if I have to implement all the methods or if it's enough to just have the variables. As far as I can tell, it stores two times (RTime32 or time_t?) and two char[]. The two char[] are the date and the time from strfmttime (and the formats for strfmttime are helpfully in the decompile). One time is the last time that UpdateRealTime is called. The second time seems to be the last time the CRTime was updated... which doesn't make a lot of sense to me. It may only be updated if the clock hasn't spun backwards (I can tell from the decompile that there's a check for this). Unfortunately, I'm at my laptop right now and the CRTime stuff I was working on is on my home desktop and work desktop.