Stuart,
On Wednesday, December 14, 2011 15:49:22 Stuart Buchanan wrote:
> 2011/12/14 Mathias Fröhlich wrote:
> > But, the question is how many cloud drawables do we have? The render Bin
> > sorting bottleneck - if we run into this - is O(log(n)*n) with the n=
> > number depth sorted drawables. Wh
Stuart Buchanan wrote:
> I currently maintain the c172p.
I still don't understand why Heiko was alienated from maintaining the
C172 model
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
Gijs de Rooy wrote:
> Stuart, now we're at it, could you please decrease the cockpit-status-rating
> of the
> C172P? It really is not complete and does not fit the five-stars category.
> For example,
> our current model even lacks something as a master switch! Nor does it have
> "photo-
> rea
Hi all, Stephan in particular,
> Stuart wrote:
> I currently maintain the c172p. The only other changes I'm aware of are
> some significant updates that Gijs was working on prior to the 2.4.0 release.
> I don't know whether he's still working on them - Gijs?
Right, I had indeed quite some updat
On Wed, Dec 14, 2011 at 4:52 PM, Fernando García Liñán wrote:
> Hello Stephan,
>
> It looks nice so far! But someone has already improved it, you can find more
> info here: http://flightgear.org/forums/viewtopic.php?f=14&t=10187
The changes Fernando refers to were applied before the 2.4.0 release,
> Here are some questions:
> 1. Should I work from a c172p model more recent than on the website?
> If so, where can I find the Aircrafts in gitorious?
> 2. How do I contribute? Do I learn to use git and create a branch? Do
> I post the aircraft as a .zip file for someone to look at?
> 3. Should
Hello Stephan,
It looks nice so far! But someone has already improved it, you can find
more info here: http://flightgear.org/forums/viewtopic.php?f=14&t=10187
You don't need to upload it to GIT by yourself, you can pack it in a .zip
and a FGData committer can upload it for you.
If you run a more
On 14 Dec 2011, at 14:49, Stuart Buchanan wrote:
> (BTW - I think I've managed to get Impostors working though I've still to see
> any performance gain)
That's very interesting, because if we had truly generic impostors working,
they could also be used to push out the scenery rendering substant
Hello everybody,
I have been looking at improving the Cessna 172p cockpit. I have been mostly
focusing on the instruments. I am creating new 256px textures, and modifying
the geometry and xml files when required. All the work is based on pictures of
Cessna cockpits and pictures of instruments p
2011/12/14 Mathias Fröhlich wrote:
> But, the question is how many cloud drawables do we have? The render Bin
> sorting bottleneck - if we run into this - is O(log(n)*n) with the n= number
> depth sorted drawables. Which means we need to have a huge amount of cloud
> drawables that this effect domi
On Mon, Dec 12, 2011 at 8:19 AM, Erik Hofman wrote:
> This reminds me that vegetation uses a texture strip with 8 different
> trees at a size of 256x64 pixels whereas clouds use one texture for
> every cloud (puff) using 256x256 pixels. Maybe that makes a difference?
It varies by cloud definition,
On Wed, Dec 14, 2011 at 10:35 AM, Thorsten R. wrote:
> Thanks to Hooray who helped me setting up the CMake environment and the
> guys at Infocare who finally managed to fix heat management of my
> computer, I am now back on the devel tree. I've done a few tests yesterday
> and identified a list of
Hi James,
thanks for bringing this up (again)! Last Sunday I actualy started documenting
the use of rebase when
applying mere-requests: http://wiki.flightgear.org/Git#Merge_requests Would be
nice if you (and others,
like our Git-pro AndersG) could extend/correct it ;)
In the "new" git rules w
Thanks to Hooray who helped me setting up the CMake environment and the
guys at Infocare who finally managed to fix heat management of my
computer, I am now back on the devel tree. I've done a few tests yesterday
and identified a list of weather-related issues which I think should be
addressed (unf
Hi Gene
Thanks for the link. Yes, the database has a 1 or 2 months update cycle.
I think most people working with xplane data for FlightGear takes this
updates already into account for their development (I do so for many
months), also the "new" specifications of 8.50 version and also a lot of
On 14 Dec 2011, at 09:32, Anders Gidenstam wrote:
> If your topic is freshly rebased it will just be a fast-forward merge,
> that is, your new commits are just added to the history of master.
> Nice and linear IMHO.. :)
Yes, sorry, I didn't express that clearly at all - thanks Anders!
James
On Wed, 14 Dec 2011, James Turner wrote:
> Of course, when you do finally merge your topic into next, that's a
> merge - because we do all care about recording that action in the
> history.
If your topic is freshly rebased it will just be a fast-forward merge,
that is, your new commits are jus
A note for people committing code:
Please don't *ever* merge from next to a topic / local branch, and then merge
that branch back to the public next. Doing so makes the history much more
confusing than it needs to be. Rebase your local topic branches onto next
periodically when you wish to 'syn
18 matches
Mail list logo
