Menu
▾
▴
#54 All input received from events
The problem with methods that poll for data while having another thread, the battle thread, updating the very same data is that it can not be trusted what time frame the data is reflecting. Concider this hypothetical example:
getTime(); // returns 49
getX(); // returns 104
getY(); // returns 98
getTime(); // returns 50
What is the robot's x, y position at time 49?
The robot obviously lost a turn. But the question is when did the battle thread update the x and y position? Before or after we read the data with getX() and getY(), or maybe after getX() but before getY(). We can not tell.
However a more robust model can be implemented.
Consider a new command, much like setScan(), that would make the battle thread generate an event with a timestamp and information about the robot: x, y, velocity, bearing, ... etc
Then we would always know what timeframe the data reflects.
/Procyon (System tester)
Discussion
Anonymous
Logged In: YES
user_id=1249353
Originator: NO
You are right that this is a valid issue. However, Robocode has been like that since it was introduced.
Most Robocoders create a Condition that test when the time is changed. When the moment the time is changed, then they read out e.g. the coordinates, heading of the body, gun, and radar etc.
So. In order to fix this issue, I should make the current getX(), getY(), getHeading() etc. deprecated, and then introduce new methods to get all these informations with a timestamp? I would not get popular with the fans of Robocode if a change the current API too much with the common methods.
Logged In: YES
user_id=1249353
Originator: NO
Perhaps I misunderstood you. You want to add some additional methods in order to receive an event that contain a snapshot of all the robot data with a timestamp? If this is the case, then your suggestion is quite good. :-)
Logged In: YES
user_id=1249353
Originator: NO
Perhaps I misunderstood you. You want to add some additional methods in order to receive an event that contain a snapshot of all the robot data with a timestamp? If this is the case, then your suggestion is quite good. :-)
Logged In: YES
user_id=1249353
Originator: NO
Perhaps I misunderstood you. You want to add some additional methods in order to receive an event that contain a snapshot of all the robot data with a timestamp? If this is the case, then your suggestion is quite good. :-)
Logged In: YES
user_id=1249353
Originator: NO
Perhaps I misunderstood you. You want to add some additional methods in order to receive an event that contain a snapshot of all the robot data with a timestamp? If this is the case, then your suggestion is quite good. :-)
Logged In: YES
user_id=1249353
Originator: NO
Perhaps I misunderstood you. You want to add some additional methods in order to receive an event that contain a snapshot of all the robot data with a timestamp? If this is the case, then your suggestion is quite good. :-)
Logged In: NO
Yes, I'd like to receive one event that contain a snapshot of all robot data and a timestamp.
The idea is actually influenced on RoboCup simluated football http://www.robocup.org/ where you send a sense_body command to the server in order to receive information about yourself and the current server time.
And I wouldn't dream of deprecating the current methods to get to the information. This is just an alternative way to get to the same information.
/Procyon
Logged In: YES
user_id=1249353
Originator: NO
I will try to handle this in Robocode 1.5, which is the next version of Robocode with new features.
Logged In: NO
Consider having robocode automatically create this new event that contain a snapshot of all the robot data every frame instead of the need to request it for the next frame. This way accessing robot data at time t, as one otherwise would via the getXXX() methods, does not depend on the last frame being skipped.
With this in place the only downside compared to the getXXX() methods is that the getXXX() get have information at the first frame, the event does not.
/Procyon
Logged In: YES
user_id=1249353
Originator: NO
This feature is currently being implemented with a new StatusEvent, which contains a RobotStatus object, with getTime(), getHeading(), getX(), getGunHeat() etc. that is a snapshot of of the robot status at the time specified by getTime().
When the event occurs, it triggers the new 'public onStatus(StatusEvent event)', which is only defined for the AdvancedRobot. The StatusEvent will get a priority = 99 (next to the max. priority = 100) as default. But I will make it possible to change the priority to something else.
In order to enable this functionality, the new setStatusEvent(boolean enable) must be called with 'true', which means that this new event will be called for each new turn, and put into the event queue of the robot.
If the robot skips one or more turns, the event will still be on the event queue of the robot. The StatusEvent will NOT occurs a the time when the robot skips a turn (likewise for all other robot events). That is, robots are punished for using too much CPU power, and will not be able to handle events before they are "granted" the time to handle events.
Logged In: NO
Do we really need setStatusEvent(boolean enable) ? Why not just put StatusEvents onto the queue of every robot and then let the programmer decide if he/she want to use the new event by overriding onStatus(StatusEvent event) or not. I suggest you only introduce the new event and not the toggle. It's clean simple and backwards compatible.
"The StatusEvent will NOT occurs a the time when the robot skips a turn (likewise for all other robot events)."
You get me confused when you write: likewise for all other robot events. Other events are still generated and put onto the robot queue but are not processed. The punishment for skipping a turn in terms of events is the risk of losing unprocessed events (events from two frames ago). Correct me if i'm wrong.
/Procyon
Logged In: YES
user_id=1249353
Originator: NO
You got a real good point that the robot developer should not have toogle the events using setStatusEvent(boolean enable). So I agree, the developer should just override the onStatus(StatusEvent e) method. Thank you! :-)
Regarding "The StatusEvent will NOT occur at the time when a robot skips a turn
(likewise for all other robot events)."...
What I mean is, that the StatusEvent is put into the event queue like any other event put on the event queue. If a robot uses too much time, it will not be able to read process the events like the StatusEvent, where the internal processEvents method automatically calls onStatus(StatusEvent e), when the robot is "ready" for it. The events are not lost, but at the time when the robot is able to process the events, the time have pasted 1 perhaps more turns compared to the time when the event really occured. There is nothing new to this behaviour really. It's only one of the consequences of putting events to the robot event queue. Does this make sense to you, or am I rambling? :-)
Logged In: NO
It turns out we both have the same understanding of how events work after all.
I misinterpreted you when you said "StatusEvent will NOT occur at the time when a robot skips a turn". I thought you meant that StatusEvents won't even be created and thus not put on the queue when a robot skips a turn. That would make StatusEvents a special case so it had me raise an eyebrow. But I understand now that you meant that StatusEvents will work like any other event (with any and drawbacks this might have).
/Procyon
Logged In: YES
user_id=1249353
Originator: NO
Hehe.. I am glad to hear that we have the same understanding. :-)
This feature has now been implemented for Robocode 1.5
Logged In: NO
Request: a slight modification to the new StatusEvent behaviour and the event management in general to allow for a statusEvent to occur the very first frame.
The problem: at the very first frame the robot's position on the field among other status data is known and is accessible via the various getXXX() methods, however the new means to get to this information via the StatusEvent does not allow access to this data at the first frame.
The solution:
the StatusEvent needs to be created for the first frame. The eventqueue needs to be processed prior to the first frame.
/Procyon
Logged In: YES
user_id=1249353
Originator: NO
Thank you for your suggestion. I have now implemented this as well. :-)
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).