Jump to content
The simFlight Network Forums

mfrias

Members
  • Posts

    18
  • Joined

  • Last visited

mfrias's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. So basically it is now working... Honestly I don't know why this happens. Here is the code I use regarding FSUIPC Open: int TCLFSUIPC_OPEN(Tcl_Interp *interp) { DWORD dwResult; char err[1024]; dwResult = 3; // this was added right now and it seems that setting an initial value here makes it work. if (FSUIPC_Open(SIM_ANY, &dwResult)) { return TCL_OK; } sprintf_s(err, "FSUIPC: Failed to open link: %s", pszErrors[dwResult]); Tcl_SetResult(interp, err, TCL_STATIC); FSUIPC_Close(); // Closing when it wasn't open is okay, so this is safe here return TCL_ERROR; }
  2. I was using the program itself not the FSUIPC7 application which is why I didn't find any help. However, my websocket client test works with: wss://echo.websocket.org but doesn't work with: ws://localhost:2048/fsuipc Although I used the help page test and it does in fact connect. Weird... got to do with localhost probably.
  3. I just found that URL in the forum thanks. Let's have a go at it
  4. I'm using a small program (FSUIPC WebSockets Server) that comes with the FSUIPC7 zip to start the web sockets server on port 2048. It has version 0.2.0.5. When I open it I only see Web Services, Flight Sim, Options and About tab on the left.
  5. Ok, in terms of websocket I am trying to start this line of thought. Having issues connecting at the moment but... what are the commands within the WS? Is there a manual for this?
  6. No. Let me give a more detailed outlook on the whole solution. I am one of the few Tcl/Tk programmers on earth 🙂 I developed the Acars entirely in Tcl. But for FSUIPC I used the FSUIPC_User.lib and compiled my own DLL (Tclfsuipc.dll) to link the Tcl framework to FSUIPC. Basically, I create a new command called "fsuipc" within Tcl so that it interfaces with the FSUIPC lib and therefore with MSFS. This was programmed back in 2010 (!). And I've never had to touch it since. However, I wanted to migrate my VA's website to HTTPS. This requires adding the TLS layer on top of HTTP. But due to the security mechanisms and all many of the security protocols are not allowed any more. Therefore, I had to upgrade to using the latest version of the TLS lib which is 64 bit. This means that I had to start using Tcl 64 bit. And hence, all libs used must be 64 bits now. This means I had to recompile Tclfsuipc.dll as a 64 bit DLL. In Visual Studio 2019 I changed the include/libs parameters and selected everything to become 64 bits. Initially the linker was complaining about FSUIPC_User.lib, because it was still the 32 bit version and therefore there were no 64 bit symbols available. I then used the FSUIPC_User.lib in "UIPC64_SDK_C_version2" and it compiled ok and produced the DLL. Then, I integrated everything into my Acares EXE but then I initiate the FSUIPC connection I get three or fours garbled characters and no connection. My setup: Win XP, FS2004, WideServer Win 10, WideClient 7 where my Acars now runs
  7. I did recompile it with the 64bit lib. The reason for moving to 64 bits is that my Acars uses other libs. One of them has to do with TLS/SSL/HTTPS and must be compiled 64 bits, which forces everything else to upgrade as well. If anyone else has used the 64 bit version, if they use WideClient did it work? I was also wondering if there is another way to access MSFS variable via FSUIPC but not using the lib. I see there is a new web sockets program, would this allow to access the data another way?
  8. Yes, I had already seen it but I think the problem here is more obvious: My FS2004 is [still] running on a Windows XP (32bit). I have my Acars running on a Windows 10 (x64) laptop accessing via WideFS. Would this be compatible?
  9. Hello, I have had to migrate my Acars to use 64 bits. This means I need to compile it linking to a 64 bit FSUIPC_User.lib Where can I find this? I tried recompiling using the IPCuser.c + .h files and in fact it seemed to work in terms of compilation an all. But when I invoke "fsuipc open", I get mumbo jumbo (something like: ÃÂo Thanks, Miguel
  10. Hi Pete, Thanks for the reply. I was coming back to say I had solved the issue since I found the old configuration file in another computer and it indeed had the Protocol=TCP line there. As soon as I added it everything was fine again. But the log wasn't really clear for me. It did mention IPX/SPX, I just couldn't understand why. Apparently, if no line is present, it assumes IPX as default. Nevertheless I never changed the config file. I think it was because of an unstable Wireless in the laptop which probably made WideFS think: can't work with TCP so let's go to defaults. But instead of leaving the "Protocol=" line, it simply deleted it. Thanks for the reply
  11. Hello, I've been flying for years now with my main FS9 computer and a side laptop using WideFS. They have always been in a local network and configured with the basics. Both have Windows XP SP3 I recently moved but brought everything along and the same setup. And... I have had it working for about 2 months. The only difference was that the laptop was now connected via Wireless instead of fixed cable. Nevertheless I've tried with a small switch and the problem persists. And what is the problem? Well I can't get WideFS to work. When I open WideClient, it opens the small window as usual but on the FS9 window it always says "waiting for clients". The laptop has internet, web, local shares, TCP/IP is working, I can ping servers and all. The laptop is using account Administrator. If I start WideClient with right-click RunAs, Administrator but with the "Protect my computer and data from unauthorized program activity" it will get FS9 to detect one client, but then all applications that use WideFS say it has a fishy protocol and it won't work. I've turned firewall off: still the same I've turned McAfee antivirus off: still the same The WideClient.ini config (which has never changed) is: ; PLEASE SEE WideFS documentation for parameter details ; ===================================================== [Config] ServerIPAddr=192.168.1.10 Port=8002 Window=0,701,444,37 Visible=Yes ButtonScanInterval=20 ClassInstance=0 NetworkTiming=5,1 MailslotTiming=2000,1000 PollInterval=2000 Port2=9002 ResponseTime=18 ApplicationDelay=0 TCPcoalesce=No WaitForNewData=500 MaxSendQ=100 OnMaxSendQ=Log NewSendScanTime=50 Priority=3,1,2 [Sounds] Path=C:\Documents and Settings\Administrator\Desktop\WideFS\Sound\ Device1=Primary Sound Driver Device2=SigmaTel Audio Device3=C-Media USB Headphone Set If I telnet into the FS9 machine on port 8002 it connects. Now... can anyone solve the mystery?
  12. Hello, I recently updated our acars so that it also loads the payload onto the aircraft. I then started investigating why the change is not immediate. Seems the only way to make it permanent is accessing the Payload subdialog from the "Payload and fuel" menu. At least in FS9. After this, when I close the dialog I can see the plane shortly do a bounce-like motion, asserting the weight change. I believe this is because the CoG must be updated. Is there still no way to force the CoG to be updated? There is variable 2EF8 but it seems to be readonly. Has anyone found a way that enables payload station modification and then "committing" it? Miguel
  13. Hi, I have created my own Acars for FS2004 and finally got someone to try it out but in FSX. Using the same .DLL, it seems that almost all of the basic reads from FS work properly (altitude, speeds, QNH, lat/long, etc). However, the acars was unable to ensure that the user cannot Pause or Slew or change sim rate. I do this (with FS2004) by constantly writing to the offsets (0262 for pause, 05DC for slew). I checked the FSX offsets and these are the same for what I want. However it seems it's not working in FSX. Am I missing something here? Do I have to do something different for FSX? Thanks, Miguel
  14. Hello Pete, Thanks for your reply. I've tested the code with consecutive calls. Let me try to explain it for the "heading": function FSUIPCREAD(..., int offset, int numberofbytes, ....) { void *data; data=malloc(numberofbytes); // allocate 4 bytes in this case memset(data, 0, numberofbytes); // to make sure everything is clean FSUIPC_Read(offset, numberofbytes, data, &dwResult); // offset = 0x580 Tcl_SetResult(..., (char *) data,...); // this interfaces with Tcl and returns the value } Therefore, the "heading" is read and stored into "data" which has been initialized for 4 bytes. Tcl_SetResult is a function that returns the data to Tcl. However, whenever the problem occurs, I already have "data" with an incorrect value prior to returning it to Tcl. If I do the following cycle in Tcl (pseudo code below): while { forever } { val = Call_FSUIPCREAD_from_C 0x0580 4 ; // read 4 bytes from offset 0x580 (heading) val = $val * 360 / (65536*65536) ; // calculate heading write($val) ; // output to screen } It ends up doing something like this: 34 34 34 34 0 34 34 34 34 0 34 34 ....... Most of the times it reads the value well. When it doesn't, it reads as "0", or "1" or a low value. I found out why: when the result is incorrect, it is because the value returned is 1 byte misaligned. If I split the "heading" value that has been read, into hex components: 0x4BDEF017 => 0x4B 0xDE 0xF0 0x17 => 75 222 240 23 But, when the problem occurs, I see something like: 1582 240 23 0 (notice that 240 is now byte #2 and 23 is now byte #3) and a 0 appears. My doubt here is: why does this happen some times, in a non-deterministic way? I thought that using a "void *" in C would enable me to map the FSUipc_Read function to Tcl in a generic form, rather than having to create a function for each value I want to retrieve, depending on byte sizes, etc. Miguel
×
×
  • 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.