Pete Dowson

If I were you, now, I'd hold off. The weather facilities in FS9 are going to be substantially improved and I am looking at an easier way of taking advantage of it rather than extending the AWI. Admittedly, the new facilities will not be backward compatible to FS2002 or FS2000 as the AWI is (or to FS98 as the method you are now using is), but even so ... That is certainly how it is intended to be used. Every time you call the Process routine Windows has to do a process switch, allocate memory, send the message, free memory, and process switch again. You not only slow down your program, but also FS. It's even worse if your program is run on a Networked PC under WideFS, as not only all that has to happen, but WideClient also has to send a Network block over for each call. The Read and Write calls merely add data to a block in your memory, forming it all up ready to send. Takes no time at all. It's the same as this message -- how efficient would it be if I put each sentence in a difference response to you, or worse, each word? Regards, Pete

If I were you, now, I'd hold off. The weather facilities in FS9 are going to be substantially improved and I am looking at an easier way of taking advantage of it rather than extending the AWI. Admittedly, the new facilities will not be backward compatible to FS2002 or FS2000 as the AWI is (or to FS98 as the method you are now using is), but even so ... That is certainly how it is intended to be used. Every time you call the Process routine Windows has to do a process switch, allocate memory, send the message, free memory, and process switch again. You not only slow down your program, but also FS. It's even worse if your program is run on a Networked PC under WideFS, as not only all that has to happen, but WideClient also has to send a Network block over for each call. The Read and Write calls merely add data to a block in your memory, forming it all up ready to send. Takes no time at all. It's the same as this message -- how efficient would it be if I put each sentence in a difference response to you, or worse, each word? Regards, Pete

Not just the "flight sim" folder, but the Modules folder inside that -- the same place that you put FSUIPC into (which is also needed in any case). You can put the Client stuff where you like. I normally plonk it into the same folder as the Application I want to load. so, for instance, if it is FSMeteo and I have all the FSMeteo stuff in a folder "C:\FSMeteo", then I put WideClient in there, then edit the INI file to make WideClient load and close FSMeteo. THEN I drag a shortcut to WideClient.exe onto the desktop, name it "FSMeteo" and change its Icon to the FSMeteo Icon. that way, it looks like I'm starting FSMeteo, but in fact it runs Wideclient which in turn starts FSMeteo. With the parameters in the INI file you can even make FSMeteo load only when FS and the Server are ready. No! The "FS utility" is the program you are wanting to run on the Client PC. FSUIPC is an FS module, not a separate program, and can only be loaded and run by FS. Pete

Not just the "flight sim" folder, but the Modules folder inside that -- the same place that you put FSUIPC into (which is also needed in any case). You can put the Client stuff where you like. I normally plonk it into the same folder as the Application I want to load. so, for instance, if it is FSMeteo and I have all the FSMeteo stuff in a folder "C:\FSMeteo", then I put WideClient in there, then edit the INI file to make WideClient load and close FSMeteo. THEN I drag a shortcut to WideClient.exe onto the desktop, name it "FSMeteo" and change its Icon to the FSMeteo Icon. that way, it looks like I'm starting FSMeteo, but in fact it runs Wideclient which in turn starts FSMeteo. With the parameters in the INI file you can even make FSMeteo load only when FS and the Server are ready. No! The "FS utility" is the program you are wanting to run on the Client PC. FSUIPC is an FS module, not a separate program, and can only be loaded and run by FS. Pete

You can now try the http://www.schiratti.com/dowson page -- Enrico has kindly provided an alternative method for donations via PayPal on his website. this just became operable today. Maybe you might find it simpler? Regards, Pete

You can now try the http://www.schiratti.com/dowson page -- Enrico has kindly provided an alternative method for donations via PayPal on his website. this just became operable today. Maybe you might find it simpler? Regards, Pete

I'd love to find a way to do that. In FS98 I was able to separate off the ADVenture sounds (Adventures then being used for ATC), which is why I wrote ESOUND.DLL, but I could never figure out how to do than in FS2000 or FS2002. I supsect things are even more complex with the FS2002 ATC itself. This is one of the reasons why I use Radar Contact Version 3, running on a separate PC via WideFS. Regards, Pete

I'd love to find a way to do that. In FS98 I was able to separate off the ADVenture sounds (Adventures then being used for ATC), which is why I wrote ESOUND.DLL, but I could never figure out how to do than in FS2000 or FS2002. I supsect things are even more complex with the FS2002 ATC itself. This is one of the reasons why I use Radar Contact Version 3, running on a separate PC via WideFS. Regards, Pete

No. They are highly supported by base code and DLLs in FS itself. Really they are a "template" for the gauge, whether it is written in C or XML -- obviously more so in XML which is an interpreted template in any case. Pete

No. They are highly supported by base code and DLLs in FS itself. Really they are a "template" for the gauge, whether it is written in C or XML -- obviously more so in XML which is an interpreted template in any case. Pete

Yes, it is odd the way it worked in FS98. It was the folks who had got FS98 weather programs working who told me these things. I've never used them myself. I think MS intended to add more types but didn't. Ah, I didn't notice that. Forget what I said then, except it is a good idea to clear the storm layer since it may have been set from before. Sorry, I don't know VB -- I suspect it would get quite complicated in VB. It is defined in terms of C of course. Maybe someone else could help (thought the only two persons I know who have used the AWI are Marc Philibert, in FSMeteo, and Luciano Napolitano, in WidevieW). Pete

Yes, it is odd the way it worked in FS98. It was the folks who had got FS98 weather programs working who told me these things. I've never used them myself. I think MS intended to add more types but didn't. Ah, I didn't notice that. Forget what I said then, except it is a good idea to clear the storm layer since it may have been set from before. Sorry, I don't know VB -- I suspect it would get quite complicated in VB. It is defined in terms of C of course. Maybe someone else could help (thought the only two persons I know who have used the AWI are Marc Philibert, in FSMeteo, and Luciano Napolitano, in WidevieW). Pete

The data you are setting is not entirely valid. Going from the LOG (I do not know or use VB): First setting: 583869 WRITE0 0EA4, 2 bytes: 64 0D 583869 WRITE0 0EA2, 2 bytes: 9D 12 583869 WRITE0 0EA6, 2 bytes: FF FF 583869 WRITE0 0EA8, 2 bytes: 39 05 583869 WRITE0 0EFE, 2 bytes: 04 00 583869 WRITE0 0F1E, 2 bytes: 49 09 583869 FS98 Cloud2: type=4, from 7798ft to 10764ft (+/- 1965ft), cover 8, turb 0, ice 0 You are setting Upper Cloud first. That won't work. The first cloud is Thunderstorm or Lower cloud. You can't have a second or third layer before you have a first layer. Don't ask me why, it is the way FS98 worked, and the interface you are using (unlike the Advanced Weather Interface) is based on FS98 practice. Worse, you are trying to set cloud type 4. which is not defined. You see the list in the SDK document? 583869 WRITE0 0F1C, 2 bytes: 40 0B Writing to 0F1C is the same as writing to 0E9A -- as clearly documented. You should really be only writing to 0F1C upwards in any case. The 0E9A area is for reading. But FSUIPC enforces this rule in any case. Writing to both as you are only wastes time. 584069 WRITE0 0EA4, 2 bytes: F4 05 584069 WRITE0 0EA2, 2 bytes: 6E 15 584069 WRITE0 0EA6, 2 bytes: FF 9F 584069 WRITE0 0EA8, 2 bytes: E8 0B 584069 WRITE0 0EFE, 2 bytes: 07 00 584340 FS98 Cloud1: type=7, from 5000ft to 17998ft (+/- 10000ft), cover 5, turb 0, ice 0 Again, there's no type 7, and you cannot have a variation in cloud base of 10000 feet when the cloudbase is only 5000 feet in the first place. Variations are usually small, like 50-300 feet. Possibly, apart from the invalid cloud type FS doesn't like such a big variation. From the FSInterrogate pictures you attached, I also noticed that the Storm layer coverage is set to 1 but with no cloud altitudes set nor a type. This seems to be left over from a previous setting (?), but you should take care to clear the storm data before setting the lower cloud. So the order is: 1. clear storm layer (or, of course, set it if required) 2. set lower layer (taking care to ensure VALID numbers) 3. if more than one layer, set upper layer (with VALID numbers) and you do all this in the 0F1C- area (same applies to all the other weather data). This is the FS98 way, so you are limited to two cloud layers, plus the optional stom lowest layer. FS2000 ad FS2002 can have many more layers, but to use them you'd have to switch to the AWI. Regards, Pete

The data you are setting is not entirely valid. Going from the LOG (I do not know or use VB): First setting: 583869 WRITE0 0EA4, 2 bytes: 64 0D 583869 WRITE0 0EA2, 2 bytes: 9D 12 583869 WRITE0 0EA6, 2 bytes: FF FF 583869 WRITE0 0EA8, 2 bytes: 39 05 583869 WRITE0 0EFE, 2 bytes: 04 00 583869 WRITE0 0F1E, 2 bytes: 49 09 583869 FS98 Cloud2: type=4, from 7798ft to 10764ft (+/- 1965ft), cover 8, turb 0, ice 0 You are setting Upper Cloud first. That won't work. The first cloud is Thunderstorm or Lower cloud. You can't have a second or third layer before you have a first layer. Don't ask me why, it is the way FS98 worked, and the interface you are using (unlike the Advanced Weather Interface) is based on FS98 practice. Worse, you are trying to set cloud type 4. which is not defined. You see the list in the SDK document? 583869 WRITE0 0F1C, 2 bytes: 40 0B Writing to 0F1C is the same as writing to 0E9A -- as clearly documented. You should really be only writing to 0F1C upwards in any case. The 0E9A area is for reading. But FSUIPC enforces this rule in any case. Writing to both as you are only wastes time. 584069 WRITE0 0EA4, 2 bytes: F4 05 584069 WRITE0 0EA2, 2 bytes: 6E 15 584069 WRITE0 0EA6, 2 bytes: FF 9F 584069 WRITE0 0EA8, 2 bytes: E8 0B 584069 WRITE0 0EFE, 2 bytes: 07 00 584340 FS98 Cloud1: type=7, from 5000ft to 17998ft (+/- 10000ft), cover 5, turb 0, ice 0 Again, there's no type 7, and you cannot have a variation in cloud base of 10000 feet when the cloudbase is only 5000 feet in the first place. Variations are usually small, like 50-300 feet. Possibly, apart from the invalid cloud type FS doesn't like such a big variation. From the FSInterrogate pictures you attached, I also noticed that the Storm layer coverage is set to 1 but with no cloud altitudes set nor a type. This seems to be left over from a previous setting (?), but you should take care to clear the storm data before setting the lower cloud. So the order is: 1. clear storm layer (or, of course, set it if required) 2. set lower layer (taking care to ensure VALID numbers) 3. if more than one layer, set upper layer (with VALID numbers) and you do all this in the 0F1C- area (same applies to all the other weather data). This is the FS98 way, so you are limited to two cloud layers, plus the optional stom lowest layer. FS2000 ad FS2002 can have many more layers, but to use them you'd have to switch to the AWI. Regards, Pete

It sounds plausible, but if so it seems to be rather a serious error in the design of that part of PM. What does Enrico say? He will surely know that there are folks with individual throttle controls. Please keep me posted. Pete

It sounds plausible, but if so it seems to be rather a serious error in the design of that part of PM. What does Enrico say? He will surely know that there are folks with individual throttle controls. Please keep me posted. Pete

Yes, of course you do! The Server is the one "serving" the clients. No client knows about any other clients! Furthermore, the shutdown facility is done merely by setting an offset in FSUIPC which is read by all clients. If FS isn't running, then neither can FSUIPC or WideServer, so there is nothing going on between any of them! This is why the shutdonw facility in WideServer is delayed by a number of seconds, to ensure all Clients read the message. Pete

Yes, of course you do! The Server is the one "serving" the clients. No client knows about any other clients! Furthermore, the shutdown facility is done merely by setting an offset in FSUIPC which is read by all clients. If FS isn't running, then neither can FSUIPC or WideServer, so there is nothing going on between any of them! This is why the shutdonw facility in WideServer is delayed by a number of seconds, to ensure all Clients read the message. Pete

I'm sorry, but I've not heard of this "Safeline" console. It sounds like a piece of hardware from what you say. Does it have a driver running in the PC? If so is it an EXE talking to FSUIPC, or a module or gauge for FS? Does it even use FSUIPC? >> I have contacted the manufactur for the last three month and tried different things including replacing the CPU on the console. << Ah, so it definitely is hardware! >> The console uses the COM port. It seems that the computer does not recognize the console anymore. << Right. So there is some driver which you must be loading in the FS PC. Is this an EXE? OR have you installed something into FS? It is this which is most suspect I think -- either that or your COM port has become inoperable for some reason. Maybe you've changed your PC configuration and the COM port IRQ is being shared? That might not be good. >> I tried to revert back to the older version of FSUIPC, it did not help either. << Well that most certainly eliminates FSUIPC in any case -- FSUIPC does no permanent changes. If you revert, you revert. >> I have read the posts on this forum and documents came with the update and could not find an answer. << I think you need to look at what the console driver is doing, and whether that has been corrupted or whether something is amiss with the COM port side of things. Pete

I'm sorry, but I've not heard of this "Safeline" console. It sounds like a piece of hardware from what you say. Does it have a driver running in the PC? If so is it an EXE talking to FSUIPC, or a module or gauge for FS? Does it even use FSUIPC? >> I have contacted the manufactur for the last three month and tried different things including replacing the CPU on the console. << Ah, so it definitely is hardware! >> The console uses the COM port. It seems that the computer does not recognize the console anymore. << Right. So there is some driver which you must be loading in the FS PC. Is this an EXE? OR have you installed something into FS? It is this which is most suspect I think -- either that or your COM port has become inoperable for some reason. Maybe you've changed your PC configuration and the COM port IRQ is being shared? That might not be good. >> I tried to revert back to the older version of FSUIPC, it did not help either. << Well that most certainly eliminates FSUIPC in any case -- FSUIPC does no permanent changes. If you revert, you revert. >> I have read the posts on this forum and documents came with the update and could not find an answer. << I think you need to look at what the console driver is doing, and whether that has been corrupted or whether something is amiss with the COM port side of things. Pete

Page 1 is the "all engine" throttle with no reverse section. Page 3 are the individual throttles for each of up to 4 engines. Those have reverse sections. They are different FS axis controls. Please see the FSUIPC documentation where the controls are listed in the tables. >> I am assuming that the problem is related to the "Axis_throttle_set" and "Axis_throttle1_set", "Axis_throttle2_set" etc in the FS joystick setup linking to different values in FSUIPC and that the PM software is reading from a differing value. << Sorry, I've really no idea what you are talking about here. Before even attempting to use FSUIPC's joystick facilities you do need to get things working normally. Apart from the special mapping facilities in FSUIPC, the calibration is only a final "tweaking" of the values just before they get to the FS simulation engine, for more precise null and centre settings. If PM's Airbus processing is at all realistic (i.e. fly by wire) your joystick inputs, including throttles, would actually be disconnected from FS in any case and manipulated by the flight management system, even without auto-throttle or A/P engaged. There are facilities in FSUIPC to allow this to be done -- but you will have to ask PM support what is actually going on I'm afraid. Meanwhile, either delete the joystick section from your FSUIPC.INI file, or press the "reset" button in FSUIPC options for each axis, and get everything reasonably working without FSUIPC calibration first. Only use it to "sweeten" the results afterwards. Pete

Page 1 is the "all engine" throttle with no reverse section. Page 3 are the individual throttles for each of up to 4 engines. Those have reverse sections. They are different FS axis controls. Please see the FSUIPC documentation where the controls are listed in the tables. >> I am assuming that the problem is related to the "Axis_throttle_set" and "Axis_throttle1_set", "Axis_throttle2_set" etc in the FS joystick setup linking to different values in FSUIPC and that the PM software is reading from a differing value. << Sorry, I've really no idea what you are talking about here. Before even attempting to use FSUIPC's joystick facilities you do need to get things working normally. Apart from the special mapping facilities in FSUIPC, the calibration is only a final "tweaking" of the values just before they get to the FS simulation engine, for more precise null and centre settings. If PM's Airbus processing is at all realistic (i.e. fly by wire) your joystick inputs, including throttles, would actually be disconnected from FS in any case and manipulated by the flight management system, even without auto-throttle or A/P engaged. There are facilities in FSUIPC to allow this to be done -- but you will have to ask PM support what is actually going on I'm afraid. Meanwhile, either delete the joystick section from your FSUIPC.INI file, or press the "reset" button in FSUIPC options for each axis, and get everything reasonably working without FSUIPC calibration first. Only use it to "sweeten" the results afterwards. Pete

You need the AllowShutDown in each Wideclient.ini and, if you want FS also to shut down, in WideServer.ini too. The Server maintains the command in the ShutDown offset for 10 seconds, or something like that, to give time to each of the others to see it, before it too closes. This works consistently here -- mixture of XP and 98SE PCs, TCP/IP. Pete

You need the AllowShutDown in each Wideclient.ini and, if you want FS also to shut down, in WideServer.ini too. The Server maintains the command in the ShutDown offset for 10 seconds, or something like that, to give time to each of the others to see it, before it too closes. This works consistently here -- mixture of XP and 98SE PCs, TCP/IP. Pete

Yeah. The control names are none too good in many cases. All FSUIPC does is read the FS assigned names from the CONTROLS.DLL, so it gets what MS called them internally. It's the only was FSUIPC can get the correct list for each version of FS without me building in losts of extra data. Regards, Pete