Jump to content
The simFlight Network Forums

Pete Dowson

Moderators
  • Posts

    38,265
  • Joined

  • Days Won

    170

Everything posted by Pete Dowson

  1. Sorry, I don't understand much of that. What is "FS Comm"? Aren't you calibrating anything in FSUIPC? Did you read the write up about those offsets in the Offsets documentation, as i pointed you to? Using them like PFC uses them your values have to be 0-127, as that is the range used by PFC. FSUIPC then scales them by x 512 in order to get them to normal FS-accepted values. If you are already sending such values you have to take precautions, as described. So, I think you must be missing something in the documentation. Pete
  2. Well, an FSUIPC.LOG file would have been far more useful. It would probably actually show what you have wrong. The install log shows nothing wrong, except this: which shows that when you tried to Install FSUIPC, it was not only already installed, but running! In other words, FS2004 was also still running! The installer cannot replace a file currently in use -- Windows won't allow it. Close FS properly first. If it has no Window then it has probably hung on termination -- use the task manager to terminate it. Show me the complete FSUIPC log file. Also state whether there's an FSUIPC menu entry in the "modules" menu in FS. Regards Pete
  3. It is certainly possible, but generally undesirable. Those add-ons you are talking about cannot tell the difference between axes assigned in FS and axes assigned to the same FS controls in FSUIPC. The can only be detected as FS controls. At present you are probably using the FSUIPC facilities to assign "direct to FSUIPC calibration", which doesn't use FS controls at all until, possibly, after the calibration process -- and that depends on how it is implemented in FSUIPC. For FSX or ESP it aactually means those controls bypassing any applications wanting to hook into them before they reach FS. So, for those add-ons, just make a separate Profile or "aircraft-sepcific" arrangement where the axes affected are assigned to FS controls instead of direct. If you try to use FS assignments instead, you'll have to do so for all aircraft as FS doesn't have the capability of switching for different aircraft. No, you misunderstand. Once you assign an axis in FSUIPC, no matter which method you select there, you do not need, and in fact certainly do not want, ANY assignment in FS for them. The assignment in FSUIPC is sufficient. Regards Pete
  4. AhI wrote something down about that in one of my "to do" lists, but i think it's got buried or lost someplace. I've been unbelievably busy with one thing or another. We'll, as far as I remember, it didn't look like a big job. But I can't find my notes now. if you have the details, can you post them here again for me, please? Regards Pete
  5. Some add-on panels (including, mostly, the Microsoft defaults, annoyingly enough) are not written using the standard Gauge SDK and therefore don't have the standard tabular structure to deal with mouse operation of their switches. The Mouse Macro facilities in FSUIPC then cannot hook these and simulate them for you. For FSX and ESP there are facilities in FSUIPC4 to read and write local gauge variables (L:vars), which are often used in modern cockpit gauges -- especially those written in XML. However, whilst these can often be read okay, writing values to them does not always produce the desired result -- it all depends upon how they are written. Failing both these choices, unless the panel makers have made provision for short-cut keypresses, or have provided an SDK (like Level D) then I'm afraid there's no satisfactory answer. You could resort to a program like "Key2Mouse" by Luciano Napolitano, which translates keypresses into mouse actions, then program the keypresses on the buttons, but this technique is only really suitable for static gauge displays, as in 2D panels. Regards Pete
  6. I don't actually have a website, but FSUIPC is sold by SimMarket, so the correct places for purchase are: http://secure.simmarket.com/pete-dowson-fsuipc3.phtml for FSUIPC3 (FS9 and earlier) http://secure.simmarket.com/pete-dowson-fsuipc4.phtml for FSUIPC4 (FSX and ESP). That's Enrico Schiratti's website. It is where folks may download FSUIPC from, but it isn't the purchasing place. You may point folks wherever you like, but the purchase pages are the most appropriate. Regards Pete
  7. Well, if FS is that coarse then all you can do is interpolate values between and move the needle more slowly to its destination. That will obviously make it lag somewhat, so I wouldn't think that would be a good idea for crucial flight instrumentation such as the AI. Have you tried looking for better FS aircraft models which don't have such a coarse value change? Or is the jump purely due to some rather slow sampling your program is performing, like once per second instead of every 20-50 milliseconds? Regards Pete
  8. You can write a little Lua plug-in which receives your throttle value as a parameter, scales it to fit your range 1-100, and writes the L:var value with the result. When the Lua plug-in is saved in the Modules folder, assign the lever axis to it in the normal axis assignment tab in FSUIPC. Alternatively you could simply try assigning direct to your L:var macro in the axis assignment TAB, scaling the value by using the simple arithmetic multiplier and divider facility. See the Advanced User's document, the section at the end of the Axis Assignments section entitled "Additional parameters to scale input axis values". You haven't got the power of the Lua language to help scale exactly there, but you might get close to what you want. Regards Pete
  9. This sounds like exactly what I want to happen and by a much simpler means. Okay. I'll do that, probably later this week. Well you can, of course, but not without writing a program. All the ButtonScreen option provides is a set of buttons. What they are programmed to do in FS doesn't easily or necessarily relate to any status. Most would be actions or even sequences of actions, as in macros. Regards Pete
  10. A string is merely an array of bytes. Declare a variable large enough, then read the correct number of bytes directly into it. Whilst there are 2 bytes in a WORD and 4 in a DWORD, and 8 in a double, there are almost any number of bytes in a string -- the offset list will tell you the maximum. The address you supply for the FSUIPC read will need to be the byte address of the first byte of the byte array into which you read the string. For example, if you define: char szATCmodel[24]; DWORD dwResult; then the FSUIPC_Read could be FSUIPC_Read(0x3500, 24, (BYTE *) &szATCmodel[0], &dwResult); or, because C/C++ takes the name of an array as the address of its first element: FSUIPC_Read(0x3500, 24, (BYTE *) szATCmodel, &dwResult); I only cast the address by "(BYTE *)" to stop the compiler giving warnings if you are using signed characters instead of unsigned ones ("BYTE" is defined as an unsigned character). Regards Pete
  11. Looking further down your message I see you mean "L:vars" not "Lua" values -- Lua is a separate language used to provide plug-in code for FSUIPC (and many other games and simulators for that matter). "L:vars" are the local gauge variables with names prefixed by L: in FS to denote them as Local (I think). It does not work because "Battery" is the name of the macro, and "L:LeftBatSwitch" etc are also names of macros. The L:var macros use the L:var identifier as the name, whereas in button, keypress and mouse macros you choose the name. If you want more than one macro action from a button or keypress you would need to either edit the INI file Buttons assignments to assign the different actions to the same keypress/button, or write a Lua plug in to action the multiple macro operations and then assign your button or keypress to the Lua action which then appears in the drop-down. Regards Pete
  12. I hope someone else reading this can help - C# is outside my sphere of knowledge, and, I think, being a completely managed language, is subject to a lot of peculiarities when trying to address something with a native mode C/C++ interface. However, I do have one observation: Even though each thread supposedly uses its own connection to FSUIPC, unless the code in the "class object" you are using does something very different to make its "atom" identifier different, both threads will actually be using the same memory-mapped object in order to talk to FSUIPC. The memory-mapped object is normally identified by an atom id obtained using a string name generated using a fixed portion and a portion generated from the PROCESS ID -- which will be the same for both threads. Since the code for generating this string ID is actually part of your program, it can of course be changed -- possibly by also including the Thread ID -- but maybe this has not been done? If both threads are sharing the same memory mapped file area for transfer of data to and from FSUIPC, then without some sort of lockout semaphore arrangements you are going to get one thread corrupting the other's data sooner or later. Regards Pete
  13. Use floating point. Regards Pete
  14. No, there's no such problem on either TCP or UDP. Only the IPX protocol isn't working, and that'll be because neither WinXP nor WinVista installs that protocol by default (presumably because it was a Novell invention, not Microsoft's, so they demoted it!). For some reason you posted two copies of the Server log but not one at all from the Client. However, the fact that you have one PC running Vista and the other XP leads me to guess that you have two differently named WorkGroups there -- Vista's default WorkGroup name is different from XP's. This difference causes the Server's broadcasts to never reach the other PC -- broadcasts are limited to the group. Your best solution is to rename one, other, or both, workgroups to be the same. I always name mine "PETES". This is done in the same place as where you name your PC -- the "My Computer" properties. Alternatively you can revert to the old-fashioned way of WideFS, and specify the ServerName and Protocol via pramaters in the Client's INI file -- the documentation describes this. Regards Pete
  15. What security warning is that, please? Does it say the program is from an unknown publisher, or from simFlight? If the latter it is certainly not an indication of a corrupt or infested program and I think you must be reading something incorrectly. FSX always asks you to confirm running of any newly installed program from a publisher you've not approved of specifically before. BTW the fact that it installed and registered okay proves it is not corrupt or infected. Pete
  16. I've no idea about C#, but if you know how to read and write FSUIPC offsets, please look at the Offsets list and find offsets 0D70 and 0D6C. It is all explained there. Regards Pete
  17. What "things" are there to work? If you have no idea of what you want to use FSUIPC for, why did you buy it and register it? There are three manuals provided with FSUIPC, and installed for oyu, and these are listed in the Installation guide. The only one most folks may want is called, obscurely, the "User Guide". It doesn't tell you "how things work" but only how to use the facilities FSUIPC offserts, if that's what you want to do. What bit is that? Sorry, I do not recognise that. And all that time you never looked at any of the documentation provided? Why did you buy it if you didn't know what you were getting? Regards Pete
  18. Sorry, where would those words be placed, and why would you need to download FSUIPC again when you already have it? The Installer is called the installer and the download doesn't include FSUIPC in any other form. Regards Pete
  19. Good! Now enjoy flying! ;-) Pete
  20. The "offset status" you are talking about is only the default comiler-made initialisation of values to zero, but those are just in local memory in WideClient. Not to any old WideClient memory locations, no. WideClient only gets data about offsets from WideServer. I'm not clear which you are getting into all this complciation. I start off any sessions in my cockpit with a flight saved "cold and dark" with everything off and in a known state. That way everything always stays in sync. Are you in the habit or starting things off in different phases of flight? There are two WideClient enhancements I can think of which you might regard as a help: 1) Have a set of FSUIPC offsets assigned with a bit for each "virtual button" which reflects the last state of whatever ButtonScreen cell is programmed to change it and which can be changed to cause the state in the ButtonScreen display to change. This is probably what you want, but is very problematic. There's no one-to-one correspondence of ButtonScreen display cells to virtual buttons as it now depends on the arrangement and use of other cells. Additionally, some users (myself included) have virtual buttons not only controlled from one Client display, but from others too and from real switches or other programs doing other things. I hate to imagine what conflicts might arise. I suspect I could resolve all this and make it work, but it isn't really something I'd want to do. 2) Allow an initial toggle setting flag in the ButtonScreen, so when Wideclient starts up you can have some inidicating "on" whilst others indicate "off", according to the parameters. This one is pretty easy, and i could do that quite quickly. Regards Pete
  21. Are you looking in the SDK as you should? They are listed in both the "FSUIPC for Programmers" document and the "FSUIPC4 Offsets Status" document, the only continually updated references for FSUIPC offsets, and they've been so listed for a couple of years at least. As all of the offsets are listed in order, I don't see how it is you cannot find them! Regards Pete
  22. Project Magenta is really a cockpit system in its own right, and effectively replaces all of the cockpit parts in FS. If you only want networkable instrumentation for default FS aircraft (or aircraft using only default instrumentation, or instruments only using default data) you'd probably be best off looking at other packages which do such things. But note that there is no way to take gauges from sophisticated add-on aircraft like those from PMDG and so on and move them onto a separate computer. The best place to ask these questions is over in the MyCockpit forums http://www.mycockpit.org/forums. There are cockpit builders sections, and a selection dedicated to PM http://www.mycockpit.org/forums/forumdi27981&f=99 Regards Pete
  23. FSUIPC's axis logging should show you what is going on. If you are getting jitter with controls centralised and not being touched then there's something odd. Have they got a clean power supply, good connections and cables? If USB connected try a different USB socket, preferably either one on the motherboard, or on a good powered hub. Don't use unpowered hubs. And check that the potentiometer or whatever in the control isn't worn or dirty. I've used Servisol electrical cleaner on some to good effect. For the neutral, central area, you could use FSUIPC's "slope" facility to set a flatter central response. Of course this wastes a little resolution in the outer areas which have to be steeper to compensate, but it is often a good fix. It is the equivalent of the "null zone" in FS, except that simply removes part of the range altogether. Only if it is trying to write direct to the FS control offsets. There are a set of offsets (3BA8 to 3BC6) which were originally made for handling the PFC range of serial port devices. Values written to those are detected in FSUIPC's Axis Assignments as being on joysticks 16-18 and can be assigned and calibrated like any others. Regards Pete
  24. No, sorry, I don't know how to get such information automatically. If there are active AI traffic flights with runway assignments then you can read those through offsets at D000 following. details are in the "FSUIPC for Programmers" document (part of the FSUIPC SDK) -- see the section on the 4th page. For locations on the airport you would need to refer to a database, such as the files made by my freeware "MakeRunways" utility, looking up your airport by its ICAO and using the runway coordinates and dimensions in relation to your own aircraft's coordinates. Just a matter of some trigonometry. For such short distances you cane use plane geometry, spherical formulae are not needed. Regards Pete
  25. You certainly still have a broken FSX installation. The SimConnect installation is incorrect. Check that the ONLY place you have any SimConnect DLLs is in the Windows "WinSxS" folders, or maybe in your FSX SDK folders if you have installed the SDK. This error: is direct from SimConnect and says that the version of the DLL loaded in FSX is incompatible with that version of FSX. I've seen it most often when you, or another program, has incorrectly placed a part of SimConnect into the FSX folders or even the Modules folder. Well, that's one option I suppose, if you've no other use for it -- though taking it to the city dump would be tidier. No, joking aside, I'd guess either the above diagnosis is correct, or your attempt at reinstalling SimConnect files was wrong. What was actually wrong in the first place, that you went to such measures? Have you previously been uninstalling and reinstalling FSX or its updates? That always seems to make a right mess of things. FSX simply does not uninstall properly. You may need to start again. If so, do it in reverse order: uninstall SP2 or Acceleration first, if you have it, then SP1, then FSX, and then delete the two or three SimConnect WinSxS folders. Only then install the FSX base, run it once, then SP1, run it once, then SP2. If you have Acceleration, install that instead of SP1 and SP2. 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.