Andy Ross writes: > There are actually two problems here. The first, making the object > move, is relatively easy. It will require C++ code, though. One way > I've thought about doing it is to put the object in the property tree > rather than the static scenery description. Something like: > > /scenery/objects[n]/model-file=Models/carrier.ac3 > /lat-deg=nn.nnnnnn > /lon-deg=nn.nnnnnn > /alt-ft=nnn > /hdg-deg=nnn > /speed-kt=nnn
I've considered something similar, but I don't think it's scalable. Imagine two year from now, if people have created tens of thousands of custom objects for scenery around the world. This requires more thought. > But there's another problem -- the current FDMs model gear force using > only the aircraft's velocity. They assume the ground is fixed and > unmoving. This means that you could land on the carrier, but would > then come to a stop relative to the earth, while the carrier slipped > smoothly out from under you. I hadn't thought of that -- interesting. > I'm not quite sure about the "right" way to do this -- doing it in the > low-level ssg "hitlist" collision detection is going to be rather > complicated, and won't perform well. Perhaps the best way to handle > it would be to special case "carrier deck" objects (more generally, > anything moving on which the gear are expected to rest), and expose > them directly to the FDMs via a "ground velocity" parameter. What about landing a helicopter on top of a moving train in a James Bond emulator? This is a nasty problem. I do think that it should be possible to locate the ssgVertexTable under the wheels, walk up to the nearest branch, then lock the gear to the object's motion somehow. Probably not this week, though. All the best, David -- David Megginson [EMAIL PROTECTED] _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
