Hello,
Quicker than i could plan (thanks to Saikrishna for the help) , i just
found the following:
When running GIT FG/SG at date 2013 Feb the 24 the terrain is right, we
can land on a building and we can use the modified LFHU airport (by PAF)
When running FG/SG at date 2013 Feb the 25 the terrai
Hello, Saikrishna
Thanks.
Ahmad
On 21 June 2013 01:24, Saikrishna Arcot wrote:
> Use "git log --before -MM-DD --after -MM-DD" to see the comment
> of the change, commit ID, and the date the change was made. You can
> leave out before or after switch if you want to. Then use the commit
Use "git log --before -MM-DD --after -MM-DD" to see the comment
of the change, commit ID, and the date the change was made. You can
leave out before or after switch if you want to. Then use the commit ID
in "git reset --hard ". You only need the last 7 characters
of the commit ID. This
Hello, again my question
Help
What is the right git command line.? to get the git content at a specific
date
Ahmad
On 20 June 2013 19:41, grtuxhangar team wrote:
> I'll have some free time along the end of that week, i could try to build
> some versions.
>
> However, to get the Git content
I'll have some free time along the end of that week, i could try to build
some versions.
However, to get the Git content at a specific date , is beyond my
expertise.
What is the right git command.
Thank
Ahmad
On 20 June 2013 15:53, James Turner wrote:
>
> On 20 Jun 2013, at 14:44, grtuxhan
On 20 Jun 2013, at 14:44, grtuxhangar team wrote:
> We have a FG Git built working version which is Feb the 17, versus a next
> FG Git built version NOT working which is March the 20.
>
> Sorry we can't be more precise.
Okay, that's still a good narrowing of possible changes, thanks.
If an
I order to narrow the research, our system manager told me.
We have a FG Git built working version which is Feb the 17, versus a next
FG Git built version NOT working which is March the 20.
Sorry we can't be more precise.
Ahmad
On 20 June 2013 14:28, James Turner wrote:
>
> On 20 Jun 201
On 20 Jun 2013, at 13:20, grtuxhangar team wrote:
> UNFORTUNATELY, right now, with recent FG GIt we can't use it.
> At FG load the new terrain ( it is an object ) is not recognized and the
> Aircraft is positioned on the original surface of the scenery which is under
> the new_terrain_object.
Hello,
With FG Git , we have lost a feature which was existing with FG 2.10.
When an airport within the generic scenery is wrong, we may have to
customize an Airport with some objects add on. mostly a new shape of the
terrain ( runway) , which is positioned within the scenery
(Scenery/Objects/xlon
On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote:
> Hi,
>
Hi all,
I have added my new code for far-tiles in a merge request for flightgear and
simgear. You can now test the code, and also check whether texture resizing is
necessary for materials which are not inside the near tiles
> There are many issues and tradeoffs with mesh simplification. There are
> many algorithms and approaches, each with their own unique strengths and
> weaknesses. Challenges include finding a strategy to hide the cracks
> between adjacent tiles draw with different levels of details (and
> possi
On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote:
Hi Mathias,
> Ok, for that, I can see a lot of solutions.
>
> Having one that is may be close:
> Use the BVH tree that is used in fgelev or fgai. The fgelev one is
> parametrized like you probably need today. There is one hacky switc
Hi,
On Sunday, December 16, 2012 22:32:48 Adrian Musceac wrote:
> My main interest with terrain was a) having longer distances available, and
> b) having separate traversal masks only for surface. All for use in my
> infamous now radio code. This lead to what I have now, an improvement in
> memor
On Sunday, December 16, 2012 22:38:41 Mathias Fröhlich wrote:
> Hi,
>
> On Sunday, December 16, 2012 22:02:15 Adrian Musceac wrote:
> > I am aware there are better systems out there, I'm just doing what I can
> > within the restrictions of the BTG format. I'd be more than happy to have
> > a real
Hi,
On Sunday, December 16, 2012 22:02:15 Adrian Musceac wrote:
> I am aware there are better systems out there, I'm just doing what I can
> within the restrictions of the BTG format. I'd be more than happy to have a
> real terrain LOD, but right now that means lots of changes in Terragear and
>
On Sunday, December 16, 2012 21:18:10 Stuart Buchanan wrote:
> On Sun, Dec 16, 2012 at 11:44 AM, Adrian Musceac wrote:
> > It' basically very simple. Far tiles no longer compute anything other
> > than it's own geometry, and also use a very low resolution texture set,
> > obtained by running a batc
On Sunday, December 16, 2012 19:37:37 James Turner wrote:
> On 16 Dec 2012, at 19:18, Stuart Buchanan wrote:
> > I'm surprised there's any benefit to using a very low resolution texture
> > set. Surely the normal textures are already loaded by OSG and it's
> > cheaper just to refer
> > to those rat
On Sunday, December 16, 2012 21:37:37 James Turner wrote:
> On 16 Dec 2012, at 19:18, Stuart Buchanan wrote:
> > I'm surprised there's any benefit to using a very low resolution texture
> > set. Surely the normal textures are already loaded by OSG and it's
> > cheaper just to refer
> > to those rat
On 16 Dec 2012, at 19:18, Stuart Buchanan wrote:
> I'm surprised there's any benefit to using a very low resolution texture set.
> Surely the normal textures are already loaded by OSG and it's cheaper
> just to refer
> to those rather than loading some more textures? Or are we not
> sharing our
On Sun, Dec 16, 2012 at 11:44 AM, Adrian Musceac wrote:
> It' basically very simple. Far tiles no longer compute anything other than
> it's own geometry, and also use a very low resolution texture set, obtained by
> running a batch resize on the regular texture set.
OK. So you don't load anything
Hi,
On Sunday, December 16, 2012 20:24:48 Adrian Musceac wrote:
> It's actually nothing really special about it, I'm just modifying a little
> the tile manager to define "inner tiles" and "outer tiles". The elevation
> data is inside the same old BTG files, which are actually lists of polygons
>
On Sunday, December 16, 2012 18:39:47 Mathias Fröhlich wrote:
> Hi Adrian,
>
> The same idea is behind the osg lod based whole world model.
> Where do you store the elevation data?
>
> Greetings
>
> Mathias
>
Hi Mathias,
It's actually nothing really special about it, I'm just modifying a littl
There are many issues and tradeoffs with mesh simplification. There are
many algorithms and approaches, each with their own unique strengths and
weaknesses. Challenges include finding a strategy to hide the cracks
between adjacent tiles draw with different levels of details (and possibly
more or
Hi Adrian,
The same idea is behind the osg lod based whole world model.
Where do you store the elevation data?
Greetings
Mathias
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access P
On Sunday, December 16, 2012 12:35:20 Stuart Buchanan wrote:
> Hi Adrian,
>
> On Sun, Dec 16, 2012 at 4:32 AM, Adrian Musceac wrote:
> > I am presenting an experimental (WIP) method to reduce memory consumption
> > by scenery with 30%, while increasing the visibility distance 4 times.
> > This met
Hi Adrian,
On Sun, Dec 16, 2012 at 4:32 AM, Adrian Musceac wrote:
> I am presenting an experimental (WIP) method to reduce memory consumption by
> scenery with 30%, while increasing the visibility distance 4 times.
> This method relies on some kind of LOD system, without mesh simplification.
> Peo
Hi all,
I am presenting an experimental (WIP) method to reduce memory consumption by
scenery with 30%, while increasing the visibility distance 4 times.
This method relies on some kind of LOD system, without mesh simplification.
People smarter than me can come up with a safe algorithm to do that,
Am 11.11.2012 19:05, schrieb Geoff McLane:
> That's strange no one has done this for WIN32 ;=()
I guess most Windows people are using launchers. It's mainly Linux
people who love command-lines ;-).
> #if defined(_WIN32)
> // with absPath NULL, will allocate, and ignore length
> char *buf
On Sun, 2012-11-11 at 18:04 +0100, ThorstenB wrote:
> If anyone was interested/able to fix the support for relative paths on
> Windows, please implement "SGPath::realpath" in simgear/misc/sg_path.cxx:
>
Hi Thorsten,
re: std::string SGPAth::realpath() const
That's strange no one has done this f
> Well, I've tried all sorts of combinations of pathnames, using
> different path name specification forms (windows, linux, etc.) and I
> can get FlightGear to run using several of the forms - and to load the
> scenery I desire, as well - I cannot get both the custom scenery and
> the HUD symbology
Well, I've tried all sorts of combinations of pathnames, using different
path name specification forms (windows, linux, etc.) and I can get
FlightGear to run using several of the forms - and to load the scenery I
desire, as well - I cannot get both the custom scenery and the HUD symbology
to work a
Am 11.11.2012 18:23, schrieb Jon S. Berndt:
> Thanks for the reply. The path handling in FlightGear seems a bit delicate.
> Not sure if in Cygwin under Windows I need to be more unix-like, or more
> windows-like in specifying paths. I'll play with that some, but relative
> paths do work - at least
> Am 11.11.2012 17:39, schrieb Jon S. Berndt:
> > Also, if I specify only the custom scenery path - as in the command
> > line below - I get the errors that follow. Don't know if those are
> > revealing or unexpected ...
> >
> > bin/Win64/fgfs.exe --fg-root=./data --fg-scenery=./scenery
> > --aircr
Am 11.11.2012 17:39, schrieb Jon S. Berndt:
> Also, if I specify only the custom scenery path - as in the command line
> below - I get the errors that follow. Don't know if those are revealing or
> unexpected ...
>
> bin/Win64/fgfs.exe --fg-root=./data --fg-scenery=./scenery
> --aircraft=CitationX
Gear developers discussions'
> Subject: Re: [Flightgear-devel] Scenery not being loaded
>
> > When the HUD no longer works, make sure you haven't deleted anything
> > in FGDATA - like the fonts. You don't need to define the path to the
> > base scenery (wit
> When the HUD no longer works, make sure you haven't deleted anything in
> FGDATA - like the fonts. You don't need to define the path to the base
> scenery (within fgdata). If you downloaded additional scenery, in one
> or multiple separate directories, you can separate the paths with ":"
> (works
Am 11.11.2012 13:14, schrieb Frederic Bouvier:
>> multiple separate directories, you can separate the paths with ":"
>> (works also on Windows).
>>
>> fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:...
>
> On windows, the path separator if ";"
You are right, for scenery it indee
> multiple separate directories, you can separate the paths with ":"
> (works also on Windows).
>
> fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:...
On windows, the path separator if ";"
-Fred
--
Ev
Am 11.11.2012 05:32, schrieb Jon S. Berndt:
> I have a new problem, now, though. I do see the scenery (when I get under
> about 6000 feet - until then I see only white fog) since I gave the path to
> the directory outside $FG_ROOT where I placed the terrain, but now I no
> longer get proper HUD sym
starting FlightGear.
Jon
> -Original Message-
> From: Jon S. Berndt [mailto:jonsber...@comcast.net]
> Sent: Friday, November 09, 2012 3:59 PM
> To: 'FlightGear developers discussions'
> Subject: Re: [Flightgear-devel] Scenery not being loaded
>
> Another th
> From: Jon S. Berndt [mailto:jonsber...@comcast.net]
> Sent: Friday, November 09, 2012 3:53 PM
> To: 'FlightGear developers discussions'
> Subject: [Flightgear-devel] Scenery not being loaded
>
> I'm running the latest FlightGear (64 bit v2.8.0.5, under Window
I'm running the latest FlightGear (64 bit v2.8.0.5, under Windows 7). I'm
driving it from an external instance of JSBSim, and it's working very well
except that no terrain is loaded. I can see what looks like a planet below
me that is covered in fog. Altitude ranges from about 40kft to 200kft, and
On Mon, 6 Aug 2012 11:09:15 + (UTC), Martin Spott
wrote:
> Tim Moore wrote:
>> On Mon, Aug 6, 2012 at 10:00 AM, Martin Spott
>> wrote:
>
>>> Therefore I think trying to guide "2nd-row developers" is a waste of
>>> time in most cases.
>>
>> How does scenery production, including airport mode
Tim Moore wrote:
> On Mon, Aug 6, 2012 at 10:00 AM, Martin Spott wrote:
>> Therefore I think trying to guide "2nd-row developers" is a waste of
>> time in most cases.
>
> How does scenery production, including airport modeling, scale without
> 2nd (and 3rd and 4th)-row developers?
Badly. The p
Hi Tim,
De : Tim Moore
Envoyé le : Lundi 6 août 2012 12h31
> How does scenery production, including airport modeling, scale without
> 2nd (and 3rd and 4th)-row developers?
I think this debate is on terrain generation. For 3D models submission +
objects submi
On Mon, Aug 6, 2012 at 10:00 AM, Martin Spott wrote:
> Moin Yves,
>
> ys wrote:
>
>> [...], it's just in responsability of the core developers to show how
>> "2nd-row" developers can help to improve apt.dat without being
>> blocked by a deprecated.
>
> I tend to disagree.
>
> You're probably askin
Sorry for the no-op posting, I acidentally sent the unmodified
buffer
Moin Yves,
ys wrote:
> [...], it's just in responsability of the core developers to show how
> "2nd-row" developers can help to improve apt.dat without being
> blocked by a deprecated.
I tend to disagree.
You're probab
ys wrote:
>
>
>
>
>
> Am 05.08.2012 um 19:07 schrieb Martin Spott :
>
>> Hi YVes,
>>
>> ys wrote:
>>
>>> A lot of scenery will come with 850 airport data either, and this is
>>> still refused by the core developers [...]
>>
>> Personally I don't like this sort of claims.
>>
>> After readi
Am 05.08.2012 um 19:07 schrieb Martin Spott :
> Hi YVes,
>
> ys wrote:
>
>> A lot of scenery will come with 850 airport data either, and this is
>> still refused by the core developers [...]
>
> Personally I don't like this sort of claims.
>
> After reading the above statement, the 'innoc
Hi YVes,
ys wrote:
> A lot of scenery will come with 850 airport data either, and this is
> still refused by the core developers [...]
Personally I don't like this sort of claims.
After reading the above statement, the 'innocent' observer might
understand that swapping the current "apt.dat" fil
On 08/04/2012 02:50 PM, Curtis Olson wrote:
> Where were you seeing the links and references to the 1.0.1 scenery.
> It's true we haven't regenerated terrain since probably back then, but
> we do continually add new objects continually.
Oh wait, when searching for "flightgear scenery" the first
Hi Erik
First of all the various custom scenery contributors have to start to
communicate with each other and making a list of custom scenery available. This
list should contain sources for custom scenery development, so GPL license
incompatible scenery (i.e. scenery created with cgiar or osm d
On Sat, Aug 4, 2012 at 2:59 AM, Erik Hofman wrote:
> When searching for some nice scenery spots for FlightGear to download I
> discovered that everything on the site still refers to the 1.0.1 scenery
> that was automatically generated in 2008.
Hi Erik,
Where were you seeing the links and refere
+1
IB
On Aug 4, 2012, at 4:00 AM, "Erik Hofman" wrote:
>
> Hi,
>
> When searching for some nice scenery spots for FlightGear to download I
> discovered that everything on the site still refers to the 1.0.1 scenery
> that was automatically generated in 2008.
>
> Are new scenery projects alr
Hi,
When searching for some nice scenery spots for FlightGear to download I
discovered that everything on the site still refers to the 1.0.1 scenery
that was automatically generated in 2008.
Are new scenery projects already integrated in the download map on the
site or do I have to search els
On Sat, 07 Jul 2012 01:41:26 +0200, HB-GRAL wrote in message
<4ff777a6.5070...@sablonier.ch>:
> Am 05.07.12 18:04, schrieb Curtis Olson:
>
> >
> >
> > We !!!STRONGLY!!! encourage authors to use the GPL so that we can
> > incorporate their work into the overall project and distribute the
> > work
Am 05.07.12 18:04, schrieb Curtis Olson:
>
>
> We !!!STRONGLY!!! encourage authors to use the GPL so that we can
> incorporate their work into the overall project and distribute the work
http://git.fgx.ch/flightgear/commit/?h=next&id=b14ddd40110e271efcd1416e9bf15d48d99c3123
Cheers, Yves
---
Ok, I see, just my misunderstanding of Gijs post when I read all other
posts now ... I guess one of the best explanation comes from Brandano here.
Sorry for the noise, I hate to participate in another license
discussion. (I hate myself for this, not you.) ;-)
-Yves
Am 06.07.12 21:34, schrieb H
Am 06.07.12 10:10, schrieb Gijs de Rooy:
> Nothing stops you from releasing that scenery under whatever license you'd
> like ( within the legal constraints ofourse), we just cannot include it in
> the official scenery.
>
No. Official scenery can also incorporate resources with other licenses:
ht
On Fri, 6 Jul 2012 00:26:48 -0700 (PDT), Michael wrote in message
<1341559608.65675.yahoomailclas...@web140205.mail.bf1.yahoo.com>:
> My last comment to this subject.
> I've got permission to distribute some swiss sceneries as GPL but
> only after asking back. Obviously I had to, as the author s
t_h...@yahoo.com
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] scenery licence for 2.8 and later
>
> My last comment to this subject.
> I've got permission to distribute some swiss sceneries as GPL but only after
> asking back. Obviously I had t
om: scrat_h...@yahoo.com
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] scenery licence for 2.8 and later
>
> My last comment to this subject.
> I've got permission to distribute some swiss sceneries as GPL but only after
> asking back. Obvi
My last comment to this subject.
I've got permission to distribute some swiss sceneries as GPL but only after
asking back. Obviously I had to, as the author said first that it needs to
remain Freeware.-
Now that's only possible because he bent back a little. But many
won't or can't do and hence
Curtis Olson wrote:
> [...] or scenery GPL? :-)
Who cares about Scenery >;-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
On Thu, Jul 5, 2012 at 1:50 PM, Curtis Olson wrote:
> On Thu, Jul 5, 2012 at 1:42 PM, Martin Spott wrote:
>
>> Hi Curt,
>>
>> Curtis Olson wrote:
>>
>> > We !!!STRONGLY!!! encourage authors to use the GPL [...]
>>
>> except from SimGear, which is supposed to be LGPL, correct ?
>>
>
> Yes.
On Thu, Jul 5, 2012 at 1:42 PM, Martin Spott wrote:
> Hi Curt,
>
> Curtis Olson wrote:
>
> > We !!!STRONGLY!!! encourage authors to use the GPL [...]
>
> except from SimGear, which is supposed to be LGPL, correct ?
>
Yes. :-)
Curt.
--
Curtis Olson:
http://www.atiak.com - http://aem.umn.e
Hi Curt,
Curtis Olson wrote:
> We !!!STRONGLY!!! encourage authors to use the GPL [...]
except from SimGear, which is supposed to be LGPL, correct ?
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
-
On Thu, Jul 5, 2012 at 10:36 AM, Stefan Seifert wrote:
> On Thursday 05 July 2012 07:50:20 Michael wrote:
>
> > Everything on GPL only means:
> > - less scenery and airplanes included ( wasn't there recently some
> > photoscenery rejected because of the GPL?)
>
> There are already 565 airplanes to
On Thursday 05 July 2012 07:50:20 Michael wrote:
> Everything on GPL only means:
> - less scenery and airplanes included ( wasn't there recently some
> photoscenery rejected because of the GPL?)
There are already 565 airplanes to choose from in git (all licensed GPL). More
than enough for me, if
>
> And Keep It Stupid Simple (tm). One license is already too
> many licenses.
>
Everything on GPL only means:
- less scenery and airplanes included ( wasn't there recently some photoscenery
rejected because of the GPL?)
- authors lose copyrights
- only to find their work rebranded and sold f
Le 04/07/2012 14:27, Erik Hofman a écrit :
> On 07/04/2012 01:12 PM, Michael wrote:
>> No, I mean authors could leave as is or use any licence they want.
>>
>>-- But it doesn't need to be GPL. --
>>
>> Sorry, GPL is ok for code but feels like a lead-foot for everything else.The
> The only optio
On 07/04/2012 01:12 PM, Michael wrote:
> No, I mean authors could leave as is or use any licence they want.
>
> -- But it doesn't need to be GPL. --
>
> Sorry, GPL is ok for code but feels like a lead-foot for everything else.The
The only option would be a less restrictive license (which you pro
No, I mean authors could leave as is or use any licence they want.
-- But it doesn't need to be GPL. --
Sorry, GPL is ok for code but feels like a lead-foot for everything else.
--
Live Security Virtual Conference
Ex
On 4 July 2012 19:45, Erik Hofman wrote:
> On 07/04/2012 11:26 AM, Michael wrote:
>> Hi
>> is it possible to have different licences than GPL for sceneries etc.?
>> Now that would help fight piracy, while keeping GPL for the source code.
>
> No and no.
>
Correct form my understanding.
If someone
On 07/04/2012 11:26 AM, Michael wrote:
> Hi
> is it possible to have different licences than GPL for sceneries etc.?
> Now that would help fight piracy, while keeping GPL for the source code.
No and no.
Erik
--
http://www.adalin.com - Hardware accelerated AeonWave, OpenAL for Linux
-
Hi
is it possible to have different licences than GPL for sceneries etc.?
Now that would help fight piracy, while keeping GPL for the source code.
Thanks for the info
Michael
--
Live Security Virtual Conference
Exclusive
Hi,
On Saturday, March 24, 2012 09:29:41 James Turner wrote:
> Tangental, but, yes please!
>
> This and a few other similar options, like generating a low-detail terrain
> node 'automatically' for distant tiles, were some ideas I considered last
> year to allow further draw distances.
Yes, the s
On 24 Mar 2012, at 08:54, Mathias Fröhlich wrote:
> This question is motivated by the scenegraph structure we currently generate.
> I can imagine improovements to scenery paging with this kind of change. What
> I
> want to try is not put individual model files into own level of detail nodes
>
Hi,
I had a busy week, so sorry for the delay.
On Saturday, March 17, 2012 10:07:07 Anders Gidenstam wrote:
> I have not had time to consider the proposal carefully, but I agree that
> the ocean tiles are problematic in the old (old) scheme if you have
> object directories with overlapping objec
Hi Jon,
On Tuesday, March 20, 2012 17:27:52 Jon Stockill wrote:
> Except a bunch of scenery developers pointing out it completely breaks
> their method of working.
>
> Merging the work into an existing tree isn't really an option - the
> ability to completely erase a tree and rebuild by script d
On Thu, 15 Mar 2012 18:38:34 +0100, Mathias Fröhlich wrote:
> Good Evening,
>
> Ok, no feedback to my comments here except Martin who tells me that
> the
> current checked in version behaves as expected.
Except a bunch of scenery developers pointing out it completely breaks
their method of worki
I fully agree with Jacob. I thought that is why we have seperate
Terrain/Object/Airport folders in the first place...
Eric
On 03/17/2012 11:15 PM, Jacob Burbach wrote:
> On Sat, Mar 17, 2012 at 4:57 PM, Martin Spott wrote:
>
>> Anders Gidenstam wrote:
>>
>>
>>> While the (old) new beh
On Sat, Mar 17, 2012 at 4:57 PM, Martin Spott wrote:
> Anders Gidenstam wrote:
>
>> While the (old) new behaviour is as Martin expects it is not what most
>> that has read Docs/README.scenery would expect (I'd think). However, I
>> would not consider Docs/README.scenery a normative source (i.e. no
Anders Gidenstam wrote:
> While the (old) new behaviour is as Martin expects it is not what most
> that has read Docs/README.scenery would expect (I'd think). However, I
> would not consider Docs/README.scenery a normative source (i.e. not how
> it should be but rather how it was) - but Martin'
On Thu, 15 Mar 2012, Mathias Fröhlich wrote:
Good Evening,
Ok, no feedback to my comments here except Martin who tells me that the
current checked in version behaves as expected.
Hi,
I have not had time to consider the proposal carefully, but I agree that
the ocean tiles are problematic in
Good Evening,
Ok, no feedback to my comments here except Martin who tells me that the
current checked in version behaves as expected.
I personally can understand that people want to have a local seperated
directory for their own personal additions. Let it be additions to the scenery
that are
Hi,
On Sunday, March 11, 2012 21:07:37 Martin Spott wrote:
> Mathias Fröhlich wrote:
> > The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg
> > for example) with models never contain a base tile line where we could
> > know when to stop seraching the FG_SCENERY directory seq
Mathias Fröhlich wrote:
> The problem is that these sea tiles (Objects/e000n60/e001n61/2975201.stg for
> example) with models never contain a base tile line where we could know when
> to stop seraching the FG_SCENERY directory sequence.
> So for this kind of tiles we could probably place sometin
Anders Gidenstam wrote:
> This change breaks my setup. I consider it a feature that FG used
> to load objects from all scenery directories visited up until the first
> one that contains terrain for the tile.
The current item in the scenery path may be defined either by having
the requested terr
Hi Mathias,
I know a lot of users who use this kind of organisation about scenery folder,
and these users aren't "scenery developpers". I think your change will breaks a
lot of users configuration with the next release (2.8.0)
I'm convinced that your change is a good improvement (if I understan
Hi Jon,
On Friday, March 09, 2012 10:43:55 Jon Stockill wrote:
> Can you explain exactly how the loading now works, and if it's still
> possible to use extra local objects trees in the way I describe?
Thanks for the response.
Well, I guess this hits the same problem that I try to solve now with
Hi,
On Thursday, March 08, 2012 23:13:56 Clement de l'Hamaide wrote:
> Without this little tweaks the tile can't be loaded. In conclusion, with
> your change we need to associate Object AND Terrain folder. It's just a
> feedback of my experience, don't take it as a critics ;)
That's fine.
Have w
Hi,
On Friday, March 09, 2012 21:37:32 Anders Gidenstam wrote:
> This change breaks my setup. I consider it a feature that FG used
> to load objects from all scenery directories visited up until the first
> one that contains terrain for the tile. It made it possible to have
> scenery object direc
On Thu, 8 Mar 2012, Mathias Fröhlich wrote:
Hi,
Also for the breginning of the development cycle, I started working on
improoving fgviewer and cleanup scenery/model loading.
I have now checked in a change that should fix some long standing
problems with modelss that appear to have z-fighting
On Thu, 8 Mar 2012 23:13:56 +0100, Clement de l'Hamaide wrote:
> I've encountered a problem about this change but I fixed it. Some
> explanation :
> I use 5 sceneries folders and some of them add some data to the
> precedent scenery folder.
> I use this argument :
>
> --fg-scenery=/home/clement/S
> Hi,
>
> Also for the breginning of the development cycle, I started working on
> improoving fgviewer and cleanup scenery/model loading.
>
> I have now checked in a change that should fix some long standing problems
> with
> modelss that appear to have z-fighting. This change should not harm a
Hi,
Also for the breginning of the development cycle, I started working on
improoving fgviewer and cleanup scenery/model loading.
I have now checked in a change that should fix some long standing problems with
modelss that appear to have z-fighting. This change should not harm and works
so fa
On Thursday, February 23, 2012 01:05:07 Martin Spott wrote:
> I do, I've been the first real user of the "xplane" driver in GDAL -
> except from Even himself :-)
> BTW, I didn't say I "don't want any 850 centerlines as a base for
> this". I just wanted to make clear that there's a trap hiding b
Christian Schmitt wrote:
> Martin Spott wrote:
>
>> Any volunteer(s) ? Proper representation of ground network nodes as
>> PostGIS (actually OGC) geometry data type preferred.
>>
>
> Apparently you don't want any 850 centerlines as a base for this, which
> would be easy as gdal imports 850 dat
Martin Spott wrote:
> Any volunteer(s) ? Proper representation of ground network nodes as
> PostGIS (actually OGC) geometry data type preferred.
>
Apparently you don't want any 850 centerlines as a base for this, which
would be easy as gdal imports 850 data directly into Postgis, as you surely
1 - 100 of 374 matches
Mail list logo
