Pete Dowson

"Offsets" are just bytes of memory. Each byte can contain a number (0-255 or signed -128 to 127) or a character of a string, represented by its ASCII value, which is also a number (eg 65 = 'A'). Groups of adjacent bytes are read/written as different value types. A "WORD" is 16 bits which uses 2 bytes together 9eg 66C0 and 66C1), an int or a DWORD is 4 bytes, a double float uses 8 bytes, and strings of characters or arrays of numbers can use any number of bytes. So, to write a string to 66C0 you just do so. in Lua it would be ipc.writeSTR(0x66C0, "this is a string"). At 66C0 there's only 64 spare offsets so you need to make sure you write no more than 64 characters, Thus: ipc.writeSTR(0x66C0, "this is a string", 64) would be safer. So, what is the difficulty? I don't understand why you find yourself unable to do similar? This forum has a number of "threads", seen as a list of subject titles. One of those titles is "MS Flight Simulator Support" and being quite recent is near this thread that you are reading! i.e. "HERE" is where you are reading at this very moment! Sorry if you natural language is not English. It is always worth scanning the list of titles to see if there's anything of interest or relevance to you, and also to see if your question has already been asked and answered. Pete

Why do you want to read it? If you do, and you don't have Excel installed properly (because that's probably what it wants to open for such a file), you can use Notepad or any proper editor. Just use "Open with" on the right click menu. But why on Earth are you wanting to open it? The files are intended as data for other programs which need them. Neither! MakeRunways is nothing whatsoever to do with FSUIPC in any case. CSV means "comma separated values". If you are trying to open sucgh files without saying by what, then Windows will just automatically try to open the program it thinks is associated with them, whether that is Excel or not. Pete

Then it is some other add-on. Assuming you've already tried with no other programs running, only P3D, What other DLLs do you have running? Did you bother to try the ; metod of saving manually as I asked? There really isn't anything I can do. the only way to save a flight is to ask P3d, via Simconnect, to do it. I'm not able to figure out how to gather the data and produce the files myself. it is all done by P3D I assure you. Pete

Is the brightness control actually like an axis control, with the brightness as a parameter? If so then do it the same way as your macro. To get the parameter form -16000 to +16000 converted to a value o to 300 it needs scaling. Please see Additional parameters to scale input axis values on about page 42 of the Advanced User's manual. You would need something like +16000 (maybe more if it is really -16384, say) to get the range to 0 to 32000 then *0.0094 to convert that to 0-300. (300/32000 = 0.0094 approx). So add ,*0.0094,+16000 to the end of the axis assignment in FSUIPC5.INI. You might need to experiment a little to get it just right. You might also want to raise or lower the "delta" value for the axis (in the assignments tab). Pete

I've moved you support question to the Support Forum, where it can be answered! PLEASE ALWAYS POST YOUR SUPPORT QUESTIONS TO THE MAIN SUPPORT FORUM, NOT TO THE REFERENCE SUB-FORUMS! All of them? And you have to re-create them all? We can't help without proper information. Please, next time it happens, find the FSUIPC5.LOG and FSUIPC5.INI files in the Modules subforum, and post them here, describing the last action you performed. Remember that Buttons & Switches can be assigned for General use or specifically for a profile. The profile for your current aircraft is not necessarily active in Buttons & Switches -- make sure the Profile option at the top is ticked when assigning specifically rather than generally. Pete

If you don't calibrate, then Axis Assignment to standard Sim controls ("Axis ... Set") controls just sends the controls on to Simconnect as if you had assigned in P3D. But if you calibrate in FSUIPC it has to send them at a priority level where they are not being seen be FSUIPC again and continually re-processed. It looks like it. I am not familiar with "ControlMapFile". I am not really a PDK programmer -- John is more involved in that but he is on holidsy for a couple of weeks. Reading about it briefly in the reference you gave it looks like just another method of assigning axes except then using them directly in your object. So it is effectively doing the same as FSUIPC except for the calibration. PMDG boeing aircraft use axes directly as well, though I don't think they use the PDK for that. If you calibrate throttles, for example, in FSUIPC then the PMDG aircraft seem to get two values which can conflict if the calibration changes the axis value (which of course is rather the point). Pete

Always also test with a default aircraft. That shouldn't happen either. What happens if you save a flight using the ; key (default shortcut for 2save flight0. It will prompt you for flight name. Pete

There are free user offsets documented at 66C0 to 66FF (see the offsets list). So those can be used for any string up to 64 bytes long (including final zero). If you want more and you are not using Project Magenta you could make use of the PM reserved offsets. Why not read this thread from the beginning, where you will find that such information has already been provided? Please refer to the thread near here on that subject. Pete

Can FSUIPC see the axis in its axis assignments tab? FSUIPC intercepts axes via SimConnect at their normal reception priority, and, if they are calibrated, with flags set to stop them being sent on. An axis calibrated through FSUIPC is sent on to SimConnect at a lower proirity level. Otherwise there would be an infinite loop. I suspect, for this reason, your method doesn't see them any more. You therefore cannot use FSUIPC for calibration. Pete

FSUIPC's "AutoSave" is merely a call to Simconnect to save the flight, in exactly the same way as using P3D's menu or the ; key would do. the only difference is that it automatically generates the flight name for you. So, something else is doeing your flashing or minimising. I suspect you have an add-on, maybe an aircraft, which is seeing the save happen and is doing it's own actions as a result. For example, many add-on aircraft save the state of the parts of the aircraft not otherwise saved by default. There will be other examples. So, you'll need to eliminate each add-on you have running until you find it. Pete

Right. I'll mske the public release tomorrow. Pete

No. You'd need a program to do that. Look to see if the program you are using to convert it into a command has such an option. Pete

No. So you can change the offsets used if it turns out to be necessary. That's good. Pete

You can't change the name of the current aircraft! Pete

You need to treat it as unsigned int, not int, though an int is usually 4 bytes (32 bits). You should declare it as an unsigned short, or whatever your software understands. I know 16-bit values as WORD (Windows programming definition0. An unsigned short int has a range of 0 to 65535. Pete

Well, thanks for the file. It isn't trivial I'm afraid. apart from the Simconnect sharing data changing (different IDs), which is dead easy to deal with, there are lots of extra entries at the end of the data (after the "FMC FlightNumber"). Now for your existing use they probably don't matter because you wouldn't be using them. BUT there are these extra values plonked in the middle too, just following "FUEL PumpCtrSw:" bool FUEL_AuxFwd[2]; // aux fwd A and aux fwd B bool FUEL_AuxAft[2]; //aux aft A and aux aft B bool FUEL_FWDBleed; bool FUEL_AFTBleed; bool FUEL_GNDXfr; I seem to remember their "bool" being defined as a Byte, so that insertion shifts everything following down 5 bytes. I don't know if the software you are using is easily configurable to change the offsets it is using. If it isn't then the only way would be for FSUIPC to manipulate the data to move those extra 5 values to the end, after all the new stuff, and move the following stuff back to where it is with the NGX. That would make sense for compatibility reasons, but being a more work cannot be done instantly. I'll discuss it with John next week. The problem we would then have is testing. You would need to do that for us as it really isn't worth us purchasing the NG3 (which, BTW, seems to be known as the "NGXu" when it's for P3D4, only NG3 for MSFS2020 -- that's despite it being called NG3 in that .h file!) Pete

Okay. ZIP them, please, and send to petedowson@btconnect.com. I'll take a look. but changes to FSUIPC5 are the province of John Dowson now, not myself, so even if it is easy to do, it might be a while before a formal update. Possibly John would supply an interim update for you to test in the meanwhile. Pete

Are you saying there's no data listed? If that's the case then maybe PMDG have stopped supporting that option. Pete

Is that version actually released now? I thought PMDG were saying they'd be waiting for MSFS2020 instead now. Anyway, either way, it is a new product which of course is not recognised by and therefore not supported by FSUIPC. If you have the (supported) NGX, compare the installed SDK ".h" file in that with the one for the NG3. If they are the same apart from the Name or ID it states then it should be an easy enough job to adapt FSUIPC5 to cover it. But if there are changes in the data list then it will be a lot more work. I don't have either model, so in order to advise further I'd need to see both of those .h files. And any changes could only apply to FSUIPC5, so i hope you are using P3D4. Also, i couldn't give you a timescale. Pete

It's just that you have Windows set to hide known filetypes -- .csv files are probably recognised as normally opened by Microsoft Excel, as shown in Thomas' pic. Just stop Windows hiding parts of filenames from you! It'll be one of the Folder options in Explorer. Pete

Okay, I understand now. Please test this one. If it is okay I'll release it properly, so let me know. You can either supply it with your product (with the instructions of course) or just tell your users to get it. Got it! Thank you! Pete MakeRwys4891_TEST.zip

You are premature. No one has any useful information about MSFS2020 yet. Ask again in a few months. Maybe someone will know something then. Meanwhile enjoy P3D4. Pete

Well, that depends. Do you need your users to run MakeRunways, or is it only used in house to generate your data? I am just a little concerned that programs processing MakeRunways files using their own scanning methods may stumble over the unexprected "." decimal point in the Altitude. I don't think that would be a problem with XML files, so if you only need it there I can restrict the change to that file. Would that be okay? Do you think the 0.03% difference in the version I already offered could cause such a phenomena? I think the cockpit altitude above the ground is much less accurately computed than that, and even the Radar Altitude isn't actually computed from the underside of the tyres. Nevertheless, if you only need it in RUNWAYS.XML i will make the computation accurate, using 3.28084 instead of 3.28, and provide it to 2 decimal places in that file only. That should upset nothing and allow me to make it a general release. The only result in the other files (r4 and r5.csv) would be that the .99 will round the integer result to 2343 instead of the previous 2342. Let me know. I can do that quite quickly, then, if it is suitable, make a Release. ============================= BTW will I be able to get Aerodata from your website? Please email me (petedowson@btconnect.com) my credentials so that I may start using it again. After the download problems i kept getting I went over to the Herve Sors free ones, but they are a bit more of a hassle to install. I've forgotten or lost your data. Pete

I already said the default for CYPZ I was getting was 2342.39. When it was an integer it was 2342. Why didn't you reply before to say you thought 2432.39 was wrong? It would have saved time! To 5 decimal places there are 3.28084 feet to a metre. Because no one has EVER need anything so accurate for feet I use 3.28. Which in this case gives the value you are getting. The difference between 3.28084 and 3.28 is a mere 0.03% I thought you wanted just a more accurate value. Are you saying you really need the number read from the BGL? Even the 3.28084 is probably an approximation, I can re-do the test build using 3.28084 is this is really so desperate, but i'd like to know why beforehand please! Pete

Try this test version 4.8.9. Pete MakeRwys489_TEST.zip