Jamie Fox

I downloaded it earlier with no problems. Presuming you're referring to Enrico Schiratti's site, I did this earlier this afternoon (UK) and 3.08 was there. Try pressing CTRL+F5 rather than just F5.

Peter's preferred distributor is Enrico Schiratti's website: http://www.schiratti.com/dowson.html

This is Pete Dowson's support forum. Pete is the author of the FSUIPC module (among others) which allows external programs (such as Squawkbox) to send and receive data to/from FS. "SB Relay connect but main Squawkbox send an error message" What is the error message you're getting? Sorry, but if you don't bother to provide details of what the problem is, it's very difficult to find a solution. A couple of things to check: 1. You say SBRelay connects OK. Presumably by this you mean you have connected BOTH Flight Sim's and Squawkbox's multiplayer to SBRelay. 2. If you have an unregistered version of FSUIPC (if you have not paid at SimMarket and received a registration key) then you need to register Squawkbox with FSUIPC. In FS, click Modules...FSUIPC and on the main screen you'll see a button to 'register an application'. The details you need to enter here can be found in the 'Freeware Access Keys' thread in this forum, under 'Squawkbox'.

Daniel, The automated messages you are getting from the server are caused by something incorrect in your position or frequency data coming through FSUIPC. By far the most likely cause of this is that you haven't registered Squawkbox successfully. Check that you entered the following details: Program Name: 'Squawkbox' (no quotes, and no '.exe') Key: LWVQ 7I2V 9GPB The correct program name here is 'Squawkbox' not 'Squawkbox 2.3'. This may well be what's wrong. Pete: could you check your freeware keys post and ensure that this is updated to the correct application name of 'Squawkbox'.

A few weeks ago, after receiving some very detailed and comprehensive support from Pete on a programming issue, I found myself thinking what excellent value FSUIPC registration had been. I don't think I've ever seen a product with better support than this. It then dawned on me, ironically, that the support was not part of what I'd paid for anyway! As a developer, I'd really suggest that FSUIPC is a small price to pay for the superb support you'll get in this forum, should you come across any problems at all.

In order to use Squawkbox with FS2004, you need to use another program called SBRelay, because the FS2004 and FS2002 multiplayer interfaces are not compatible. SBRelay hosts two sessions: an FS2004 session and an FS2002 session. You then JOIN FS2004 to the SBRelay session, and you also JOIN Squawkbox to the FS2002 session (you don't need to worry which is which, there's no way they can join to the wrong one and only one will ever be found by any given program). SBRelay then relays all the data Squawkbox is putting into the FS2002 session and sends it to the FS2004 session, so that you can see the aircraft. Also make sure your CSL configuration is correct (this applies to all versions of SB when using WideFS). By default, SB renames the aircraft.csl file to aircraft.cfg when you load SB, but this won't work if it's on a different PC. To ensure CSL works, make sure you have an aircraft.cfg in there. You can get SBRelay from http://www.chocolatesoftware.com By the way, 127.0.0.1 is the loopback address and refers to your local computer. It's not use trying to use it to connect to another computer on your network that is hosting an MP session (use 192.168.0.x address of the host instead), although as I've explained above, this probably isn't your problem.

I'm not quite sure what to suggest here; it sounds like you've done everything right. The 'invalid frequency' message would suggest there is a problem with FSUIPC though. The key originally provided with SBRelay (which is needed for multiplayer to see other aircraft, but you can use Squawkbox without by clicking 'no multiplayer' on startup) may be incorrect. Check that you entered the following: SquawkBox.exe KEY = LWVQ 7I2V 9GPB One way to check to see if you have got Squawkbox and FSUIPC interacting properly, is to try one of the 'dot' commands. In the main Squawkbox window, type .x 1234 A message should appear to say 'XPDR SET' and your transponder should change to 1234. If it doesn't, then that's another sure sign there's something wrong with the FSUIPC link. Let me know how you get on.

Thanks for all your help. It makes a lot more sense now.

Thanks very much Pete. All the problems I was experiencing were due to my own mistakes in some of the programming. It all seems to work fine now. What happens if I provide an incorrectly-sized variable to FSUIPC. For example, if I was to call FSUIPC_Write(0x1234, 1,...) but write it to a DWORD. Will FSUIPC just take the lowest (least significant) byte? Similarly, what if I try to read four bytes to a BYTE? Presumably FSUIPC, knowing only of a pointer, will try to write to a memory address allocated to something else, probably causing a crash?

For some reason it hadn't crossed my mind to manipulate the 32-bit offsets as an array of four BYTEs, rather than a single DWORD. It's clearly much easier to keep track of what's going using individual BYTE types. So, going by the way that an Intel processor would handle things, it's actually 'written down' the opposite way as to how you'd write it in human-readable (or even C++ readable) form. Right, so byte 0 is 0x3210, byte 1 0x3211, etc. This makes sense. If I was to manipulate this as a single DWORD, the least significant part is byte 0 bit 0, which would go on the right (as written). I think I have my head round this now. I've had all kinds of trouble this morning trying to get a joystick hot button to work, although mainly due to my inability to type the data in the right order! That reminds of me of the other question, this time specific to hot buttons and joysticks. The SDK says that 'Joysticks are number... from 0. Game Controllers numbers from 1.' I only have one joystick connected (a CH products USB yoke), so would that be joystick 0 or 1? Similarly, are the joystick buttons numbered from 0 or 1?

This is quite a hard problem to explain, so I'll try an example. Let's say that there is a hot key slot free at offset 0x3210. This is a 32-bit area, so therefore contains 4 bytes. What I'm unsure of is which byte is 'byte 0' and which is 'byte 3'. To put it another way, are they numbered from right to left or left to right? To take an arbitrary hex value of 0x12AB34CD. Which is byte 0? 0x12 or 0xCD? Also, if I was to write 0x12AB34CD to offset 0x3210, what would be at offset 0x3213? Would that be 0x12 or 0xCD? This question isn't really specific to FSUIPC I don't think, but having a very limited background when it comes to programming I don't really know where to find the answer to this. Thanks in advance.

I've just reformatted the hard drive of the offending computer (not purely because of this!). I visited the Windows Update site and found some updated drivers for the network card that I don't think were installed before. For one, both, or neither of these reasons, the problem seems to have gone away! Thanks Pete for your help in this. Best wishes, Jamie.

FSUIPC_FS_Version now has a seventh possible value (7), to indicate FS2004, so if you want your software to recognise 'FS2004' rather than 'Unknown', you need to extend your *pFS[] array and make sure your check for unknown is now FSUIPC_FS_Version > 7 rather than 6. (I took the opportunity to #define this elsewhere for future versions ) If you're not using SIM_ANY, you'll need to add SIM_FS2K4. You can find these in FSUIPC_User.h near the top, and SIM_FSK4 follows the pattern and should be assigned 7. Everything else should then work as expected I hope ;)

I think I might just leave it be ;)

Pete, I think I agree it has something to do with the network. I haven't really tried this enough times to be a proper scientific test, but it seems that if I unplug the network and then exit FS it will prevent the problem. I get the feeling this might have nothing to do with WideFS and is triggered only because WideServer accesses the network. I can't remove the cards because both are on-board Ethernet cards. Both the video card and the network card have an IRQ in the Device Manager of 5? I know absolutely nothing on this subject unfortunately

When exiting FS (both 2002 and 2004), sometimes FS will fail to shut down properly and will cause an 'error' (the box offering to send an error report to MS). This behaviour occurs in both Wide FS 5.50 and 6.02, and across both versions of FS. It never occurs when Wideserver.dll has been renamed or deleted. It intermittently occurs when Wideserver is running. It tends to be more likely if WideClient has, at some point during the session, been connected to WideServer. Sometimes it is prevented if a multiplayer session is manually disconnected prior to exiting (and other times it will still happen even if no multiplayer session was ever used). I'm using TCP/IP networking for WideFS. This problem occurs with FS being hosted on either of two PCs: Compaq Presario Notebook: Celeron 2GHz, 192MB RAM, Windows XP Home. Advent Desktop: Athlon 1GHz, 128MB RAM, Windows ME. (Wide FS 6.02, FSUIPC 3.04) Wideserver.log doesn't seem to pick up any errors: ... 2013242 Client socket disconnected at Client: removing (skt=1104) 2078027 Closing down now ... Memory managed: Offset records: 37 alloc, 37 free Throughput maximum achieved: 32 frames/sec, 1584 bytes/sec Throughput average achieved for complete session: 5 frames/sec, 386 bytes/sec ********* Log file closed ********* I'd love to get to the bottom of this, but even the logic and reproducability seems to be non-existent! Any ideas anyone?