MantisBT - Zandronum |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0001853 | Zandronum | [All Projects] Suggestion | public | 2014-06-22 01:41 | 2015-08-25 23:34 |
|
Reporter | StrikerMan780 | |
Assigned To | | |
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | duplicate | |
Platform | | OS | | OS Version | |
Product Version | 1.2 | |
Target Version | | Fixed in Version | | |
|
Summary | 0001853: Ability to access time (but not date/year to prevent abuse) in ACS. |
Description | 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.) |
Steps To Reproduce | |
Additional Information | |
Tags | No tags attached. |
Relationships | related to | 0002400 | closed | Dusk | Simple current date server variable that can be overwritten |
|
Attached Files | |
|
Issue History |
Date Modified | Username | Field | Change |
2014-06-22 01:41 | StrikerMan780 | New Issue | |
2014-06-22 03:34 | Blzut3 | Note Added: 0009634 | |
2014-06-22 03:52 | Blzut3 | Note Edited: 0009634 | bug_revision_view_page.php?bugnote_id=9634#r5107 |
2014-06-22 04:36 | Watermelon | Note Added: 0009635 | |
2014-06-22 04:38 | Watermelon | Note Edited: 0009635 | bug_revision_view_page.php?bugnote_id=9635#r5109 |
2014-06-22 05:15 | StrikerMan780 | Note Added: 0009637 | |
2014-06-22 05:17 | StrikerMan780 | Note Edited: 0009637 | bug_revision_view_page.php?bugnote_id=9637#r5111 |
2014-06-22 05:19 | StrikerMan780 | Note Edited: 0009637 | bug_revision_view_page.php?bugnote_id=9637#r5112 |
2014-06-22 05:21 | StrikerMan780 | Note Edited: 0009637 | bug_revision_view_page.php?bugnote_id=9637#r5113 |
2014-06-22 05:25 | StrikerMan780 | Note Edited: 0009637 | bug_revision_view_page.php?bugnote_id=9637#r5114 |
2014-06-22 06:57 | Torr Samaho | Note Added: 0009640 | |
2014-06-22 08:36 | Blzut3 | Note Added: 0009641 | |
2014-06-22 09:36 | Torr Samaho | Note Added: 0009642 | |
2014-06-22 09:56 | Blzut3 | Note Added: 0009644 | |
2014-06-22 10:00 | Torr Samaho | Note Added: 0009645 | |
2014-06-22 17:20 | AlexMax | Note Added: 0009671 | |
2014-06-22 18:01 | Dusk | Note Added: 0009676 | |
2014-06-22 18:02 | Dusk | Note Edited: 0009676 | bug_revision_view_page.php?bugnote_id=9676#r5136 |
2014-06-22 19:59 | StrikerMan780 | Note Added: 0009680 | |
2014-06-23 02:03 | Blzut3 | Note Added: 0009692 | |
2014-06-23 02:07 | StrikerMan780 | Note Added: 0009694 | |
2014-06-23 02:08 | StrikerMan780 | Note Edited: 0009694 | bug_revision_view_page.php?bugnote_id=9694#r5150 |
2014-06-23 02:16 | Blzut3 | Note Added: 0009695 | |
2014-06-23 02:19 | Blzut3 | Note Edited: 0009695 | bug_revision_view_page.php?bugnote_id=9695#r5152 |
2014-06-23 02:24 | StrikerMan780 | Note Added: 0009696 | |
2014-06-23 02:24 | StrikerMan780 | Note Edited: 0009696 | bug_revision_view_page.php?bugnote_id=9696#r5154 |
2014-06-23 02:27 | StrikerMan780 | Note Edited: 0009696 | bug_revision_view_page.php?bugnote_id=9696#r5155 |
2014-06-23 03:49 | Watermelon | Note Added: 0009699 | |
2014-06-23 06:15 | Torr Samaho | Note Added: 0009704 | |
2014-06-23 06:49 | Blzut3 | Note Added: 0009705 | |
2014-06-23 11:39 | StrikerMan780 | Note Added: 0009707 | |
2014-06-23 20:38 | Blzut3 | Note Added: 0009720 | |
2014-06-23 20:50 | StrikerMan780 | Note Added: 0009722 | |
2014-06-23 20:51 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5174 |
2014-06-23 20:53 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5175 |
2014-06-23 20:54 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5176 |
2014-06-23 20:56 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5177 |
2014-06-23 21:02 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5178 |
2014-06-23 21:03 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5179 |
2014-06-23 21:05 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5180 |
2014-06-23 21:07 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5181 |
2014-06-23 21:12 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5182 |
2014-06-23 21:24 | StrikerMan780 | Note Edited: 0009722 | bug_revision_view_page.php?bugnote_id=9722#r5183 |
2014-06-24 19:36 | Torr Samaho | Note Added: 0009734 | |
2014-06-24 19:38 | Torr Samaho | Note Edited: 0009734 | bug_revision_view_page.php?bugnote_id=9734#r5198 |
2014-06-24 19:38 | Torr Samaho | Note Revision Dropped: 9734: 0005197 | |
2014-06-24 20:11 | Blzut3 | Note Added: 0009735 | |
2014-06-24 21:17 | Konar6 | Note Added: 0009736 | |
2014-06-25 06:11 | Torr Samaho | Note Added: 0009737 | |
2014-07-05 10:16 | Torr Samaho | Product Version | 2.0-beta => 1.2 |
2014-07-05 21:14 | StrikerMan780 | Note Added: 0009858 | |
2014-07-05 21:15 | StrikerMan780 | Note Edited: 0009858 | bug_revision_view_page.php?bugnote_id=9858#r5277 |
2014-07-05 21:17 | Blzut3 | Note Added: 0009859 | |
2014-07-05 21:23 | StrikerMan780 | Note Added: 0009860 | |
2014-07-05 21:24 | StrikerMan780 | Note Edited: 0009860 | bug_revision_view_page.php?bugnote_id=9860#r5279 |
2014-10-18 15:25 | Hypnotoad | Note Added: 0010622 | |
2015-08-10 17:41 | Blzut3 | Relationship added | related to 0002400 |
2015-08-25 23:34 | Dusk | Note Added: 0013279 | |
2015-08-25 23:34 | Dusk | Status | new => closed |
2015-08-25 23:34 | Dusk | Resolution | open => 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.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
Ah, so you'd like the server admin to bring in the non-deterministic part. StrikerMan780, does this solution work for you? |
|
|
|
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.
|
|
|
|
"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.
|
|
|
|
Yes
If you need help with this, I can help you get all the ACS |
|
|
|
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. |
|
|
|
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(). |
|
|
|
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.
|
|
|
|
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
|
|
|