Re: [Flightgear-devel] FlightGear mapserver offline
Michael Sgier scrat_h...@yahoo.com writes:
Still down:
The server at scenemodels.flightgear.org is taking too long to respond.
The server at mapserver.flightgear.org is taking too long to respond.
etc.
Sigh...only in USA. The last swiss power outage must have been ~10
years ago and only lasting a couple of minutes.
That's the difference between a country that's submerged in debt (356%
of GDP), vs. a country that's has a positive balance.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Erik Hofman e...@ehofman.com writes:
On Sun, 2012-05-20 at 10:43 +, Renk Thorsten wrote:
Advanced Weather doesn't burn any significant performance inside
Nasal - it burns the performance by calling hard-coded C++
functionality from Nasal.
I hope you're not suggesting that C++ is always slower than Nasal? :-)
Of course it is. Think about it! Only slow functions are written in
C++! If the function was fast enough in the first place, it wouldn't
have been written in C++, it would be left in nasal. QED, C++ is the
slowest part of the system.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
Renk Thorsten thorsten.i.r...@jyu.fi writes:
There are good sources for sea colour out there - here is one:
http://oceancolor.gsfc.nasa.gov/FEATURE/IMAGES/A2008129125500.Scotland.png
The Northern North Sea, away from the turbidity and major river outfalls
of the Southern North Sea, is indistinguishable from the Atlantic, the other
side of Scotland.
4 West, 54 North I get an rgb value of (93, 113, 121)
2 East, 54 North I get (31, 71, 83)
There's pretty significant variation everywhere, but I don't see that in that
picture that the two would even be similar.
There are many examples in this archive, and if there
are differences in the deep ocean colour in any of the oceans they are darned
hard to spot. Similarly, if there is a difference between the Atlantic
and the Mediterranean, it's very hard to see.
We might not be after the same thing here...
In reality, water color depends on a lot of factors:
* light reflection at the surface, i.e. light diffuseness, intensity, wave
patterns, sky color, ...
- we have a decent way to account for that in the shader
* sediment and algae in the water - water being a flowing substance,
all these are variable phenomena, rivers carry a lot of mud in spring
when the snow thaws, algae bloom seasonally,... we can't model this
realistically in any case
* near the coast, depth and nature of the bottom - white underwater
sand looks quite differently from overgrown rocky bottom, deep water
looks different from shallow water... we simply don't have this
information - we might get depth somehow, pass true depth to the
shader, use it to determine color, then let the shader move the vertex
up to the water surface, but it's a bit tricky.
Given that we can't do so much realistically anyway for lack of data
(and lack of framerate - I could probably write a detailed water color
computing code, but that'd really drive framerate down), my idea is
more to re-create iconic pictures.
When approaching Nice in sunshine, I want to see one of these postcard
Cote d'Azur pictures. When landing on a drilling rig in the Northern
Sea, I don't expect to see this deep blue. Probably in reality the
differences are driven by differences in lighting, average weather and
some sediment/algae component - but when I can't do the realistic
thing, I might as well do the iconic thing.
Many people (including myself) seem to feel that the sea should look
different in different places. I'm entirely willing to tweak physics
here a bit to create a better illusion that one is in the place by
fulfilling the expectation. True, the actual Caribbean deep ocean is
not turquoise. Then again, the actual Caribbean city doesn't look the
Flightgear way either. But making sea color a lighter turquoise in the
Caribbean helps me to maintain the illusion that I am in the Caribbean
rather than the Northern Sea.
Feel free to disagree, but for me creating the visual environment has
much more to do with credible illusions than with getting the physics
of the scene right (disclaimer: my position is diffferent for the
fidelity of the FDM where we can actually get the physics really right
since we have often the required amount of data).
There are also nice patterns drawn by wind and by oil.
When the sea is flat, over distances on the order of hundreds of meters
you have changes in the wavelets that give quite different patterns from
a distance.
And furthermore, there some oil floating in nice patterns seeing at
different scales, generally in spiral.
They're stricking when saw from space, but they are also visible from
the beaches.
https://docs.google.com/viewer?a=vq=cache:P6Iom6_AjrMJ:armi.ucsd.edu/Spirals.pdf+hl=enpid=blsrcid=ADGEEShQ-kOpl7JfwiDDG2SHOGs7fkAkhVrVHwuUs1tJZO9pLKhS9ks-VrdHB2k68QgP1jJ2pKH7HwSKqnzn1tCJ0GLa88JxHVR_4xbQifElWm4FlScwpk0lZ8hfTZWjJYSld-d_ryw7sig=AHIEtbQ9vmtNjZC9WylNau0sW17FgGEe9Apli=1
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter - April 2011
Gijs de Rooy gijsr...@hotmail.com writes:
I'll keep it short this time (as I got some FG work to do myself), so
here's the link to the April edition of our monthly newsletter:
http://wiki.flightgear.org/FlightGear_Newsletter_April_2011
Papillon81's git repo is not available:
[pjb@kuiper :0 fg]$ git clone
https://gitorious.org/papillon81/flightgear-custom-scenery/
Cloning into flightgear-custom-scenery...
fatal: https://gitorious.org/papillon81/flightgear-custom-scenery/info/refs not
found: did you run git update-server-info on the server?
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future repository for non-GPL aircraft
Ryan M tpbspamm...@gmail.com writes:
Something I've always thought about is an official aircraft repository
that contained non-GPL2 aircraft- straight from the authors, of course.
There are many aircraft for FlightGear that are not GPL-licensed (some
of them very well-developed, like the Tu-154b and the MD-81), and I
think it'd be best if we had an official repository for them. Currently,
they are hosted on a number of unofficial hangars, decreasing their
visibility and their accessibility to the end-user.
This discussion has been raised before on the forums; just thought I'd
mention it here. Sorry if there's been a previous conversation about
this and I've resurrected a dead topic.
Eventually, this could even develop into a PlaneStore. The models could
be used for visualization for free, but to pilot one, the users could
have to pay a (small) fee to the authors.
I'm not specifically advocating it, but with the right structure, this
could motivate plane developers, if we need that.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] props protocol problem
ThorstenB bre...@gmail.com writes:
On 16.04.2011 02:06, Pascal J. Bourguignon wrote:
The props data protocol ls command has a problem: there's no way to
determine that its output is complete (unless we use a timer, which
would mean that all ls commands would suspend the client for the time out
duration).
I'm proposing to add a lsx command, similar to ls, but that will
terminate its output with an empty line.
Hi Pascal,
before we duplicate commands: couldn't you detect output completion by
reading until the prompt?
I was using the data mode.
In the meanwhile I detected another problem with get returning
multi-line strings. Also there's nothing preventing some lines in the
string to start with -ERR which would be interpreted as an error report.
When output is complete, the server prints a
linefeed (\n) and a / (followed by an optional property path and
). Should be easy to parse.
Ok, the prompt is only printed in PROMPT mode (obviously). There is no
prompt in RAW mode. But then it might be better to add another output
mode, i.e. a mode similar to RAW which completes _every_ existing
command with a specific character sequence, such as an additional
linefeed. Adding another command (lsx) wouldn't cost much - but then
we should also add new versions of all other commands (getx,
dumpx, runx, ...) for the same reason.
So indeed, I had to add a getx.
So, a different output mode seems a better solution?
Right. The data mode seems entirely unusable.
Or also possible:
just add a new option to configure the prompt in PROMPT mode. So
everyone can configure this to his needs.
To see what I mean, try
export PS1=FOO\nBAR\n
in your linux console - or
set prompt=#FOOBAR#
in your Win-DOS box.
Might be a better solution if you added something similar to
props.cxx. Any other thoughts?
Well, some more thought is needed, since I also notice that it is quite
slow to dump the whole property tree. The props protocol doesn't seem
adapted to my needs.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] props protocol problem
The props data protocol ls command has a problem: there's no way to
determine that its output is complete (unless we use a timer, which
would mean that all ls commands would suspend the client for the time out
duration).
I'm proposing to add a lsx command, similar to ls, but that will
terminate its output with an empty line.
In props.cxx, replace:
if (command == ls) {
with:
if((command == ls)||(command == lsx)){
and add:
if (command == lsx){
push( getTerminator() );
}
at the end of the branch.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fg_property_scale
Hello,
It seems to me that in fg_property_scale, it would be more useful if the
power was applied after the linear scaling.
The problem I have is to map the radar range axis, from [-1.0,+1.0]
to [5.0,200.0]. But a linear scale is not too nice, so I'd want to
apply a power 2.5 or 2.7. Unfortunately the current implementation
applies the power before the linear scale.
In practice, this tends to neutralize the linear scaling. If you check
the existing uses, most of the time when there's a power different from
the unit, the factor is left to 1 and the offset is 0 or close.
I would propose to use instead:
static bool
do_property_scale (const SGPropertyNode * arg)
{
SGPropertyNode * prop = get_prop(arg);
double setting = arg-getDoubleValue(setting);
double offset = arg-getDoubleValue(offset, 0.0);
double factor = arg-getDoubleValue(factor, 1.0);
bool squared = arg-getBoolValue(squared, false);
double power = arg-getDoubleValue(power, (squared ? 2.0 : 1.0));
return prop-setDoubleValue(powl((setting+offset)*factor,power));
}
This should not impact a lot of existing configurations (as mentionned,
most of them have neutral linear parameters when they use power), and
this would allow better transformation curves.
(defun property-scale (value key (offset 0.0) (factor 1.0) (power 1.0))
(expt (* (+ value offset) factor) scale))
(defun solve-property-scale (omin omax tmin tmax key (power 1))
(flet ((solve (omin omax tmin tmax)
(list :factor (/ (- tmax tmin) (- omax omin))
:offset (/ (- (* tmax omin) (* tmin omax))
(- tmin tmax)
(if (= 1 power)
(solve omin omax tmin tmax)
(solve omin omax (expt tmin (/ power)) (expt tmax (/ power))
(loop
with power = 2.5
with solution = (solve-property-scale -1.0 +1.0 5.0 200.0 :power power)
with offset = (getf solution :offset)
with factor = (getf solution :factor)
for setting from -1.0 to +1.01 by 0.1
do (format t ~10,3F -- ~10,3F~% setting (expt (abs (* factor (+ offset
setting))) power)))
-1.000 -- 5.000
-0.900 -- 7.382
-0.800 -- 10.341
-0.700 -- 13.917
-0.600 -- 18.147
-0.500 -- 23.067
-0.400 -- 28.712
-0.300 -- 35.113
-0.200 -- 42.301
-0.100 -- 50.307
0.000 -- 59.160
0.100 -- 68.887
0.200 -- 79.515
0.300 -- 91.071
0.400 --103.580
0.500 --117.067
0.600 --131.556
0.700 --147.071
0.800 --163.635
0.900 --181.271
1.000 --200.000
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal Garbage Collector
Robert dogg...@googlemail.com writes:
In the case of nasal, I believe the garbage collection pass must
be done in a single atomic step, otherwise it would leave the heap
in an inconsistent state and adversely affect the scripts.
I completely agree with you. Now I understand the whole thing much
better. I originally thought about a non-mutual-exclusive thread (
completely asynchronous ), but then it would potentially leave a mess
in Nasal heap, right?
It might be possible to use a GC module from a GPL:d Java vm or
similar.
That's a good idea. As Curtis Olson said the GC should have an atomic
step character (or don't produce too much delay).
Does anybody of you know how garbage collectors of Java and Python and
other GPL'd script engines compare to each other? (atomic step
character)
Google gives lot of real-time and multi-threaded real-time garbage
collection algorithms.
I don't know which is best.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changing ICAO codes
Martin Spott martin.sp...@mgras.net writes:
Arnt Karlsen wrote:
On Mon, 11 Apr 2011 11:49:14 + (UTC), Martin wrote in message
inuprq$pc4a$1...@osprey.mgras.de:
Shapefiles go into a PostGIS database, the Landcover-DB behind The
FlightGear MapServer. Actually it's exactly the same database which
is also holding our 3D Scenery models and, among more stuff, an
import of the OpenStreetMap Planet Dump currently 157 GByte in
total :-)
..the last fg-scenery (1.0.1) is 13GB, _roughly_, how much
will your 157GB add to the next version?
I'm talking about raw vector data used for Scenery generation and more
or less related adventures, this is only partially related to the size
of the resulting Scenery.
Nevertheless people should expect the size of the World Scenery to grow
as detail in land cover increases.
Which is no problem, a 2 TB HD costs less than 100 euro.
And downloading 2 TB on a 50 Mb/s link could take less than 4 days.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] link error on jpgRenderFrame in next pulled this night.
Erik Hofman e...@ehofman.com writes:
On Mon, 2011-04-11 at 05:39 +0200, Pascal J. Bourguignon wrote:
I just checked out the next branches in simgear and flightgear and
pulled them, and when compiling with:
I think you either need to configure simgear using --with-jpeg-factory
or need to doe a 'make uninstall' for simgear before running configure
at the flightgear side.
Thank you and Arnt, it works well with this option.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] link error on jpgRenderFrame in next pulled this night.
I just checked out the next branches in simgear and flightgear and pulled them, and when compiling with: #!/bin/bash base=/data/src/simulation/fg/ prefix=/opt/fgfs rsynch=rsync -HSWacvxz --progress --force --delete --delete-after cd $base/simgear ./autogen.sh ./configure --prefix=$prefix \ make make install cd $base/flightgear ./autogen.sh ./configure --prefix=$prefix \ make make install cd $base $rsynch fgdata $prefix/share/FlightGear the compilation of flightgear ends with this error: mv -f .deps/bootstrap.Tpo .deps/bootstrap.Po g++ -DPKGLIBDIR=\/opt/fgfs/share/flightgear\ -g -O2 -Wall -D_REENTRANT -L/opt/fgfs/lib -L/usr/local/lib -L/opt/fgfs/lib -L/usr/local/lib -o fgfs bootstrap.o libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATCDCL/libATCDCL.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Network/libNetwork.a ../../src/FDM/libFlight.a ../../src/FDM/ExternalNet/libExternalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/JSBSim/initialization/libInit.a ../../src/FDM/JSBSim/models/libModels.a ../../src/FDM/JSBSim/models/flight_control/libFlightControl.a ../../src/FDM/JSBSim/models/atmosphere/libAtmosphere.a ../../src/FDM/JSBSim/models/propulsion/libPropulsion.a ../../src/FDM/JSBSim/input_output/libInputOutput.a ../../src/FDM/JSBSim/math/libMath.a ../../src/FDM/YASim/libYASim.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/FDM/SP/libSPFDM.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../../src/Input/libInput.a ../../src/Instrumentation/KLN89/libKLN89.a ../../src/Instrumentation/libInstrumentation.a ../../src/Instrumentation/HUD/libHUD.a ../../src/Model/libModel.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/AIModel/libAIModel.a ../../src/ATC/libATC.a ../../src/Systems/libSystems.a ../../src/Time/libTime.a ../../src/Traffic/libTraffic.a ../../src/Environment/libEnvironment.a -lsgroute -lsgsky -lsgsound -lsgephem -lsgtgdb -lsgmodel -lsgbvh -lsgmaterial -lsgutil -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstructure -lsgenvironment -lplibpuaux -lplibpu -lplibfnt -lplibjs -lplibsg -lplibul -lpthread -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm -lalut -lopenal -lrt -ldl -lm -lpthread -losgFX -losgParticle -losgSim -losgViewer -losgGA -losgText -losgDB -losgUtil -losg -lOpenThreads -ljpeg libMain.a(renderer.o): In function `~FGRenderer': /data/src/simulation/fg/flightgear/src/Main/renderer.cxx:397: undefined reference to `jpgRenderFrame' /data/src/simulation/fg/flightgear/src/Main/renderer.cxx:397: undefined reference to `jpgRenderFrame' libMain.a(renderer.o): In function `FGRenderer': /data/src/simulation/fg/flightgear/src/Main/renderer.cxx:389: undefined reference to `jpgRenderFrame' /data/src/simulation/fg/flightgear/src/Main/renderer.cxx:389: undefined reference to `jpgRenderFrame' ../../src/Network/libNetwork.a(jpg-httpd.o): In function `HttpdImageChannel::foundTerminator()': /data/src/simulation/fg/flightgear/src/Network/jpg-httpd.cxx:117: undefined reference to `trJpgFactory::render()' /data/src/simulation/fg/flightgear/src/Network/jpg-httpd.cxx:208: undefined reference to `trJpgFactory::destroy(int)' ../../src/Network/libNetwork.a(jpg-httpd.o): In function `~HttpdImageChannel': /data/src/simulation/fg/flightgear/src/Network/jpg-httpd.hxx:79: undefined reference to `trJpgFactory::destroy(int)' /data/src/simulation/fg/flightgear/src/Network/jpg-httpd.hxx:80: undefined reference to `trJpgFactory::~trJpgFactory()' /data/src/simulation/fg/flightgear/src/Network/jpg-httpd.hxx:79: undefined reference to `trJpgFactory::destroy(int)' /data/src/simulation/fg/flightgear/src/Network/jpg-httpd.hxx:80: undefined reference to `trJpgFactory::~trJpgFactory()' ../../src/Network/libNetwork.a(jpg-httpd.o): In function `HttpdImageChannel': /data/src/simulation/fg/flightgear/src/Network/jpg-httpd.hxx:74: undefined reference to `trJpgFactory::trJpgFactory()' /data/src/simulation/fg/flightgear/src/Network/jpg-httpd.hxx:75: undefined reference to `trJpgFactory::init(int, int)' collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/data/src/simulation/fg/flightgear/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/src/simulation/fg/flightgear/src' make: *** [all-recursive] Error 1 Perhaps the problem is with simgear, while I find jpgRenderFrame declared in simgear/screen/jpgfactory.cxx, I don't find it in the library: nm
Re: [Flightgear-devel] Parking position names with spaces, a problem?
On 2011/04/08, at 14:45 , Roland Häder wrote:
Hi all,
for example the airport LFPG has a parking position with a name with
spaces in it. My little launcher script [1] does currently not support
this because of a for() loop will break those spaces into seperate
lines.
Assume that ${OPTIONS} is the list of command-line parmeters (I know, I
should rename that):
-- Snip
# Flushs all options to ~/.fgfsrc
fgfs_flush_options() {
echo $0: Flushing options to ~/.fgfsrc ...
echo -n ${HOME}/.fgfsrc
for entry in ${OPTIONS}; do
echo ${entry} ${HOME}/.fgfsrc
done
}
-- Snap
Can those spaced names be fixed e.g. to names with underscores? Or
won't FGFS (latest GIT/master here) find them?
If not, can I somehow support them in my script?
If you write OPTIONS as an array:
OPTIONS=( --airport=LFPG --parking='P 12' )
then you can write:
for option in ${OPTIONS[@]} ; do
printf %s\n $option
done ${HOME}/.fgfsrc
Now, while we get one option per line, we lose the quote in .fgfsrc.
If you need the quote there, then you may add them in a ad-hoc manner:
OPTIONS=( --airport=LFPG --parking='P 12' )
or you may quote systematically all the options you write:
for option in ${OPTIONS[@]} ; do
printf '%s'\n $option
done ${HOME}/.fgfsrc
but this would break if there is an option containing single quote.
To do the right thing, you have to know exactly how .fgfsrc is processed.
--
__Pascal Bourguignon__
http://www.informatimago.com
--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
