Jump to content
The simFlight Network Forums

Recommended Posts

Posted

Hi!

I've been using WideFS for a long time, I'm very familiar with it, with FSUIPC configuration in general and yes, I do read the manuals :) I never had any problems of any kind connecting Wideclient with WideFS until today, I saw there was a new version of WideFS and decided to upgrade. (I had the version released in december and upgraded with the one released June 27)

The only thing i did was:

Replace WideServer.dll in my modules folder in fs9 in the server machine, and replace wideclient.exe in the client machine. Now, it does not work. If I check the log there is a message (in the client) that says:

Trying to locate server: Protocol not yet decided

I never had this message in the previous version of WideFS, why I'm getting this now? I tried adding the ProtocolPreferred in the Server ini file to see if this was the problem and nothing... I don't get it, i've spent more than two hours fixing this problem... WHY a simple upgrade is causing a problem??

Posted
Hi!

I've been using WideFS for a long time, I'm very familiar with it, with FSUIPC configuration in general and yes, I do read the manuals :) I never had any problems of any kind connecting Wideclient with WideFS until today, I saw there was a new version of WideFS and decided to upgrade. (I had the version released in december and upgraded with the one released June 27)

The only thing i did was:

Replace WideServer.dll in my modules folder in fs9 in the server machine, and replace wideclient.exe in the client machine. Now, it does not work. If I check the log there is a message (in the client) that says:

Trying to locate server: Protocol not yet decided

I never had this message in the previous version of WideFS, why I'm getting this now? I tried adding the ProtocolPreferred in the Server ini file to see if this was the problem and nothing... I don't get it, i've spent more than two hours fixing this problem... WHY a simple upgrade is causing a problem??

Fixed my problem Pete. But the manual is incorrect.

ProtocolPreferred does NOT automatically sets the client for Wideclient when not specificed. At least not for UDP.

I fixed the problem by modifying the wideclient.ini file adding protocol=UDP (even though protocolpreferred=udp is set on wideserver.ini)

Posted

Fixed my problem Pete. But the manual is incorrect.

ProtocolPreferred does NOT automatically sets the client for Wideclient when not specificed. At least not for UDP.

I fixed the problem by modifying the wideclient.ini file adding protocol=UDP (even though protocolpreferred=udp is set on wideserver.ini)

More on this subject:

ServerIPAddr is either deprecated and not stated in the manual -OR- simply a bug if I use ServerName everything works perfectly fine. TIP: you CAN use an IP Address in ServerName instead of a server name

Posted

Fixed my problem Pete. But the manual is incorrect.

ProtocolPreferred does NOT automatically sets the client for Wideclient when not specificed. At least not for UDP.

Actually it does for all three protocols, but there is a bug in the current release which only occurs if you specify the Server in WideClient by IP address instead of either omitting it (the preferred method for several releases) or also specifying the protocol, as you have done.

Sorry, I would have released a fix (it affects Wideclient only), but I'm in the middle of something else at present. Oddly, I did actually think it was unlikely that anyone would be using IP addresses when Names are so much easier and more flexible, and even more unlikely that the protocol was not also specified by those that were. So far I think there have been three including yourself.

For the others please see thread http://forums.simflight.com/viewtopic.php?t=53340

More on this subject:

ServerIPAddr is either deprecated and not stated in the manual -OR- simply a bug if I use ServerName everything works perfectly fine. TIP: you CAN use an IP Address in ServerName instead of a server name

Yes, it's a bug. Apologies again. I will release an update for WideFS, and probably FSUIPC, by the end of the month, hopefully.

Regards,

Pete

Posted

Thanks for the prompt response!

Pete,

An unrelated question to the problem.. but I don't want to open a new thread ;)

I use a software called FSNet to share the cockpit with friends over the internet. My friends DO have FSUIPC and WideFS. I was wondering if it would be possible to have MULTIPLE WideFS Servers send keystrokes to a single Wideclient using the SendKey facility of WideFS even when there is no session established between the WideClient and WideFS machine.

In the wideclient everything works PERFECTLY fine *IF* the WideFS computer doing the keysend is the one in the wideclient.ini ServerName= parameter. My impression, was that WideFS would do a SendKey to ANY wideclient machine, but I guess this is a security concern so thats why the feature is not there...

Do you know what my options are to have a FS2004 machine send (over the network) a command to a wideclient machine when there is no session established between them? I just want my friends to be able to PPT the squawkbox running on the Wideclient machine so we BOTH can talk to ATC while in VATSIM.

Sorry If All this is confusing... but i'm pretty sure you know exactly what I'm talking about :)

Posted

I was wondering if it would be possible to have MULTIPLE WideFS Servers send keystrokes to a single Wideclient using the SendKey facility of WideFS even when there is no session established between the WideClient and WideFS machine.

No, sorry. ALL the protocol code in WideFS is using directed communications. What you are asking for would either have to be done by a separate mechanism altogether (broadcasting), or would need Wideclient to establish multiple links to multiple servers, quite an horrendous upheaval in code either way.

In the wideclient everything works PERFECTLY fine *IF* the WideFS computer doing the keysend is the one in the wideclient.ini ServerName= parameter.

Well that's too specific. WideClient talks to one Server. How it identifies that server varies -- you can omit identifying it in the INI file and it will find it (on WinXP or Win2K systems) by the occasional mailshots sent by any running server. It just latches on to the first one with the matching Port.

My impression, was that WideFS would do a SendKey to ANY wideclient machine, but I guess this is a security concern so thats why the feature is not there...

No, it is nothing to do with security. What you are asking is a totally different way of programming network links. Broadcasting is not really suitable for the majority of what WideFS does. Don't forget its main job is to allow FS applications on client PCs to talk to FS and receive *specific* information from it as if it were running on the same PC. Broadcasting won't do that. For WideFS we need a one-to-one connection between application and FS.

Do you know what my options are to have a FS2004 machine send (over the network) a command to a wideclient machine when there is no session established between them? I just want my friends to be able to PPT the squawkbox running on the Wideclient machine so we BOTH can talk to ATC while in VATSIM.

You can run another copy of WideClient in the same client PC with a different Class name -- see the ClassInstance parameter in the WideFS doc. In that WideClient INI identify your friend's FS Server.

You don't need SendKeys for Squawkbox PTTs as they are built in. Just program the FSUIPC controls for PTT.

Regards,

Pete

Posted

You can run another copy of WideClient in the same client PC with a different Class name -- see the ClassInstance parameter in the WideFS doc. In that WideClient INI identify your friend's FS Server.

Ok, this is interesting.. I will take a look. But, let me see if I understood you correctly. Can I run an instance of wideclient on a machine that is running FS2004 already just by using a different Class name?

You don't need SendKeys for Squawkbox PTTs as they are built in. Just program the FSUIPC controls for PTT.

Oh that I know ;) thats the way I use it for my current setup. But remember that what I'm trying to do here is a bit more complicated. I'm trying to make a SECOND computer running FS2004 send commands over another computer running FS2004 too. SO, WHat I basically want is that a user running FS2004 on computer #2 can press the letter H and on the computer #1 that is also running FS2004 you can see the effect of H being pressed remotely. Now, if H is assigned for PPT I can have a remote user activate PPT and have BOTH pilots share a single SB3 connection when using FSNet for cockpit sharing.

Posted

Ok, this is interesting.. I will take a look. But, let me see if I understood you correctly. Can I run an instance of wideclient on a machine that is running FS2004 already just by using a different Class name?

Yes, but it won't accept any applications unless those too look for the different classname. Anyway, that wasn't what you asked, was it? I thought you wanted a Client running Squawkbox or similar to have the latter's PTT controlled from more than one Server? That would be two WideClients running on that client PC.

I'm trying to make a SECOND computer running FS2004 send commands over another computer running FS2004 too.

Oh, I didn't understand that from what you said earlier, sorry. But the same principle applies.

SO, WHat I basically want is that a user running FS2004 on computer #2 can press the letter H and on the computer #1 that is also running FS2004 you can see the effect of H being pressed remotely. Now, if H is assigned for PPT I can have a remote user activate PPT and have BOTH pilots share a single SB3 connection when using FSNet for cockpit sharing.

Don't send H though, use the PTT control. there's no need to use the ketyboard in either circumstance.

Regards,

Pete

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.