MacroQuest64

Posted: **Fri Sep 24, 2004 9:28 am**

According to /time today is December 24, 3182, but according to ${GameTime.Date} it's 13/24/3182. Not COMPLETELY sure this is a bug since they may have screwed around with the Norrathan calendar and added months that I don't know about but...

Posted: **Fri Sep 24, 2004 10:58 pm**

Maybe Undecember is the 1st month? I dunno lol.

I know theres something about Java and 13 months. Something to do with undecember (I think theres 13 lunar months). Heres some code documentation for some calendar application written in Java (http://oss.software.ibm.com/icu4j/cover ... endar.html) (too lazy to dig up more info/look up the Java API Docs):

Code: Select all

/**
 	   	* Field number for <code>get</code> and <code>set</code> indicating the
 	   	* month. This is a calendar-specific value. The first month of the year is
 	   	* <code>JANUARY</code>; the last depends on the number of months in a year.
 	   	* @see #JANUARY
 	   	* @see #FEBRUARY
 	   	* @see #MARCH
 	   	* @see #APRIL
 	   	* @see #MAY
 	   	* @see #JUNE
 	   	* @see #JULY
 	   	* @see #AUGUST
 	   	* @see #SEPTEMBER
 	   	* @see #OCTOBER
 	   	* @see #NOVEMBER
 	   	* @see #DECEMBER
 	   	* @see #UNDECIMBER
 	   	* @stable ICU 2.0
 	   	*/

i might be completely off so feel free to mod this as troll if I am wrong. Oh wait :-).

Posted: **Sat Sep 25, 2004 12:57 am**

Nice try, but the new month (if any) would appear to come before January (2) not after December.

Posted: **Sat Sep 25, 2004 7:49 pm**

I thought I might have missed that "extra" month, but it's been a day and a half and we're still in "January". It's looking like all the months have the month number high by 1.

Posted: **Tue Oct 12, 2004 9:58 am**

Okay, it took a full Norrathan year, but I've verified this as a bug. The month number goes right from 13 for December to 2 for January. There is no month number 1.

Posted: **Tue Oct 12, 2004 2:44 pm**

no idea why it would do that, but also players not supposed to see it so its probably why its unchanged

Posted: **Tue Oct 12, 2004 2:46 pm**

better file a /bug in game and have them fix it :p

Posted: **Thu Oct 14, 2004 7:07 am**

I'd buy that argument _maybe_ for the numerical month value, but not for the stringification routine. The internal representation should never matter to that.

Posted: **Thu Oct 14, 2004 8:45 am**

In MQ2DataTypes.cpp

Code: Select all

	case Month:
		Dest.DWord=pTime->tm_mon+1;
		Dest.Type=pIntType;
		return true;

and

Code: Select all

	case Date:
		sprintf(DataTypeTemp,"%02d/%02d/%04d",pTime->tm_mon+1,pTime->tm_mday, pTime->tm_year+1900);
		Dest.Ptr=&DataTypeTemp[0],
		Dest.Type=pStringType; 
		return true;

I imagine this used to be 0-based and changed at some point. Just lose the +1 if it bugs you.

Posted: **Fri Oct 15, 2004 6:38 am**

Ya it does bug me. I'd really like to see the fix rolled into the next zip especially since it's trivial.

Posted: **Thu Oct 21, 2004 6:42 pm**

Implemented this a couple of days ago, but just realized it isn't working right. You DO need the +1 for real-time, but not for game time. Geniuses they a'int.

MacroQuest64

Gametime bug?

Gametime bug?