[Flightgear-devel] Crazy usability suggestion of the day
Can anyone tell me a problem, with forcing startup location to 'not a runway'
*when MP is enabled* ?
I'd pick an available parking at semi-random, if the airport has parking
locations. Another option, if the airport has a ground-network, would be to try
to guess a hold-short location for the runway, but that rapidly becomes tricky
with parallel runways, different aircraft radii, and so on. Parking locations
seem safer, but people will have to taxi in MP mode. I'm sure the ATCs would
prefer than anyway.
This *could* disregard the --runway option, but then we're actively over-riding
the user's wishes, rather than just avoiding a default behaviour which is bad
with MP on. In the GUI (airport selector dialog ) we could disable the 'best
runway' option, or even the runway selector combo entirely, if we wished to be
strict about it. ('this feature is disabled in multiplayer mode' prompt text,
of course)
Comments?
James
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crazy usability suggestion of the day
On Tue, Mar 5, 2013 at 11:10 AM, James Turner wrote:
Can anyone tell me a problem, with forcing startup location to 'not a runway'
*when MP is enabled* ?
I'd pick an available parking at semi-random, if the airport has parking
locations. Another option, if the airport has a ground-network, would be to
try to guess a hold-short location for the runway, but that rapidly becomes
tricky with parallel runways, different aircraft radii, and so on. Parking
locations seem safer, but people will have to taxi in MP mode. I'm sure the
ATCs would prefer than anyway.
This *could* disregard the --runway option, but then we're actively
over-riding the user's wishes, rather than just avoiding a default behaviour
which is bad with MP on. In the GUI (airport selector dialog ) we could
disable the 'best runway' option, or even the runway selector combo entirely,
if we wished to be strict about it. ('this feature is disabled in multiplayer
mode' prompt text, of course)
Comments?
I think this is a fine idea. At present working out the available
parking positions for and airport from outside the sim is a bit of a
pain. (In fact I usually start with MP off, then use the Select
Airport dialog to position at a parking position, and then turn MP on)
I assume by semi-random you mean to choose parking positions fairly
close to the approach end of the active runway?
Making a similar change to the airport selector would be a good idea
as well, though obviously we'd only disable the option if parking
positions exist for the airport.
On a related note, I've been wondering whether we should start the sim
with the engines running when starting from a runway. Being on the
runway with the engine off isn't particularly realistic. If we were
feeling particularly keen also having the altimeter set and the radios
tuned to the tower frequency might be nice.
-Stuart
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crazy usability suggestion of the day
On 5 Mar 2013, at 11:28, Stuart Buchanan stuar...@gmail.com wrote: I think this is a fine idea. At present working out the available parking positions for and airport from outside the sim is a bit of a pain. (In fact I usually start with MP off, then use the Select Airport dialog to position at a parking position, and then turn MP on) Indeed, which is what I'd like to streamline, as well as avoiding novice users cough doing the default bad behaviour. I assume by semi-random you mean to choose parking positions fairly close to the approach end of the active runway? Probably, that's the area that will need work. We don't have parking occupancy data over MP, but it could be guessed by looking for AIModels whose location is within 4 (?) metres of the parking location, and skipping that one. Making a similar change to the airport selector would be a good idea as well, though obviously we'd only disable the option if parking positions exist for the airport. Sure. On a related note, I've been wondering whether we should start the sim with the engines running when starting from a runway. Being on the runway with the engine off isn't particularly realistic. If we were feeling particularly keen also having the altimeter set and the radios tuned to the tower frequency might be nice. Ah, that's a much more contentious one. The problem, from my point of view, is that our -set.xml files only encode one aircraft state (usually cold-and-dark). To encode (accurately) engines-running or in-flight as the start state, needs some kind of profile system where properties can have different values, and XML / Nasal can be initialised differently. That would make nice in-air starts possible (gear already up, throttles at sane position), as well as offering 'cold, dark and parked' or 'on the active and ready to go' as options. (And end all the per-aircraft 'auto-start' menu options - since they'd become standardised). That's the UX idea, I have pretty much zero idea how the code might work, especially getting state-ful systems such as GPWS, autopilot PID filters or the like to work with it. I think at least one FDM also has issues with in-air starts at the moment. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get my bug fix into the git?
Hi Thomas, Anyhow, I have just pushed a fix which replaces the manual string copying with directly using std::string. Please test if this also solves your problem. Not sure if I'm experiencing the same issue, but it looks related. SimGear fails to compile for me, showing these errors: http://pastebin.com/917r9B1s Thanks! Gijs -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get my bug fix into the git?
Hi Gijs, I don't think it is related specific to the strdup(), it looks more like it has something to do with boost 1.44, I was compiling using a higher version, boost 1.53. And @Tom, I used macros to work around the strdup() under MSVC, as you suggested, and I have submitted the merge request to both simgear and flightgear, please have a look. Thanks! Sincerely Godspeed On Tue, Mar 5, 2013 at 1:23 PM, Gijs de Rooy gijsr...@hotmail.com wrote: Hi Thomas, Anyhow, I have just pushed a fix which replaces the manual string copying with directly using std::string. Please test if this also solves your problem. Not sure if I'm experiencing the same issue, but it looks related. SimGear fails to compile for me, showing these errors: http://pastebin.com/917r9B1s Thanks! Gijs -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get my bug fix into the git?
Hi, Am 2013-03-06 00:11, schrieb Godspeed Dash: I don't think it is related specific to the strdup(), it looks more like it has something to do with boost 1.44, I was compiling using a higher version, boost 1.53. The warnings should now have gone, but the other errors look like due to a very old boost version. And @Tom, I used macros to work around the strdup() under MSVC, as you suggested, and I have submitted the merge request to both simgear and flightgear, please have a look. I'd prefer to add it globally instead of doing it for every single occurrence. Could you try it with adding -Dstrdup=_strdup to the respective set(MSVC_FLAGS commands in FlightGear/SimGear root CMakeLists.txt files? Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
