I've got an application that presents the user with ongoing status for roughly 15 minutes. What I want to do is make it so the unit will not power off during this time (because the wifi goes down and the status stops :( )
I'd assume the system is capable of doing this gracefully because I can watch a whole episode of Dilbert (22min) without having to touch my screen. At the same time, when the its over, the system goes to "sleep" (at least after a few min).
Keep alive if you please.
Another option is to press a virtual "key" every so often:
keybd_event(VK_F24, 0, KEYEVENTF_KEYUP, 0);
This will be ignored by applications and it will keep your device from timing out / suspending.
L.B.
Related
In my application, it needs a timer to asynchronously launch a new UI screen when the timer expires.
The following code shows the desired semantics:
Timer t = Timer(Duration(seconds: myDuration), () {
askQuestion('How are you doing?'); });
// Maybe later, before the timer goes off...
t.cancel();
Using Timer, my implementation works sometimes, especially with small durations.
But when the duration is large, say 25, or 400 minutes, then my app would be killed and restarted, then the Timer is lost, the timeout will never happen.
My question is how I can make the Timer persistent surviving the restart of the app or reliable with some equivalent mechanism?
I may provide an ad hoc persistent solution by checking stored time value for the timer to expire at the (re)start of my program, and decide if I should relaunch the timer. But I'd like to learn if there is already a generic solution, as it's a general requirement for Future.delayed operation to survive program restart, otherwise, the use of Future.delayed is limited.
Otherwise, I might search for alternative solutions that provide persistence. I remember local notification might.
I think, you should have to start timer when application started, but you also need to write time when you should show screen to cache service/preferences/db. Then if your application killed and started again you will start timer with rest time(because you need every time start timer on start and you know how much is rest).
Imagine that you should show screen every 400 min. Okay, from now is DateTime.now().add(Duration(minutes:400)) and we can safely start timer from now to this time by (pseudo code) but idea should be clear
timeLeft = cachedDateTime - DateTime.now()
if(timeLeft<0){
show you page immediately and write to cache next time
}
else {
start timer with time left here
}
I’m developing a multiplayer network pong game, my first game ever. The current state is, I’ve running the physic engine with the same configurations on the server and the clients. The own paddle movement is predicted and get just confirmed by the authoritative server. Is a difference detected between them, I correct the position at the client by interpolation. The opponent paddle is also interpolated 200ms to 100ms in the past, because the server is broadcasting snapshots every 100ms to each client.
So far it works very well, but now I have to simulate the ball and have a problem to understanding the procedure.
I’ve read Valve’s (and many other) articles about fast-paced multiplayer several times and understood their approach. Maybe I can compare my ball with their bullets, but their advantage is, the bullets are not visible. When I have to display the ball, and see my paddle in the present, the opponent in the past and the server is somewhere between it, how can I synchronize the ball over all instances and ensure, that the it got ever hit by the paddle even if the paddle is fast moving? Currently my ball’s position is simply set by a server update, so it can happen, that the ball bounces back, even if the paddle is some pixel away (because of a delayed server position).
Until now I’ve got no synced clock over all instances. I’m sending a client step index with each update to the server. If the server did his job, he sends the snapshot with the last step index of each client back to the clients. Now I’m looking for the stored position at the returned step index and compare them. Do I need a common clock to sync the ball?
EDIT:
I've tried to sync a common clock for the server and all clients with a timestamp. But I think it's better to use an own stepping instead of a timestamp (so I don't need to calculate with the ping and so on - and the timestamp will never be exact). The physics are running 60 times per second and now I use this for keeping them synchronized. Is that a good way?
When the ball gets calculated by each client, the angle after bouncing can differ because of the different position of the paddles (the opponent is 200ms in the past). When the server is sending his ball position, velocity and angle (because he knows the position of each paddle and is authoritative), the ball could be in a very different position because of the different angles after bouncing (because the clients receive the server data after 100ms). How is it possible to interpolate such a huge difference?
As you are developing your first game, I think you should try the simplest but brute-force method first. Then you will experience the first exciting result, then you will get courage and try the better methods.
Like Source Engine method, process the game play in one side and send every object state to the other for each 1/30 second. This is a brute method but it works in LAN environment.
Now you will find problems that occur WAN environment where latency is more than 1/30 second.
I am not sure it works actually, but I think that:
Assume that the movement of ball does not change by only player's hit.
Send ball position P, velocity and player A position only when player hits the ball to B.
At B, receive it but process it as if time L is already passed (L=latency between A and B * 2) However, rendered ball should be keep its previous movement until it reaches the ball position P.
Values which never are affected can be masqueraded, even if it is time value. :)
I am working on a unity mobile game. Which is like a multiplayer version of temple run. Because this game is meant for mobile there is a fluctuating latency generally in the range of 200ms - 500ms.
Since the path is predetermined and actions the user can perform are limited (jump,slide, use powerup etc) , the remote player keep running on the path until it receives the updated state from its local player.
This strategy generally works pretty well since I only need to send limited amount of data over the network but there is a specific case in which I am having issues.
In the game, players die on the specific positions (obstacles).
I want remote players to die on the same obstacle/position as local player but due to latency in sending message, the remote player crosses the obstacle by the time it receives the death message.
Is there a way to sync the players on the deaths.
One of the things I tried was moving the remote player back to the local players death position but not only does it look awkward visually but can also raise other syncing issues.
Is there some other better way to do this ?
One way I may recommend is to make one player acts like server (not real server). The server-player will do all the computation like moving, jumping, creating scenes, etc. Then the server-player will send all the data to sync with the client-player. The client-player get the data and process game state. The client-player can also send his action (left-right-jump-slide) to the server-player. This way both player will have the same state of the game like position, die. You also need to deal with latency by adding some prediction.
So the solution I implemented was I spawned all the remote player behind enough so they can have some time to receive the information that local player was died on specific obstacle. And in the end there is a straight path where I just sync players again. So that result is displayed correctly.
How can i set print time for flex printjob.
when the time is ripe my program will automatically print my job
eg. i want to print my job at 11.00 AM i will set print time in my program to 11.00 AM when time is 11.00 AM flex will automatically print my job
You can't. Flex is the wrong tool for this.
You could use a timer to trigger something at 11am, however unless the application is active the timer gets wiggy as the frame rates of the app will slow down. This is one of the changes made in the recent version of the player to help w/ battery life and performance on mobile devices. so, there is no guarantee the timer will trigger at the correct time.
Additionally, Flex is a client side tool. There is no guarantee that your users will have their Flex client up and running and active when 11am rolls around. Depending on your user base, there is also no guarantee that your 11am is there 11am.
All that said, the best you can do from Flex is to pop up a print window which will require user interaction. I wouldn't consider that automatic.
If you want to do this server side, use your server side language, or some server side daemon to trigger the print job at 11am. If you want to do this on your clients, there should be a way to schedule this with the OS, or to write a java or .NET program to run in the background and print when appropriate.
I have been involved in building a custum QGIS application in which live data is to be shown on the viewer of the application.
The IPC being used is unix message queues.
The data is to be refreshed at a specified interval say, 3 seconds.
Now the problem that i am facing is that the processing of the data which is to be shown is taking more than 3 seconds,so what i have done is that before the app starts to process data for the next update,the refresh QTimer is stopped and after the data is processed i again restart the QTimer.The app should work in such a way that after an update/refresh(during this refresh the app goes unresponsive) the user should get ample time to continue to work on the app apart from seeing the data being updated.I am able to get acceptable pauses for the user to work-- in one scenario.
But on different OS(RHEL 5.0 to RHEL 5.2) the situation is something different.The timer goes wild and continues to fire without giving any pauses b/w the successive updates thus going into an infinite loop.Handling this update data definitely takes longer than 3 sec,but for that very reason i have stopped-restarted the timer while processing..and the same logic works in one scenario while in other it doesnt.. The other fact that i have observed is that when this quick firing of the timer happens the time taken by the refreshing function to exit is very small abt 300ms so the start-stop of the timer that i have placed at the start-and-end of this function happens in that small time..so before the actual processing of the data finishes,there are 3-4 starts of the timer in queue waiting to be executed and thus the infinite looping problem gets worse from that point for every successive update.
The important thing to note here is that for the same code in one OS the refresh time is shown to be as around 4000ms(the actual processing time taken for the same amount of data) while for the other OS its 300ms.
Maybe this has something to do with newer libs on the updated OS..but I dont know how to debug it because i am not able to get any clues why its happening as such... maybe something related to pthreads has changed b/w the OSs??
So, my query is that is there any way that will assure that some processing in my app is timerised(and which is independent of the OS) without using QTimer as i think that QTimer is not a good option to achieve what i want??
What option can be there?? pthreads or Boost threads? which one would be better if i am to use threads as an alternate??But how can i make sure atleast a 3 second gap b/w successive updates no matter how long the update processing takes?
Kindly help.
Thanks.
If I was trying to get an acceptable, longer-term solution, I would investigate updating your display in a separate thread. In that thread, you could paint the display to an image, updating as often as you desire... although you might want to throttle the thread so it doesn't take all of the processing time available. Then in the UI thread, you could read that image and draw it to screen. That could improve your responsiveness to panning, since you could be displaying different parts of the image. You could update the image every 3 seconds based on a timer (just redraw from the source), or you could have the other thread emit a signal whenever the new data is completely refreshed.