Problems with 3.0 release

[rioit]

I have downloaded and installed 3.0 release but it crash everytime after few minutes. The 777 seattle autopilot doesn´ t work for me; when i click the v/s buttom it set the speed and if i click on hdg buttom nothing happen. Also the v/s number doesn´ t appear.
Last question I cant see the menu bar on the top of the screen; there is some special keys to do it?
Anyone with suggestions?

[Thorsten]

F10 should bring up the menu bar.

With regard to the crash:

What OS?

Is there any reason for the crash shown on the console? Any error message?

Can you monitor memory consumptions, are you perhaps having memory overflow on a 32bit system?

With regard to the AP - are you sure you're using it correctly?

[Hooray]

Hi & welcome, please see the red/pink box at the top of the support forum, regarding FG crashing, please provide the startup log file that you can find in $FG_HOME, for details see: http://wiki.flightgear.org/$FG_HOME

To troubleshoot those crashes, you may want to check out: http://wiki.flightgear.org/Howto:Debugg ... ar_Crashes

[rioit]

Thanks everibody but after 10 minutes crash again. I was running 2.12 perfectly with windows 8 64 bit with almost all features on as clouds and so on and only sometimes in very traffic airports had some crash. I have done all the procedure you told me but continue crashing; I think I need to continue using the 2.12 version.

[Hooray]

please provide the log file that we asked for previously

[rioit]

Sorry where I find the log file?

[Hooray]

see my earlier comments regarding FG_HOME

[rioit]

<?xml version="1.0" encoding="UTF-8" ?>
<CrashRpt version="1402">
<CrashGUID>ecfcef1a-b87b-4434-b6da-f15d02bc193e</CrashGUID>
<AppName>FlightGear</AppName>
<AppVersion>3.0.0</AppVersion>
<ImageName>C:\Program Files\FlightGear\bin\Win32\fgfs.exe</ImageName>
<OperatingSystem>Windows 8 Pro Build 9200</OperatingSystem>
<OSIs64Bit>1</OSIs64Bit>
<GeoLocation>pt-br</GeoLocation>
<SystemTimeUTC>2014-01-30T17:52:01Z</SystemTimeUTC>
<ExceptionAddress>0x53190104</ExceptionAddress>
<ExceptionModule>C:\Windows\System32\ig7icd32.dll</ExceptionModule>
<ExceptionModuleBase>0x530a0000</ExceptionModuleBase>
<ExceptionModuleVersion>9.17.10.2817</ExceptionModuleVersion>
<ExceptionType>11</ExceptionType>
<GUIResourceCount>18</GUIResourceCount>
<OpenHandleCount>319</OpenHandleCount>
<MemoryUsageKbytes>1465968</MemoryUsageKbytes>
<CustomProps>
<Prop name="hudson-build-id" value="2014-01-23_11-12-43" />
<Prop name="hudson-build-number" value="93" />
</CustomProps>
<FileList>
<FileItem name="crashdump.dmp" description="Crash Minidump" />
<FileItem name="crashrpt.xml" description="Crash Description XML" />
<FileItem name="fgfs.log" description="FlightGear Log File" />
</FileList>
</CrashRpt>

[Thorsten]

I was running 2.12 perfectly with windows 8 64 bit with almost all features on as clouds and so on and only sometimes in very traffic airports had some crash.

But you appear to be running the 32 bit version of FG now - so if that overruns the memory allowed for a 32bit application it would presumably crash. And if you had a 64bit version of 2.12, it would run perfectly.

[rioit]

But there is just one version to download, how I can find the 64bit?

[Gijs]

It's the same download, but on installation you should uncheck the "force 32 bits installation" option

[rioit]

ok, thanks a lot

[Hooray]

We should really add an option to the HELP/ABOUT dialog that shows the architecture, i.e. 32/64 bit, based on fgSetBool() and using #ifdefs or checking void pointer size:

Code: Select all


#if _WIN64 || __amd64__ || __X86_64__
// 64 bit build
const char* ARCH = "64bit";
#else
const char* ARCH = "32bit";
#endif
fgSetBool("/sim/version/platform", ARCH);


http://sourceforge.net/p/predef/wiki/Architectures/

But there's probably also a cmake macro for this.

Alternatively, we can simply use SimGear's Nasal headers, which already determine if the target is 32bit or 64bits

[Philosopher]

... Nasal doesn't quite do what you want, only *supported* 64-bit platforms. Besides, that code is hardly accessible from anywhere else - it's hidden/back-end for a reason.

[Hooray]

the naRef structs are accessible to FGNasalSys, so matching the MAGIC COOKIE against the #defines would be straightforward to do, it could be just a static member of FGNasalSys (even though we want to get rid of those...)
I do agree that there are probably better ways to expose this tho.