Dom3 programming/scripts to reset timers
 

This is turning into a pain.
edited note: this all applies to direct connect but comments about the pbem differences acceptable also

Dom3 --hours 24 --quickhost game
is a fairly standard setting. Quickhost it if all the turns are in, otherwise at 24 hours even if someone hasnt done their turn. But if someone wants to change the maximum time or worse yet a temporary extension then its a pain.

The best answer would be if Dom3, like other server programs, would recognize external requests to reread its files and settings. But it doesnt. Direct connect is nice in many ways but it has the drawback of requiring shutdown for almost any change. I should mention that the game DOES have options for things like hosting everyday at 4am or Mon/Wed/Fri at midnight. That would make things easier to manage and much easier on server loads but no one seems to ever choose that for their games.

Ive considered it quite abit but it always comes up "impossible" (meaning of course, possible but more time/effort than its worth). Maybe if I gripe abit here someone more capable than I might smooth some of it out.

Re: Dom3 programming/scripts to reset timers
 

OK the game started with --hours 24 --quickhost
Now I get a request for changing it to 36 hours. No problem. Take the game down, change the script to --hours 36 --quickhost, start the game back up.

Now I get another request, this time for an extension. Dont change the timer, just add 6 hours to it. Grrrrr..... ok. Take down the game, --hours 42 --quickhost, restart. When you notice that the game has hosted, take it down, --hours 36, restart.

But wait, theres more. The players are watching the onscreen countdown. When you got the request, you did the change when the timer showed 8 hours to go. So you extended it too far. And by the time you saw the hosting, it was 3 hours into the timer and you reset it too far. I have things to do. I want to go out. I dont want to catch it RIGHT at a specific time.

OK...
so I should be able to use the --preexec --postexec switches to manage this...
IF there is a change.sh then instead of hosting, SHUTDOWN Dom3, switch the change.sh for restart.sh, RESTART.
But that would start the timer and go 36 hours till next hosting. Also what happens to the chaining of shells? Which preexec is still running? Plus shutting down the game at that point might catch someone logged into the game trying to squeeze under the wire which can create corrupted files. And some people never disconnect, or they incorrectly disconnect (using the big red X instead of quit/disconnect), so it never looks like no one is connected to some of the games.

Re: Dom3 programming/scripts to reset timers
 

So it becomes
IF there is a change.sh
and IF there are no connections
then SHUT DOWN the game
FORCEHOST the game
COPY change.sh to restart.sh
restart the game
delete the change.sh

the headache now becomes making it generic. Which dom3 game am I so I dont shut down the wrong one. Which port is it running on so I can check for connections.

Re: Dom3 programming/scripts to reset timers
 

Wouldn't it make more sense to do that as a postexec?
At least you wouldn't have to forcehost then.

Can you still get corrupted turn files if it hosts and then shuts down while someone was connected? I've never seen this problem, but I haven't run a direct connect game in awhile.

And can you get connection info from the game, instead of checking the port yourself? I remember it displays who's connected.

Re: Dom3 programming/scripts to reset timers
 

Post exec would still have to shut down the game. On the one hand it would avoid the problem of force-hosting the game. On the other hand it would extend the pause time while rabid players download new turns. And if the timer is off by ANY measurable amount then I get complaints. Ive had complaints for the timers being off by minutes, much less *horror* if it was off by as much as an hour

Re: Dom3 programming/scripts to reset timers
 

The debug log (game.log) does show the connections. But some games never show "no" connections. The game is notorious for not seeing disconnects if the player just ends Dom3 before quitting the server. But I could try testing it to see if the wrong results are within acceptable misses

Re: Dom3 programming/scripts to reset timers
 

OK side thought...
The tail of the game.log looks like this:
allgang, Connections 0, Time 14h (quick host)
Arc+ Er+ Py- Ul+ Ti+ Mac- Aby+ Ca- Jo+ shi+ As+

The "Time XXh" shows the countdown. I could use that to avoid alot of the *&^$% date math. When I get "we want 6 hours added for just this turn" I cant just take down the game and add 6 to the --hours 24 switch then restart because the game might already be 7 hours into the timer. So restarting with --hours 30 is way more than they want. This used to mean checking the time-stamp on the ftherlnd file to see when it last hosted, adding the total force-time plus extension to that, then trying to figure out how much time is left to hit that new mark (yes I know its simple math but I hate simple math)

Im realizing now that I can take the "Time XXh" off the game log, add 6 to that, and change to the --hours X switch to that number for an accurate extension.

But knowing to make it --hours 13 to hit the new mark for the extension and restarting it still doesnt solve all the headaches. As soon as the game hosts, it will display a new timer based on a 13 hour limit. There is no way to set the game to "host in 13 hours then go back to 24 hours". Unless Im up and watching, or have that one game out of 100 contact me when it hosts, players will see the timer and rely on it getting pissed if it changes (no matter what they are told)

Re: Dom3 programming/scripts to reset timers
 

New thought:
if the new extension would have the game host on Monday at 5am and I change the switches from:
--hours 24 -q
to being
--hosttime 1 5 --hours 24 -q
then it should host at Mon 5am. And the countdown timer would include Mon 5am and 24 hours but since the 24 hours is sooner it should display that counter which gives me lots of time to take down the game and remove the --hosttime switch before the next Monday. This would avoid lots of confusion about the next hosting time

Re: Dom3 programming/scripts to reset timers
 

AARRGGHH
previous thought is no good either! Most extensions dont go to the limit. In fact, the purpose of the extension is specifically to avoid having the game host on forced-timer. If it quickhosts because the lagging player got his turn in (sometimes just squeezing under the time limit), then it will STILL host AGAIN when it hits the Monday 5am setting giving a double hosting and requiring a *shudder* rollback.

Re: Dom3 programming/scripts to reset timers
 

The only thing I can see is some extensive testing of post.sh
The problem there is that the programs job ID would be something like
5907 dom3 thisgame --preexec pre.sh --postexec post.sh

Now if the post shell decides it needs to reboot the game to a new timer, it will begin by killing the job 5907 dom3 thisgame --preexec pre.sh --postexec post.sh
and starting a new one such as
5919 dom3 thisgame --preexec pre.sh --postexec post.sh

But since job 5907 is the one which started the post.sh will it stop when that job is killed never getting to the line to create another?

Re: Dom3 programming/scripts to reset timers
 

It appears that the choices are this.....

Game has a 48 hour timer, 30 hours in we get a request for an 8 hour extension
(A) take down game, change timer to the 18 hours left plus 8 more --hours 26, restart.
Of course the request is because they DO plan to beat the timer so most likely the game quickhosts. Maybe in the middle of night. So I might not get to it for 5 hours after hosting. For that time the players have seen a new --hours 26 countdown. And what do I fix it to? The original --hours 48? Then there is a jump in the timer to complain about. Or do I set it for 48 minus the 5 hours its already run? That means another try to reset it on the NEXT hosting.

OR
Game has a 48 hour timer, 30 hours in we get a request for an 8 hour extension
(B) take down game, and restart it. This puts 48 hours back on the clock.
Of course the request is to beat the timer so most likely the game quickhosts. Possibly in the middle of the night. And it immediately gets a new 48 hour clock.

OK (B) puts too much time on the clock. But its a one time change and one time difference between what the players are expecting. I think in games I am running (not hosting) this might be the standard for now until something more complicated can be worked out.

Re: Dom3 programming/scripts to reset timers
 

Speaking as someone who hosts direct connect manually, I almost always do B, because A is far too much of a pain. And I tell my players to suck it up and blame the guy who wanted an extension.



Keep in mind I've never used Linux so it's possible I'm spouting BS,

But A should be possible. The first part of A isn't hard to do manually, although I'm sure it's possible to script given that the current timer is in the log and in the packet when you ping a server. Then you would just need to enter the extension ammount as a parameter and run something that reads the log/packet, adds the parameter, then closes the running dom3 and opens a new one with the newly calculated timer. Probably unnecessary, but we have computers to do math for us so why not.

For the second part (after it hosts), I'm sure there's a way to use --postexec to close the game and re-launch it using the original switches. Again I have never used linux but I'm sure there's a way to close the parent, probably by disassociating the child job from the parent job first. I googled up this but I have no idea if it is even related to what you're trying to do:
http://help.lockergnome.com/linux/Sp...ict509666.html

Re: Dom3 programming/scripts to reset timers
 

Thank you. That is exactly the territory and gives me some important keywords I had forgotten in order to search further.

Im still trying to get motivated to look further into it but that will help immensely if I do. (so far no "please" just "its really expected" which is actually a minus on the motivation meter)