simspark-devel — Discussion about Spark development

Re: [simspark-devel] discussion

[Hesham <hes...@gm...>]

Oops, the last sentence was a bit silly. I mean the closer to the ball the
more precision.

On 2/6/07, Hesham <hes...@gm...> wrote:
>
>
>
> On 2/6/07, Oliver Obst <Oli...@ne...> wrote:
> >
> >
> > wasn't hesham looking for a job? ;-)
> >
> >
> Yes, he was. Just could you please do me a favour and let me know what you
> expect from the logger. I have just a simple idea, maybe it works or maybe
> not. What's your opinion about LOD (level of detail)? IMHO when an object
> (agent) is not close to the ball logging its exact movement frame by frame
> isn't necessary.
>


Hesham

Re: [simspark-devel] [Sserver-three-d] Offside Bug Report

[Hesham <hes...@gm...>]

On 2/5/07, Joschka Boedecker <jbo...@un...> wrote:
>
> thanks for the updated file. I added you to the sserver project on
> SourceForge, so could you please commit your changes to the CVS? And
> please also snyc with the simspark CVS.


OK. I'll commit it asap.

Well, I'm not sure yet, whether activating the offside in the
> competition makes sense yet (since some teams might not even be able to
> move very much), but at least for the GermanOpen etc., I'd like to have
> a version as bug-free as possible. But I'm also sure we find some other
> work for you, don't worry ;-)


Thanks :-)

Cheers,
Hesham

Re: [simspark-devel] discussion

[Hesham <hes...@gm...>]

On 2/6/07, Oliver Obst <Oli...@ne...> wrote:
>
>
> wasn't hesham looking for a job? ;-)
>
>
Yes, he was. Just could you please do me a favour and let me know what you
expect from the logger. I have just a simple idea, maybe it works or maybe
not. What's your opinion about LOD (level of detail)? IMHO when an object
(agent) is not close to the ball logging its exact movement frame by frame
isn't necessary.

Cheers,
Hesham

Re: [simspark-devel] discussion

[Oliver O. <Oli...@ne...>]

>> mmh, yeah, but maybe I'm wrong. At least if we only store the  
>> data  close to the object they belong to, that shouldn't affect  
>> the  performance. We have this graphics-engine part inside the  
>> project  (kerosin), which was really cool stuff when it was  
>> created. But as  nobody is really using and maintaining it, we  
>> should think of using  3rd party graphic libs, and they will  
>> handle this kind of data  internally. So in the simulator core,  
>> the graphics stuff would be  mainly needed for initialisation, and  
>> then be passed to the graphics  engine. Anyway, as long as  
>> additional data is only stored in the  tree, we can put in  
>> anything we want. We'd have to think about an  interface to  
>> possible graphics engines, though.
>
> Of course, you're right. Sorry, I forgot about the plan to change  
> to an external graphics lib for a moment there :-/

no worries...
the thing is that a converting from our tree to the representation of  
the Graphics Engine (possibly also a tree) costs time that you can  
save if you don't have to do it.

>> yep. Would be great to just pass a pointer to the graphics  
>> engine,  saying "here's my scene", now please render it. Well,  
>> this was the  initial idea of our approach with kerosin, and yes,  
>> it would be nice  to continue this idea even with other graphic  
>> engines. Might work, as  they will also use a tree internally. So  
>> we could use nodes of an  external graphics engine inside our  
>> scene tree, but of course that  would add a compile time  
>> dependency on a particular engine. I'm  currently looking into this.
>
> Hmm, yeah, it would be nice not to have these dependencies. Maybe  
> having two different scene trees (one for the physics, one in the  
> rendering engine) is not a bad idea after all.

it's more flexible, but you pay a price for that (see above). On the  
other hand, using the same tree means (as far as I see it now) that  
we have to change some of the fundamental classes in our framework  
(the node/leaf classes), so that we use the node class of an external  
scene graph. I'm not so sure if there's an easy way to do that  
(without breaking everything, that is). Something like 2 trees that  
share some nodes or so, but I haven't had much time to think about it.

>> something smarter, maybe --- the logging takes also a lot of  
>> cputime.  Logging keyframes and updates, maybe, or ...
>
> Yeah, something along the lines of the delta-scenes we have in the  
> current monitor maybe (just describing changes in the scene).  
> Keyframes with interpolation might be too crude for detailed frame  
> by frame analysis I'm afraid.

wasn't hesham looking for a job? ;-)

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] discussion

[Joschka B. <jbo...@un...>]

Hi Oli,

Oliver Obst wrote:
> [...]
>> What visual information do you mean? Position and orientation are  
>> needed
>> by both physics and visuals, and stuff like textures and the meshes
>> (usually) don't change much I think. Oh, but maybe you're thinking of
>> animation data?
>
> mmh, yeah, but maybe I'm wrong. At least if we only store the data  
> close to the object they belong to, that shouldn't affect the  
> performance. We have this graphics-engine part inside the project  
> (kerosin), which was really cool stuff when it was created. But as  
> nobody is really using and maintaining it, we should think of using  
> 3rd party graphic libs, and they will handle this kind of data  
> internally. So in the simulator core, the graphics stuff would be  
> mainly needed for initialisation, and then be passed to the graphics  
> engine. Anyway, as long as additional data is only stored in the  
> tree, we can put in anything we want. We'd have to think about an  
> interface to possible graphics engines, though.

Of course, you're right. Sorry, I forgot about the plan to change to an 
external graphics lib for a moment there :-/

>> I think having all the necessary information in one scene structure
>> (like the scene tree) is nice if you have internal rendering.
>
> yep. Would be great to just pass a pointer to the graphics engine,  
> saying "here's my scene", now please render it. Well, this was the  
> initial idea of our approach with kerosin, and yes, it would be nice  
> to continue this idea even with other graphic engines. Might work, as  
> they will also use a tree internally. So we could use nodes of an  
> external graphics engine inside our scene tree, but of course that  
> would add a compile time dependency on a particular engine. I'm  
> currently looking into this.

Hmm, yeah, it would be nice not to have these dependencies. Maybe having 
two different scene trees (one for the physics, one in the rendering 
engine) is not a bad idea after all.

>
>> If you want to copy, you have to lock anyways if you're using  
>> threads, I
>> think. Otherwise you might have inconsistent data to display.
>
> yes, but I'm not sure if this would be a big problem. The updates  
> between single steps are usually not large, so it should be possible  
> to ignore inconsistencies. But as I said, I'm not sure.

We can try with locking first and then see what happens :-) I think the 
locking shouldn't be a big problem either though.

>
>>> - if we want the agents to run as fast as possible, we should use
>>> something like a syncmode in 2D, but for giving the agents enough
>>> time to think, the simulator should wait with the physics if it is
>>> faster than real time for competition settings.
>>>
>> Yeah, a sync mode would definitely be a nice feature :-)
>
> especially for machine learning and a new internet league, some speed  
> improvements would be really good.
>
> We also have to think about a logfile format... and what get's logged  
> with the more complex bodies anyway. A mpeg or quicktime from a match  
> would certainly be nice (and probably not much bigger than  
> textlogging everything), but if you want to kind of replay the match  
> from every possible angle, that's not enough. We should think about  
> something smarter, maybe --- the logging takes also a lot of cputime.  
> Logging keyframes and updates, maybe, or ...

Yeah, something along the lines of the delta-scenes we have in the 
current monitor maybe (just describing changes in the scene). Keyframes 
with interpolation might be too crude for detailed frame by frame 
analysis I'm afraid.

Cheers,
Joschka

Re: [simspark-devel] [Sserver-three-d] Offside Bug Report

[Joschka B. <jbo...@un...>]

Hi Hesham,

Hesham wrote:
> Sorry for the long delay. I couldn't answer earlier, that's a long
> story. Anyway, Junqing Wang, thank you so much for your report. I'm
> afraid, I didn't understand some parts of the report. Actually,
> if (mGameState->GetTime() != time)
> {
> return false;
> }
> isn't necessary. That was there to be sure when a new collision
> doesn't occur it doesn't go through the offside code. To get rid of
> it, there is a simple solution, please take a look at the attached file.
thanks for the updated file. I added you to the sserver project on
SourceForge, so could you please commit your changes to the CVS? And
please also snyc with the simspark CVS.
>
> So far as I noticed for the next version there is no offside. In
> December I was working on refactoring the offside code (I promised
> Joschka to finish it before January but I couldn't). Since it was my
> first code for the server I mad a big mistake in its design and that
> caused a lot of problems in debugging. Anyway, I got rid of my
> problems and have more free time. Since working on the offside doesn't
> make sense, I wonder if there is something that I can work on for the
> new server. (I'm following the discussion regarding multi-thread)
Well, I'm not sure yet, whether activating the offside in the
competition makes sense yet (since some teams might not even be able to
move very much), but at least for the GermanOpen etc., I'd like to have
a version as bug-free as possible. But I'm also sure we find some other
work for you, don't worry ;-)

Thanks again,
Joschka

Re: [simspark-devel] discussion

[Oliver O. <Oli...@ne...>]

Hi Joschka,

On 05/02/2007, at 9:30 PM, Joschka Boedecker wrote:

> I think we could start with 1a) and guarantee mutually exclusive
> operation on the SceneGraph between the different threads. You can  
> set a
> Mutex for this if you want to use the SceneGraph, then you'll have
> exclusive access, and then remove that Mutex once you're done. This  
> way,
> another thread might have to wait for a while to get access, but  
> you'll
> have correct data all the time. The only way the system could  
> 'hang' is,
> if a Mutex doesn't get removed. But even then, there are time out
> mechanisms that can be used. Since the physics thread runs a lot  
> faster
> than visualization and agent updates, these locks won't occur too  
> often,
> I think. If 1a) turns out to be too slow, we could consider option  
> 1b).

1a should at least not be (much) slower than using no separate  
threads at all. If we find a way to program everything so that we can  
switch back to single thread easily, that would be really great (for  
debugging), but I'm not sure if this can be done.

> What visual information do you mean? Position and orientation are  
> needed
> by both physics and visuals, and stuff like textures and the meshes
> (usually) don't change much I think. Oh, but maybe you're thinking of
> animation data?

mmh, yeah, but maybe I'm wrong. At least if we only store the data  
close to the object they belong to, that shouldn't affect the  
performance. We have this graphics-engine part inside the project  
(kerosin), which was really cool stuff when it was created. But as  
nobody is really using and maintaining it, we should think of using  
3rd party graphic libs, and they will handle this kind of data  
internally. So in the simulator core, the graphics stuff would be  
mainly needed for initialisation, and then be passed to the graphics  
engine. Anyway, as long as additional data is only stored in the  
tree, we can put in anything we want. We'd have to think about an  
interface to possible graphics engines, though.

> I think having all the necessary information in one scene structure
> (like the scene tree) is nice if you have internal rendering.

yep. Would be great to just pass a pointer to the graphics engine,  
saying "here's my scene", now please render it. Well, this was the  
initial idea of our approach with kerosin, and yes, it would be nice  
to continue this idea even with other graphic engines. Might work, as  
they will also use a tree internally. So we could use nodes of an  
external graphics engine inside our scene tree, but of course that  
would add a compile time dependency on a particular engine. I'm  
currently looking into this.

> If you want to copy, you have to lock anyways if you're using  
> threads, I
> think. Otherwise you might have inconsistent data to display.

yes, but I'm not sure if this would be a big problem. The updates  
between single steps are usually not large, so it should be possible  
to ignore inconsistencies. But as I said, I'm not sure.

>> - if we want the agents to run as fast as possible, we should use
>> something like a syncmode in 2D, but for giving the agents enough
>> time to think, the simulator should wait with the physics if it is
>> faster than real time for competition settings.
>>
>
> Yeah, a sync mode would definitely be a nice feature :-)

especially for machine learning and a new internet league, some speed  
improvements would be really good.

We also have to think about a logfile format... and what get's logged  
with the more complex bodies anyway. A mpeg or quicktime from a match  
would certainly be nice (and probably not much bigger than  
textlogging everything), but if you want to kind of replay the match  
from every possible angle, that's not enough. We should think about  
something smarter, maybe --- the logging takes also a lot of cputime.  
Logging keyframes and updates, maybe, or ...

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] [Sserver-three-d] Offside Bug Report

[Hesham <hes...@gm...>]

Hi Joschka and Junqing Wang,

Sorry for the long delay. I couldn't answer earlier, that's a long story.
Anyway,  Junqing Wang, thank you so much for your report. I'm afraid, I
didn't understand some parts of the report. Actually,
    if (mGameState->GetTime() != time)
    {
             return false;
    }
isn't necessary. That was there to be sure when a new collision doesn't
occur it doesn't go through the offside code. To get rid of it, there is a
simple solution, please take a look at the attached file.

So far as I noticed for the next version there is no offside. In December I
was working on refactoring the offside code (I promised Joschka to finish it
before January but I couldn't). Since it was my first code for the server I
mad a big mistake in its design and that caused a lot of problems in
debugging. Anyway, I got rid of my problems and have more free time. Since
working on the offside doesn't make sense, I wonder if there is something
that I can work on for the new server. (I'm following the discussion
regarding multi-thread)

With kind regards,
Hesham

On 12/21/06, w jq <wj...@ho...> wrote:
>
>                               Offside Bug Report
>
> As all we known that the offside rule in simulator was not perfect. Today
> I
> don`t want to
>
> complain about it, but to solve the problem.
>
> I have watched many many matches . Some team took the advantage of this
> bug:Shooting the
>
> goal when they were offside.
>
> how could they do this ?how could some team can`t do this?
>
> The truth is that this team`s players don`t HIT the ball when they are
> attacking.they just
>
> kick the ball.
>
> so I thought there must be something wrong with "Last kick agent".
>
>
> Thus, I refered to the  function
> void
> Ball::PrePhysicsUpdateInternal(float deltaTime) in ball.cpp
>
> The agent who kicked the ball is recorded , everything seems to be OK.
>
> Then ,I refered to the  function
> bool
> SoccerRuleAspect::CheckOffside()
>
> Add some print code.
> /*****************************************/
>     if (mGameState->GetTime() != time)
>     {
>         GetLog()->Error()
>             << "ERROR: (SoccerRuleAspect) "<<mGameState->GetTime()<< " "
> <<
> time <<endl;
>         return false;
>     }
> /******************************************/
> Then ,when my player was dribbling. I thought the statement
> (mGameState->GetTime() != time)
> shall be FALSE sometimes,but things turned out to be not the same as  I
> thought.
>
> ....
> ERROR: (SoccerRuleAspect) 13.017 13.007
> ERROR: (SoccerRuleAspect) 13.027 13.017
> ERROR: (SoccerRuleAspect) 13.037 13.027
> ....
> After I refered to the function
> void SimulationServer::Step() in Simulationserver.cpp
> , I found the bug.
> /*****************************************/
>                     mSceneServer->Update(mSimStep);
>                     mGameControlServer->Update(mSimStep);
> /*****************************************/
> After Update the Physics(UpdateLastCollidingAgent),
> the sim time will add one sim step.
>
> As a result , if there is a agent kick the ball, the record time will
> aways
> be 0.01
> earlier than current time.
>
>
>
> One of the possible solutions:
>
> Add a bool member "mRecordTimeForKick"to class BallStateAspect
>
> Modify:
> void
> BallStateAspect::UpdateLastCollidingAgent(boost::shared_ptr<AgentAspect>
> agent)
> {
>     mLastCollidingAgent = agent;
>     mLastAgentCollisionTime = mGameState->GetTime();
> }
> ->
> void
> BallStateAspect::UpdateLastCollidingAgent(boost::shared_ptr<AgentAspect>
> agent)
> {
>     mLastCollidingAgent = agent;
>     mRecordTimeForKick = true;
> }
>
> Add "mRecordTimeForKick = false;" to
> BallStateAspect::BallStateAspect() : SoccerControlAspect()
>
> Add "
>     if(mRecordTimeForKick)
>     {
>         mLastAgentCollisionTime = mGameState->GetTime();
>         mRecordTimeForKick      = false;
>      }
>     " to the end of the function --
> void BallStateAspect::UpdateLastCollidingAgent()
>
>
>
>
> /****************************End of
> report*****************************************/
>
> Author:Junqing Wang
> Team:  Apollo3D ,  Nanjing University of Posts & Telecommunications, China
>
> _________________________________________________________________
> 与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Sserver-three-d mailing list
> Sse...@li...
> https://lists.sourceforge.net/lists/listinfo/sserver-three-d
>
>

Re: [simspark-devel] discussion

[Joschka B. <jbo...@un...>]

Hi,

Oliver Obst wrote:
> Hi,
>
> On 04/02/2007, at 3:50 PM, Yuan Xu wrote:
>
>   
>> 2007/2/3, Oliver Obst <Oli...@ne...>:
>>     
>>> sounds all quite good.
>>> I've also found this hints for timing the physics loop (in a computer
>>> game) here: [1], it's an interesting read, at least. From this page,
>>> there are also more interesting articles.
>>>       
> [...]
>   
>>> [1] http://www.gaffer.org/game-physics/fix-your-timestep/
>>>       
>
>
>   
>> The article is great!
>> There is a similar implementation in the simspark ( See void
>> SimulationServer::Step() ).
>> Set the mSimStep to 0.01, then the physics will run in 10ms step.
>>     
>
> a smaller step should make the simulation more stable, but for this,  
> we need to run some experiments (maybe later on).
>
>   
Exactly. So far, I've had good experience with 0.01 s, but we can play 
around to find a good value.
>> I face a problem when try introduce the threads:
>> there is only one scene information in the simulator,
>> then, different threads can not operate the scene information at  
>> the same time.
>> For example, when the agent-management-thread encodes the  
>> perception messages,
>> the scene information should not be changed,
>> so the physics-thread should be hang up.
>> As a result, this kind multi-threads is meaningless, I think.
>>     
>
> I understand the problem. But it's not entirely meaningless, please  
> see below.
>
>   
>> Maybe we need a buffer, like the frame buffer in OpenGL,
>> saving the scene information which will be handled by
>> agent-management-thread to the buffer.
>> But it is not a straight-forward work, for the scene information is
>> stored in different objects.
>>     
>
> Well, one direction to approach that would be (1) to start using  
> threads anyway:
> 1.a) We decide to care about inconsistencies in sensor readings.
> We could start this by using no buffer, and for the beginning, we  
> could use locks so that no 2 threads operate on the scene graph.  
> Later on, if the threads are working, we can think about something to  
> get rid of the big locks (like the proposed buffer).
> 1.b) We decide not to care about inconsistencies in sensor readings.
> We start using threads and no buffers (like 1.a), but care only about  
> multiple writes (which are obviously a bad thing, and shouldn't  
> happen anyway). At the moment, I think the worst thing that can  
> happen would be an inconsistent sensor reading... the physics should  
> be fine. But maybe I'm missing something, what would be the reason  
> for the physics thread to hang up? Inconsistent readings can happen  
> with real sensors as well (e.g. a laser range finder and moving  
> objects etc). Later on, if that's working, we resolve the  
> inconsitency issue by small locks or buffering.
>   

I think we could start with 1a) and guarantee mutually exclusive 
operation on the SceneGraph between the different threads. You can set a 
Mutex for this if you want to use the SceneGraph, then you'll have 
exclusive access, and then remove that Mutex once you're done. This way, 
another thread might have to wait for a while to get access, but you'll 
have correct data all the time. The only way the system could 'hang' is, 
if a Mutex doesn't get removed. But even then, there are time out 
mechanisms that can be used. Since the physics thread runs a lot faster 
than visualization and agent updates, these locks won't occur too often, 
I think. If 1a) turns out to be too slow, we could consider option 1b).
> The alternative approach (2) would be to not use threads in the  
> simulator for now, but to think of a smart single-threaded solution  
> along the lines of the article [1] above. The single-threaded  
> solution would be more interesting for the development phase, because  
> it's easier to debug (and maybe also easier to implement). At the end  
> of the day, I'd prefer a multi-threaded solution, because it might  
> help with the current performance issues (and all the machines are  
> becoming multi-core anyways). But if a single threaded solution is  
> more stable, let's stick with one thread and think about more threads  
> later.
>
>   

Yes, debugging multi-threaded programs is not exactly fun in most cases 
:-( But in the end, the performance gain might be worth it, I think 
(especially on multi-core machines).
>> If there is a class or struct represent the scene information, the
>> work will be easier.
>> But the plug-in mechanism makes the scene changes, so build such a
>> scene class is not simple.
>>     
>
> The original idea of the whole simulator framework was to represent  
> all kind of information of an object in an extended scene graph  
> (tree); this includes visual aspects like textures etc, if an object  
> possesses these. I still think, that the tree kind representation is  
> still very good, but for a few reasons we have to think over this  
> concept again. Firstly, if the monitor is external (a separate  
> program), there is no point in representing (and updating) visual  
> information together with the physical properties of an object.

That's true.
>   
> Secondly, even if the monitor is part of the simulator process (which  
> would be nice to avoid serialization), the visual information doesn't  
> need to be updated at the same rate as the physical information.
>   

What visual information do you mean? Position and orientation are needed 
by both physics and visuals, and stuff like textures and the meshes 
(usually) don't change much I think. Oh, but maybe you're thinking of 
animation data?

I think having all the necessary information in one scene structure 
(like the scene tree) is nice if you have internal rendering.
> My feeling is that some of the steps to a solution are something like  
> this (comments more than welcome):
> - initially (or whenever new objects are spawned), the simulator  
> needs to tell the monitor _how_ everything wants to be displayed (in  
> terms of textures, meshes etc). The simulator has to store this  
> information somewhere (but not necessarily in the part of the tree  
> that get's updated by the physics).
> - if we want an extra thread for the visualization, we should check  
> if it's better to copy the scene tree or if it's better to let the  
> visualization plugin access the scene tree directly (using a lock or  
> so). Copying takes extra time, but can have advantages too.
>   
If you want to copy, you have to lock anyways if you're using threads, I 
think. Otherwise you might have inconsistent data to display.
> - the same thing holds for the agents' sensors, with the difference  
> that these have to be coupled with the actual simulation speed,  
> whereas the visualization just displays the situation as it currently  
> is (i.e. the visualization can run at a constant framerate even if  
> the simulator step rate changes).
> - the actions of an agent should then not modify the world directly,  
> but be placed in a queue and the physics loop should take care of  
> them (so that there is only a single thread actually changing the  
> world directly). I think that's not fundamentally different from the  
> current approach, but still worth looking over.
>   

That sounds reasonable.
> - if we want the agents to run as fast as possible, we should use  
> something like a syncmode in 2D, but for giving the agents enough  
> time to think, the simulator should wait with the physics if it is  
> faster than real time for competition settings.
>   

Yeah, a sync mode would definitely be a nice feature :-)

Cheers,
Joschka

Re: [simspark-devel] discussion

[Oliver O. <Oli...@ne...>]

Hi,

On 04/02/2007, at 3:50 PM, Yuan Xu wrote:

> 2007/2/3, Oliver Obst <Oli...@ne...>:
>> sounds all quite good.
>> I've also found this hints for timing the physics loop (in a computer
>> game) here: [1], it's an interesting read, at least. From this page,
>> there are also more interesting articles.
[...]
>> [1] http://www.gaffer.org/game-physics/fix-your-timestep/


> The article is great!
> There is a similar implementation in the simspark ( See void
> SimulationServer::Step() ).
> Set the mSimStep to 0.01, then the physics will run in 10ms step.

a smaller step should make the simulation more stable, but for this,  
we need to run some experiments (maybe later on).

> I face a problem when try introduce the threads:
> there is only one scene information in the simulator,
> then, different threads can not operate the scene information at  
> the same time.
> For example, when the agent-management-thread encodes the  
> perception messages,
> the scene information should not be changed,
> so the physics-thread should be hang up.
> As a result, this kind multi-threads is meaningless, I think.

I understand the problem. But it's not entirely meaningless, please  
see below.

> Maybe we need a buffer, like the frame buffer in OpenGL,
> saving the scene information which will be handled by
> agent-management-thread to the buffer.
> But it is not a straight-forward work, for the scene information is
> stored in different objects.

Well, one direction to approach that would be (1) to start using  
threads anyway:
1.a) We decide to care about inconsistencies in sensor readings.
We could start this by using no buffer, and for the beginning, we  
could use locks so that no 2 threads operate on the scene graph.  
Later on, if the threads are working, we can think about something to  
get rid of the big locks (like the proposed buffer).
1.b) We decide not to care about inconsistencies in sensor readings.
We start using threads and no buffers (like 1.a), but care only about  
multiple writes (which are obviously a bad thing, and shouldn't  
happen anyway). At the moment, I think the worst thing that can  
happen would be an inconsistent sensor reading... the physics should  
be fine. But maybe I'm missing something, what would be the reason  
for the physics thread to hang up? Inconsistent readings can happen  
with real sensors as well (e.g. a laser range finder and moving  
objects etc). Later on, if that's working, we resolve the  
inconsitency issue by small locks or buffering.
The alternative approach (2) would be to not use threads in the  
simulator for now, but to think of a smart single-threaded solution  
along the lines of the article [1] above. The single-threaded  
solution would be more interesting for the development phase, because  
it's easier to debug (and maybe also easier to implement). At the end  
of the day, I'd prefer a multi-threaded solution, because it might  
help with the current performance issues (and all the machines are  
becoming multi-core anyways). But if a single threaded solution is  
more stable, let's stick with one thread and think about more threads  
later.

> If there is a class or struct represent the scene information, the
> work will be easier.
> But the plug-in mechanism makes the scene changes, so build such a
> scene class is not simple.

The original idea of the whole simulator framework was to represent  
all kind of information of an object in an extended scene graph  
(tree); this includes visual aspects like textures etc, if an object  
possesses these. I still think, that the tree kind representation is  
still very good, but for a few reasons we have to think over this  
concept again. Firstly, if the monitor is external (a separate  
program), there is no point in representing (and updating) visual  
information together with the physical properties of an object.  
Secondly, even if the monitor is part of the simulator process (which  
would be nice to avoid serialization), the visual information doesn't  
need to be updated at the same rate as the physical information.

My feeling is that some of the steps to a solution are something like  
this (comments more than welcome):
- initially (or whenever new objects are spawned), the simulator  
needs to tell the monitor _how_ everything wants to be displayed (in  
terms of textures, meshes etc). The simulator has to store this  
information somewhere (but not necessarily in the part of the tree  
that get's updated by the physics).
- if we want an extra thread for the visualization, we should check  
if it's better to copy the scene tree or if it's better to let the  
visualization plugin access the scene tree directly (using a lock or  
so). Copying takes extra time, but can have advantages too.
- the same thing holds for the agents' sensors, with the difference  
that these have to be coupled with the actual simulation speed,  
whereas the visualization just displays the situation as it currently  
is (i.e. the visualization can run at a constant framerate even if  
the simulator step rate changes).
- the actions of an agent should then not modify the world directly,  
but be placed in a queue and the physics loop should take care of  
them (so that there is only a single thread actually changing the  
world directly). I think that's not fundamentally different from the  
current approach, but still worth looking over.
- if we want the agents to run as fast as possible, we should use  
something like a syncmode in 2D, but for giving the agents enough  
time to think, the simulator should wait with the physics if it is  
faster than real time for competition settings.


cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] discussion

[Yuan X. <xuy...@gm...>]

2007/2/3, Oliver Obst <Oli...@ne...>:
> sounds all quite good.
> I've also found this hints for timing the physics loop (in a computer
> game) here: [1], it's an interesting read, at least. From this page,
> there are also more interesting articles.
>
> I'm also re-directing this thread to the simspark-devel mailing list
> (I know you're all subscribed :-), because the advantage of this list
> is that everybody interested can read what's going on and the emails
> get archived automatically. Please, let's continue our discussions
> there.
>
> cheers
> Oliver
>
> [1] http://www.gaffer.org/game-physics/fix-your-timestep/
>

The article is great!
There is a similar implementation in the simspark ( See void
SimulationServer::Step() ).
Set the mSimStep to 0.01, then the physics will run in 10ms step.

I face a problem when try introduce the threads:
there is only one scene information in the simulator,
then, different threads can not operate the scene information at the same time.
For example, when the agent-management-thread encodes the perception messages,
the scene information should not be changed,
so the physics-thread should be hang up.
As a result, this kind multi-threads is meaningless, I think.

Maybe we need a buffer, like the frame buffer in OpenGL,
saving the scene information which will be handled by
agent-management-thread to the buffer.
But it is not a straight-forward work, for the scene information is
stored in different objects.

If there is a class or struct represent the scene information, the
work will be easier.
But the plug-in mechanism makes the scene changes, so build such a
scene class is not simple.

Any ideas?

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] discussion

[Oliver O. <Oli...@ne...>]

	
On 03/02/2007, at 2:21 AM, Yuan Xu wrote:

> Hi Joschka,
>
>
>> What do you think about this approach? Do you think you could work  
>> on that?
>
> Yes, multi-threads should be introduced.
> I will try to work on this.
> As I know, we can use three thread libraries: pthread, boost::thread
> and SDL::thread,
> and I think we may choose one between boost::thread and SDL::thread,
> since they are all convenient and platform-independence.
> what do you think about it?

sounds all quite good.
I've also found this hints for timing the physics loop (in a computer  
game) here: [1], it's an interesting read, at least. From this page,  
there are also more interesting articles.

I'm also re-directing this thread to the simspark-devel mailing list  
(I know you're all subscribed :-), because the advantage of this list  
is that everybody interested can read what's going on and the emails  
get archived automatically. Please, let's continue our discussions  
there.

cheers
Oliver

[1] http://www.gaffer.org/game-physics/fix-your-timestep/

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] discussion about timer

[Yuan X. <xuy...@gm...>]

Hi all,

About the timer again,
Joschka supposed to implement a mechanism just like 2D server,
discard the whole SPADES,
but in my my opinion, we should create a new commserver with timer(not
try tracking
agents, but timing), the commserver should not send the overtime
command to the server.

What do you think about it?
Any comment is welcome ;-)

our discussion is here:

/////////////////////////BEGIN///////////////////////////////////////
>> No, I think it wouldn't need that. To my understanding, the commserver
>> had the purpose of tracking the instruction cycles used by an agent and
>> doing the communication with the server. I think the agents should be
>> able to connect to the server directly (like in the simspark right now).
>
> OK, if there is no "commserver", the simulator is much more like the
> 2D simulator, I think the technology is mature.

I agree. It's simple, but easy to implement, and with the right network
setting, definitely suited for a competition environment.

> As we know the SPADES tries to tracking the instruction cycles, but it
> is hard too do, and the agent thinking is not only the CPU consumption
> but also any other operation of the agent.
> We should implement a new timer to replace it, but another function of
> commserver is applicable, communication by commserser keeps the
> influence of net away.
> Here I means we do NOT set the net "correctly", i.e. in the lab with a
> public switch, or anything doesn't match the competition settings. And
> the competition settings are changed between games, so we can not
> prove this is not a affection of team's performance.

I like the idea of having independence from network activity in the
simulation. On the other hand, this means a lot more "book keeping"
between the server and the commservers, which is harder to implement and
can slow down the simulation speed (to some extent).

> And I think we should try to make the simulator
> Hardware-Platform-Independent, although it nearly impossible.
> ;-D

You say it, it would be great, but it's almost impossible.

> And there is disadvantage of discarding the whole "commserver":
> If discard the "commserver", all the teams will be forced to implement
> a new communication module, and may need multithreading and complex
> synchronous mechanism.
> But all these technologies are not the focus of AI and RoboCup.

Yes that's true. I guess the new server (possibly with Humanoid robots)
will force teams to implement quite a lot of new code anyways, but we
should try to minimize the work.

> In my opinion, we should a new commserver with timer(not try tracking
> agents, but timing), the commserver should not send the overtime
> command to the server.

I think it sounds good. I will bring your proposal to the technical
committee discussion and I hope that we will have a decision soon.

///////////////////////////END///////////////////////////////////////





-- 
Best wishes!

Xu Yuan
Institute of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

[simspark-devel] discussion about timer

[Yuan X. <xuy...@gm...>]

Hi all,

I am willing to work on the timer.

I have discussed with Joschka,
he told me that the SPADES should be replaced by a new timer which is
much more like the 2D server timer.

Joschka suggested me ask additional details about what
needs to be done in this mail-list.

Thanks for your time.

-- 
Best wishes!
Xu Yuan

[simspark-devel] discussion about timer

[Yuan X. <xuy...@gm...>]

Hi all,

I am willing to work on the timer.

I have discussed with Joschka,
he told me that the SPADES should be replaced by a new timer which is
much more like the 2D server timer.

Joschka suggested me ask additional details about what
needs to be done in this mail-list.

Thanks for your time.

-- 
Best wishes!
Xu Yuan

Re: [simspark-devel] Re: [BugReport]the kickeffector bug?

[Yuan X. <xuy...@gm...>]

SGkgSmFuLAoKMjAwNi80LzI3LCBKYW4gTXVycmF5IDxtdXJyYXlAdW5pLWtvYmxlbnouZGU+Ogo+
IERpZCB5b3UgdHJ5IHRvIGtpY2sgaW4gImJvdGggZGlyZWN0aW9ucyIgYWxvbmcgdGhlIGF4ZXMs
IGkuZS4gYWxvbmcKPiB0aGUgeC1heGlzICJ0b3dhcmRzIG9wcG9uZW50IGdvYWwiIGFuZCAidG93
YXJkcyBvd24gZ29hbCIgYW5kIGFsb25nCj4gdGhlIHktYXhpcyB0byB0aGUgInRvcCIgYW5kIHRv
IHRoZSAiYm90dG9tIiBvZiB0aGUgZmllbGQ/IERpZCB0aGUKPiBkaXJlY3Rpb25zIG1ha2UgYW55
IGRpZmZlcmVuY2VzPwoKSSBoYXZlIHRlc3RlZCBpbiA0IGRpcmVjdGlvbnMsIHlvdSBjYW4gd2F0
Y2ggdGhlIGxvZ3Mgd2hpY2ggSSBhdHRhY2hlZC4KVGhlIE9yaWdpbmFsS2lja0VmZmVjdG9yLmxv
ZyB0ZXN0ZWQgaW4gIm1Ub3JxdWVGYWN0b3IqZm9yY2VbMV0vc2FsdDo6ZzJQSSIsCmFuZCB0aGUg
TW9kaWZpZWRLaWNrRWZmZWN0b3IubG9nIHRlc3RlZCBpbiAiLW1Ub3JxdWVGYWN0b3IqZm9yY2Vb
MV0vc2FsdDo6ZzJQSSIuCgp5b3UgY2FuIHNlZSB0aGUgZGlmZmVyZW5jZSBjbGVhcmx5OgoKVGhl
IGtpY2sgcG9zaXRpb24gYXJlIGFsbCAoMCwwKQoKLS0tLSB0aGUgT3JpZ2luYWxLaWNrRWZmZWN0
b3IgdGVzdDotLS0tLS0tCnRvd2FyZHMgb3Bwb25lbnQgZ29hbCA6IHN0b3AgcG9zID0gKDI4Ljk0
NzggLTIuMDU0NzcpICA6IGRpc3QgPSAyOC45CnRvd2FyZHMgb3duIGdvYWwgICAgIDogICAgICAg
ICAgICgtMjYuMjAwMSwgLTAuMjczNDkzKSA6ICAgICAgMjYuMgp0b3AgICAgICAgICAgICAgICAg
IDogICAgICAgICAgICgtMC4zMzg4NjYgMTkuODE0MykgIDogICAgICAgMTkuOApib3R0b20gICAg
ICAgICAgICAgIDogICAgICAgICAgICgtMC45NzA1NjEgLTE5Ljk0NTEpICA6ICAgICAgMTkuOQoK
LS0tLSB0aGUgTW9kaWZpZWRLaWNrRWZmZWN0b3IgdGVzdDotLS0tLS0tCnRvd2FyZHMgb3Bwb25l
bnQgZ29hbCA6IHN0b3AgcG9zID0gKDI2Ljk1OTggLTMuMzczNTUpICA6IGRpc3QgPSAyNy4xCnRv
d2FyZHMgb3duIGdvYWwgICAgIDogICAgICAgICAgICgtMjUuOTE3MyAxLjY0MTUyKSAgOiAgICAg
ICAyNi4wCnRvcCAgICAgICAgICAgICAgICAgOiAgICAgICAgICAgKC0wLjYyMjU1NSAyNi44NjQ0
KSAgOiAgICAgIDI2LjcKYm90dG9tICAgICAgICAgICAgICA6ICAgICAgICAgICAoLTQuMDgxMTUg
LTI2LjE4NDYpICA6ICAgICAgMjYuNQoKQWx0aG91Z2gsIG9ubHkgb25lIGRhdGEgaW4gZXZlcnkg
c2l0dWF0aW9uLApJIHRoaW5rIGl0IGlzIGNsZWFyIGVub3VnaCA7LSkKCgotLQpCZXN0IHdpc2hl
cyEKWHUgWXVhbgo=

Re: [simspark-devel] Re: [BugReport]the kickeffector bug?

[Jan M. <mu...@un...>]

Hi Yuan,

|On Thu, 27 Apr 2006 22:35:48 +0900, Joschka Boedecker <jbo...@un...> said:

> thanks a lot for the bug report. I'm forwarding it to the developers list and 
> I'll try to take a closer look tomorrow.

> yuan xu wrote:
>> Dear Joschka,
>> I think I found a bug in kickeffector:
>> While the agent both kick with the same kick force, but with
>> differentdirections, the kick distance will be different! That is, when the
>> agent act "kick(0,100)" in direction 0(means kickalong x axis), the
>> distance is about 27m,but, when the agent act "kick(0,100)" in direction
>> 90(means kick alongy axis), the distance is only about 20m. That's strange!

Did you try to kick in "both directions" along the axes, i.e. along
the x-axis "towards opponent goal" and "towards own goal" and along
the y-axis to the "top" and to the "bottom" of the field? Did the
directions make any differences?

Bye,
 Jan

-- 
Jan Murray + Uni Koblenz + http://www.uni-koblenz.de/~murray/contact.html
                 ________________________________________________________
                 \"Trusting every aspect of our lives to a giant computer
                  \ was the smartest thing we ever did!" -- Homer Simpson

[simspark-devel] Re: [BugReport]the kickeffector bug?

[Joschka B. <jbo...@un...>]

Dear Yuan,

thanks a lot for the bug report. I'm forwarding it to the developers list and 
I'll try to take a closer look tomorrow.

Thanks again!

Joschka

you wrote:
> Dear Joschka,
> I think I found a bug in kickeffector:
> While the agent both kick with the same kick force, but with
> differentdirections, the kick distance will be different! That is, when the
> agent act "kick(0,100)" in direction 0(means kickalong x axis), the
> distance is about 27m,but, when the agent act "kick(0,100)" in direction
> 90(means kick alongy axis), the distance is only about 20m. That's strange!
> So, I looked into the source code of kickeffector,
> In kickeffector.cpp
> 00050 KickEffector::Realize(boost::shared_ptr<ActionObject> action)
> 0012600127     const Vector3f
> torque(mTorqueFactor*force[1]/salt::g2PI,00128                          
> mTorqueFactor*force[0]/salt::g2PI,00129                          
> 0.0);00130 I think it is a bug here, I think the torque added to the ball
> should be Vector3f torque(-mTorqueFactor*force[1]/salt::g2PI,              
>  mTorqueFactor*force[0]/salt::g2PI,                0.0); the first paramter
> should be "-mTorqueFactor*force[1]/salt::g2PI", right? After change this, I
> test again, and the kick distance is onlydetermined by the kick force. Hope
> this is useful :-)
>
> --Best wishes!Xu Yuan

[simspark-devel] excuse me after a long absent

[Hesham <hes...@gm...>]

Hi Oliver and Joschka

First of all, I'm sorry I didn't send the fixes on time. I spent my spare
time on our team for Iran Open and Dutch Open, besides Sunday(tomorrow) I'm
going to Oxford and this took a lot of time, but for six weeks I'll have
more free time. Anyway I suppose I can make ready the fixes for next week
(if it isn't very late(?)), I hope I don't break my promise again.

I looked at the logs of Dutch Open, Jelle was right, because of restricted
vision it's difficult for attackers to shot fine. So a good goalie with 2
meter catch margin can catch almost all shots. If you don't disagree I'll
change it to 1 meter for the fix.

Best wishes,
Hesham

[simspark-devel] Re: offside

[Hesham <hes...@gm...>]

Dear Oliver

Unfortunately I couldn't complete the offside tests tonight. But I hope to
make it ready tomorrow or at least next week before the next version.

I'd like to know your opinion about:

Virtual Werder 3D Team:
"The third is something that could again lead to problems in the current
implementation. As we see it, every time the ball comes from an opposing
player, the situation is decided not to be offside in the current
implementation. The official rule differentiates between rebounding from an
opponent (which is offside) and the ball being played by that opponent
(which is not offside).

A situation could be:

---------GOAL---------
          K

             A
     Ao

The attacker performs a shot at the goal. The ball only hits the keeper and
bounces to the right attacker. This is offside according to FIFA, while the
server would see the ball coming from an opponent and allow this situation.
However, if the keeper got the ball under control and then plays the ball s=
o
that it gets to the right attacker, it is not offside for FIFA.
For the server, this means we need a criterion for "just bouncing or really
playing". A possible idea could be to check if the keeper uses the kick
effector (defining this as "playing the ball") or not (defining as
"bouncing")."

I'm afraid, I disagree. Using the kick effector isn't a good criterion, I
think I'll make trouble for us. Because we can't see what the keeper is
doing, and perhaps a team complains and says this is a bug in the server an=
d
their goalie hasn't kicked the ball. I suppose it would be better if we
assume the opponent has kicked the ball, this way all teams should play
safer and can't complain after a situation like this. Anyway implementing
this idea(using this criterion) isn't difficult, if you decide this should
be implemented for the next version, I'll make it ready.

(I'm sorry I don't know Virtual Werder's email address and because of this =
I
couldn't send them this email)

Virtual Werder 3D Team:
"One could probably drop this point for the implementation, but at least
this change to the official rules should be mentioned in the manual."

I'm sorry this is my fault. I should spend time to write a document about
the implemented offside. I promise to write this as soon as possible. Excus=
e
me.

Virtual Werder 3D Team:
"There are some more problems, which we could not fix, as this would involv=
e
more complex changes, and we do not know the code well enough to do that."

I've made the offside code more cleaner and wrote more comments, I'll send
it tomorrow after the tests.

All the best,
Hesham

[simspark-devel] Re: rcssserver3D release

[Hesham <hes...@gm...>]

On 3/1/06, Oliver Obst <fr...@tz...> wrote:
>
> On Wednesday 01 March 2006 18:43, Joschka Boedecker wrote:
> > I just checked out the code from the CVS and compiled from scratch
> > without any problems.
>
> compiles also fine for me.
> I'm just trying to solve a problem with the restricted vision perceptor;
> the predicate lists for my agents are always empty :-(



This may also help, I compiled and test it, it's fine for me too.

Hesham

[simspark-devel] Re: rcssserver3D release

[Oliver O. <fr...@tz...>]

On Wednesday 01 March 2006 18:43, Joschka Boedecker wrote:
> I just checked out the code from the CVS and compiled from scratch
> without any problems.

compiles also fine for me.
I'm just trying to solve a problem with the restricted vision perceptor; 
the predicate lists for my agents are always empty :-(

cheers
Oliver

-- 
Oliver Obst                     form follows function. Louis Sullivan
Uni Bremen    +49 421 218 4676
Intelligent Systems Department      Center for Computing Technologies

[simspark-devel] Re: rcssserver3D release

[Joschka B. <jbo...@un...>]

Oliver Obst wrote:
> Hi Yuan,
>
> On Wednesday 01 March 2006 16:50, Yuan Xu wrote:
> > It is strange, and I delete the last two blank lines, the bootstrap
> > seems working.
>
> OK, strange, but anyway, thanks for letting me know. I'll remove the last
> blank lines in the repository.
>
> > Step2. configure
>
> I don't know about the other bugs right now. Seems to be something strange
> with your shell (or with the files in the repository). Somebody else any
> ideas?

I just checked out the code from the CVS and compiled from scratch without any 
problems.

Cheers,
Joschka

[simspark-devel] Re: rcssserver3D release

[Oliver O. <fr...@tz...>]

Hi Yuan,

On Wednesday 01 March 2006 16:50, Yuan Xu wrote:

> It is strange, and I delete the last two blank lines, the bootstrap
> seems working.

OK, strange, but anyway, thanks for letting me know. I'll remove the last 
blank lines in the repository.

> Step2. configure

I don't know about the other bugs right now. Seems to be something strange 
with your shell (or with the files in the repository). Somebody else any 
ideas?

cheers
Oliver

-- 
Oliver Obst                     form follows function. Louis Sullivan
Uni Bremen    +49 421 218 4676
Intelligent Systems Department      Center for Computing Technologies

[simspark-devel] Re: rcssserver3D release

[Yuan X. <xuy...@gm...>]

SGkgYWxsLAoKSSB0cmllZCB0byBidWlsZCB0aGUgcmNzc3NlcnZlcjNEIGluIHRoZSBDVlMoMjAw
Ni8yLzI4KSwgYnV0IEkgYW0gZmFpbGVkIDooCgpTdGVwMS4gYm9vdHN0cmFwCgpXaGVuIEkgcnVu
ICIuL2Jvb3RzdHJhcCIsIGJ1dCB0aGUgb3V0cHV0IGlzCgo6IGJhZCBpbnRlcnByZXRlcjogbm8g
c3VjaCBmaWxlIG9yIGZsb2RlcgoKYW5kIEkgcnVuICJhdXRvcmVjb25mIC0taW5zdGFsbCIgbWFu
dWFsbHksIGl0IHNlZW1zIE9LLgpJdCBpcyBzdHJhbmdlLCBhbmQgSSBkZWxldGUgdGhlIGxhc3Qg
dHdvIGJsYW5rIGxpbmVzLCB0aGUgYm9vdHN0cmFwCnNlZW1zIHdvcmtpbmcuCgpTdGVwMi4gY29u
ZmlndXJlCldoZW4gSSBydW4gIi4vY29uZmlndXJlIC0tZW5hYmxlLWtlcm9zaW4iLCB0aGUgZXJy
b3IgY2FtZToKCmNvbmZpZ3VyZTogY3JlYXRpbmcgLi9jb25maWcuc3RhdHVzCmNvbmZpZy5zdGF0
dXM6IGNyZWF0aW5nIE1ha2VmaWxlCmNvbmZpZy5zdGF0dXM6IGNyZWF0aW5nIFwKLmluZmlnLnN0
YXR1czogZXJyb3I6IGNhbm5vdCBmaW5kIGlucHV0IGZpbGU6IFwKCkkgZG9uJ3Qgd2h5IDooCmFu
ZCB0aGVuIEkgbWFrZSB0aGUgQUNfQ09ORklHX0ZJTEVTKC4uLikgaW4gb25lIGxpbmUgKHdpdGhv
dXQgXCkgaW4KdGhlIGNvbmZpZ3VyZS5hYwpJIHNlZW1zIHdvcmtpbmcuIFdoeT8/PwoKU3RlcDMu
IG1ha2UKQW5kIHRoaXMgdGltZSwgc3RpbGwgZXJyb3I6CgouLi8uLi9saWIvb3h5Z2VuLy5saWJz
L2xpYm94eWdlbl9kZWJ1Zy5zbzogdW5kZWZpbmVkIHJlZmVyZW5jZSB0bwpgc3BhZGVzOjpTaW1F
bmdpbmU6OnN0YXJ0TmV3QWdlbnQoc3RkOjpfUmJfdHJlZV9jb25zdF9pdGVyYXRvcjxzdGQ6OnBh
aXI8c3RkOjpiYXNpY19zdHJpbmc8Y2hhciwKc3RkOjpjaGFyX3RyYWl0czxjaGFyPiwgc3RkOjph
bGxvY2F0b3I8Y2hhcj4gPiBjb25zdCwKc3BhZGVzOjpBZ2VudFR5cGUqPiA+LCBpbnQpJwpjb2xs
ZWN0MjogbGQgcmV0dXJuZWQgMSBleGl0IHN0YXR1cwoKSSBkb24ndCBrbm93IGhvdyB0byBzb2x2
ZSBpdC4KQ2FuIGFueWJvZHkgZ2l2ZSBoZWxwPwpUaGFua3MhCgpQUzogSSBpbnN0YWxsZWQgdGhl
IHJjc3NzZXJ2ZXIzRC0wLjQgYmVmb3JlLCBhbmQgdGhlIE9TIGlzIEZDNCwgYW5kIEkKYWxzbyB0
cmllZCBpbiBGQzIuCgotLQpCZXN0IHdpc2hlcyEKWHUgWXVhbgo=