barryoo

My most successful generic home build starts with a strong enough computer and video card to use two monitors that provide frame rates that meet my comfort zone. Note that every window created and moved to a second or third monitor cuts frame rates. With two monitors, hopefully 27inch +/- , you can use the first monitor, zoomed in for large readable panel gauges, MDF, ect; This allows you to easily mouse click any control without using the irritating pan, zoom, or anything like that. Any time you change aircraft you are looking at the real panel. In my mind anytime you have a switch, knob, or other hardware you partially take away the actual aircrafts configuration. The second monitor is used only for front windscreen view. Now not the 2D view, I mean the 3D cockpit view. If the windows fog, you see it; if the wipers are on you see them. Once you have this going you can decide it any other hardware is necessary or not.

Thanks Stephen, The Opus "weather only feature" has previously worked well on my client computer, and in fact, I would like it installed there for your weather map features. (ps. Hope you are still considering the addition of the wind direction arrows and legends. LOL.....as off subject as this may be a 10 and 20 mile ring around the weather maps center point would be an astonishing improvement) Anyway back on subject, My opus client problem has most always been about transferring server configured client cameras to the client as well as my configured window cameras being ignored and replaced by the default Opus window view camera. I will again reinstall Opus on the client and hope that Opus weather will translate to the WidevieW client.

Opus is a very good program, it does so many things well. I purchased Opus for the weather; Haze, fog, cloud layering; the weather reporting system is outstanding and surprisingly - it continues to be improved. I also like live view on the server as well as buttkicker. On my computer system WidevieW is easier to set up on a client and it does seem to work well with Opus on the server. I kind of gave up on Opusclient, at least for a while, until live view camera transfer issues and security/ownership issues work better on my equipment. As this is a new client build to remove Opus client and resurrect my older but latest update WidevieW program I have yet to establish if the Opus weather properly transfers to the client.

Copied from A2A Forum: I beat a similar topic to death with flaps and lights not working on the A2A c172 using a server and client computer system with OpusFSX. So for the thousands of FSX users who run more than one computer with OpusFSX or WidevieW I have further bad news for you. With a new FSX build installing all updates, SP1 and SP2 and additionally, as an addon, the latest version of WidevieW. Guess what: The A2A c172 flaps and lights do not work. Surprise, surprise! It's disturbing to find the A2A programmers so uninterested in correcting this deficiency.

Finally back on-line with client and server. Stephens Quote: Could you please try loading a standard C172 on the server and your A2A C172 on the client. Then see if the FLAPS HANDLE INDEX control will be accepted by the sim (after all it is operating in FROZEN mode so with a bit of luck the A2A software is completely dormant). If this works there may be a solution. My Results: When the 172SP is loaded on the server and the Opus server Is running, with colored green OpusFSX client connections, the servers 172SP flaps go up and down as would be expected. When the 172SP is loaded on the client the servers flap commands are received by the client and the flaps, although slightly delayed, go up and down to the servers flap position. Everything works as would be expected. During the same session or during a clean FSX start-up substituting the A2A for the 172SP on the client the results follow: When the 172SP is loaded on the server and the Opus server Is running, with colored green OpusFSX client connections, the servers 172SP flaps go up and down as would be expected. When the A2A c172 is loaded on the client the servers flap control lever commands are not received by the A2A. The A2A flaps do not move. The A2A c172 offers some fairly realistic aircraft fuselage, wing and stabilizer movements from the CLIENTS spot view while running the A2A c172 or the 172SP on the server. The aircraft body will tip down when breaks are applied, the tail of the aircraft vibrates and bounces during taxi ( perhaps too much but usable). One problem I do see is that when the clients A2A is stopped on a taxiway, ramp, etc. it will tend to roll backwards about 6 feet when the servers aircraft flap lever is pushed.

Quote: Could you please try loading a standard C172 on the server and your A2A C172 on the client. Then see if the FLAPS HANDLE INDEX control will be accepted by the sim (after all it is operating in FROZEN mode so with a bit of luck the A2A software is completely dormant). If this works there may be a solution. The solution being ... if A2A find it too difficult to update the FLAPS HANDLE INDEX variable then I will maintain it for them. ------------------------------ Stephen, Yesterday, will beating myself to death trying to change variables to get FSXserver to save .CAM files to FSXclient, I destroyed my Opus programs. Relax and enjoy your flight to France or where-ever. I will have an answer when you return. Thanks for your help.

Quote: I hope you can see and understand the dilemma here. The client software will be sending two simultaneous controls to the sim ... The FLAPS HANDLE INDEX control / indication (being always zero) will always be commanding the sim to move the flaps to the fully up position. As I wrote previously, the Trailing Edge Left/Right variables can be used only to read current flaps position in A2A aircraft. To set them from the client computer, use one of the flaps events (KEY_FLAPS_SET, KEY_AXIS_FLAPS_SET, KEY_FLAPS_INCR etc.). When two flaps related A:variables are set at the same time using simConnect, the result may be unpredictable. We did such tests when we develped this system about six years ago, so I don't remember the details, but the variables will fight each other and one of those will take precedence. That's the reason why we don't use the other variable. _________________ Michael Krawczyk

Quote: If A2A are unwilling to add this variable could you ask them to confirm that they will treat the Trailing Edge Left/Right Percent signals as a control, and not simply as there output signal to show what the flap status is currently. I don't want to implement these changes only to find they are pointless. I will implement it if needed and leave it to you to test the results, but would prefer confirmation from A2A. The Trailing Edge Left/Right variables can be used only to read current flaps position. To set them from the client computer, use one of the flaps events (KEY_FLAPS_SET, KEY_AXIS_FLAPS_SET, KEY_FLAPS_INCR etc.). _________________ Michael Krawczyk

Stephen, Are you in direct communication with Michael Krawczyk? if so - I should not need to copy your last two posts to the A2A site.

A2A responses: Post subject: Re: A2A c172 Flaps do not work on Opus Client computerPosted: Tue Apr 29, 2014 11:34 am Staff Sergeant Joined: Mon Sep 02, 2013 5:30 pm Posts: 292 Location: N07, 12N, KLDJ, KCDW I'm not an A2A rep but you should consider what is being stated by the developer. A2A is seeing the actual flap position and not the flap lever position. I can only guess at the reason for this but I suspect that A2A needs to do this so they can simulate behaviors that can not be modeled if the flap position is left as a derivative of the flap lever function. Instead of telling the flap motor to move flaps from position 1, 2 and 3, they are the motor itself. I imagine this is how they can model the wiggling and loose flaps during preflight as well as broken flaps while inflight. This is a fundamental difference in operation. If course this is only my interpretation of what has been stated. ---------------- ---------------- Post subject: Re: A2A c172 Flaps do not work on Opus Client computerPosted: Tue Apr 29, 2014 1:07 pm A2A Lieutenant Colonel Joined: Sun Aug 03, 2008 9:56 am Posts: 1076 Location: Poland In FSX the same result can often be achieved in several ways, and all of them can be viewed as "standard". But once you start to develop systems beyond fsx defaults, everything gets much more complicated, not every way becomes the "right" way. And it gets impossible to maintain compatibility with every addon on the planet. In this particular case, the variable suggested by Opus is a simple flaps switch position. Since the first accusim aircraft years ago, we have used a more sophisticated system that allows us to directly control each flap independently, and this variable is not compatible with it. For some of our airplanes it does not even make sense, P40, P47 and B17 don't have typical flaps controls, their flaps can be set smoothly to any position between min and max. [COMMENT] The FLAPS HANDLE INDEX (0 = flaps up, 255 = flaps fully down) is listed as a general All Aircraft parameter. It does not measure the flap handle position as simply 1,2,3 etc. it actually measures the current flap 'control' as 0 = fully up to 255 = fully down, 1 to 254 = all positions in between. So you can STILL use the control to indicate ANY flap position totally independent of the aircraft type. That's why this percentage type variable is for 'All Aircraft'. Stephen. {/COMMENT] Even if we somehow managed to set this variable while still using our system for flaps control, you won't see on your client computer any of the advanced accusim features, like flaps wiggling, jamming, assymetric flaps deployment etc. Which defeats the purpose of doing it. [COMMENT] True, sounds good to me but never personally known it to happen in the real world in nearly 20 years of flying and a lot of my friends fly 172s all the time. I will include the Trailing Edge... signals for the user to try. Stephen. [/COMMENT] _________________ Michael Krawczyk

Responding to Stephens question: Can you confirm you have the Everyone user group added. Perhaps I do not know how to add the Everyone user group. The only thing I have done in install Everyone in Properties-Sharing-advanced sharing- permissions-share permissions and created full control for the everyone "group or user names". Same thing for Security. May be I somehow don't have a Everyone user group and do not know how to install it. Windows 7 help does not describe "user group" only " User Account" and " HomeGroup". Responding to Firewall issue: I have removed Macafee and turned Windows firewall, Malwarebytes Off on both computers for this tweak process. I tried to do the work- around by giving up on the servers OpusFSX-Camera save to client function and tried to do a server copy of all FSXCLIENT_xxxxx.CAM files and paste them to my clients C:\OpusFSX subdirectory but that kind of destroyed use of the program. Do the FSXCLIENT.DAT and FSXCLIENT.CAM FILE also have to be copied?

Hi. This is from A2A: We use flaps, but we use them directly by writing their actual position into fsx using simconnect. If opus is listening only for keyboard events to raise or lower flaps, they are not sent. The variables we use for current flaps position are standard fsx variables named "Trailing edge flaps left/right percent". They can be read using simconnect from client computer.

12. Does "Authenticated Users" have to be installed and set as full control on properties-share? ( I am only speaking about the {Share} not security).

Sorry for the pain. This is deliriously funny but perhaps necessary if this is to be resolved. I assure you that I am doing what you tell me. I am Not at my computer now so I will respond to your directions on a later post. For now, in order to better understand and deal with my problem, please answer simply YES or NO or NOT SURE YET to the following questions. 6. Is my camera save problem a SimConnect problem where Opus SimConnect.msi should be installed? 7. Do you agree {for the entire Opus program to work} that there are only two (2) drives on the server and two (2) drives on the client that need property changes to insure share and security rights? ( on my computer those are C drive where the OpusFSX subdirectory is located and the D drive where the FSX program is located). 8. Does the {camera save to client problem} have anything to do with share and security rights on both server and client computers D drive where the FSX programs are located? 9. Do you agree {for the entire Opus program to work} that there are only two (2) subdirectories on the server and two (2) subdirectories on the client that need property changes to insure share and security rights? ( on my computer those are C:\OpusFSX is located and the D:\FSX program is located). 10. I have installed OpusFSX_V345 Beta.msi. I was getting an occasional but not consistent camera save completed to the client before doing the last two Beta upgrades. Should I reinstall your old OpusFSX that is published? 11. Opus is doing an excellent job presenting weather, live camera etc. while I am actually flying an aircraft. Perhaps there Is a work around my save problem. Can l do a manual copy of Clientxxxxx.cam files that are saved in C:\OpusSFX on the server and pasting them into C:\OpusFSX on the client?

To reinterate: I can fly any aircraft using Opus live camera on both the Client and Server. everything works during a flight. The Opus client receives and translates all server flight data without any problems. I just can not get Opus server to save a camera data to the client. To my mind it is entirely a file save issue between server and client. 1. I can not see that this is a LAN adapter problem or network connection problem. Data seems to perfectly flow from server to client, and client to server. 2. As instructed: I changed drive names properties-general-user defined name to single capital letter. for example C and not C: or just leaving it blank to default to "Drive Name:" 3. After many unsuccessful attempts to get a camera to save to client I uninstalled Opus on server and then reinstalled using .msi to it's recommended default install drive which is the C: drive. The G: drive OpusFSX was renamed. I therefor only have to worry about share and security on two drives on each computer. They are drive C where OpusFSx is and drive D where the FSX program is installed. 4. On server and client computers I modified C, C\OpusFSX, D, and D\FSX subdirectory to ensure share rights, full read and write, for "everyone" On share I also tried to add "Authenticated User" and an accept then ok. Sometimes the program would write attributes to child (files within the subdirectory) and sometimes not. under share everyone always has read and write attributes. Under share "authenticated users" sometimes dissapears. 5 . On both server and client computers I modified C, C\OpusFSX, D, and D\FSX subdirectory to ensure security rights, full control, for "everyone" On security I also added "Authenticated User" and under advanced added full control then accept then ok. Under share "authenticated users" seems to stay installed. I have only done this about nine times. Don't know what I am missing. The camera files still do not save to client. PS: This is not a SimConnect problem is it? I would think that the "save file" command in your program would be an external windows related network save file instruction. One thing I have not done is run the clients or the servers Opus SimConnect.msi program because everything seemed to work without it.