Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Yes, you can do that with FSX's own shared aircraft system, or by using WidevieW. But you certainly do need FSX installed on both. And you probably want the more powerful PC to be the one showing the scenery. Sorry, I don't know anything about that. It sounds like a video driver problem. Regards Pete
  2. It means that the Server couldn't initialise the IPX/SPX protocol (as seems to be pretty explicit from the text in those lines to me). This will be simply because you didn't install it (it has been optional in Windows since XP came out). It doesn't matter unless you want to use it. If you want to use it you have to install it. If you don't, then don't. WideServer supports three protocols simultaneously. The choice can be made independently by each connecting Client. The protocols are TCP (defalut), UDP and SPX. The documentation does explain all this, and the pros and cons of each. Unless you know what you are doing I'd stick to TCP if I were you. It's the protocol used by most things. UDP can be faster but it is less reliable. SPX used to be much faster, but it is more difficult to get right. Regards Pete
  3. Good. That makes it dead easy, as I said. No no no! How do you work that out? Where does this business of 8 bits come in? Please re-read what I said before about how easy it is with a 64 bit number: You surely aren't reading "8 bytes" as "8 bits" are you? They are very differntt. a byte is 8 bits, so 8 bytes is 8 x 8 = 64 bits, the 64 bits representing the whole number, fraction and all. You don't need to separate anything! Pete
  4. For the first time with FSX you can do it without extra software, just with FSX installed on each PC, but I've not tried it. Check the Help in FSX for "Multiplayer -- Shared aircraft". I've seen it demonstrated but I've not tried it myself. In a shared aircraft you have several PCs all "flying" the same aircraft -- yours -- but one might be for the pilot, another for the co-pilot, etc. Each can obviously have its own arrangement of windows or cockpit views. You don't have to have a copilot of course, just his PC. ;-) The other way is by using the payware package WidevieW - but this is more designed to give you multiple outside scenery views than inside cockpit views, as I don't think all the gauges etc stay synchronised. But check it out anyway. Google on WidevieW or Luciano Napolitano, the author. Regards Pete
  5. There's literally zero difference in the code for WideFS in FSX and FS9. All I did for FSX, because of the installation difficulties with SimConnect loading, and to make things tighter, more efficient, was to incorporate the WideServer code into FSUIPC4. Therefore the difference must be that something, in FSX or added to FSX, is blocking WideServer's reception of client requests. As far as I know FSX only uses TCP/IP for SimConnect, Multiplayer and weather downloads -- but the latter is common to FS9 too. Have you actually tried a different port like I suggested? You've not said yet. Pete
  6. Is this in FS's windowed mode, or full screen? If in full screen try Windowed mode (ALT + ENTER). If that works, then the problem is in your video drivers. No, it'll be the video drivers in Vista. Try a different version. Regards Pete
  7. So why are you reading a fixed point integer into a floating point variable? It is bound to be misinterpreted! There's no such variable type. Where are you reading type "fractional"? Look at the description of 0570. It says the integer part is in the top part, as a 32 bit integer, and the fractional part is in the lower part, also as a 32-bit integer (but it will be unsigned). Consider a decimal number with fractional parts: e.g 3.142. The integer part is 3, the fractional part is 0.142. But you could consider storing that 142 bit in a 4 digit decimal store capable of values 0000 to 999. So it could be stored as 0142. To recoup the original value you'd read the integer part, 3, and add the fractional part re-made into a fraction, 142/1000. The factional part of the altitude is such that it runs from 0 to the whole 32-bits worth (65536 * 65536, I don't remember the actual number). So, you read the integer, copy it to a double or float, then read the fraction, copy it to a double or float and divide it bt 65536*65536, then add it to the integer part. There's one slight complication. If the integer part was negative, then so must be the fractional part, so you have to test for that and subtract the fraction, not add. All this is made much much (much) simpler if your compiler supports 64-bit integers. The microsoft C/C++ one does, they are __int64's. By reading all 8 bytes from 0570 into an __int64 it becomes a doddle: __int64 alt; ... read 8 bytes from 0570 into alt, then double dAlt = (double) alt / (65536.0 * 65536.0); You are not reading the description for 0570, where it tells you that. It's the first 32 bits. The next 32 bits (at 574) are the integer. Regards Pete
  8. Yes. WideFS starts when the system is ready -- i.e. in flight mode, ready to fly. Pete
  9. As far as I understand it, two keyboards is like having two mice -- they both do the same thing. In other words the "E" key produces the "E" keypress on either. If there's a way of making the 2nd keyboard produce totally different codes to the first I've nt heard of it, and in fact there are no decodings defined in Windows for those to mean anything. Really it is all irrelevant to FSUIPC. If the keyboard gives different codes and Windows passes different codes on via its messaging, then they wil be seen differently in FSUIPC and you can program them as such. Not sure how they'd be represented though -- there are only defined representations for the known keys. QWERTYUIOP and all that. Regards Pete
  10. Can't be. A "bad file" would be detected via the codesigning checks built in. Pete
  11. What's a "Single"? You said 8-bit last time. Surely you don't mean that? I would have thought that giving the bit-size and the representation type (integer, fraction, or floating point) would be much clearer than using C or C++ technical terms. After all every language has its own set of types with its own names. What you really seem to need is a reference list of what variable types you can have in your chosen language. Please think about using the tools provided -- especially the logging, which you seem to have ignored completely. Also FSInterrogate, which can show you all these values in all sorts of different representations. Pete
  12. Okay, but before doing anything in FSUIPC do you check they work okay in FS? All FSUIPC calibration is doing is providing more accuracy. It cannot put right a chronic problem in the first place. What's an "acceleration" axis? Do you mean throttle? Have you checked in FS that the Sensitivity is at max (slider full right) and the Null zone is minimum (slider full left). You need to do that for all axes for best calibration. Interference between axes is usually a sign of double assignment -- i.e. that you have axes assigned in more than one place, or FS controls assigned to more than one axis. If neither of these applies it is more likely you have a faulty joystick. FS doesn't actually have any calibration -- it relies on the Windows Game controllers calibration. But your symptoms, except the interference, sound like the classic case of a minimum setting on the sensitivity slider in FS -- this happens quite a lot in FS9. Check it, and all the others. Regards Pete
  13. Hold on. You are reading 0574 (which is the upper half of the 64-bit value, the whole number of metres) into a "Long value (8bit)". What does "Long value (8bit)" mean? 8 bits make one byte. There's no way -1170756313435 will fit into 32-bits (which is all you have at 0574) let alone 8 bits! Please be a little clearer about what you are doing. And PLEASE PLEASE start useing the tools provided -- especially the Logging. Pete
  14. More or less. Keep above 8000 though, FSX uses some below that. Pete
  15. No, but programs can use it without you knowing. Try another port number first. I can't think of anything else at present. Pete
  16. You mean your aircraft's altitude, AMSL? Use search when looking for things in the list. Searching on "altitude" would soon find it. Check offset 0570. It is among the 6 values which define your aircraft position and altitude exactly -- "LLAPBH" in order = Latitude, Longitude, Altitude, Pitch, Bank, Heading. Pete
  17. Keyboards are handled through Windows. FSUIPC cannot see them as devices -- it doesn't even know they are keyboards. All it sees are WM_KEYDOWN and WM_KEYUP messages from Windows. I don't even know if it is possible to get device control over them without writing special low level drivers. Same with mice. I think multiple keyboards on a PC are merely treated identically. i.e. they do the same things. Regards Pete
  18. Ah, I missed that fact. If, using the same versions of Windows it works with FS9 and not with FSX it can't be a firewall problem. The last time I heard of anything like this was when someone configured ASX on a client PC to use port 8002 for Simconnect. You don't have any remote programs using SimConnect, do you? You could try a different port in WideFS -- you'd need to set "Port=xxxx" in the [WideServer] section of FSUIPC4.INI and in the [Config] section of the WideClient.INI. Of course if you then use the same WideClient for FS9 you'd need to do the same in the WideServer.INI for FS9. I can't think of anything else other than an unavailable port. Regards Pete
  19. For accuracy you should copy the original value into a floating point variable first, before doing any calculations. The way you have it you are losing all fractions of a metre. What is the original value you are reading? Don't forget it is the GROUND altitude you are reading, not "your altitude". They are only the same, or nearly so, when you are on the ground. Don't forget that you can easily check what you are actually reading by using FSUIPC's logging facilities -- enable IPC read logging and check the log. I know the data there is in Hexadecimal, so it takes some working out (I actually have a hex calculator), but even if you can't figure it out, I can tell you what is happening. I can't do that from snippets of VB (or even whole chunks of VB). Regards Pete
  20. Okay. Everything is running fine, and the Client is seeing the Server. But the Server never sees anything from the Client. So the most likely problem is a firewall block on the Server. See if can set your firewall to allow FSX/FSUIPC to receive connections on Port 8002. Regards Pete
  21. Have you enabled WideServer in FSUIPC4 options? In Windowed mode, does the FSX title bar show that WideServer is waiting for clients? I'd need to see the WideServer and WideClient logs. Those are text files produced showing whether things are okay or errors are occurring. Maybe the FSUIPC4 log as well please. Regards Pete
  22. No, don't use loops. You should use the Windows timer facilities to create a timer event every second, and do all your requests there. The only FSUIPC calls which should be outside that, in the main program, are the Open and Close calls. I don't know VB I'm afraid, but the Windows API calls as seen from a C/C++ program are SetTimer and KillTimer. Regards Pete
  23. Er. Sorry, but I am having great difficulty understanding what you are saying here. First, tell me what VERSION of FSUIPC you are using, and exactly HOW you are assigning and calibrating the axes. You say you have 5 axes, and 4 are okay, but 1 is not. In what way is the 5th one not behaving? Please describe the symptoms. Also, have you checked them all in Windows Game Controllers? do they all work correctly there? Sorry, are you saying you have exactly the same settings in both FSX (with FSUIPC4), and in FS9 (with FSUIPC3), and that it works in FSX but not in FS9? I need to know VERSION numbers please -- both FSUIPC4 and FSUIPC3. This information is ALWAYS needed. It may also help if you show me your FSUIPC4.INI and FSUIPC.INI files so I can compare your settings. Basically, if both INI files have the same values for the axes they must behave the same -- as the code is so similar. The only difference comes if you assign axes in FSUIPC instead of in FS -- in FSUIPC4 my code uses DirectInput, just like FSX, but in FSUIPC3 I still use the older Windows joystick interface. If you are assigning the axes in FSUIPC rather than FS itself, please tell me why. Regards Pete
  24. In flight mode, when you press ALT to get the Menu, isn't there a new Menu entry, to the right of all the others, called "Add-Ons"? I think you are making a mistake thinking FSUIPC has anything to do with that. In fact it isn't to do with any of my software. FSX itself supports multiple PCs (at least the DeLuxe version does, not so sure about the basic version). You have to have multiple copies so you can install the complete FSX on each PC. Alternatively you can use a program called WidevieW by Luciano Napolitano, but this still needs multiple FSX installs. Now you are talking about WideFS, not FSUIPC. Have you purchased WideFS? What applications do you intend to use it with? As clearly documented, WideFS provides a Networked extension to the FSUIPC interface, and WideClient provides that interface on the client PCs. Programs which use FSUIPC can then be run on those PCs, thinking they are running with FSX. There's no way you get to "see multiple screens from the game" as you put it. Regards Pete
  25. The new SimConnect interface isn't in FSUIPC but in the new SimConnect for SP2/Acceleration. Nothing in the FSUIPC end has changed except that it links to the SimConnect SP2 version if present. With the Windows Side-by-Side library system the library user has to explicitly request the version it needs. Before 4.20 FSUIPC couldn't link to SP2 because it didn't know the correct manifest values. Strange. I would have thought yor algorithms would have had to work with a variety of timings as FSX performance is so varied on different folks' systems. It will also vary with DX9/DX10 selection, video cards, and so on. The only difference that I'm aware of between FSUIPC 4.2xx + FSX SP2/Accel and FSUIPC 4.1xx + FSX SP2/Accel is that the former will be using Named Pipes for the transfer of data (which uses shared memory) whilst the latter still uses TCP/IP -- the same as using 4.2xx with FSX+SP1 or before. The timing differences should merely be that of less latency -- in other words the data should arrive in FSUIPC from FSX after a shorter time than before. It is certainly more efficient -- FSUIPC can ask for a lot more data before it impinges upon FSX performance with SP2. Right. So the only difference that I know of is the use of Named Pipes instead of TCP/IP. If you had done the same tests with FSX SP1 you would have seen where the difference was more quickly. No, sorry, I find that very hard to believe. All my measurements show that SimConnect using named pipes is far far more efficient. I could understand a difference if you found the same on SP2 with both 4.20 and 4.15, because that would indicate a change in FSX itself, probably in the SIM1 engine. Microsoft certainly have made some changes there to support some of the Acceleration facilities Could you please tell me which variables you are reading in FSUIPC for the autopilot control, those which you have had to make timing adjustments for? I'd like to do some tests on them, just to prove to myself what is happening. If this is confidential information tell me in an email to petedowson@btconnect.com. Regards Pete
×
×
  • 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.