John Fee Posted January 28, 2018 Report Posted January 28, 2018 Hello! The two PCs are on the same network and belong to the same workgroup (the client is W10 x64; the server is W7 x64) . Their files can be seen by each other, and opened in both directions. I've attached log files and the WideClient.ini WideClient.log WideServer.log WideClient.ini I'd be grateful for help., John
Pete Dowson Posted January 28, 2018 Report Posted January 28, 2018 33 minutes ago, John Fee said: The two PCs are on the same network and belong to the same workgroup (the client is W10 x64; the server is W7 x64) . Their files can be seen by each other, and opened in both directions. I've attached log files and the WideClient.ini Although, if they are in the same Workgroup, the automatic connection should work fine, you've put the ServerIPAddr parameter into the WideClient.INI. This should be unnecessary, but if you do add it, as you have, you MUST put the Protocol parameter in as well. Pete
John Fee Posted January 28, 2018 Author Report Posted January 28, 2018 Many thanks Hmm, rather than inserting the Protocol parameter I've acted on your advice and reverted to ServerName. Still no connection. Firewalls are off. A new set of files are attached: WideClient.ini WideClient.log WideServer.log Regards, John
Pete Dowson Posted January 28, 2018 Report Posted January 28, 2018 23 minutes ago, John Fee said: Hmm, rather than inserting the Protocol parameter I've acted on your advice and reverted to ServerName. No. I did NOT advise that! That needs the protocol parameter too. It's exactly the same as giving the IP Address. It would have been easier for you to simply deete the ServerIPAddr line, or add the Prototocl parameter. Didn't you try things first before messing with the INI file? The default with NO ServerIPAddr and NO ServerName and NO Protocol is normal for a connection within the one workgroup -- the Client then simply waits for the broadcast from the Server and gets the information that way. If you identify the Server you defeat the automatic method and you must also then provide the Protocol selection. Pete
John Fee Posted January 28, 2018 Author Report Posted January 28, 2018 27 minutes ago, Pete Dowson said: No. That needs the protocol parameter too. It's exactly the same as giving the IP Address. Didn't you try things first before messing with the INI file? Pete I changed ServerName=Ivy to ServerIPAddr=192.168.1.38 because the .ini with the ServerName failed to connect! So I made one change; somewhat harsh to call it 'messing' but there you are. In fact, you recommend ServerName because it avoids problems if/when the IP address changes. However, I tried a fresh install of WideFS, with NO ServerIPAddr and NO ServerName and NO Protocol. Still no connection. WideClient.ini John
Pete Dowson Posted January 29, 2018 Report Posted January 29, 2018 17 hours ago, John Fee said: I changed ServerName=Ivy to ServerIPAddr=192.168.1.38 because the .ini with the ServerName failed to connect! But why did you add ServerName in the first place? Did it not connect just with the default installation? If you do add an excplict Server identity (it doesn't matter whether by Name or Address), you must also provide the protocol for the reason I explained. 17 hours ago, John Fee said: So I made one change; somewhat harsh to call it 'messing' but there you are. Sorry, but you haven't yet explained why you changed the INI file to begin with! 17 hours ago, John Fee said: In fact, you recommend ServerName because it avoids problems if/when the IP address changes. Not separately to having the Protocol specified! and the main and first recommendation is to leave it alone, viz (from the User Guide): So, to summarise: in order to use WideFS with its default protocol (recommended) you should really not need to do anything other than Install as described above. BUT if you have a mix of XP, Vista and Win7 PCs, check and fix the workgroup names first. then: Once you have the same Workgroup names throughout, and either no firewall or exceptions properly made, everythingshould work ... ... However, if you find the connection is still not happening, or you have more than one Server and it is connecting to the wrongone, then you will need to add these lines to the [Config] section of the WideClient.ini file (add the [Config] section too if your ini file hasn‘t even got one!):ServerName=NameOfServerProtocol=TCP (My emphasis in red for the important parts) If this is the part you read, threen you simply missed the part about the Protocol parameter, which i've been mentioning already in each reply! 17 hours ago, John Fee said: However, I tried a fresh install of WideFS, with NO ServerIPAddr and NO ServerName and NO Protocol. Still no connection. Please do read the above and my previous relies, or refer to the section in the User Guide headed thus: Configure your NetworkIT IS IMPORTANT FOR ALL USERS TO READ AT LEAST PART OF THIS! it starts on page 4, after the initial sections describing what WideFS is and how to Register it. Pete
John Fee Posted January 29, 2018 Author Report Posted January 29, 2018 6 hours ago, Pete Dowson said: But why did you add ServerName in the first place? Did it not connect just with the default installation? If you do add an excplict Server identity (it doesn't matter whether by Name or Address), you must also provide the protocol for the reason I explained. Sorry, but you haven't yet explained why you changed the INI file to begin with! It did not connect with the default installation. I did not change the 'ini file because it was working! As for the rest of your reply, if you took the trouble to read what I wrote, you would understand that the workgroups are the same, the firewalls are off, and the network is correctly configured. I hate shouting, Pete, least of all to my customers. Forgive my boldness ;) I've been reading your excellent FSUIPC and WideFS .pdf's for many years and have usually found them very helpful. On this occasion, with this particular pP3Dv3.4 connection problem, I didn't. Thank you for your interest.
Pete Dowson Posted January 29, 2018 Report Posted January 29, 2018 1 hour ago, John Fee said: As for the rest of your reply, if you took the trouble to read what I wrote, you would understand that the workgroups are the same, the firewalls are off, and the network is correctly configured. Yes, I know. I never disputed that. Why are you arguing so? 1 hour ago, John Fee said: I hate shouting, Pete, least of all to my customers. Forgive my boldness ;) Where are you shoulting? Shouting is ALL CAPS. Emboldening is just emphasis, to attract attention, and also I use emboldening when quoting from documents to show it isn't part of the normal narrative. In my last case I use red to attract attention within the quotes. Have you yet done as I kept advising, in every reply, i.e. to add the Protocol line as well as either the ServerName or the ServerIPAddr? This is absolutely needed, as I said (and explained the reason, very early on!), if you have either of those! I don't understand why you continued ignoring this advice even when I emphasised it. Pete
John Fee Posted January 29, 2018 Author Report Posted January 29, 2018 3 hours ago, Pete Dowson said: Where are you shoulting? Shouting is ALL CAPS. Emboldening is just emphasis, to attract attention, and also I use emboldening when quoting from documents to show it isn't part of the normal narrative. In my last case I use red to attract attention within the quotes. Have you yet done as I kept advising, in every reply, i.e. to add the Protocol line as well as either the ServerName or the ServerIPAddr? This is absolutely needed, as I said (and explained the reason, very early on!), if you have either of those! I don't understand why you continued ignoring this advice even when I emphasised it. I know what shouting looks like on boards! That is why I never do it. That is why I used bold. Guess who was shouting? I am grateful for your continuing support but I'm afraid the news is not good. Still no connection, despite my complying with everything. The files are posted and include pics of my Workgroup name just to allay any doubts. Ivy is the server. One thing I did notice was that when WideClient is exited, the server still carries the 'waiting for connection' text. Maybe irrelevant. WideClient.ini WideClient.log WideServer.log Kind regards, John
Pete Dowson Posted January 29, 2018 Report Posted January 29, 2018 42 minutes ago, John Fee said: I know what shouting looks like on boards! That is why I never do it. That is why I used bold. Guess who was shouting? No one in this thread. If you are referring to the CAPS in the quote from the User Guide, that's only because it is a direct quote, by copy, from the User Guide, including the red. 44 minutes ago, John Fee said: I am grateful for your continuing support but I'm afraid the news is not good. Still no connection, despite my complying with everything. The files are posted and include pics of my Workgroup name just to allay any doubts. I believed you in any case. I'm sorry, I'm running out of ideas. I'm no Network expert. Something is obviously wrong somewhere. The Network code is straightforward, lifted direct from Microsoft examples. I don't know any better than to copy working examples, and this has worked now since WideFS first started, with little change, from 1999. One more desparate thought. Could the Port Number being used be in use by something else on the Server? You could try changing it. You'll need to do so both in the client INI and the [WideServer] section of FSUIPC4.INI. 49 minutes ago, John Fee said: One thing I did notice was that when WideClient is exited, the server still carries the 'waiting for connection' text. Well, it IS still waiting for a connection. It would only change to show how many connections it has when there are any. In all this I have been assuming that you have the IP Address correct. I know it doesn't connect when you use ServerName instead, but I have seen cases where this hasn't been met with a correct IP address either (it still uses an address. The name is just used to ask Windows to supply the address).. This can sometimes happen when a router is providing some sort of proxy, and when you have two or more network connections between the two PCs. In the latter case it is possible that WideServer is on the other. Pete 1
John Fee Posted January 30, 2018 Author Report Posted January 30, 2018 Thanks again, Pete. A further twist. I have FSX on the same server - different HDD. I've not used it for so long I forgot I had it. Using the same client, WideFS connects perfectly with FSX using the ServerName=IVY, Protocol=TCP lines in the Wideclient.ini. So I think the network is not an issue. Perhaps it is something to do with ports, but I tried changing these to 8006 and 9006 without success. Any more thoughts before I take a sledgehammer to the whole damned thing, and take up flower arranging? Regards, John
John Fee Posted January 30, 2018 Author Report Posted January 30, 2018 I just noticed, comparing the FSX/Modules files, there's no wideserver.ini in the P3D/Modules folder or in any of the Lockheed Martin folders. This should be generated automatically?? John
Pete Dowson Posted January 30, 2018 Report Posted January 30, 2018 21 minutes ago, John Fee said: Using the same client, WideFS connects perfectly with FSX using the ServerName=IVY, Protocol=TCP lines in the Wideclient.ini. So I think the network is not an issue. Perhaps it is something to do with ports, but I tried changing these to 8006 and 9006 without success. Well, seeing that your FSX has no problems, presumably with the same WideClient running on the client PC and the same settings both ends, and, apart from the WideServer code in FSUIPC5 being 64-bit instead of 32-bit, the code at both ends being identical between FSX and P3D4, it just has to be down to something else running when you are using P3D4 but not with FSX. And I can't think of anything but ports being in use. Did you change ports in the [WideServer] section of the FSUIPC5.INI file, as I advised? Both ends need changing, of course. Quote I just noticed, comparing the FSX FSUIPC folder files, there's no wideserver.ini in the P3D/Modules folder or in any of the Lockheed Martin folders. This should be generated automatically?? No. There's no separate INI file for WideServer. It is part of the FSUIPC INI file, as I pointed out. The last time there was a separate WideServer.INI was when there was a separate WideServer.DLL, i.e. FS9 and before. If you have a WideServer separate to FSUIPC4 in your FSX then you must have put it there, it isn't used! Pete 1
John Fee Posted January 30, 2018 Author Report Posted January 30, 2018 Pete, I'm not using FSUIPC5. I am running P3D3.4, 32-bit, not P3D4, 64-bit. I'll check out the ports again. The wideserver.ini must have been a carryover from an earlier version of FSUIPC. John
Pete Dowson Posted January 30, 2018 Report Posted January 30, 2018 28 minutes ago, John Fee said: Pete, I'm not using FSUIPC5. I am running P3D3.4, 32-bit, not P3D4, 64-bit. Ah yes, of course. Sorry. I've got so used to answering many posts relating to P3D4 it came semi-automatically. In that case it is identical code of course, so there really can't be any difference is WideFS actions between FSX and P3d3. Something is somehow blocking it. Pete 1
John Fee Posted January 30, 2018 Author Report Posted January 30, 2018 Pete, I changed the ports, both ports, both ends, but there's still no connection. I am going to abandon P3D. To be honest I really don't think it is all it is cracked up to be - not the 32-bit versions anyway. I felt I had to try it given that FSX development has ceased. Perhaps I will have better luck with XP11. Thanks for your help. Regards, John
Pete Dowson Posted January 30, 2018 Report Posted January 30, 2018 3 hours ago, John Fee said: Pete, I changed the ports, both ports, both ends, but there's still no connection. Only other thing to try would be to disable each P3D3 add-on 9DLL or EXE pre-loaded, eg via EXE.XML) one at a time. something is blocking it somehow. It isn't P3d3 itself, unless there's something corrupted doing it which is really unlikely. Simconnect uses ports, so check Simconnect.xml too. I've use WideFS with P3D3 as well as FSX-SE and P3D4 with no problems and the same WideClients at the many clients. Pete
John Fee Posted January 31, 2018 Author Report Posted January 31, 2018 Simconnect doesn't work either, and I've tried various ports. The simconnect.xml is attached if you would be so kind as to check it for me. SimConnect.xml 16 hours ago, Pete Dowson said: Only other thing to try would be to disable each P3D3 add-on 9DLL or EXE pre-loaded, eg via EXE.XML) one at a time. something is blocking it somehow. Not sure what you mean here. I do not know how to use exe.xml to disable files - and do you mean .dll or something else? SimConnect.xml John
Pete Dowson Posted January 31, 2018 Report Posted January 31, 2018 27 minutes ago, John Fee said: Simconnect doesn't work either, and I've tried various ports. The simconnect.xml is attached if you would be so kind as to check it for me. SimConnect.xml What SimConnect applications have you tried? Does it not work for both local and remote Simconnect clients? Quote Not sure what you mean here. I do not know how to use exe.xml to disable files - and do you mean .dll or something else? DLLs are loaded via DLL.XML and EXE's are loaded by EXE.XML. There might be such filles in both the Appdata\Roaming P3D folder, or in the ProgramData P3D folder, or in both. To stop them loading you just neen to rename or delete those files (but if you delete them you may need to reinstall applications). ---------------------------------------------------------------- That SimConnect isn't standard. Belowis a more 'normal' one, though it is possible for some applications to use different ports. Not that the port isn't required for the 'local' support. My P3D system has IP Address 192.168.0.170, and that is only needed for the 'global' entry, as you can see. Pete <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="SimConnect" version="1,0"> <Descr>SimConnect</Descr> <Filename>SimConnect.xml</Filename> <Disabled>False</Disabled> <SimConnect.Comm> <Disabled>False</Disabled> <Protocol>Auto</Protocol> <Scope>local</Scope> <Address></Address> <MaxClients>64</MaxClients> <Port></Port> <MaxRecvSize>4096</MaxRecvSize> <DisableNagle>False</DisableNagle> </SimConnect.Comm> <SimConnect.Comm> <Disabled>True</Disabled> <Protocol>IPv4</Protocol> <Scope>global</Scope> <Address>192.168.0.170</Address> <MaxClients>64</MaxClients> <Port>500</Port> <MaxRecvSize>4096</MaxRecvSize> <DisableNagle>False</DisableNagle> </SimConnect.Comm> </SimBase.Document> 1
John Fee Posted January 31, 2018 Author Report Posted January 31, 2018 I've tried to connect both Active Sky 2016 and PlanG with an amended Simconnect.xml. Initially, I was trying to connect just PlanG with WideFS.No joy, despite following all the instructions as best I can. One odd thing though. In the client 'shares' with the server I have Lockheed Martin and Lockheed Martin2 folders. This renaming was done by W10, not by me, presumably because there are at least two Lockheed Martin folders in my set up which must be shared. In other words, Lockheed Martin2 contains the P3D3.exe although I guess WideFS is looking for ..../Lockheed Martin/P3D3.exe. Am I clutching at straws, or do I need a large gin and tonic? John
Pete Dowson Posted February 1, 2018 Report Posted February 1, 2018 13 hours ago, John Fee said: I guess WideFS is looking for ..../Lockheed Martin/P3D3.exe. WideFs doesn't have anything to do with folders. it doesn't use shared folders. It just links FSUIPC's WideServer to WideClient on your other PC, using TCP or UDP protocols. SimConnect does the same over a network. Pete
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now