-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
| With the following model:
|
| world '' (2)
| group 'testgroup1' (2)
| poly 'test1'
| group 'testgroup2' (1)
| poly 'test2'
|
| I can use a material animation on
On Jan 21, 2008 4:03 PM, till busch wrote:
> hi all,
Hi Till,
I don't know all the nuances of the OSG branch and OSG usage, but originally
the common material library textures were all loaded at start time so they'd
be available at any time and not hit the fps like they would if they needed
to
dave perry wrote:
> Tim Moore wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> dave perry wrote:
>> | Patch adds a member function to FGRenderer class that returns the
>> | current aspect ratio. Uses this in place of 4.0/3.0 in setFOV and
>> | setNearFar.
>> |
>> | The diff fo
hi all,
i have continued my random optimizations to flightgear (and simgear, this
time).
changes in the attached diffs
=
in simgear:
* removed _tex_cache from SGMaterial (osg takes care of texture caching)
* made textures load on demand when SGMaterial::get_state() is first
On Jan 22, 2008 12:53 AM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> On Jan 21, 2008 2:32 PM, Nagy Mate <[EMAIL PROTECTED]> wrote:
> > We noticed a rather peculiar effect, having landed our plane near
> > (under) a grey parking passenger jet. Fiddling with our flight controls
> > made the control s
> That sounds like you're using TCP, since if you were using UDP, the
> master would not know if the slave(s) received the message -- UDP is an
> unreliable protocol and the master
> does not know if it is transmittiing into oblivion or reaching an actual
> slave instance of FlightGear. Provided th
> Which compilier is tpalinkas using?
We were using the current version of gcc in Debian testing (4.1.2, I
believe?), but the same problem occurred with the debian packaged 1.0.0,
the ubuntu packages, and older versions as well.
As said in another mail, the stability issues improved with the sm
Torsten Dreyer schreef:
> Neither of this is occouring here. When I run the master without a slave,
> there are many "Error writing data." messages on the master's console which
> stops again when the slave is up.
> But I can startup/shutdown the master or slave independently without crash or
>
Am Montag, 21. Januar 2008 22:00 schrieb Curtis Olson:
> The other thing that concerns me is that even with your patch, tpalikas is
> reporting order depencies in the master/slave startup sequence and doing it
> wrong results in a crash. Also some new double free errors when exiting.
>
> The commu
On Jan 21, 2008 2:38 PM, Torsten Dreyer wrote:
> > g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
> >
> > So the problem could also be related to your newer version of gcc
> (perhaps
> > being more picky or more standards compliant.) Or there could be a libc
> > difference too.
> Yeah that's what I
Yes, this should already be done in both plib and osg branches. Regards,
Curt.
On Jan 21, 2008 2:55 PM, Torsten Dreyer wrote:
> > The native_ctrls issue you point out is a surprise to me, but as I look
> in
> > the cvs web browser pages, I see that Erik Hofman's name is attached to
> > these,
> The native_ctrls issue you point out is a surprise to me, but as I look in
> the cvs web browser pages, I see that Erik Hofman's name is attached to
> these, and the specific commit was adding some new fields to the structure.
> I think it makes sense to remove the comments that disable network b
> g++ (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
>
> So the problem could also be related to your newer version of gcc (perhaps
> being more picky or more standards compliant.) Or there could be a libc
> difference too.
Yeah that's what I think, too. I assume a different implementation in the STL
to
On Jan 21, 2008 1:45 PM, Torsten Dreyer wrote:
> >
> > Here's one possible difference, I'm running with plib-1.8.4 ... any
> chance
> > you could try that and see if it makes a difference. I realize a
> complete
> > ground up recompile is not trivial, but flightgear does leverage plib's
> low
> >
On Mon, 21 Jan 2008, Curtis Olson wrote:
If you are talking about position lags and not frame rate lags, then I
believe the MP server builds in about a 10 second buffer delay to try to
prevent buffer starvation and show continuous motion on the client side.
Yes, we have such a buffer but it
>
> Here's one possible difference, I'm running with plib-1.8.4 ... any chance
> you could try that and see if it makes a difference. I realize a complete
> ground up recompile is not trivial, but flightgear does leverage plib's low
> level network code, so is it possible that a change in plib sin
On Jan 21, 2008 12:51 PM, Torsten Dreyer wrote:
> Am Montag, 21. Januar 2008 18:21 schrieb Curtis Olson:
> > I am testing the udp version of doing master/slave copies of FlightGear
> > here this morning. I'm doing this with a stock v1.0 version. So far
> > everything seems to be behaving well.
Ron Jensen a écrit :
> On Mon, 2008-01-21 at 14:32 +0100, Nagy Mate wrote:
>
>> We noticed a rather peculiar effect, having landed our plane near
>> (under) a grey parking passenger jet. Fiddling with our flight controls
>> made the control surfaces of the jet move in the same way. The jet was
>
Curtis,
The problem is about Frame delay, but in stand-alone mode i have not lags
even when aircraft is near to land. Because this i suppose the problem with
frame delay is on the server, maybe by user number (27 at critical time).
If the problem occur by the new users, why this not occur
Am Montag, 21. Januar 2008 18:21 schrieb Curtis Olson:
> I am testing the udp version of doing master/slave copies of FlightGear
> here this morning. I'm doing this with a stock v1.0 version. So far
> everything seems to be behaving well. I'm not seeing any rapid memory
> leak, and so far no cra
On Jan 21, 2008 12:27 PM, Gijs de Rooy wrote:
> Hi Cleber,
>
> Every pc will experience some lag when the MP-server is bussy.
> When there is a great number of pilots online the lag will be
> larger.
>
> There are periods that I've got about every 5 minutes a few
> seconds lag. The servers isn't c
Hi Gijs,
This cannot be solved using asynchronous procedures ? Or there any plan to
make this asynchronous ? With this, the lag occurs only in the server and the
user will not affected by this.
Tks,
Cleber.
Gijs de Rooy <[EMAIL PROTECTED]> escreveu:.hmmessage P { margin:0px;
padding:0
With the following model:
world '' (2)
group 'testgroup1' (2)
poly 'test1'
group 'testgroup2' (1)
poly 'test2'
I can use a material animation on testgroup1 and both test1
and test2 respond, which is what I would expect. I can't
seem
Hi Cleber,
Every pc will experience some lag when the MP-server is bussy.
When there is a great number of pilots online the lag will be
larger.
There are periods that I've got about every 5 minutes a few
seconds lag. The servers isn't calculated at this amount of
pilots I think.
Gijs
Date: M
Hello,
Me and my friends having several lags when using FG in multiplayer mode,
because low internet speed(dial-up connection) or fully network usage(occurs
for me even network usage is 90% or above) .
I believe this is in the procedure for send/receive position and aircraft
data.
My ma
On Jan 21, 2008 7:32 AM, Nagy Mate wrote:
> Greetings.
>
> We're still experimenting with flight slaving (two fgfs instances, the
> master sends flight data to the slave using the native protocol).
>
> Other than the stability concerns already discussed in other threads,
I am not able to reprodu
I am testing the udp version of doing master/slave copies of FlightGear here
this morning. I'm doing this with a stock v1.0 version. So far everything
seems to be behaving well. I'm not seeing any rapid memory leak, and so far
no crash.
Are you seeing this only with file I/O? Are you seeing th
Now that HEAD is for fg/osg only, some aircraft and other stuff
will soon start to work badly or not at all with v1.0 and fg/plib.
No problem for exclusive fg/osg users, but some people still like
volumetric shadows and 3D clouds and will therefore also use
fg/plib for a while. (Helicopters in outs
FYI, I proposed a patch to the AC3D loader to preserve Optional database path
and it was accepted. It should be included in the next 2.3.3 developer release.
-Fred
- Forwarded message from Robert Osfield <[EMAIL PROTECTED]> -
Date: Mon, 21 Jan 2008 11:24:22 +
From: Robert Osfi
With Curt's OK I have now created a PLIB branch for the data
directory. For developers this means:
- work on HEAD can go on as usual -- there's no need to care
about the PLIB branch at all
- HEAD does no longer have to be compatible with fg/plib and
fgfs v1.0
- only changes that should be co
On Fri, 18 Jan 2008, Torsten Dreyer wrote:
> Hi all,
>
> I think there is a bug when using the native protocol to link two instances of
> FlightGear via network or when recording and playing back flights using
>
> fgfs --native=file,out,20,fgfs.out
>
> and
>
> fgfs --native,file,in,20,fgfs.out -
On Mon, 21 Jan 2008, Nagy Mate wrote:
> We noticed a rather peculiar effect, having landed our plane near
> (under) a grey parking passenger jet. Fiddling with our flight controls
> made the control surfaces of the jet move in the same way. The jet was
> otherwise inert, and the effect didn't happ
On Jan 21, 2008 2:32 PM, Nagy Mate <[EMAIL PROTECTED]> wrote:
> We noticed a rather peculiar effect, having landed our plane near
> (under) a grey parking passenger jet. Fiddling with our flight controls
> made the control surfaces of the jet move in the same way. The jet was
> otherwise inert, and
On Mon, 2008-01-21 at 14:32 +0100, Nagy Mate wrote:
> We noticed a rather peculiar effect, having landed our plane near
> (under) a grey parking passenger jet. Fiddling with our flight controls
> made the control surfaces of the jet move in the same way. The jet was
> otherwise inert, and the effec
We noticed a rather peculiar effect, having landed our plane near
(under) a grey parking passenger jet. Fiddling with our flight controls
made the control surfaces of the jet move in the same way. The jet was
otherwise inert, and the effect didn't happen with other nearby planes
on the ground.
(Th
Greetings.
We're still experimenting with flight slaving (two fgfs instances, the
master sends flight data to the slave using the native protocol).
Other than the stability concerns already discussed in other threads,
the most significant problem seems to be that some important data isn't
sent
Hans Fugal wrote:
> It may not be the same problem, but I remember getting almost no
> helpful indications from either of those debug methods so OTOH it may
> indeed be the same problem. Make sure you don't have conflicting
> plugins in /Library or wherever the OSG release readme says to put
> them
37 matches
Mail list logo
