Re: [simspark-devel] APL Update

[Hedayat V. <hed...@ai...>]

Hi Andreas,

On ۱۰/۰۲/۰۲  02:46, ah...@un... wrote:
> Hi,
>
>
> Just a few things...
>
> 1) Joschka and I have reflected on the design and decided that we want to
> employ the physicsserver and use it as the (exclusive) interface between
> the physics classes and the rest of simspark. Right now, the RSGImporter
> creates physics objects by itself and adds them to the scene graph, and we
> want to move this functionality to the physicsserver. The physicsserver
> will also be in charge of creating implementation objects, so the
> ImpFactory will be completely removed over the course of this.
>    
That's very nice!


> 2) Thanks to Hedayat's input, I was able to get rid of the
> staticphysicsmethods class completely. :-) I'm actually very happy about
> this, since this was the workaround I felt the most uncomfortable about.
>    
:)

> 3) It turned out that deriving engine-specific classes from the
> engine-unspecific version of their superclass does not help me fix the
> Joint problem. I'm now contemplating undoing this change - it doesn't harm
> the functionality or the performance, but it "feels" weird and it causes
> engine-specific classes to be derivied from BaseNode, which is something
> we said we wanted to avoin in the beginning.
>    
:P Yes I figured it out myself last night that I was thinking a little 
more about it. Sorry! I have another solution in mind but I prefer to 
say it after a little more thinking and checking with the code to make 
sure that I don't do a similar mistake again. :(

> ---
> And now for two completely new things:
> ---
>
> 4) Right now, all header files in the /int and /ode directories are
> completely undocumented. Doing this would be redundant, as the methods
> that the calls are delegated to usually have the same name and the same
> functionality as the documented method which calls them. I.e. I would just
> be copy-pasting most comments. I assume I'll have to do this anyway,
> though, because it's good sport, right? ;-)
>    
:) About the classes in the int/ directory, yes I think it is needed as 
they are interfaces which should be implemented for each engine and the 
one who is implementing them should have a reference in a reasonable 
place. And these interface classes might have functions which differ a 
little from the abstract classes who use them.
But about the ode/ classes, I'm neutral at this point!

> 5) In the standard text that precedes each source file, I find a line like:
>
> "$Id: boxcollider.h 155 2010-02-01 05:08:06Z a-held $"
>
> I observed that SVN updates this line automatically when the file is
> changed in a commit. However, no matter what I do, this does not work for
> new files. So what do I do with them?
>    
You should add "Id" keyword to "svn:keywords" property of the new files.

Thanks,
Hedayat

>
>
> thanks,
>
> Andreas
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the business
> Choose flexible plans and management services without long-term contracts
> Personal 24x7 support from experience hosting pros just a phone call away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>