RE: [Flightgear-devel] Cannot specify --aircraft in system.fgfsrc
--- David Megginson [EMAIL PROTECTED] wrote: The idea was that system.fgfsrc is system-wide, while .fgfsrc is per-user. For Windows, perhaps we should look for fgfs.cfg in My Documents or wherever (is there any concept of separate user directories yet?). $USERPROFILE on WinNT shold resolve to the root of the users home directory. $SYSTEMROOT should resolve to the operating system root directory. Many cross platform apps (X-Plane as an example) use the OS root directory ($SYSTEMROOT) to store stuff. I don't know if this is good practice (I don't care for it personally), but nonetheless. IMHO, it would be nice to see default config file names and locations be names that would work across all platforms and to see that they land in places on a given OS that have analogies to each other. Better, IMHO, would be to keep default configuration info encapsulated under the application root somewhere, with command line options for specifying alternate locations and/or names. I guess this flies in the face of what applications typically do on a UNIX machine. Tony = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Not that my input means diddly ... but YES. I had the exact same thought. Wouldn't it be great it the terrasync util could be pointed at an http server that could stream data back. Simple, well known type of service. Opens the door to random individuals hosting scenery even ? Tony --- Christian Mayer [EMAIL PROTECTED] wrote: Norman Vine wrote: Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? IMHO we should switch to HTTP. This avoids firewall problems and clients are also easy to get. CU, Christian = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
somewhat OT (was Re: [Flightgear-devel] heads up ...)
you know, i've been thinking about the nature of bandwidth, storage and mirrors as it relates to open source for a while as I've seen bandwidth and mirroring discussions before. i wanted to throw some thoughts out there to this group ... just for fun. feel free to care or not ... it occurs to me that there might be some sort of lesson in P2P, and mirroring as it relates to scaling and bandwidth/disk space sharing. for instance, I am sending e-mail right now from my own domain. I pay a small fee for this service, for which I _mostly_ use it for e-mail. For my fee, I end up with a fair bit of bandwidth and disk space that I don't use. Like most ISP's, my provider allows me to develop PHP until my heart is content. Now imagine ... if FlightGear had a PHP application that I could install at my domain ... and with a registration/setup process I could selectively or otherwise choose to host stuff from flightgear.org. A potential consumer of these goods would never come to my domain, they would always go to flightgear.org, choose the content they were looking for, and under the covers, complementary software to that which I am running at my domain, would pick my site or some other site based on the content type, or metrics information about the capable sites, and would redirect the users browser to the content in question for download. Kind of a distributed content management system. The installed software on both ends would probably make it easy for me to sync the goo that I am hosting to whatever the latest is on the mirrored domain. The software running on the primary site would make it easy for me, the donater to pick content that I would want to host, potentially based on a) stuff I personally care about b) the size of a given mirrorable chunk c) statistics that the primary site keeps about how popular particular chunks of content are (meaning it might push my bandwidth limits on my end as the donater) The system would be flexible enough that I as the donater could throttle or shutdown the content I was hosting if I was getting past my bandwidth threshold ... and this would be transparent as the refferrer would simply pick another site out of its list so the user would be none the wiser. It sounds kind of lofty perhaps ... but personally ... defining a basic request/response contract between the primary and donater systems over HTTP and some basic UI designs would make it fairly trivial. Then, implementation could be in anything, CGI, PHP, servlets, JSP, carrier pigeon. random thoughts ... Tony --- Martin Spott [EMAIL PROTECTED] wrote: I haven't given any thought to soliciting bandwidth donations recently. However, that is a very good idea. My sense is that FTP is what kills me here. It would be great if we could move the official ftp site to somewhere with higher bandwidth which could handle a lot more concurrent connections. Which bandwidth, how many concurrent user connections do you consider as 'useful' ? Martin. -- = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] XMLSchema or DTD ?
... for preferences.xml ? anyone ? Bueller ? Particulary sim/sim and environment/environment. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] trying to confirm
all, i am trying to confirm my brief investigation. it appears to me, by looking at fgfs --help --verbose output that there is no mechanism for providing the main binary with an argument pointing at some other rendition of preferences.xml ? Is this correct ? (I hope so ...) This would simplify the configuration permutations I have to worry about up front for a project I am working on. Cheers, Tony = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] trying to confirm
mmm ...
I got the sense that --config was for pointing at a file containing other
-- options ... not for pointing at a different XML config file.
I haven't tried to confirm this.
Too lazy I guess.
Not a huge deal ...
I'm just trying to figure out if I can hardwire certain assumptions in my code
for the time being to make some issues simpler.
Tony
--- Norman Vine [EMAIL PROTECTED] wrote:
Curtis L. Olson writes:
I haven't looked closely at the code that loads preferences.xml, but
if David M. confirms this is hardwired, then definitely, I think the
ability to specify an alternate config file would be a very good thing
to add.
From options.cxx
} else if ( arg.find( --config= ) == 0 ) {
string file = arg.substr(9);
try {
readProperties(file, globals-get_props());
} catch (const sg_exception e) {
string message = Error loading config file: ;
message += e.getFormattedMessage();
SG_LOG(SG_INPUT, SG_ALERT, message);
exit(2);
}
norman
=
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] XML config file questions
David et al ... (I re-wrote this e-mail three times as I am having a heck of a time expressing my questions ...) In looking at preferences.xml and c172-3d-set.xml ... I see in prefrences ... /PropertyList/contols/child::* I see in c172-3d-set ... /PropertyList/contols/child::* Applied to these documents seperately, we would end up with a intersection of a number of named elements. Coincidentally or by design, attributes for the matching set of nodes are different, by the exclusion of a type attribute in the aircraft config file. This is one example. Now ... if I am trying to ... a) render a GUI exposing these values ... b) allow a user to change these values and persist them ... then ... a) do I merge these values into a final DOM, where the last entry wins and where load order is important ? b) where do I persist the change ? to the aircraft ? to the preferences ? preferences _seems_ like the place to store user configuration info, but seems to fly in the face of what I would have suspected for precedence between conflicting values in the two files ... I have other edge questions ... but maybe some understanding of this one will help me make some design decisions in my code. TIA, Tony = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
--- Curtis L. Olson [EMAIL PROTECTED] wrote: [ ... a bunch of cool TerraSync stuff ...] Do I have to be building/using the CVS cut of FG to take advantage of TerraSync ? TIA, Tony = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] question about 3d models
It's not the I _really_ feel the need. It is just that the few 3d tools I have taken a look at, Maya, Blender and one other one (can't rememeber the name, it was a bit ago) are complex to use. Harder, it seems to me anyway, than thinking in terms of edges and nodes in some 0,0,0 centered 3d space, drawing it on a piece of paper, making a list of nodes, and typing them in somewhere. Having said that, it is probably my issue that I don't really _want_ to learn a 3d modeling tool. For FG, I would love to be able to put together a really simple 3d model for the airframe, and a really simple 3d model for the cockpit, where they only (for me) need to be good enough to get the perspective out of the cockpit right (view over the dash, view out the window while on base turning to final etc ...). Eye candy could be for those that _do_ care about 3d modeling. It's not a big deal. I'm just enjoying hacking around with FG right now, trying to understand the parts, and trying to figure out where I might be able to contribute a little. I am also doing a little research and trying to collect a little data here and there in the hopes of maybe trying to put together an aircraft a'la a mooney type of aircraft. I starting looking at and found some data for the commander series of aircraft as these are a'la mooney with a high performance single, running ~200kias or more at cruise, seating 4 people with baggage at max useful load and having the low wing design. I am also playing with a GUI front end for dealing with configuring flight gear, starting with simple stuff like being able to select aircraft, airport, time of day, clouds, weather etc. Since all of this info is laid out in XML files (I wonder who influenced that design ? ...) I am finding this to be an intuitive project. I do wish the was an XML Schema or DTD to help me understand what the possible/expected permutations of the XML config files was and to help my understand what the enumerated values were for some of the elements, such as cloud types for instance. Cheers, Tony --- David Megginson [EMAIL PROTECTED] wrote: The Tone'ster writes: In this way, a person might not have to run off and download/pay for/learn some heavy duty 3d program to render some sort of basic aircraft frame, or building, or even cockpit. I've considered adding support for defining simple geometry directly in the XML, but it seems like a waste. If you *really* feel the need to create 3D models in your text editor, use AC3D format, which is text based and well supported. = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] question about 3d models
hi, new to flight gear. ignore me if this is an FAQ. really like what I see with the sim. since the sim architecure is so highly built around the use of XML files exposing everything from config, to flight models to panels ... ... I was wondering if there has ever been talk of exposing 3d models through a metalanguage in XML, or maybe to a spec such as SVG (though I guess SVG is 2d, not 3d). In this way, a person might not have to run off and download/pay for/learn some heavy duty 3d program to render some sort of basic aircraft frame, or building, or even cockpit. Tony = ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
