PhilippeV8

Pete, The info you gave helped someone else to give me some code which now works. So thanks for that. You say that getting code is not helping one to understand or learn .. that's true .. but my phylosophy is that I don't need to knox exact how it works .. as long as it does work and I know how to mold it so that I can use it. After a while I understand by doing and using the code. That's a total different approach than you suggest .. taking a book and learning 'bout program languages. But I think that would take me way too far and take me way too much time doing/learning things I don't need to know. It's a different phylosophy I guess. Either way, the thing I want to acoumplishe is nearly finished and it'll work for me. So I'm happy. Tnx

Hy Pete, I am having a bit of problems with the data types and conversion. (C++) Could it be possible to get an example of a code which reads the NAV1 frequency from fsuipc and then puts it in a label or textbox ? That would be quite handy. The SDK example from C/C++ doesn't explain me really how to do that.

I think I nailed it; you can see that the image in my first post has changed to the current state. What I did is take the FD LOC (0C48) and substracted the current turn rate and used this to position the LOC needle. Then took the FD GS (0C49) vanlue and substracted the current pitch value to position the horizontal needle. Don't know if this is precise, but it does seem to do the trick. Especialy for the turn. Not sure yet it the horizontal needle shows good ofset but it can't be far off. Tnx Pete, I'm on a roll again :)

http://forums.simflight.com/viewtopic.php?t=29677

I changed that to And it works now. I don't seem to find those % things on the net. I understand that the 05 indicates the number of digits to use ? But what is the d or the f behind ? And what other choises are there ?

:idea: 31E4 ? 8) works fine here.

glPrint("goodADF2 %05d", (double)_fdbank); That's what I got at the moment. I tried with the (double) and without with the same result. The ofsets I was refering to is the 0C48. I think I did try to declare it as "signed double" but I'll check again if it changes anything. I know 'bout the warnings. However I don't know how to fix this :oops: Most of them are: warning C4244: 'argument' : conversion from 'double' to 'float', possible loss of data And the line it refers to is something like this: // 20° up line glBegin(GL_QUADS); glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.43, 0.0f); glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.43, 0.0f); glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.40, 0.0f); glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.40, 0.0f); glEnd();

Hi Pete, So I've just searched what's up on the forum here on the FD matter. Indeed I know 2EE8 and 2EF0 don't give the needle position but a direction in which the needles should point the aircraft. Either way, when I read them from FSUIPC I get wierd stuff. The value changes on each read and goos from very large to very low (below 0) numbers. When I make the plane turn a lot (like from 0° to 100° or 200°) with the autopilot, the bank stabilises on 000008. These numbers are nothing like what I get from FSInterr. I suspect I am doing something wrong here. I'm new at C++ but I have managed to make this work in OpenGL (all you see on the img works) So I guess I'm not such a n00b as you might suspect. I am reading other stuff and using it proprely. Ok so for this FD thing, I declare: double _fdpitch; double _fdbank; int _fdflag; _fdflag works super. I tried changing the data type from _fdpitch and _fdbank to float or int and though the numbers get different each time, I get nothing like I see in FSInterrogate. Then I got this in the FSUIPC code: !FSUIPC_Read(0x2EE8, 8, &_fdpitch, &dwResult) || !FSUIPC_Read(0x2EF0, 8, &_fdbank, &dwResult) || !FSUIPC_Read(0x2EE0, 4, &_fdflag, &dwResult) || //etc.. At the moment I show the values in the green text you see on the picture above. Maybe it gets screwed up while showing it as text ? One other thing. I was working last night on those GS and LOC bugs. The GS was working good but I had a lot of issues with the LOC. It showed me values in the texbox from 0 to 127 and then jumped to 255 and counted backwards to 128. Even if I used double as type it didn't want to show negative values, so I just use an if/else and substract 256 from the value if the value is higher than 127. That works though probably unclean sollution. I hope you can give me some tips here. Cheers,

True, true ..

Ok, that's clear. Hèhè .. but it will be me telling him where to write what :P Because it is me who will be using this afterwards, not him (unless offcours he choses to build a home sim himself) I would ask what the difference is between Open2 and Open but .. never mind :) That's info for Espen and he will probably read 'bout it in the SDK. I do have a key for fsuipc so that should be OK then. I'd suggest him to request a key since his software is freeware (think that's possible to get a free key then, right ?) but that's no use either because I got a key and I am the only user :P No use getting a freeware key for me alone :wink: Ok then! I think I know enough. It's all up to Espen now. I'm outa here 8) Pete, thnx a lot ! If this thing is going to work, my sim is going to rule big time :) Cheers, Pv8

Ok. So Espen should confirm here ? Ow Espen e-mailed me and he expressed concurns about him having to have licence or not. Could you clear it out for us ? Or should it just work from inside FS to write via fsuipc ?

Espen >> the indicators are the button statuses (e.g. btnExtPower = 1 or 0, btnGlareASEL = 1 or 0etc etc.) Shortly said: every button that has a led. This way I could read those statusses from your panel code and adjust led on/off state in my sim. This way I will be 100% sure if a led in the sim is on, that that function IS on in your panel as well! Normal users can see it on your panel but I won't see your panel (or at least not all parts exept left MIP gauges and engine gauges). And I do not feel like show/hide the overhead or main panel each time i press a button to make 100% sure the signal got trough to FS and your panel. Pete >> if "people don't set the altitude hold until the climb or descent is to begin"how then is the aircraft to maintain altitude ? e.g. I come from FL080 to intercept the ILS. I set 3000 ft on the glare and chose descend mode. at 3000 the plane will level off, waiting to intercept the glidepath. Then before intercepting the GP, I will set e.g. 4000 ft on the glare which is the "go around altitude" for that airport. But even I change to 4000 I do not want my plane to climb or even descent! I want it to stick to 3000 so I want to maintain altitude function on untill the intercepting of the glidepath. how do these people solve that then ?? without using a separate variable for the ap-alt as we plan to do ?

Hèhè, that's the comon mistake people make. I had this too at first. I looked at the overhead and though ow yeah like 40 push buttons and about 20 leds I want to work I ended up with more than 70 of those push buttons in total and quite a few switches and other stuff. Most of the push buttons have a led so you'd get to 40 quite fast. If you count gear status leds (4) and glarepanel (+/- 16) then main panel has 4, pedestall has none, overhead has about 40 to 50 I don't know if I will want all of those to work right away (from the overhead I mean) but it would be preferable to leave space to go that far if I would chose to do so. I'm sure you would agree that it would be silly paying 1.50 euro per "push button with led" and have 80 of those and then not use the led Other than that you should agree that annunciators and leds bring your sim to life. And they are vital to the sim as they are in the real cockpit. F50 uses dark cockpit system so the leds should be out ideally but if something is wrong a led will go on and I want that in my sim too. Sometimes if I shift from FS to other programs for a while and then go back to flying my fuel pumps are offI want to see that from the cockpit and not only hear a warning beep beep beep .. cuz the beep could have multiple causes but if those leds are illuminated I know at once what is causing it. My A/P IS on and it is the one from FS. The FS attitude is used and quite a few other AP functions as well. Only not the altitude. If we would use the altitude we wouldn't be able to use any of the rest like attitude or v/s .. so what's the use. You can not use at least 1 of the FS variables to end up realistic in any way. I never made gauges so I am not sure from own experiance, though I know very sure now that PM does it the same way (not using the altitude) and many other advanced panels do exactly the same. I appreciate you trying to find more handy sollutions but trust me on this one. The AP alt is what we need separate from the FS defaults. There's just no other way around it. As long as FS doesn't drop this sillyness. Dito for the rudder. In FS the tail rudder is linked to the front weel. Not realistic at all. But as long as they don't make it loose from eachother we can't build a working tiller and pedal control separated from eachother.

Don't think it is 1 gauge. It just is 1 file. As far as I can see at least. I know little about gauges and how they are made. Thats 1 of the areas of FS that I have never really looked into before. I am not as such the only user of Espens panel, but I am the only user of this version or mod of the panel yes. It is for home sim builders only so as I said, maybe in the future if there ever would be someone building another Fokker50 home sim he would be interested in using the same mod. However most home sim builders chose Boeing or Airbus or regional jets or cessnas, so chance seems small. Concerning conflict .. I think that if I am the only person to use this mod (or maybe 2 or 3 others in the future, who knows) than that conflict would be with PM software. But no one could tell if PM would ever make any software which would be usable from a F50 type cockpit. And even if it would .. PM specialises in software which make it such that you do not need a panel in MSFS ! :) So even if PM would ever make F50 software, that would replace Espens panel and thus create no conflict at all. I understand your concurn. I can immagine that you and the PM folks keep good contact and if this idea I have could in any way create a conflict that could maybe harm your relationship with them. That zone is reserved for their use either way so if you OK for me to use it, they could perhaps not be OK with that. So I understand it fully. However as said .. no chance that normal FS users will download from Espens website the same version of the panel as I got and a conflict is most unlikely to ever occur. But if you prefer to reserve some space for my project that would be ok for me too. Makes no difference really. If you want that, let me know and I'll try to figure out how many bits I would need. ( 12 for the AP altitude + 1 per led , right ? Not sure yet though how many leds that would be but I'd guess somewhat around 30 or 50. 60 would be max I think )

Well as far as I know for now I am the only person building a F50 sim and if there ever will be more, for sure it will never be more than a handfull. People using Espens panel get an other version of the gau file so I got one custom made for me. If any other person would ever build F50 he would get it too probably but it is not to be distributed as a panel for normal FS users. Secondly F50 sim builders (or builder as long as I am alone) will not use PM software simply because they don't have (yet) no F50 type gauges available. This way there is no chance of any conflict between my program and PM because I simply don't have it. Hèhè, no no I am not translator. He is from norway but he sure understands english well enough :) I am just the one to contact you first because I am the one who wants this made possible. Once I figure out as much as I can about how to do it, then I forward all this info to him and kindly ask him if he would edit the gauge file for my needs. Then it is up to him to contact you if he needs more info. I just want to know first if it is possible and it is indeed so I read from your answers. So I will let him know this via e-mail and will direct him to the manual which you point out and then I can only keep my fingers crossed that he will manage to make this happen :wink: So far I am happy to know that it could be done. One last thing from me. Now that you know that PM and my gauge files will never meet on anyones platform .. is it OK then to use the PM zone ? Then also there is no need for any change to the FSUIPC dll (don't know if that WOULD require a change if we were not to use the PM zone) .. you tell me :)