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.
.
Gotcha. Hard to keep up with how fast you're doing this...
That wasn't what I said was going on, reread what I wrote carefully.
I think that one's already included mate.Then here is fix for groundpower, so you dont have to waste fuel on apu: http://www.avsim.su/f/fs2004-paneli-samoletov-41/rap-115-v-scs-tu-134-a-55643.html
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.
Also, what Vlad didn't mention, the correct ground power systems are indeed missing from the plane.
Sound00=.[COLOR=#ff0000].[/COLOR]/SCS Tu-134/Sound/tumbler.wav - The way it appears in original file
[COLOR=#ff0000]^[/COLOR]
Sound00=./SCS[COLOR=#ff0000]/[/COLOR]Tu-134/Sound/tumbler.wav - The way it appears in modified file.
[COLOR=#ff0000]^
[/COLOR]
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.Code:Sound00=.[COLOR=#ff0000].[/COLOR]/SCS Tu-134/Sound/tumbler.wav - The way it appears in original file [COLOR=#ff0000]^[/COLOR] Sound00=./SCS[COLOR=#ff0000]/[/COLOR]Tu-134/Sound/tumbler.wav - The way it appears in modified file. [COLOR=#ff0000]^ [/COLOR]
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.
Then here is fix for groundpower, so you dont have to waste fuel on apu: http://www.avsim.su/f/fs2004-paneli-samoletov-41/rap-115-v-scs-tu-134-a-55643.html
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.
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 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!
Code:Sound00=.[COLOR=#ff0000].[/COLOR]/SCS Tu-134/Sound/tumbler.wav - The way it appears in original file [COLOR=#ff0000]^[/COLOR] Sound00=./SCS[COLOR=#ff0000]/[/COLOR]Tu-134/Sound/tumbler.wav - The way it appears in modified file. [COLOR=#ff0000]^ [/COLOR]
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.
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.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
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.
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:
"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.
Again: No.
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?SearchTerm=rcbse-10.zip&CatID=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 writeThe 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).
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).
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?
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).
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!
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.