FSX
NAS-1 is essential, but I guess that VOR and NDB ist the more popular navigation method, so you don't need to cover it right now.Originally Posted by vl82m
NAS-1 is essential, but I guess that VOR and NDB ist the more popular navigation method, so you don't need to cover it right now.
Well, the last update worked nice for me, this one broke the temperature control, if I add thrust and/or turn on the bleeds of the engine it goes bananas again with raising/lowering the temps, in the previous one it worked just fine. Whatever you did in the previous build concerning loading the plane cold&dark correct, this one broke it Bjoern.
Adonis/NSAdonis (depends on where).
Easy is the path to wisdom for those not blinded by themselves.
Two minor irritations:
1. I get this random clicking. The "ZZ_Selector2" seems to be playing randomly. Wouldn't be so bad if it was regular but it's irregular and OFTEN.
2. The Load/Save module is causing a stutter in my system. Every three seconds the sim pauses very briefly and if I am on an outside view it resets slightly as well -- it's a bit disconcerting.
Other than that, loving it.
I didn't do anything to the ECS.
If you're cranking open the bleeds and expect the temps to stay where they are, it's a classic ID10T error. Handle the bleeds DELICATELY.
You're not using the latest version of the modifications.
Gotcha. Hard to keep up with how fast you're doing this...
Thought I'd contribute something as well -- think of it as alternate VC textures, and as a work in progress.
That wasn't what I said was going on, reread what I wrote carefully.
Adonis/NSAdonis (depends on where).
Easy is the path to wisdom for those not blinded by themselves.
Restored the sounds for the hydraulic pumps and avionics. And added some ill fitting, but "better than nothing" windshield wiper sounds.
If you're staying in the update loop: Affected files and folders are Tu134_XML_sound.ini, Tu134_Mods and SCS\Tu-134\Sound.
Link:
https://docs.google.com/document/d/1...EgfZ6G7Q/edit#
The to-do list is getting shorter, if that's any consolation.
a) Again: I did not touch the ECS system.
b) The Load/Save-Stuff only loads and saves what is set on the dials and switches. If you think you have a screwed save, start over.
c) Keep the f'in bleeds closed on high RPMs and bring the temperature controls out of "auto".
d) The system seems to be buggy. It's written in C++ and compiled as a .dll, so I can not do anything about this at all.
I was also thinking about VC textures, they are low resolution for FSX,and most text is unreadable. I will visit a real Tu-134 and if needed can take some photos of the flight deck for photorealistic textures.
In the meantime I am thankful to Bjoern for continuing his efforts on improving the SCS Tu-134. ARK, DISS, no difference what switches on the avionics sound... as I mentioned on the real airplane there is countless of different sounds for Tu-134 for each and every system, which would be very hard to implement (not to mention almost impossible to find clean soundfiles even if you are actually in the aircraft recording each and every flip))
Alternate sounds Tu-134: http://www.avsim.su/f/fs2004-zvuki-3...ents&hl=tu-134
This returns the engine to as loud and noisy as they really once were... Brings back memories.
Then here is fix for groundpower, so you dont have to waste fuel on apu: http://www.avsim.su/f/fs2004-paneli-...4-a-55643.html
I think that one's already included mate.
a) I know you didn't directly
b) I'll try by ripping it out and seeing what happens then
c) exactly what i do. It always either shoots up or down rapidly in temperature depending on what my last command on the matter is (up or down, auto just keeps the last)
d) noted
My own addition: It worked before those additions correctly. The problem is the initial load, not the ecs system itself. The engine fuel valves on the overhead where in the up position again and wasn't previously.
The bolding is to get your attention on what is important.
Adonis/NSAdonis (depends on where).
Easy is the path to wisdom for those not blinded by themselves.
Hello Bjoern,
Last night me and Adonis performed several tests on the SCS Tu-134 lasting a little over 2 hours. As a conclusion we did find a very big bug regarding the state the airplane loads in.
Basically, Russian designed aircraft for MSFS needs to be loaded in a certain panel state to initialize correctly. And in the present version, the aircraft does not load correctly when you first load the aircraft. And the problem is rather simple. If the aircraft does not load correctly then there is several vital systems that will not function properly such as electrics, hydraulics (brake), and ventilation system.
You can identify the initialization failure by observing on the overhead panel that the fuel valves are in the "up" position, when they are supposed to be down. This in the real aircraft is not possible and indicates that the aircraft has failed to load as it should. Of course, you can ignore the fuel valves being in the wrong position but if switches all over the place, once again, the airplane has not loaded correctly and more bugs will appear in the long run.
The cause:
What's more interesting to note, is the fact that the incorrect initialization of the aircraft is dependant on "Tu134_XML_sound.ini". An earlier version of Tu134_XML_sound.ini with less sounds than the latest version of the file, actually loads the aircraft just fine. This is very strange for us and it made us scratch our heads. Probably one or several of the sounds might be blocking the incorrect initialization of the plane, or similar.
Basically, this sound ini loads airplane correctly: https://yadi.sk/i/wPeDGGNDgUX6i
And this sound ini breaks the correct initialization of the airplane (it is your latest version, i just renamed it as my cloud cant host two files of the same name): https://yadi.sk/i/0B_ZkTU6gUXRK
I hope you will look into this issue, as if this fault is solved, I believe many of our troubles will be over. Also since Soviet aircraft for MSFS is very complex, it would be better to not mess with the code programming load/save gauges. The code for these airplanes were designed to be left as it is and breaks easily if you implement such gauges. The unstable code is the reason why nobody before has implemented such utilities or even third party GPS bundled to the autopilot... It is risky, and could end up breaking the aircraft.
Apart from the strange issue with sounds causing incorrect initialization, it would be good if you found a way to return the 2D panels from the FS9 version to the FSX. It is not very difficult and you have the panel.cfg as reference. All the necessary files you have on the following file: https://yadi.sk/d/Ou764UCIcNiUf
The mayor reason why the 2D panels should be reimplemented is very important. Simply, there is a lot of gauges and switches from 2D not available in 3D, and now the most important reason: Complex Russian aircraft designed for MSFS always must load first in 2D panels (never from the VC!) in order to correctly setup and initialize all the panels! If you load from VC, some systems will not correctly initialize, and thus we have bugs!
Why the original team porting the SCS Tu-134 from FS9 to FSX did not include the vital 2D panels I do not know. I guess it was just out of pure lazyness, or as discussed with Adonis, some people do not think 2D panels are important forgetting they are needed to load the plane correctly.
I hope my explanations were clear, and if you have skype, I would be more than happy to show you video sharing of my screen to describe exactly what kind of issues we have. It's very simple ones, nothing mayor fortunately.
P.S, this is not a demand, but a request. I can understand it might be a bit daunting to solve all these issues so take your time... At least, I know it would be difficult for me.
Last edited by vl82m; May 7th, 2015 at 00:45.
Also, what Vlad didn't mention, the correct ground power systems are indeed missing from the plane.
Adonis/NSAdonis (depends on where).
Easy is the path to wisdom for those not blinded by themselves.
That's exactly why I posted the ground power fix above... But let's focus on the more important issues such as correct initialization and 2D panels, which are vital for the correct loading of the plane.
Code:Sound00=../SCS Tu-134/Sound/tumbler.wav - The way it appears in original file ^ Sound00=./SCS/Tu-134/Sound/tumbler.wav - The way it appears in modified file. ^
Depending on what the installed folder structure looks like, try adding the additional period as in original and replacing the "/" after SCS with a space. I don't have this plane installed, so cannot check what the folder structure is.
Matt
As far as I can gather the problem seems to be a combination of sounds loading first and/or missing and the lack of 2D panels for the preload.
Adonis/NSAdonis (depends on where).
Easy is the path to wisdom for those not blinded by themselves.
RAP115V is for the ground power?
I think I had a look at the code of the fixed gauge a while ago, but could not really figure out where the improvments were. What is the RAP 115V supposed to do and which switches are involved?
According to the comments, this is the correct version by the way:
http://www.avsim.su/f/fs2004-paneli-...4-a-55642.html
The fuel valve switches do not use any custom code, but are directly connected to the Flight Simulator systems.
By default, the Tu-134 will set these valves to "Off" when the plane is initially loaded.
This is problematic if you want to load the plane from a saved flight in the air as the engines will shut off. Therefor, the code must be removed if one wants to use the Load/Save system.
The same applied to the cutoff levers (ROD), by the way. They are setting the mixture to "lean" when initially loaded, so they also will make th engines seize.
Tu134_XML_sound.ini only links sound-related L: variables to sound files in the "SCS" folder. The control logic for the sound is in "Tu134_Mods\Tu134_XML_Sound_Control.xml", but it does NOT SET any internal system variable, it does ONLY READ them.What's more interesting to note, is the fact that the incorrect initialization of the aircraft is dependant on "Tu134_XML_sound.ini". An earlier version of Tu134_XML_sound.ini with less sounds than the latest version of the file, actually loads the aircraft just fine. This is very strange for us and it made us scratch our heads. Probably one or several of the sounds might be blocking the incorrect initialization of the plane, or similar.
I have taken a shot in the dark and renamed the sound variable related to the "Connect_Lock" button as this is the only major difference between the .ini files (the rest is the default hydraulic pump, avionics sound, etc...).I hope you will look into this issue, as if this fault is solved, I believe many of our troubles will be over.
The only reason why no one has implemented GPS support is because the team tried too hard to work oustide the MSFS systems. Had they actually taken a bigger effort to work WITH the possibilities of the default systems, implementing a "follow GPS" function would have been possible.Also since Soviet aircraft for MSFS is very complex, it would be better to not mess with the code programming load/save gauges. The code for these airplanes were designed to be left as it is and breaks easily if you implement such gauges. The unstable code is the reason why nobody before has implemented such utilities or even third party GPS bundled to the autopilot... It is risky, and could end up breaking the aircraft.
I can't blame them for trying to go around the default stuff as much as possible, but it actually has more potential for bugs than simply working with it.
And since the majority of code is XML, I can, and will, mess with the code.
If the SKV system continues to act up, I might even code a (simpler) XML version of it.
Nyet. No 2D panels. They are too different from the VC model and you will have to point out any specific differences between them in the manual.Apart from the strange issue with sounds causing incorrect initialization, it would be good if you found a way to return the 2D panels from the FS9 version to the FSX. It is not very difficult and you have the panel.cfg as reference. All the necessary files you have on the following file: https://yadi.sk/d/Ou764UCIcNiUf
The Tu134 is not really complex. The code is a bit hard to read in places, but it is everything but awfully complex. With enough time, one might even be able to fix and work around every bug there is. But for that, you would have to work around the .gau and .dll files still used by the aircraft.The mayor reason why the 2D panels should be reimplemented is very important. Simply, there is a lot of gauges and switches from 2D not available in 3D, and now the most important reason: Complex Russian aircraft designed for MSFS always must load first in 2D panels (never from the VC!) in order to correctly setup and initialize all the panels! If you load from VC, some systems will not correctly initialize, and thus we have bugs!
One difference I have noticed in the FS9 version is that "scs_tu134sys.gau" is only used in the 2D panel, not in the VC. This might very well be the reason why you have to load the 2D panel before loading the VC. The gauge is absent from the FSX version. So maybe there's the reason for all your bugs.
Here is scs_tu134sys.gau.
Add the entry to the [VCockpit01] section of the panel.cfg and see if it improves things:
Code:gauge52=scs_tu134sys!system, 0,0,1,1
For what it's worth and as long as you guys keep the angry SCS team off my back, I could also upload a complete package of the 134.
The slashes and backslashes used in the paths are fine in the .ini file that I've uploaded. The sound gauge doesn't care whether paths are using slashes or backslashes, so you've got both flavors in the file. Missing slashes must indicate some issue with the text editor used (I use Notepad2) or erroneous unzipping or whatever.
I'll try this out. Mind you, before you go into complexities and what is and isn't a bug, have a long chat with Vlad about the plane. Some of those "bugs" can easily be due to your lack of understanding of how Russian planes work (like most westerners do and call out bugs where there aren't any). He knows the Tu-134, been around real ones. I have packed him up the missing stuff from the FS9 version to send to you so you can put it back together out of the simple fact that it might lead you actually fixing the sounds adequately.
Second: you didn't understand him about the sound.xml, let me clarify: What the two of us think is happening is that your sound gauge is preventing the correct functioning of the panel preload into cold and dark, maybe because it is loading prior to something vital.
My honest suggestion would be to put the 2D panels back together, so you can see if that will make your life easier in fixing the sound issues and the correct loading of the planes panel. We could then connect the 2D panel stuff into the VC I'm gonna make and diss the current one completely so it could work correctly.
Adonis/NSAdonis (depends on where).
Easy is the path to wisdom for those not blinded by themselves.
First of all, I am not installing missing stuff from the FS9 version. I have the original 2.0 release right here and it is buggy as hell in FSX without some modifications. What the original team did to adapt it to FSX was sensible (see below).
Second, it does not matter if it is a russian plane or a western plane. This is a simulator with limited capabilities and you can only do so much to get its systems into FSX. Especially when using XML, which the SCS team did to a very large extent.
For the last time:Second: you didn't understand him about the sound.xml, let me clarify: What the two of us think is happening is that your sound gauge is preventing the correct functioning of the panel preload into cold and dark, maybe because it is loading prior to something vital.
"Full" cold and dark was INTENTIONALLY DISABLED by me to PREVENT THE ENGINES FROM SHUTTING DOWN. I do not want the default cold and dark logic to be active because it is highly annyoing to have to operate dozens of switches every time that I reload the plane (which I have to do every few seconds when writing new gauge logic) just to start the engines.
And the reason you're seeing the plane in a cold and dark state at the beginning is because it is using a ton of L: type variables. MSFS can not save the last known state of these variables by default and thus will initialize them with a value of "0" ("Off" in most cases).
Now guess where the Load/Save module comes in?
Again: No.My honest suggestion would be to put the 2D panels back together, so you can see if that will make your life easier in fixing the sound issues and the correct loading of the planes panel. We could then connect the 2D panel stuff into the VC I'm gonna make and diss the current one completely so it could work correctly.
For what it's worth, here are the differences in gauges between the FS9 and modified FSX releases:
- SCS_Tu134_ELEC\hydr_system.xml:
Removed the initialization condition for the brake failure. Reason: ??? Note: I've had to use a workaround to fix the brakes due to the original logic not working reliably.
- SCS_Tu134_VC\vc_handle.xml:
Removed all references to (>K:Afterburner1) and (>K:Afterburner2) which are used for toggling the switch sounds in FS9. If used in FSX, these bits of code will make the respective engine spool up whenever you click something. This only applies to the VC; the bug is still present in the 2D panel! (<- Potential reason for the removal of the 2D panel!)
- SCS_Tu134\2077.xml:
Removed the clickspot for closing the panel. Reason: ???
- SCS_Tu134\msrp.xml:
Removed all references to Afterburner1 and Afterburner2
- SCS_Tu134\idr.xml:
More explicit conditions for the KPPM (DME?) logic, corrected typographical errors, changed some things to be more easily readble ("and" instead of "&&")
- SCS_Tu134\Main_Processor.xml:
Changed K: vars that control the landing light retraction. This uses MSFS' "Concorde Visor" function, probably an attempt at a fix. I have fixed this in the .air file and it is working perfectly now.
Added an entire section for the navigation system. From the variable names, this looks like the autoland logic. Also includes the functionality for "Test SVK".
Added a line of code for the landing light retraction. Reason probably again an attempt at a fix.
Added a section for starting the engine. Engine start works.
Added a section for making DISS dependant on the availability of 115V current.
Added a section that adds functionality to the "Steering 55" switch.
- SCS_Tu134\ap_sys.xml:
Not present in the FSX version. Contains the logic for the autopilot system. I can confirm the autopilot as working.
The following are all related to the SKV control panel...
- SCS_Tu134\apu_bleed.xml:
Removed all references to Afterburner1 and Afterburner2
- SCS_Tu134\ext_vent.xml:
Removed all references to Afterburner1 and Afterburner2
- SCS_Tu134\sw_depress.xml:
Removed all references to Afterburner1 and Afterburner2
- SCS_Tu134\sw_art_power.xml:
Removed all references to Afterburner1 and Afterburner2
- SCS_Tu134\tue_galet.xml:
Removed all references to Afterburner1 and Afterburner2
panel.cfg:
Apart from the 2D panel removal: All gauges that are providing background logic for the systems and were used on the 2D panel are in the [VCockpit01] section now. These gauges are the exact same reason why you HAD to load the 2D panel with the FS9 version! The [VCockpit] section is always refreshed by FSX, so with them being present in [VCockpit01], they are always used and always updated.
So there is absolutely no reason for a 2D panel now to properly initialize the systems.
Model files:
SCS Tu-134A\Model.A3_VCcabin\tu-134.mdl: Apart from being the only model file, it has a different date of creation, but is the same size. So it's probably nothing.
Aircraft.cfg:
- More [fltsim.x] entries due to more included repaints.
- Smokesystem coordinates have been fixed for FSX
- Fuel tank location and capacity changed
- Steering angle for the nosewheel changed
- Fuel_flow_gain (controls engine spool time) changed
- Engine thrust changed
- Autopilot section expanded, but the autopilot stays disabled
- Stronger brakes
- Removed autobrakes
- Flap positions like on the real aircraft
(The only thing that's referenced in the FSX panel.cfg, but missing, is "rcb-gauges!SelectCorrect", which is fixing engine or door selection. Download it here if you need it:
http://library.avsim.net/search.php?...root&Go=Search)
I'm sending you two my uncleaned development-tool-ridden version. If the bug with the sound system persists in this one, something is wrong with your computers or your FSX.
Actually, incorrect. The logic of operation is different to western planes and has nothing to do with FS9/FSX limitations. Most of the battery disconnects are actually caused by incorrect handling of the elec panel for example. As I said, speak with Vlad on skype about how the plane should function and be handled and don't jump to conclusions so easy.
That actually doesn't change my point tho. If you need it that way for testing purposes, it might actually mess around with your debugging.
If you happen to include that particular state in the updates you give us, could you remove it for them at least so we get a proper full cold&dark?
I'm not asking you to throw in the FS9 gauges into the FSX version, but to rebuild the 2D panels using the gauges that are present in the FSX one. Please, read more carefully what I write :P The only missing gauges besides the scs_tu134_sys.gau is the panel menu, 2D version of the Yoke system, a measure gauge, and the clock that got replaced in the FSX one with a different build it seems (or integrated into the folders present).
Noted on the afterburner thing.
That's because the FS9 version's 2D panels have closing clickspots to make closing the windows easier. Has really no bearing without the actual 2D panels being present in the FSX version really (it does exist in my one through the SKV fix that was posted on the avsim.su forum that brought back the flight attendant sounds).
Noted.
KPPM is the RMI gauge. This actually might potentially have bad consequences.
The "("and" instead of "&&")" is actually the non-unicode chars not showing up correctly. It can be fixed by setting the non-unicode language in language settings to Russian (just so you know why that's showing up that way with the && thing).
-The 1.2 version of the plane actually used the Concorde visor commands for the extension, dunno if they changed it for v2.
-Actually, the Tu-134 lacks autoland capability completely and shouldn't have it. It follows ILS LOC and glideslopes worse than the 1.2 version did (which mind you, wasn't perfect either, but didn't drift nearly as much, this actually could be the reason of the missing ap_sys.xml now that you mention it's absence).
Noted.
Add to that that I have already indicated that the FS9's fuel and load points I got back, since the FSX's ones where off compared to the fuel calculator and that the stock FSX payload points weren't as, let's say descriptive.
You sure about this?
I'll test those versions out and let you know what I find.
Another missing thing is the clickspot between the plane icon and the green light that indicates system work on the LBU gauge (NAS-1 Lateral Deviation and Automatic Control gauge) that's used to reset the deviation to zero (this omission is actually functionally very important mind you). Also, this gauge sometime misbehaves with the angle selection and only can do full degrees, original could do 0.5 degs.
Also the two RSBN code selector rotaries have strange clickspots (I doubt this one can be fixed tho without porting of the VC model anew - correct me if I'm wrong).
The radio source selector on the Captains side panel (the bottom black gauge) is also clickable but you cannot change it's selection (and it's working on the FS9 one, there a copy on the Navigator position (right of the RSBN) that isn't working tho in FS9).
The only remaining issue besides all this is the SKV not working correctly (10+ deg gains/losses of temperature in about 10 seconds which should blow the plane up in reality) when the engine fuel valves are open on load. This doesn't happen (it does change, but gradually as you should expect) with the panels I sent Vlad to test since it loads the C&D correctly by what you said now and doesn't have brake issues (but on Vlad's PC it does which gets fixed by a failure clear).
I'll let Vlad chime in with anything else he might want to add.
Last edited by Adonis; May 7th, 2015 at 18:17.
Adonis/NSAdonis (depends on where).
Easy is the path to wisdom for those not blinded by themselves.
First things first:
KPPM is the navigators VOR/RSBN/ILS course and glide-slope indicator. I ask, please nobody touch this gauge until further notice. If this one is repaired incorrectly or modified, the very complicated RSBN might cease to function with it! If any questions about this gauge, please ask me before modifying. Just for everyones information, this is not a DME. If modified to a DME, please revert!
Anyone wishing to modify the airplane, please I ask, do not touch the navigation system. It is very complex and if changes made you might end up breaking the very complex NAS-1 and RSBN-2 navigation systems because you don't know what you're doing!
About fuel system, there exists fuel calculator with the FS9 version of the plane. If any modifications to fuel tanks, please keep the original parametres so we can still use fuel calculator! This saves massive time instead of manually calculating fuel! Most importantly, let's keep the original fuel burn parametres so the calculator calculates the correct amount!
Check chapter "7.4 Fuel planning for the lazy" in my manual to learn what it is about.
And then the following information from Adonis I approve:
"If you happen to include that particular state in the updates you give us, could you remove it for them at least so we get a proper full cold&dark?"
"The radio source selector on the Captains side panel (the bottom black gauge) is also clickable but you cannot change it's selection (and it's working on the FS9 one, there a copy on the Navigator position (right of the RSBN) that isn't working tho in FS9)."
I know there are other bugs, but as I do not want anyone to touch the navigation system yet, let's leave it be.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
I will perform test flights SVO-LED and back testing both RSBN and NAS-1 systems on Saturday. If they work proper, I will provide feedback, and most likely it won't have to be changed. Reason why Saturday is because then I am not at work. Hopefully everything works and navigation system won't have to be modified at all.
My only real concern about the ADI (Attitude indicator) is the small ILS/VOR needles... very hard to see. This is the only thing that could be great to have fixed regarding navigation for the moment.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
I do not want anyone to be offended by the fact I told not to modify navigation system. I'm already writing navigation section on the manual (NAS-1 to start with, and if anyone wants to learn one-to-one training in the simulator just let me know!). In the end, NAS-1 and RSBN should be familiar to everyone, and then we can begin to try and fix the nav system once we all have proper knowledge on how it works.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
I repeat, if anybody has a question, or think something is a bug, please ask me so that I can confirm whether this "bug" is really a bug or just a feature in Russian airplanes!
Last edited by vl82m; May 8th, 2015 at 01:21.
As long as keep a few things in mind, the electrical system is actually very docile...
Dead radios are caused by the MSFS-internal battery draining because the MSFS-internal alternators are - by default - not connected to the MSFS-internal engines. That was my very first fix and the generators are now always active. The battery will still drain if the engines are not running.
The systems and indicators freezing up despite there being elelctrical power is either due to a bug or due to generator overload. In any case, the "Connect Lock" button on the elctrical panel will fix it.
If you've got too much stuff on the electrical buses you can't start up the APU anymore, but that's okay if kept in mind during operation.
Roll back the edits you need to do for the Load/Save mod if you actually want that stuff back in.That actually doesn't change my point tho. If you need it that way for testing purposes, it might actually mess around with your debugging.
If you happen to include that particular state in the updates you give us, could you remove it for them at least so we get a proper full cold&dark?
I won't touch it.
For the last time: I AM NOT REBUILDING THE F'IN 2D PANELS. End of discussion.I'm not asking you to throw in the FS9 gauges into the FSX version, but to rebuild the 2D panels using the gauges that are present in the FSX one. Please, read more carefully what I write :P The only missing gauges besides the scs_tu134_sys.gau is the panel menu, 2D version of the Yoke system, a measure gauge, and the clock that got replaced in the FSX one with a different build it seems (or integrated into the folders present).
I doubt it. It was an edit akin to replacing "(Variable) 0 > if{...}els{...}" with "(Variable) 1 == if{...} (Variable) 0 == if{...}". Same result, but more explicitly expressed.KPPM is the RMI gauge. This actually might potentially have bad consequences.
Whatever the motivation for the original edit, I totally concur with it. I've never liked writing "||" for "or" and "&&" for "and".The "("and" instead of "&&")" is actually the non-unicode chars not showing up correctly. It can be fixed by setting the non-unicode language in language settings to Russian (just so you know why that's showing up that way with the && thing).
Nope, didn't change. Quite peculiar as one could have simply used a custom animation powered by an "L:" var. But I don't mind, it's fixed now.-The 1.2 version of the plane actually used the Concorde visor commands for the extension, dunno if they changed it for v2.
I'm still not much of a fan for going a completely separate route from the default MSFS autopilot systems (as they have very good PID controllers), but whoever did this did a commendable job because autoland works.-Actually, the Tu-134 lacks autoland capability completely and shouldn't have it. It follows ILS LOC and glideslopes worse than the 1.2 version did (which mind you, wasn't perfect either, but didn't drift nearly as much, this actually could be the reason of the missing ap_sys.xml now that you mention it's absence).
Payload points did not change from the FS9 version.Add to that that I have already indicated that the FS9's fuel and load points I got back, since the FSX's ones where off compared to the fuel calculator and that the stock FSX payload points weren't as, let's say descriptive.
235.789%. Look up the gauge, read its description.You sure about this?
I'll test those versions out and let you know what I find.
The v2.0 release and subsequently the FSX version did not have the clickspot either.Another missing thing is the clickspot between the plane icon and the green light that indicates system work on the LBU gauge (NAS-1 Lateral Deviation and Automatic Control gauge) that's used to reset the deviation to zero (this omission is actually functionally very important mind you). Also, this gauge sometime misbehaves with the angle selection and only can do full degrees, original could do 0.5 degs.
The 2D version has a clickspot in the middle now, the 3D version's selector has to be right-clicked. Both can do 0.5 km increments now.
Nope, can't be fixed. The clickspots are invisible polygons in the model file.Also the two RSBN code selector rotaries have strange clickspots (I doubt this one can be fixed tho without porting of the VC model anew - correct me if I'm wrong).
Native FSX models (*) could simply declare the entire selector as clickable without any tricks.
*Probably FS9 models as well. It's been a while.
It's clickable alright, but it doesn't seem to affect any variable.The radio source selector on the Captains side panel (the bottom black gauge) is also clickable but you cannot change it's selection (and it's working on the FS9 one, there a copy on the Navigator position (right of the RSBN) that isn't working tho in FS9).
Repeating myself: I am not seeing the temperature spikes and my plane gets loaded with the valves open all the time.The only remaining issue besides all this is the SKV not working correctly (10+ deg gains/losses of temperature in about 10 seconds which should blow the plane up in reality) when the engine fuel valves are open on load. This doesn't happen (it does change, but gradually as you should expect) with the panels I sent Vlad to test since it loads the C&D correctly by what you said now and doesn't have brake issues (but on Vlad's PC it does which gets fixed by a failure clear).
If I can't reproduce a bug, I can't fix it.
The edits to the gauge were harmeless and not affecting the way it operates.
My only real concern about the ADI (Attitude indicator) is the small ILS/VOR needles... very hard to see. This is the only thing that could be great to have fixed regarding navigation for the moment.
The needles are a feature of the model and can not be changed.
I do not want to touch the navigation system anyway.I do not want anyone to be offended by the fact I told not to modify navigation system. I'm already writing navigation section on the manual (NAS-1 to start with, and if anyone wants to learn one-to-one training in the simulator just let me know!). In the end, NAS-1 and RSBN should be familiar to everyone, and then we can begin to try and fix the nav system once we all have proper knowledge on how it works.
What's the "to do" list?
Members who have read this thread: 3
Posting Permissions
Bookmarks