MantisBT - Zandronum
View Issue Details
0001853Zandronum[All Projects] Suggestionpublic2014-06-22 01:412015-08-25 23:34
StrikerMan780 
 
normalminorhave not tried
closedduplicate 
1.2 
 
0001853: Ability to access time (but not date/year to prevent abuse) in ACS.
The main reason I hear to not allow access to system time, is because people could potentially abuse it to make a WAD unplayable after a certain date/year. I think this could be avoided by restricting it strictly to time.

This would suffice and be all I need for an intended feature in a project of mine. (Random Daily events on a 24/7 round-the-clock hosted server, also influencing the day/night cycle.)
No tags attached.
related to 0002400closed Dusk Simple current date server variable that can be overwritten 
Issue History
2014-06-22 01:41StrikerMan780New Issue
2014-06-22 03:34Blzut3Note Added: 0009634
2014-06-22 03:52Blzut3Note Edited: 0009634bug_revision_view_page.php?bugnote_id=9634#r5107
2014-06-22 04:36WatermelonNote Added: 0009635
2014-06-22 04:38WatermelonNote Edited: 0009635bug_revision_view_page.php?bugnote_id=9635#r5109
2014-06-22 05:15StrikerMan780Note Added: 0009637
2014-06-22 05:17StrikerMan780Note Edited: 0009637bug_revision_view_page.php?bugnote_id=9637#r5111
2014-06-22 05:19StrikerMan780Note Edited: 0009637bug_revision_view_page.php?bugnote_id=9637#r5112
2014-06-22 05:21StrikerMan780Note Edited: 0009637bug_revision_view_page.php?bugnote_id=9637#r5113
2014-06-22 05:25StrikerMan780Note Edited: 0009637bug_revision_view_page.php?bugnote_id=9637#r5114
2014-06-22 06:57Torr SamahoNote Added: 0009640
2014-06-22 08:36Blzut3Note Added: 0009641
2014-06-22 09:36Torr SamahoNote Added: 0009642
2014-06-22 09:56Blzut3Note Added: 0009644
2014-06-22 10:00Torr SamahoNote Added: 0009645
2014-06-22 17:20AlexMaxNote Added: 0009671
2014-06-22 18:01DuskNote Added: 0009676
2014-06-22 18:02DuskNote Edited: 0009676bug_revision_view_page.php?bugnote_id=9676#r5136
2014-06-22 19:59StrikerMan780Note Added: 0009680
2014-06-23 02:03Blzut3Note Added: 0009692
2014-06-23 02:07StrikerMan780Note Added: 0009694
2014-06-23 02:08StrikerMan780Note Edited: 0009694bug_revision_view_page.php?bugnote_id=9694#r5150
2014-06-23 02:16Blzut3Note Added: 0009695
2014-06-23 02:19Blzut3Note Edited: 0009695bug_revision_view_page.php?bugnote_id=9695#r5152
2014-06-23 02:24StrikerMan780Note Added: 0009696
2014-06-23 02:24StrikerMan780Note Edited: 0009696bug_revision_view_page.php?bugnote_id=9696#r5154
2014-06-23 02:27StrikerMan780Note Edited: 0009696bug_revision_view_page.php?bugnote_id=9696#r5155
2014-06-23 03:49WatermelonNote Added: 0009699
2014-06-23 06:15Torr SamahoNote Added: 0009704
2014-06-23 06:49Blzut3Note Added: 0009705
2014-06-23 11:39StrikerMan780Note Added: 0009707
2014-06-23 20:38Blzut3Note Added: 0009720
2014-06-23 20:50StrikerMan780Note Added: 0009722
2014-06-23 20:51StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5174
2014-06-23 20:53StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5175
2014-06-23 20:54StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5176
2014-06-23 20:56StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5177
2014-06-23 21:02StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5178
2014-06-23 21:03StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5179
2014-06-23 21:05StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5180
2014-06-23 21:07StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5181
2014-06-23 21:12StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5182
2014-06-23 21:24StrikerMan780Note Edited: 0009722bug_revision_view_page.php?bugnote_id=9722#r5183
2014-06-24 19:36Torr SamahoNote Added: 0009734
2014-06-24 19:38Torr SamahoNote Edited: 0009734bug_revision_view_page.php?bugnote_id=9734#r5198
2014-06-24 19:38Torr SamahoNote Revision Dropped: 9734: 0005197
2014-06-24 20:11Blzut3Note Added: 0009735
2014-06-24 21:17Konar6Note Added: 0009736
2014-06-25 06:11Torr SamahoNote Added: 0009737
2014-07-05 10:16Torr SamahoProduct Version2.0-beta => 1.2
2014-07-05 21:14StrikerMan780Note Added: 0009858
2014-07-05 21:15StrikerMan780Note Edited: 0009858bug_revision_view_page.php?bugnote_id=9858#r5277
2014-07-05 21:17Blzut3Note Added: 0009859
2014-07-05 21:23StrikerMan780Note Added: 0009860
2014-07-05 21:24StrikerMan780Note Edited: 0009860bug_revision_view_page.php?bugnote_id=9860#r5279
2014-10-18 15:25HypnotoadNote Added: 0010622
2015-08-10 17:41Blzut3Relationship addedrelated to 0002400
2015-08-25 23:34DuskNote Added: 0013279
2015-08-25 23:34DuskStatusnew => closed
2015-08-25 23:34DuskResolutionopen => duplicate

Notes
(0009634)
Blzut3   
2014-06-22 03:34   
(edited on: 2014-06-22 03:52)
And tic counting doesn't work for your purposes?

Edit: Here's a library to get the amount of time passed since the server started. The only flaw is that it will drift based on how long an intermission takes. (In a typical hub world where something like this would be used the drift is negligible.)
#library "RT"

global int 52:totaltime;
world int 52:timeaccounted;

function int realtime(void)
{
    return totaltime + timer() - timeaccounted;
}

script 524 UNLOADING
{
    totaltime += timer() - timeaccounted;
    timeaccounted = timer();
}

If you wanted to sync the drift every so often you could have program that re-inputs the time. In addition you could use that method to get the date and mentioned in the other ticket.

(0009635)
Watermelon   
2014-06-22 04:36   
(edited on: 2014-06-22 04:38)
Another proposal is to allow ACS to read the gametic and hope it's incremented during intermission.

Then if the user enters a time, you can get the current time from the gametic with:


// Lets pretend we convert 5pm into milliseconds since midnight
startTime = (5 + 12) * 60 * 60 * 1000; // You would set this with a cvar porbably

// Set the current time
currentTime = (startTime + (GetGametic() * 28)) % (24 * 60 * 60 * 1000);

// Now get the hour, minute, and second
int hour = currentTime / (60 * 60 * 1000);
int minute = (currentTime / (60 * 1000)) % 60;
int second = (currentTime / 1000) % 60;



Which should yield you something like this

startTime = 61200000
gametic = 12834
currentTime = (61200000 + 359352) % (86400000)
            
hour = 17.09982 (becomes 17)
minute = 5.9892 (becomes 5 or 6 depending on floating point inaccuracy
second = 59.932 (becomes 59)

therefore your time is 5:05:59


I have not tested the above code.

Adding in an ACS function to get the time would be easy.




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I may make a test wad with getting the gametic value later.

(0009637)
StrikerMan780   
2014-06-22 05:15   
(edited on: 2014-06-22 05:25)
Since the map I'll be mainly using this on is a hub/lobby, map changes are frequent. I also wish to get an accurate representation of Central time in North America, which is a good middle point where day/night is not far off across the country, plus, it is where my server resides.

I don't want to constantly have to wait until 12:00AM central every day to get the time aligned correctly, it's just not practical or feasable.

This, along with the upcoming database features, would allow me to do a lot of epic shit that I couldn't before. (Very different than what's been done, too.) Some of it not just related to this specific map, but to things like "Happy Hour(s)" in Deathmatches that really change how the game plays in unexpected ways, based on the time of day people join and play.

(0009640)
Torr Samaho   
2014-06-22 06:57   
The idea of an automatic "Happy Hour" sounds intriguing to me. Does anybody see a serious danger in exposing the system time via ACS (not the date)?
(0009641)
Blzut3   
2014-06-22 08:36   
I would much rather see relative time (like the global gametic Watermelon is talking about) seeded by user defined cvar than actual time access.
(0009642)
Torr Samaho   
2014-06-22 09:36   
Can you elaborate why? I clearly see how you can abuse the date, but from the top of my head I don't see why abuse with local time is worse than with a relative time. With the relative time something like a "7pm (local time) happy hour" in a mod is impossible unless the server manually seeds the local time to ACS by puking a script or carefully times when the server is started.
(0009644)
Blzut3   
2014-06-22 09:56   
Well mainly, relative time has a shot of ZDoom supporting it (determinism). If a user cvar is used to offset the relative time then you would get more or less the same effect and it meets ZDoom's requirements.

And it would be simple to sync a server with system time within a few seconds:
./zandronum-server +set clockoffset `date +%s`

Now getcvar("clockoffset") and you can get the unix time stamp of when the server started up. Do a little math, add the relative time of the game session and there you have it.

But no, strictly speaking, I can't think of an abuse case.
(0009645)
Torr Samaho   
2014-06-22 10:00   
Ah, so you'd like the server admin to bring in the non-deterministic part. StrikerMan780, does this solution work for you?
(0009671)
AlexMax   
2014-06-22 17:20   
Note that ACS uses 32-bit integers, so `date +%s` will only work until 20138. :)
(0009676)
Dusk   
2014-06-22 18:01   
(edited on: 2014-06-22 18:02)
2096 rather.. but still, heh.

(0009680)
StrikerMan780   
2014-06-22 19:59   
"Ah, so you'd like the server admin to bring in the non-deterministic part. StrikerMan780, does this solution work for you?"


As long as it can be reasonably accurate (within seconds), and someone can give me an example of the math I'd need to do, then great.
(0009692)
Blzut3   
2014-06-23 02:03   
The math is simply converting seconds since 1970 to whatever value you desire. You instead pass the time in tics with (and avoid integer overflow in 2096): +set clockoffset $(((`date +%s`%86400)*35))
(0009694)
StrikerMan780   
2014-06-23 02:07   
(edited on: 2014-06-23 02:08)
That is extremely confusing and doesn't really explain much...

(0009695)
Blzut3   
2014-06-23 02:16   
(edited on: 2014-06-23 02:19)
zandronum-server +set clockoffset $(((`date +%s`%86400)*35))

function int currenttime(void)
{
    return (relativetime()+getcvar("clockoffset"))%3024000;
}

Theoretically returns the number of tics since midnight.

(0009696)
StrikerMan780   
2014-06-23 02:24   
(edited on: 2014-06-23 02:27)
Alright. Now, could I somehow make it so it returns x number of seconds since midnight instead of tics? I'm gonna guess division (perhaps by 35, or whatever it was for margin of error?) is involved.

Math was never my strong suit.

(0009699)
Watermelon   
2014-06-23 03:49   
Yes
If you need help with this, I can help you get all the ACS
(0009704)
Torr Samaho   
2014-06-23 06:15   
I just recalled that I made the server stop most of the tickers when no players are in the server. So you should test if this strategy actually works if there are no players connected.
(0009705)
Blzut3   
2014-06-23 06:49   
Well it would, if the new relative time function was implemented. Although, I do wonder if it's a good idea to have a function "fast forward." That is under normal conditions you can assume that the value of the function strictly increases by one, but if the server goes to sleep it may skip an arbitrary amount.

Which I suppose is fine, but it sounds like a potential source of a lot of coding errors.
(0009707)
StrikerMan780   
2014-06-23 11:39   
Yeah, sounds like there's so many factors that can screw with tic counting. I don't have any program that can re-send the current time to the game either. Doesn't seem like there would be a good formula to making the time accurate with things like intermission delays, and freezing of empty servers, etc.
(0009720)
Blzut3   
2014-06-23 20:38   
It would be trivial to add a function that returns the time since the server started in tics.

I'm just saying, for someone that says that math isn't your strong subject, are you going to be able to handle if the server freezes during happy hour and the clock rolls over? Or are we going to see a lot of bug reports from mods that break when people leave the server?
(0009722)
StrikerMan780   
2014-06-23 20:50   
(edited on: 2014-06-23 21:24)
A script would periodically check the amount of time the server has ticked up. If the time is out of range, it'll immediately stop. As long as I can still easily get an accurate time to real-world time. (Ie. Close enough, like 6:42PM in-game, while real time is maybe... 6:44PM, and that I can correct it easily if it de-synchronizes too far.)

Would this Time in Tics since the server started still tick while the server is frozen? If not, I'm probably still better off having something that can return the actual time.

I'd like to be able to do things like "if(hours >= 7 && hours <= 8) { something }" (I'd also use minutes too, for certain things.)

Having direct time access would be a hell of a lot more convenient for end-users wanting to play the wad on their own systems/servers, needing fewer steps to get working. (A lot of people are command-line illiterate. Not myself however.) It also needs less math, and also gets around the whole server freezing and de-synchronization issue as you can just call the function again and get the new time.

A good syntax could be GetTime(<type>);

For type:
TIME_24HOUR - Returns the current hour in a 24-hour clock.
TIME_12HOUR - Returns the current hour in a 12-hour clock.
TIME_MINUTES - Returns the current number of minutes in the hour
TIME_SECONDS - Returns the number of seconds in the minute
TIME_MERIDIAN - Returns 0 for AM, 1 for PM.

(0009734)
Torr Samaho   
2014-06-24 19:36   
(edited on: 2014-06-24 19:38)
Quote from Blzut3
It would be trivial to add a function that returns the time since the server started in tics.
Are you thinking about the true relative time that passed on the wall clock converted to tics? Could this by something that ZDoom would accept? Because it doesn't sound very deterministic. If not, and it just returned the value of one of the internal tickers, this would still not allow the 7pm happy hour.

(0009735)
Blzut3   
2014-06-24 20:11   
I am talking about the true relative time. The only reason I can think of for it not being deterministic is that Zandronum server sleeps and thus would need to skip values. I suppose that's similar to pausing in ZDoom, which I didn't think about, but perhaps if it's a problem it can be left up to the implementation to decide.

In other words the point is to return the total time of the game session in tics. The only thing that means for certain is that the first tic of the game returns 0 and the function is strictly increasing as long as the global scope is valid.
(0009736)
Konar6   
2014-06-24 21:17   
Would this need any of the tickers on the server to operate?
The gametic is increased regardless in SERVER_Tick().
(0009737)
Torr Samaho   
2014-06-25 06:11   
Quote from Blzut3
The only reason I can think of for it not being deterministic is that Zandronum server sleeps and thus would need to skip values.
What about if the machine is simply too slow to process a tic in 1/35 of a second? Either because there is too much going on in the map or something else on the system is hogging the CPU completely?

Quote from Blzut3
In other words the point is to return the total time of the game session in tics. The only thing that means for certain is that the first tic of the game returns 0 and the function is strictly increasing as long as the global scope is valid.
This is not enough for the 7pm happy hour idea. As I said above, you need at least access to the true time that passed on the wall clock since the server has started for this (and even then you still need to combine it with your "+set clockoffset `date +%s`" idea).
(0009858)
StrikerMan780   
2014-07-05 21:14   
(edited on: 2014-07-05 21:15)
Yeah, that's another thing I had in mind, is during times of great duress on the server, and whether or not a mod creator could compensate for that / make corrections for anything that can cause a discrepancy in the timing.

(0009859)
Blzut3   
2014-07-05 21:17   
The game is supposed to try to catch up if things take longer than 1/35th of a second. If the server is constantly unable to complete ticking on time, you will have a bad experience no matter what.
(0009860)
StrikerMan780   
2014-07-05 21:23   
(edited on: 2014-07-05 21:24)
Even then, being able to refresh the time every so often by calling... say...

int Minutes = 0;

script 35 OPEN
{
   Minutes = GetTime(TIME_MINUTES);
   Delay(35);
   restart;
}

Would be more than enough to work for the purposes I need, and I wouldn't have to worry about anything potentially screwing up.

(0010622)
Hypnotoad   
2014-10-18 15:25   
Can we discuss the opposition to acs being able to retrieve the date/time? I think this is very misguided. I'm currently attempting to rewrite the Jumpmaze scripts to use Zandronum's database system instead of relying on an external rcon parser application known as Luk to store records. Jumpmaze, when hosted online, is essentially a racing mod, and the record finish time for the map you're playing on is displayed on the screen and a puke command allows you to retrieve greater details about the record, including the author(s) and the date and time the record was set. The date is useful for players to know how old or new a record is, as the age of the record often affects a player's judgement as to whether he should attempt to beat it. It's also just an inherently interesting piece of information to display.

I'm not able to reproduce this useful functionality without luk, which is a great shame as the idea of the DB was partly so that we don't have to rely on external and potentially unreliable external applications to store persistent data. I know each DB entry stores a time stamp, which is irretrievable currently in ACS, but at least the date can be viewed on some external web page, but that is quite inconvenient in game, and forces any mod author to write a web page for their mod just to somewhat recreate a basic feature of luk.

I propose that Zandronum in fact allows acs to retrieve the timestamp value for a given entry, or otherwise allow acs access to the date and time after-all. If a mod author really wants to cripple their mod after a certain time period, that's their choice, but I honestly think that such a thing is highly unlikely to ever happen.
(0013279)
Dusk   
2015-08-25 23:34   
Let's go with 0002400 instead.