tbaMUD Continued development of the CircleMUD core

In db.c, what kind of calculation do I need to do in order to change the mud's starting year?

Discussed a while back here. But I don't think we ever answered what date/time it originated from.

Greetings, all.

I'm new to the board and really enjoying digging into the info here. This thread caught my eye so it seemed like a good place for a meaty first post.

Please correct my errors, I only started looking at the code tonight.

For those who want the quick answers:
- Time can be altered by editing lib/etc/time (I have a bash script available below to calculate the value for the time file)
- With the way the code is written and the data types used, the Mud can support up to year 2005 mud time. (2005 years 2 months 1 days 11 hrs 1 secs I believe). After this, the mud will crash with a seg fault if someone runs the time command. This is assuming 32bit compilation. gcc on 64 bit architecture with the -m64 switch should make the long a 64bit size giving a much greater amount of space to play. If you're running on 64bit arch you shouldn't need to worry about the limit.

db.c: beginning_of_time = 650336715;
This value is Unix epoch time, seconds since January 1, 1970 (midnight UTC/GMT). The time beginning_of_time translates to Sat, 11 Aug 1990 01:05:15 GMT. It was around this time that DikuMud was written so the value most likely was set to some special day during coding.

At startup, the code under this mud takes the value in lib/etc/time or uses beginning_of_time as the mud epoch time. The mud epoch time is subtracted from the current system epoch time. This value, in seconds, is then converted to current mud time, translated as per below.

utils.h has the #defines for the conversion of real time to mud time. As noted in help time: There are 75 seconds per hour, 35 days per month, and 17 months per year.

db.c has the functions that set the game time:
reset_time (sets mud time based on lib/etc/time file)
save_mud_time (writes the current mudtime to the lib/etc/time file)
- Every PULSE_TIMESAVE (structs.h) which is every 30 real mins
- When the MUD is shutdown/reset

utils.c has the functions for the time conversions, including mud_time_passed which is called from reset_time.

in mud_time_passed, we take the current system time - the mud beginning_of_time (or the value in the time file if it's available). This gets stored in a long variable, allowing that difference to be limited to 2147483648. When pushing the MUD forward in time, we are limited to just after the year 2005 before we get ourselves into trouble. Once we exceed this difference, we'll segmentation fault and crash the MUD when "time" is run. I'm sure it has similar effects in other areas of the code as well. At least we know when the end of the world is.

In the other direction, the MUD will work fine for year 0 for now. You could probably work out some negative years as well but I'm not sure what sort of funky effects that might have.

Some code changes would be needed to alter the code. It'd be pretty easy to just create a #define or config file to give a base year and have the code add that to the year after the year is calculated in the util functions. The rest could still operate the same. Then you could tweak the base year and not care about fiddling with the time file.

For anyone wanting to play with the time, I have a bash script which will calculate the value to put into the time value:


Save this into a file such as mudTimeCalc on a server with bash, make it executable and launch it with: "mudTimeCalc 123". 123 is the year you want it to be. Note that when you go further into the future, you eventually get a negative number. This works fine in the time file so long as you don't exceed the MUD year 2005 (32bit arch)

Keep in mind that this value is relative to real time so 75s after you generated the number the MUD will be one hour into the year you specified even if you are not running the server.

Thanks for digging out all the details, well done.