Make time available to quests
 

In the world building thread for the PEQ database (http://www.eqemulator.net/forums/showthread.php?t=23534) Angelox said:

Which I thought was a good idea. I also don't like running shifts.pl outside of the emulator to take care of the day/night shift. Therefore I added two variables to my quests: $zonehour and $zonemin which return the hour and minute respectively. Similarly, I created $zonetime to return the time in military time as above. However, I'm not sure if the $zonetime calculation would be better off in the .pl script where you need it vs the .cpp (since it's really a calculation using the two variables I've already given quests access to). I'm not good at benchmarking so if putting it in the .pl each time it is better than putting it in the .cpp, let me know.

To make this change you'll need to open zone\embparser.cpp and find the following:
Changing it to the following will give you the three variables I mentioned above:
To test this, I used templates\Priest_of_Discord.pl and added the following to sub EVENT_SAY:
I then created a macro with:
#time
/say time
/time

And went and talked to the POD. Here's what happened:
Keep in mind that I have already applied my other fix for #time to make it match for /time so if you haven't used the code from http://www.eqemulator.net/forums/showthread.php?t=24108 then #time will be one hour off of /time.

At any rate, since this lets us use $zonetime in quests, we can replace the (PEQ & AX Quests) kithicor\20250.pl:
With (this assumes 8pm is night and 8am is day):
There's two places in that file where this occurs: EVENT_SPAWN and EVENT_ENTER.

Now, just so you're aware, there's one thing that Angelox's shifter does that this won't do and that's synchronize the time for dynamic zones.

I could have sworn that while I was testing, I went into a dynamic zone and the clock had reset itself to 8:00am. However, now I can't seem to make it do it again...maybe I was dreaming.

You know, this is exactly the sort of thing I've been stuck with in regards to the Greenmist quest line. I knocked out all but two of the quests, and was trying to figure out a good way to work Tracker Azeal for the fifth quest. He goes patrolling (depops, a new version pops instantly, and starts pathing) at 9 PM game time, but I couldn't find a way to tie Angelox's time code in to him.

This would be incredibly helpful stuff, because I've been hesitant to implement a work-around of any kind, and then have it become completely obsolete once someone figured out how to get time and quests working together... And it seems you have! :)

You and Angelox have really put together some great work on time recently, and I hope this all gets implemented soon. Keep it up!

That script you are looking at does two things: spawns night or day creatures and sets the zone time. The full 20250.pl script is broken in three parts;EVENT_SPAWN- set time on zone boot/spawn, and spawn the proper NPCs . Next, I had set invisible "Watcher" NPC's in key areas around the zone that check $shifter when there's PC movement (EVENT_ENTER and EVENT_EXIT), they update what NPCs should be up.

What you have is very good and needed, my shifter scripts are sort of a hack to satisfy what I want. They work fine, but should be merged into the code.
I think for this, we need two things to work;

1st and most important> Time always be synchronized across the zones, even dynamic: when a dynamic zone loads and a static zone says it 1:00pm, then the dynamic zone needs to catch that and set the same time - there should be some sort of "main time" that starts at EQ8:00am on EqEmu boot up, regardless if we have statics or not. Another words, when a static loads, it looks at this "central time" and synchronizes with it. This way, if a zone reboots (static or not), it finds the proper time again. The shifter scripts already do this, but in a rather awkward way - so awkward to me (and I made them), I thought was too stupid to mention, so I kept it to myself tell Cavedude saw and liked.

2nd > "Central time" will always have a variable available for time checks via Perl scripts ($zonetime).

If you all could create a Central time that applies on zone boot up to any zone (dynamic or not), then all we would need for day and night creatures is something like you said;
And even the above code could be debatable if needed; you could create a general setting in spawn2 table, that would define night or day npcs, and you know the rest.

Also, there's many more watchers across the zones - look in "server/quests/templates" there are the PoD and Nexus_Scion scripts which end in this;
This applies to any zone with a Nexus Scion or PoD.

I listed all of the "watchers" in my other thread about time, so I didn't repeat them here. I was using the kith one as an example.

Can you give me the conditions that a zone comes up with the wrong time? I was trying to reproduce it, but on my server the dynamic zones keep coming up with the same time as my static zones. I mentioned it above because I could have sworn this wasn't the case, that my Kith was coming up at 8:00am regardless of my static zones...but that didn't happen last night while testing.

It's a freak thing, I've seen it happen too - I think it might be the client not updating properly , usually I can zone into a "watcher" zone and back, and it sets. if you use AX_PEQ database there are a few POD scripts in the zone that shouldn't be there, in NK, there was a Nexus Scion script that was voiding or confusing the one in templates. I've also seen zones sync time with no scripts running in there (zone to Harbingers spire after zoning to a scripted zone, I saw that there)

I did some testing on the "time sync" issue and modified the code for testing. My initial thoughts were that it was due to "gottime" still being true when a zone booted up. However, I had an error in my logic on my first test and ended up adding a bunch of other tests to check the server packets. Turns out, I was right originally.

The reason that the sync doesn't update properly for dynamic zones is because sometimes a dynamic zone comes up in a place where gottime is actually "true" even though it shouldn't be for that zone. (gottime gets set to false when a zone shuts down).

For testing I changed zone.cpp to:
Now all of the information we need regarding what's going on is stored in the log files. NOTE: If I planned on keeping this code in, there would need to be debug logic rather than just writing it to the normal log. However, since I was just trying to track this one issue down, there's no reason to put in all the debug logic.

I then zoned from neriakc to neriakb to neriaka to nektulos (all dynamic for my testing). NeriakC was the first zone to come up:
Next neriakb came up (and the time did not get set):
Then I went to neriaka (which was in the same logfile as neriakc) and the time did not get set:
And finally, I went to nektulos (which was in the same log file that neriakb was in originally) and the time did get set:
Note the value of gottime when the zone syncs properly is "false" as it should be. However, on the other zones, the value was true and as such, the server does not attempt to synchronize the time.

There are two ways to go about fixing this. There's the real way, and the Knight way (tm). The real way would be to find out why gottime is true and fix those conditions such that gottime is false when it should be false and true when it should be true.

The Knight way (tm) was to find out how often gottime is being used (appears to be only in the TimeSync stuff); find out how often GetTimeSync is used (appears to be only when the zone is booting up); and just remove the conditional so that the time sync is done whether we have time or not.

Now, after a brief look at the code, this should only cause us to try to sync time when the zone comes up and it should force a sync every time. HOWEVER, I did not run a debug to trace all of the instances of this to make sure that it's not being done too often. I can't help but think the reason that gottime was there was because someone had a problem with the zones repeatedly synchronizing even though they already had synchronized the time.

I won't have any more time to spend on this until next week, so I thought I'd post my findings here in case anyone else wanted to pick up the testing or try to fix the real problem.

To remove the conditional for gottime, just change the code in zone.cpp from:
To:
But again, I don't have time to test to see if that causes an egregious amount of time sync'ing or other issues.

I've been running the above change (removing the !gottime conditional) since this was posted, except with the addition that I wrote an entry to the log every time that it was used. So, I can now verify that this doesn't cause an inordinate amount of time synchronization and, indeed, keeps all of my dynamic zones in sync with time.

I didn't even see that snippet, I'll have to try it out on TGC next time I patch. I know the rest of your submissions are in the official code, but I have yet to find time to play. :(

This change never went into the source, did I miss something - or it just got forgotten?

It may be the case that the problem described by Knightly is due to the
fact that 'gottime' is not initialised in the zone constructor and therefore
has a random value each time a zone is booted up.

In zone/zone.cpp, Zone::Zone(int32 in_zoneid, const char* in_short_name)

Around line 700:

After:

Add:

I can't test this, but I'm bored at work and just had a quick look at the code :)

I just got back, saw your post. Before i tested , i pulled all "settime" scripts ;
Here's a summary of what happened:
With Knightlys gottime-removal fix, all dynamic zones start at 8pm, then continue to count normally ; all static zones start at 8am.
With Derisions gottime = false; fix, all dynamic zones start at 2:00pm, and continue normally.
so with one they stay 12 hours apart (dynamic vs static) and the other 6.
I stood around a while checked a lot of zones, and times remain stable, but with the mentioned time difference.

can't some sort of GLOBAL server side timer be build INTO server code istelf?

which will start when server itself is started (regardless if any zones have been booted or not) and then ALL zone will read time from that timer

in other words, tie timer to SERVER itself not to any zone in specific

OR as a cheap solution- make zones read time of current PC time and convert into EQ

since eq day is what 2 hours? then 11.30 am will be 6pm game time

I've been looking at this some more. It appears that when a static zone
loads, it makes the call to GetTimeSync before it is actually connected
to the world server, hence the check for worldserver.connected fails.

Angelox, try this. In zone/worldserver.cpp void WorldServer::OnConnected():

Around line 124, After:

Add:

So the whole section of code reads:

I started and stopped my server a couple of times and the time in my 5 dynamic and 1 static were now in sync.

This is purely experimental code :)