I just want to confirm re: some stuff I'm doing: the next big scenery
build, and the next release of fgfs, will be based on the switch from
basic.dat and runways.dat to X-Plane's apt.dat?
Thanks,
-c
--
Chris Metzler [EMAIL PROTECTED]
(remove snip-me. to
On Sat, 27 Nov 2004 09:13:09 +0100
Durk Talsma [EMAIL PROTECTED] wrote:
Hi Folks,
This morning I decide to post a selection of FlightGear sceenshots on my
website illustrating the development of the TrafficManager subsystem,
and its interface with the AIManager.
On Wed, 24 Nov 2004 07:29:02 +0100
Durk Talsma [EMAIL PROTECTED] wrote:
[ snip ]
Another thing I noticed is that when the AIModel subsystem loads
multiple copies of an aircraft, separate copies of each model are loaded
each time, instead of referencing to the
On Sun, 28 Nov 2004 20:34:51 -0600
Curtis L. Olson [EMAIL PROTECTED] wrote:
I can think of 4 approaches to defining taxiways and lines.
[ snip ]
2. Draw the taxi lines as separate polygons over the top of the taxiways
and runways.
[ snip ]
* Ingrid and Kris -- Saturday 20 November 2004 01:11:
So far, I've been using the Bo105 as the aircraft (and have it flying
around from pre-recorded data), but I am unable to get the rotors turning
with the fdm being external. The only way I can get them turning is by
editing the properties
On Tue, 23 Nov 2004 13:44:55 +0100
Melchior FRANZ [EMAIL PROTECTED] wrote:
Should have been: is *everyone* else happy with it?
I guess my tendency is to say I'm happy with it if it's closer to
how it sounds in real life. And my problem is that I have no idea
which one is closer to real life.
Hello David,
David Luff wrote:
This is purely a bug-fix release - there is another version in the works
with some more features.
The instructions to the key commands tell us which key to use in order
to achieve which sort of movement (R,D,F,C for shifting objects around,
J,K for rotating).
First of all, thanks to all for your responses and help with this.
I have made some progress with this and just wanted to report back for those
interested. I went through the net_fdm.hxx and native_fdm.cxx files and set
all variables to either long or double, as appropriate. I also made sure
Jason Cox wrote:
Yes it is a OOM Problem, I thought 760M would be fine but apparently it
is not. Thats why I would like to find out how much others have to build
scenery.
I have a server with enough memory, but I yet didn't manage to build
the requirements for the TerraGear utilities.
No I
On Monday 29 November 2004 11:03, Chris Metzler wrote:
On Wed, 24 Nov 2004 07:29:02 +0100
Durk Talsma [EMAIL PROTECTED] wrote:
[ snip ]
Another thing I noticed is that when the AIModel subsystem loads
multiple copies of an aircraft, separate copies of each
Chuck Cole wrote:
First of all, thanks to all for your responses and help with this.
I have made some progress with this and just wanted to report back for those
interested. I went through the net_fdm.hxx and native_fdm.cxx files and set
snip
Anyway, I'm real interested in getting this to
Quoting Chuck Cole :
Also, I uncommented out a line in the code in the process() method to print
out the size of the buffer that is being sent. According to this statement,
the size of the buffer (or the class structure in this case) is 640 bytes.
However, when I do the same thing on my side
On Monday 29 November 2004 09:17, Chris Metzler wrote:
Looking cool!
I'm curious whether you have ideas on how to generate traffic data
(flights and flightplans) for the aircraft that the TrafficManager
and AIManager will handle. Are you thinking of doing real-world
flights? If so, is
On Mon, 29 Nov 2004 17:30:51 +0100
Durk Talsma [EMAIL PROTECTED] wrote:
After solving the multiple copy problem, the AI system became a lot more
flexible and I was able to load close to 1200 aircraft, but when
multiple aircraft came into view, I experienced some nasty problems,
including
Chris Metzler schrieb:
I'm curious whether you have ideas on how to generate traffic data
(flights and flightplans) for the aircraft that the TrafficManager
and AIManager will handle. Are you thinking of doing real-world
flights? If so, is there a good place to harvest that data?
You can try
On Monday, 29 November 2004 04:34, Curtis L. Olson wrote:
2. Draw the taxi lines as separate polygons over the top of the taxiways
and runways. We would need to use glPolygonOffset, and make sure we
split all the taxiway lines at the borders of all the underlying surface
triangles so that the
This was exactly what was happening. I used the #pragma pack(4) directive
and this fixed the problem. I'm now able to receive all of the data
correctly. I was also able to receive the correct data by moving the
variable declarations around as well, but this didn't allow for common
variables to
Dale E. Edmons wrote:
PLIB, Simgear, GPC have always been required. LibNURBS is required,
but I think its a fairly recent addition. GTS, afaik, isn't used
anymore but the configure scripts still depend on it. In short, all of
the above are required with GTS depreciated.
Thanks for
On Mon, 29 Nov 2004 12:53:43 -0600, Curtis wrote in message
[EMAIL PROTECTED]:
Paul Surgeon wrote:
Number 2 is the route I was planning to take.
There would be no need for an unlimited set of textures and we could
add the black tire marks too, not just the taxiway lines.
Clipping the
On Monday, 29 November 2004 20:53, Curtis L. Olson wrote:
I.e. if the polygons don't share exactly the same verticies they likely will
round different directions in some situations and you are back to having
z-buffer fights. It's a nasty problem. I've seen some applications
that do a good
On Tue, 30 Nov 2004 01:15:27 +0200
Paul Surgeon [EMAIL PROTECTED] wrote:
On Monday, 29 November 2004 20:53, Curtis L. Olson wrote:
Do the textures stay compressed in video ram, does the texture render
unit render from the compressed texture, or does it have to uncompress
it in video ram
Chris Metzler writes:
Paul Surgeon wrote:
Curtis L. Olson wrote:
Do the textures stay compressed in video ram, does the texture render
unit render from the compressed texture, or does it have to uncompress
it in video ram before rendering it?
I'm not sure about that - I'll
On Mon, 29 Nov 2004 22:25:49 -0500
Norman Vine [EMAIL PROTECTED] wrote:
This is true .
but don't forget the gain achieved by reducing the disk to memory
bandwith required
Absolutely; but this issue (whether the video card can render the
compressed textures without decompressing first) is
On Tuesday, 30 November 2004 01:54, Chris Metzler wrote:
[ snip ]
} The compressions are not meant to save disk drive space (plenty of it)
} but to:
}
} -reduce the video card memory useage, as since the Geforce2, video
} cards can directly render a compressed texture
On Tue, 30 Nov 2004 06:33:36 +0200
Paul Surgeon [EMAIL PROTECTED] wrote:
It's pretty neat technology. No decompression is required as reading a
texture is done on the fly when it's required. If only a portion of the
compressed texture is used in a scene then only the required pixels of
the
25 matches
Mail list logo
