Geoffco

Hi Pete, Thanks for the info - I'll report back if I continue to get these errors after refreshing the graphics drivers and updating FSUIPC... Thanks, Geoff

Hi, I have been getting some odd CTD related to FSUIPC 4.90 in FSX. The fault is repeatable and will occur upon view change (within FSX) after the sim has been changed from fullscreen to windowed and back again at least once - since this is the only way I've found so far to 'clean out' the available memory a little bit, I have been attempting to use this trick before approach to 'OOM risk' sceneries... I get the standard windows 'chime' and the 'Fatal Error' message a few seconds afterwards. The only thing I can see going on in FSUIPC.log that is unusual (to my eyes) is this Exception 15 "WEATHER_UNABLE_TO_GET_OBSERVATION" business - is my crash likely to be related to this? In terms of weather, this is provided by FSGlobal Real Weather, but testing with the FSX 'Clear Skies' theme gives the same error... I have attached (as quotes below) an error log, the FSUIPC.log and my FSUIPC.ini... Any ideas as to wehat is going on / how to prevetn this error? Cheers, Geoff This is an example Windows Error log... This is the FSUIPC log after the crash... My FSUIPC.ini...

Thanks, I'll do it that way. Thought I'd check first in case there was already a method in place. Geoff

Hi, I like the debug console window, but I wonder if it is possible to show that real time log data on a second PC connected with WideClient? (Latest FSUIPC for FSX in use) What I want to do is watch the VAS memory availability during certain procedures in FSX, but the other options for viewing it are no good in fullscreen mode (the FS display option makes the screen flash at ~1Hz). I already run my weather programs etc on the second PC, so having the VAS displayed there would be a neat debugging setup... Cheers, Geoff

Thanks, I have looked at a couple of tutorials earlier on Lua and that will be a good way to do it, if I can get the gauge stable... The code I have got already does indeed use Panel ID open / Close and some custom L:Vars from a gauge by Doug Dawson that can tell me when different panel ID windows are actually open... I guess that the memory issue comes from the fact that FSX just doesn't like big 2D panels and obviously has some trouble when several of them are open. In FS9 I could have a single 5120x1600 front view with about 100 custom XML gauges and popups without too much trouble. In FSX, that just won't open and I have had to split it into two several parts, just to get it all to display! Geoff

They are key events captured using XML code like I showed in post #5. I have to admit they were new to me when starting this gauge, so my understanding of them is more than likely incorrect! Yes, thanks - Lua plugins is where my reading and testing will probably take me next... That's great - thanks for the pointers... I think first I will have to work out why FSX is gaining about 150-200MB to it's memory footprint with each of these views when I open them (consistently and at any airport I care to choose) and then not unloading that. It is quickly enough to get me an OOM message with heavier scenery areas, making the concept of the 2D views rapidly less appealing! Thanks, Geoff

In FSX, when there is no VC and you look right, you see only the scenery to the right. In FS9 you could easily define a bitmap image to also be displayed on that view so that when you looked right, you'd see the scenery /and/ that image, so it would look like you were looking out of the cockpit. See attached screenshot from FS9 - there is /no/ VC there, just the illusion of one using a fixed bitmap (the wingtip /is/ part of the model). GCS3371.bmp When I take the same aircraft, with no VC, in FSX there is no easy facility to get those views back, with the bitmap overlay. I can add them as panels, but then I need code to open and close them when the view is in the appropriate direction - FSX cannot do this natively anymore... I found an XML solution from Joao Muas on fsdeveloper that allows me to capture key commands to the views, and that way set up code to switch to the right bitmap / panel in my panel.cfg. Only problem being that it only works for the key presses, and not the joystick hat switch. Here is what the FSX view looks like with no 'extras' - all you get is the wing. GCS0005.bmp Hope that makes more sense. I have had a quick look at EZDOK, but as far as I can see, there is no provision for fixed views with bitmap overlays. Perhaps I am wrong? (Anyway, it might all be worthless as I seem to be getting OOM errors with these view switching scripts, so perhaps they have deeper problems...) Thanks, Geoff

I am trying to emulate that FS9 behaviour in FSX, with bitmap 2d panel views as there is no VC. As I'm sure you know, in FS9 you can set view directions, eyepoints and zoom factors for each direction in the panel.cfg. Then you set a [fixed_window.xx] entry that contains an overlay to look like a window / view from the left seat looking right etc etc. When you 'look' in that direction, the eyepoint, zoom and direction from the panel.gfg are used, and if defined, the overlay from the fixed window is used too. This is great for wing views etc. I am trying to replicate that behaviour in FSX, but annoyingly all those nice panel.cfg commands were dumped in favour of seeing the VC or nothing... FSX cannot handle fixed windows or individual viewpoints set in the same way as FS9. There are cameradefinitions, so that helps with the wing views. The only solution I found so far is to use some XML code to show a different 'panel' - no gauges, just a bitmap - depending on which view direction was pressed. The problem is that I am severely limited in what information I have to tell me where I am currently looking. There is no nice variable to say 'cockpit view, forward right is currently in use' - if that existed, this would be really easy. Instead, the only reliable handle I've got is the key capture in XML. That is only sent when the view direction is commanded directly. For whatever reason, the hat switch is not triggering that key to be sent for each view, but it is changing the view direction. If the hat switch individual positions are set to the view directions, then the relavent key is sent. Actually... I have just had a thought, which is that perhaps I am being a little dense and could in fact also capture the PAN_UP / DOWN keys if they are in the SDK, along with using Doug's gauge to only do it in the 2D view... This is worth testing... Geoff

Oops! I misread your 1st reply and assumed that I had to set it as a button (or rather, several buttons). Anyway, setting it as an axis then does exactly the same as FSX would do by default. Is that right? What I was looking for, was a way to send capture the view direction in use in order to use 2D panel views based on the direction - something that was removed by FSX with the clear assumption that nobody would want to fly aircraft without a VC (I disagree with this). I have a solution that works quite well using some code from a thread on fsdeveloper... On the keyboard, if I press the '9' key on the numberpad, I get the forward right view in the 2D panel and I can 'capture' that event with XML code like this: <Keys> <On Event="VIEW_FORWARD_RIGHT">1 (>L:FrontRightView, number)</On> </Keys> I can then use that variable to close the panel view, and open an appropriate side view. The problem is that this only works with the keyboard view commands. In order to make it work from the hat switch, I would either need to have a way to capture the hat switch command itself (simconnect, C++ and too far from my comfort zone), or find a way to make the hat switch also send the key 'view forward right' etc when selecting that position. If I only cared about the 2D cockpit view, the solution would be simple: set the eight positions of the hat switch to the appropriate view directions in fsuipc. This works regardless of whether the hat is set to pan in the FSX config. However, that would then mess up panning in the other views, unless I could make that assignment view specific. The other option, would be some module or other to return the current view direction, but I have not found anything for this. I know there is a gauge from Doug Dawson that will tell me when I'm in the cockpit view or not... Geoff

Thanks, but no joy there. Tried assigning all eight positions of the hat to 'Pan View' and set the control to repeat while held. Not panning properly and not selecting any views in the 2D. Am I missing something like a parameter for each of the positions? Also tried setting each of the hat positions to the various pan directions - now it does pan, but it is not as smooth as the FSX panning, especially in the VC view, where it seems to go in discrete steps (so I guess I did something wrong)? Views /are/ selected in the 2D cockpit, but the key is not sent so the view panels are not toggled, which was the point of the excersise... Any other ideas? Also, although this could actually be useful, the view does not reset on release of the hat switch. Cheers, Geoff

Hi, I have a hat switch on my yoke, which is set up to 'pan' the view in the main FS configuration. When using aricraft from FS9 that have no VC, I have made a gauge in XML (using "on key" statements) to show side view windows, since FSX no longer can do this. They work fine when I change view with the keyboard, but not when I use the hat switch... If I program the view directions to the individual points of the hat switch with fsuipc, the view switching in the 2D panel is good. However, panning modes (VC view or spot) are then messed up... Is there a way to set button assignments in fsuipc to only work in one view? Or is there another better solution for this problem (that doesn't involve having an actual VC). I have been advised on the fsdeveloper forum that I could capture the view direction of the hat switch with C++ and Simmconnect, but that is outside of my abilities. I am happy / reasonably competent in XML though. Thanks, Geoff

Thanks for the information. Fair enough that there's no plan to do something for FS9 if it's not a problem you've encountered and it's not the same issue as in FSX. Interesting that you didn't get this crash in your FS9 experience - I would say it is the most common one I have seen over the years. I have always assumed it to be related to scenery loading / generation... I'll just have to see if I can identify some commonality between the crashes and see if there are add-ons that could be to blame. The problem with these seems to be that they are not very repeatable - there are certain places in my FS world where they sometimes occur but then they don't happen when I go 'testing' for them with process monitor etc running / logging! Cheers, Geoff

Hi, I have been recently plagued with g3d.dll crashes in my FS9 setup - I have had to recover three of the last five flights from an autosave. I understand that currently there is code in the FSX version of FSUIPC to detect and prevent some instances of this crash, but if I recall there was no such implementation in (or planned for) the FS9 version. Two questions: 1) Is there any change to the above in that is there any chance of FS9 g3d.dll prevention? 2) The details given by MS on g3d.dll errors is fairly generic. I wondered if there is any better information as to what can cause these crashes? (eg if I get an fe.dll crash I know to go hunting for bad textures) My logic here is that if you have made a fix for them in FSX, then you knew why they were happening... PS. Sorry if this has been covered already, I tried a search but of course g3d.dll and fs9 are not very good search terms... Cheers, Geoff

Thanks very much for the clarification. It is certainly beyond my current ability to do any of that but hopefully Doug can see a way to implement something and has time to try it. The other possibility would be a timed function, then it would be independent of Autosave but the saved FS state and panel state should never then be more than a few minutes apart... For not my 'low tech' solution will be to make a normal ";" save at top of climb so that the panel variables are saved in an "airborne" state! Cheers, Geoff

Is that something that can be done from a C programmed gauge? My experience is limited to writing things in XML so I really don't know what would be involved... Unfortunate though, if it is not possible to save the variables upon autosave. Geoff