INC/DEC Concorde Visor Control force read.

[spokes2112]

Peter,

As you may know, the previously used Concorde visor control does not work in FSX (Although not tested with a native FSX aircraft w/ that feature, if any exsist?).. After some testing there is only 1 way to make it work in FSX from a FS9 portover and that is to set the .air file as Concorde. (Sec. 1101, Airframe Type=5943) The problem using this airfile entry is that is nearly impossible to create a realistic user airfile as I believe something in ?Sim1.dll overwrites the airfile values but the visor controls then work! Just cannot get predicted performance especially from the engines, flight dynamics go all whacky too from this airfile mod.

Is there a way that you can trap the visor controls and mod them in ?sim1.dll as you did with ground friction via an .ini entry?

Many aircraft from FS9 port over nicely to FSX and many of them use the visor control, which worked in FS9, usually for some visual movement of the visual model. Changing to the Concorde airframe type is not an option.

If you think this is possible I would be more than happy (Elated actually) to do the tests for offsets, size etc. Since I have an aircraft already setup with a visual visor conformation & and a modded airfile for testing.. FSInterrogate2std.exe would be the tool?

I believe MS removed this function as well as others due too tragic events that occour around the world.

Thanks in Advanced,

Now a proud owner of 4859q :mrgreen:

Regards,

Roman

[Pete Dowson]

Is there a way that you can trap the visor controls and mod them in ?sim1.dll as you did with ground friction via an .ini entry?

Sorry. It isn't like that. The ground friction thing was a table which once a few clues were established was easy to find. The is no easy way to hack into FSX code. It is all a series of black boxes (C++ objects) with the most convoluted assembly code imaginable. I just haven't the time nor patience any more. If I were 20 again I'd take up the challenge. but at nearly 70, life is becoming too precious to waste so much time -- and I know it would be a waste. I've tested this on several occasions recently.

Why not invest in the FSLabs Concorde? By all accounts it is a splendid re-creation!

Pete

[spokes2112]

Pete,

Thanks for the response.. It isn't for a Concorde but rather a F-111 (fs9) model and possibly any other FS9 port-over from FS9 that one may have. Yes, the FSLabs Concorde is the "bomb" from all reviews I've read and is on my future shopping list of "must haves."

Thanks again,

Roman

[Pete Dowson]

It isn't for a Concorde but rather a F-111 (fs9) model and possibly any other FS9 port-over from FS9 that one may have. Yes, the FSLabs Concorde is the "bomb" from all reviews I've read and is on my future shopping list of "must haves."

Well, the visor controls are still assignable in FSUIPC4, so if you have a ported aircraft which makes different use of them, they should still be okay. Here they are from the FSX controls list:

DECREASE_CONCORDE_NOSE_VISOR 66295

DECREASE_CONCORDE_NOSE_VISOR_FULLY 66384

INCREASE_CONCORDE_NOSE_VISOR 66294

INCREASE_CONCORDE_NOSE_VISOR_FULLY 66383

Pete

[spokes2112]

Pete,

Yes already tested them even with various 4 bit parameters. They donot work unless the aircraft type in the airfile is 5943 = Concorde = NOT GOOD.. At least for a port over from FS9. As for FSX native aircraft I have no aircraft that uses those commands.. If they work in the FSLabs Concorde I wonder what the aircraft type they are using in the airfile -or- maybe they work in a FSX compiled model. Will keep testing..

Thank You,

Roman

[Pete Dowson]

Yes already tested them even with various 4 bit parameters. They donot work unless the aircraft type in the airfile is 5943 = Concorde = NOT GOOD.

You say they "do not work", but they are simply numbers sent to FS's engine. They will work with aircraft which FS recognises as supporting what they are intended to do. If you have add-on aircraft which use the same controls for other purposes, the problem is with the add-on.

As for FSX native aircraft I have no aircraft that uses those commands.

So I don't undesratnd your interest in them!

If they work in the FSLabs Concorde I wonder what the aircraft type they are using in the airfile -or- maybe they work in a FSX compiled model. Will keep testing..

Unless FSLabs made use of the same control number codes, I don't see why they should work in their Concorde. Since they simulate almost every aspect of the aircraft they will need a great deal many more functional controls than those offered internally by FS.

There seems to be some confusion in this thread. Perhaps you need to explain yourself a little more? I thought you wanted to receive these controls, and you can do. No need to "trap them".

Regards

Pete

[spokes2112]

Pete,

Yes, all the controls are sent to FSX.. It's whether they get processed or not by FSX. I send

DECREASE_CONCORDE_NOSE_VISOR 66295

DECREASE_CONCORDE_NOSE_VISOR_FULLY 66384

INCREASE_CONCORDE_NOSE_VISOR 66294

INCREASE_CONCORDE_NOSE_VISOR_FULLY 66383

Your logging facilities in FSUIPC see's the controls "sent" with or without parameters... But if I monitor them through my test XML gauge to "read" the control response from FSX they are all 0. Using

(A:CONCORDE NOSE ANGLE, degrees )

(A:CONCORDE VISOR NOSE HANDLE, number)

(A:CONCORDE VISOR POS PCT, percent)

UNTIL....... I change the parameter in the .air file ( Section 101, Airframe Type= ) to 5943. (Concorde) When I do this the values are read, meaning, processed by FSX. But the caveat is...

Quote - "Exception is the 'supersonic series' between 5888 and 6179. These numbers switch something like the supersonic mode on with higher thrust specific fuel consumption (TSFC), lower drag induced (CDi), and hard coded Overspeed Warnings." Using the Concorde entry induces even more problems such as pitch & roll instability, so using the Concorde entry cannot be done using the .air file I use.. Which worked just fine for the visor in FS9.

As for FSX native aircraft I have no aircraft that uses those commands.[/Quote]

So I don't undesrtannd your interest in them![/Quote]

I am working on an aircraft ported over from FS9 and donot have a native FSX aircraft with visor capabilities to compare why these anomalies occur.

As you mentioned in post #2 above. It is probably is too daunting to even try... So I hope this is a little clearer explanation even if nothing can be done.

Anyhow I have found some more information regarding airfiles that may alleviate the problem I'm having.

Thanks for this interest -AND-

The new logging facilities in 4859q !!

FS wouldn't be anywhere w/o your contributions!

Regards,

Roman

[Pete Dowson]

Your logging facilities in FSUIPC see's the controls "sent" with or without parameters... But if I monitor them through my test XML gauge to "read" the control response from FSX they are all 0. Using

(A:CONCORDE NOSE ANGLE, degrees )

(A:CONCORDE VISOR NOSE HANDLE, number)

(A:CONCORDE VISOR POS PCT, percent)

But you can see them in XML okay? Surely that's all you need. what "control response from FSX" would you expect f the aircraft loaded is not Concorde?

UNTIL....... I change the parameter in the .air file ( Section 101, Airframe Type= ) to 5943. (Concorde) When I do this the values are read, meaning, processed by FSX. But the caveat is...

Quote - "Exception is the 'supersonic series' between 5888 and 6179. These numbers switch something like the supersonic mode on with higher thrust specific fuel consumption (TSFC), lower drag induced (CDi), and hard coded Overspeed Warnings." Using the Concorde entry induces even more problems such as pitch & roll instability, so using the Concorde entry cannot be done using the .air file I use.. Which worked just fine for the visor in FS9.

Hmm. I think I understand. You actually want these controls to DO something inside FSX. Is that something you can't program in XML, then?

Regards

Pete

[spokes2112]

Pete,

After further testing, any FS9 aircraft ported over to FSX will not process ANY Visor Command UNLESS, the .air file is "aircraft type" = 5888 thru 6143 no more, no less. The same aircraft DOES process visor commands in FS9 with the same air file unmodified, any "aircraft type" number.

But you can see them in XML okay? Surely that's all you need. what "control response from FSX" would you expect f the aircraft loaded is not Concorde?

I can see the return values in XML other than null, only if, the "aircraft type" is between the above values. The reason why I'm asking all of this is that there is a primary model animation that will only work if the visor command(s) get processed..Now that above #s are known I can still go thru a bunch of testing to find a "magic" number (Other than Concorde = 5943) to see if doesn't screw up months of work on the .air file we are using.

I was just thinking that there was a "read" offset that was moved/modded/ from FS9 to FSX . The "write" (control) seems to be right.. LOL!

Thanx for your interest regarding this miniscule deal.

Roman

[Pete Dowson]

I was just thinking that there was a "read" offset that was moved/modded/ from FS9 to FSX .

Sounds more likely that someplace deep in SIM1.DLL a different black-box virtual object is chosen for different 'aircraft types'. The whole business in FSX's Sim Engine is about as obscure as you can get. I *hate* object oriented programming with a vengeance! I really gve up when they re-wrote everything that way. This is why 99.9% of everything FSUIPC does is using SimConnect.

Pete

[spokes2112]

Pete,

Thank You for at least giving some insight of "what's going on". We'll just keep plugging away thru the air file. If interested our little project it is here. - Ongoing & never ending. Day by day updates.

Roman