[Ns-bugs] [Bug 511] Need ability to change mobility model

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=511





--- Comment #5 from Mathieu Lacage <mathieu.lacage at sophia.inria.fr>  2009-04-16 07:27:28 EDT ---
(In reply to comment #4)

> > I think that the challenge with this approach is that it somewhat abandons an
> > ns-3 invariant which is that, once created, the whole object topology does not
> > change. Specifically, this means that the ConfigStore won't be able to capture
> > the parameters of the models you change on the fly. Don't you have a per-node
> > object which manages the mobility model changes ? If so, can't you just make
> > this per-node object be a MobilityModel subclass ?
> > 
> 
> I have such an object, but it is in Python, and for performance reasons it
> cannot directly be a mobility model.
> 
> This is not really topology information, IMHO.  The main point of

I said "object topology", not "network topology" and, by that, I meant: "the
graph of pointer interconnections of C++ objects deriving from ns3::Object".

> HierarchicalMobilityModel is that you can have a node traveling inside a
> vehicular node, and I am putting this model to good use.  However, this
> HierarchicalMobilityModel is not very useful if a node is always attached to
> the vehicle and cannot leave the vehicle or switch to another vehicle.  I know
> you agree with me because the attributes Parent and Child had already existed
> before this patch :-)

Nice try, but, the reason why Parent and Child attributes where there was only
to make is possible to control from ConfigStore and GtkConfigStore the
attributes of the child and parent models. i.e., to read them. I made them
settable because I am stupid.

> My patch is only adding a special value to the Parent attribute.  Parent ==
> NULL is currently invalid; with my patch, Parent == NULL means "take the Child
> mobility model as absolute coordinates, relative to the world (0,0,0)".
> 
> In other words, with the patch, Parent == NULL has the same effect as Parent ==
> StaticMobilityModel(0,0,0), but is simpler and more efficient.

I could be convinced to pull this in if you beef up the documentation :)

To summarize, that specific patch is ok if there is enough documentation but,
the way you use this code in your tree is just plain evil and I hope no one
ever gets the same idea :)


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.