Jump to content
The simFlight Network Forums

Chris Brett

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Chris Brett

  • Rank
  • Birthday 01/01/1970

Contact Methods

  • Website URL

Profile Information

  • Location
    London, UK
  1. Hi Pete, Thanks for your reply. Those values you suggest may prove useful indeed - if they can be made available via FSUIPC (still using FS2004 at the mo!) that would be great. That, combined with AoA info and G info, may allow me to derive the information I need, at least for some phases of flight. Purpose of this is to get an accurate manouvre and stall speed (min speed/barber pole) indication on electronic flight instruments. Alternatively, is there a known stalling (max) AoA variable for current flight conditions, together with actual AoA variable at the present flight moment? Maybe something could be used from those too. I better dig out the ATPL Principles of Flight manuals... :-) Regards Chris
  2. Hi all, Just wondering of there is an offset providing the aircraft's current calculated stall speed in KIAS? Can't seem to find reference to anything that might be useful to determine this. Chris
  3. The solution is to read this: http://forums.simflight.com/viewtopic.php?t=8906 and take particular note of point 5 listed under "What you get if you pay". Essentially, unless you have registered (ie. paid) to license your copy of FSUIPC, then only "allowed" programs ("accredited" in Pete parlance) will be able to use FSUIPC to get/set data, like you are trying to do. Without registering & paying for your copy of FSUIPC, you can't do what you want to do. Unless you apply to Pete for a freeware access / developer's key, assuming you are going to develop freeware that is. Those are the options. Squawkbox works after you entered the Squawkbox code in FSUIPC because that is a freeware application and supported by Pete with a program access code that allows Squawkbox, and only Squawkbox, to access FSUIPC devlopers functions with that code. Hope this helps. Chris
  4. The VB example code in the SDK contains a good example of how to read data from FS. The Timer1_Timer() procedure shows how to obtain the FS time (hours mins and secs) and display them. You don't even need to do anything, just run the code. However, if you'd like an even simpler example, try this. I added a Command button onto the form of the UIPCHello demo program (mine was called Command6 but yours many be different, so modify as necessary): Private Sub Command6_Click() Dim i_APactive As Integer Dim dwResult As Long Call FSUIPC_Read(&H7BC, 4, VarPtr(i_APactive), dwResult) Call FSUIPC_Process(dwResult) Command6.Caption = "AP is " & i_APactive End Sub This reads the state of the FS autopilot master switch when you press the button, and shows "AP is 1" if it's on, or "AP is 0" if it's off. And here is the explanation: Dim i_APactive As Integer This declares the variable that will hold the value of the offset we'd like to read. Here, we declare "i_APactive" as an integer type. We do this because if we look in the FSUIPC SDK doc, we find the entry for autopilot master switch and it says it's at offset 07BC (which is &H7BC in VB parlance), and that in order to get the proper meaning of AP master, we must read 4 bytes beginning at this offset. That is what the doc says. So, we use VB help to find a list of all data types supported and look for one that is likely to hold a sensible value for what we are trying to read. An Integer type is 4 bytes itself, so that fits the bill, and the only likely values to come from FS at this location are 0 or 1 (nothing too complicated). So an Integer type will be more than adequate for us. Dim dwResult As Long This is just another declaration of the result variable for the IPC function calls. We don't bother checking it here in this example; we assume it always reads correctly, for simplicity. But nevertheless, a declaration must be made for it, so here it is. Call FSUIPC_Read(&H7BC, 4, VarPtr(i_APactive), dwResult) This initiates the process to put our request into the buffer which FSUIPC will action when we (later) ask it to do so. Here, we say we'd like to read from offset 07BC, for a total of 4 bytes-worth of data (ie. we are reading 07BC, 07BD, 07BE and 07BF from FS), and that we'd like FSUIPC to store that result into our previously declared variable called i_APactive. The dwResult part simply holds the result of the call, and we shall ignore this for this example. This FSUIPC_Read action does nothing other than to queue this particular read request. We have not communicated with FSUIPC yet, but merely added our request to the buffer. We could add more Read requests here if we wanted to. But now, we must ask FSUIPC to action the requests in the buffer, and we do this by... Call FSUIPC_Process(dwResult) This is the meat of the FSUIPC communication. All it does is ask FSUIPC to action the queued Read (and Write) events that are sat in the buffer as a result of our previous calls to FSUIPC_Read() and FSUIPC_Write. The dwResult again holds the success/fail status of the call, and we will assume for this example it all went well (ie. we will disregard the dwResult), so don't worry about it. Command6.Caption = "AP is " & i_APactive This final line merely outputs the value of i_APactive to the command button caption. It will show 1 for the AP master switch being on, and 0 for it being off. The previous FSUIPC_Process call actioned our earlier request to put the 4 bytes of FS memory from location 07BC into our 4-byte long variable i_APactive. If it worked, then i_APactive will now be made up of those same 4 bytes, and if you've chosen the correct data type, then reading out those bytes by referencing the variable itself will reveal the result. If you've chosen the wrong variable type to use, you may get garbage. We could have done this another way. We could have declared i_APactive as a byte, and read just 1 byte from 07BC (ie. 07BC itself) as the return value is only ever 1 or 0. But for compliance with the FSUIPC SDK docs, we've done it properly and used the full 4 bytes. I hope this helps you. You should also take a look at the time reading example already in the code - this is just an extension of what has been described here. And the principles for writing values to FS are the same (except strings, which are a bit of a pain in VB). -- Chris Brett c.brett@flightdecktechnology.com
  5. Post the code you are using to extract the information from FS, there may be an oddity there. If you are making many calls to UIPC every timer event, use only one _Process call rather than _Read/_Process, _Read/_Process. Also, given you are driving external hardware, it may be a hardware update delay rather than a software delay. Have you tried updating a simple label caption on the form window with the UIPC-obtained result of the slip indication and comparing how frequently that label gets updated? There must also be some conversion between the UIPC value received and the output required for the hardware to work - check there is no delay there also. Post code if in doubt. Cheers Chris Brett
  6. Anyone found offset locations for control of the individual sound volumes provided under "Options | Settings | Sound..." in FS2002/4? Specifically the contol of the engine volume level I'm looking for. Seen offset 3B88 but appears only relevant to recipricating engines, not jets. Chris
  7. Richard, In addition to Doug's much more correct answer, you can cheat a little if you want and use the Hex() VB function, which takes the integer value and returns a string as the hex value of that integer. You will have to perform string conversions to integer or float types as you require so it's less efficient if you are doing many of these calls, but will do the job. Hence, in your example, Hex(8592) returns "2190". Similarly, you can use Str() for the opposite way round, to make an integer to hex value, although this might only be used for debug purposes. Str(&H2190) gives 8592, for example. Chris
  8. From Pete's freeware keys thread: The name of the exe is Squawkbox. Check you spelled it correctly. Not "squawbox". Chris
  9. It would appear that the Currency data type is inappropriate for this. Try this instead. I'm sure this is not the most efficient method (I'm not that active in VB programming these days) but it works: In General.bas declare this: Public Type LLCoordinates dwLo As Long dwHi As Long End Type In main code block: Private Sub Command2_Click() Dim dwResult As Long Dim FSLatitude As LLCoordinates Dim ACLatitude As Double Call FSUIPC_Read(&H560, 8, VarPtr(FSLatitude), dwResult) Call FSUIPC_Process(dwResult) If FSLatitude.dwHi >= 0 Then ACLatitude = FSLatitude.dwHi + FSLatitude.dwLo / 68719476736# Else ACLatitude = FSLatitude.dwHi - FSLatitude.dwLo / 68719476736# End If ACLatitude = ACLatitude * 45# / 5000875# lblLatitude.Caption = Str(ACLatitude) End Sub I hope this helps. Chris
  10. Do people not read information put before them? The ONLY people that will have to pay for FSUIPC are commercial software developers who require FSUIPC interprocess communciation facilities to have their products communicate with FS. Freeware authors do not pay anything to have their products use FSUIPC - they just apply to Pete for a free code that they can distribute with their product and that will allow it to run on anyone's machine. So I ask simply: what exactly is everyone's problem with FSUIPC being a commercial product to commercial developers, and a freeware product to freeware developers? What has changed at all? I suggest a good few minutes reading this thread will be well-spent, for all the doubters out there. Read pages 2-5 in particular. http://forums.simflight.com/viewtopic.php?t=7222&postdays=0&postorder=asc&start=0 And as for the suggestion by some anti-commercial freeloaders that a crop of FSUIPC-like freeware "alternatives" will suddenly spring up now that FSUIPC is commercial software to developers, I pose only this: FSUIPC (and FS6IPC before that) has been around for quite some years without anyone else coming close to producing a similarly flexible and efficient interface to FS offered directly to the public. It strikes me people are not quite understanding the effort that has gone into developing FSUIPC (and indeed FS6IPC before that under Adam Szofran) and how Pete has dedicated a lot of time and effort to maintaining and extending its abilities mainly for the benefit of those who rely on it to produce other software products, particularly commercial products. It is they who will be paying in the future to use FSUIPC, not the freeware developer or the end user. The argument put forward by some is that FSUIPC is now fully "commercial software" and should be boycotted in favour of development of alternatives. There are no alternatives and nor do there need to be - FSUIPC is still free for freeware authors, and this has been stated many times by Pete in these fora. Why people choose not to read or understand such information is beyond me. It's not rocket science, people! You only pay for FSUIPC if (a) you are a commercial developer, or (b) you require the extra end-user functions such as the fancy things it can do with joysticks and keyboard mappings and such like. In all other cases FSUIPC will remain free. To Pete: might I suggest a sticky thread on this forum entitled "FSUIPC v3 FAQ - Freeware & Commercial Usage" or similar and stick the basic information in there for everyone to see, and then lock the thread? Might save some of the gibberish we are reading too frequently on here from certain people Chris
  11. Erik, No, you don't have to buy your own license! You, personally, would only buy a license if you required to use the *extra* FSUIPC functions that it can provide, ie. the joystick facilities, button mapping etc etc. If you do not require these functions or don't know what I'm talking about, you don't need a license, as an end user, and you can use freeware and commercial products that use FSUIPC without any problem whatsoever. In other words, no different to how you as an end user of a freeware or commercial product stand today using same product. Below follows my understanding of Pete's intentions with regard to licensing FSUIPC. I hope I have it correct. If people would take the time to read what Pete has already written on the matter then they would answer their own questions and concerns, rather than mouthing off and wingeing at the fact FSUIPC is now a commercial product. (1) If you are a developer writing a freeware product and wish to have your product communicate with FS via FSUIPC (it's original mission in life), apply to Pete directly for a "freeware" key. That key will be specific to your freeware product and will allow your product to get and set data from/to FS via FSUIPC programming interface. The key will be set in the FSUIPC ini file by the product on installation, the user need do absolutely nothing extra or pay anything extra, because it is the *product* that is licensed, and thus the product can use FSUIPC with no worries. (Freeware authors in the process of developing a freeware product will also, presumably, be able to apply to Pete for a freeware key even though the product is not published, in order to allow said product's development, one assumes.) (2) If you are a commercial developer, apply to Pete in same manner as 1 above, only hand over some dosh. (3) If you are not a developer at all, and merely a user of a product that requires FSUIPC to work, then you do nothing and pay nothing. The products that use FSUIPC will already have a license to allow them to work because the developers will have followed step 1 or 2 above. (4) If you are a developer OR an end user of FSUIPC requiring the use of its extra functions (joystick stuff, keyboard mapping etc) then in order to do so you, personally, will need a license to enable that part of FSUIPC. For this you will need to pay, and once you have your key, you will have access to the extra facilities of FSUIPC, and in addition, all products will be able to communicate with FS via FSUIPC as well on that instance of the licensed user's computer. Thus developers wanting to develop many programs at the same time, particularly commercial developers, would probably find things easier if they bought a license for themselves as well as the one they will require anyway for their product. In other words, if you are an end user, perhaps you don't even know what FSUIPC is, just that you need it to run your favourite addon, then for you nothing has changed. Good luck, Pete. :wink: Chris
  12. It might be OK, although if you are planning on doing this with the standard GUI Windows graphics calls then it might well be slow on a P233. That said, a half second update rate might be OK - try an experiment and see. Bitmap resolution, and needle bitmap size/memory will also affect update rate. There are other more efficient ways to make your own "virtual gauges" but if you are not too familiar with VB or programming in general, I'd stick to your idea and give it a try first. Chris
  13. Richard, Using the FSUIPC SDK "Hello" example from my VB conversion of the SDK, replace the code in the "Private Sub Timer1_Timer()" function as follows: Private Sub Timer1_Timer() Dim dwResult As Long Dim iIAS128 As Long Dim fIAS As Single Call FSUIPC_Read(&H2BC, 4, VarPtr(iIAS128), dwResult) Call FSUIPC_Process(dwResult) fIAS = iIAS128 / 128 lblClock.Caption = "IAS is " & fIAS End Sub There are various other posts on this forum concerning the basics of reading and writing to various locations within FSUIPC from VB, it might be worth clicking on Search and browsing around other examples. However, what this simple example does is this: from the FSUIPC for Programmers document we can see that the airspeed offset is at location 02BC, which in VB means &H2BC or in Delphi means $02BC. We can also see that the number of bytes FSUIPC would wish to be able to fill when this offset is requested by a program would be 4 bytes. Thus, we have declared iIAS128 as a "Long" type above (a Long type in VB is a 4-byte variable, capable of holding a value from -2,147,483,648 to 2,147,483,647, and thus will easily satisfy our needs for an airspeed value). However, the description of what is obtained from &H2BC in the document says we can expect the airspeed in knots multiplied by 128. Thus the value returned to us will be 128 times greater than the actual airspeed in knots, and so I have chosen to declare an additional variable, fIAS, as a Single type (a floating point type) to hold the conversion to knots. The calls to FSUIPC_Read and _Process are standard stuff. _Read requests that FSUIPC puts data held at location &H2BC into our variable iIAS128, and requests that it fills the variable with 4 bytes of info from this location (ie. it fills the whole iIAS128 variable). _Process activates the request in FSUIPC, and if successful, the iIAS128 variable now contains the airspeed value multiplied by 128. A quick division by 128 gives us the IAS in actual knots, and the value is output to the label on the form. As all this is in a timer, this entire procedure will be repeated every half second (timer interval is set to 500ms). Hope this helps your understanding, apologies if it's too simple. Browsing other posts in this forum or doing a search should reveal you some more examples of reading and writing various values. Chris
  14. Or you could do (pseudo code): if value from IPC > 32737 then VS := value - 65535 else VS := value; ... in the absence of knowing what the VB equivalent of a signed word is. It's a bit crude but it'll do the job. Chris
  • 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.