Project Soyuz 7K-T Custom

Gargantua2024

The Desktop Orbinaut
Joined
Oct 14, 2016
Messages
870
Reaction score
1,009
Points
108
Location
San Jose Del Monte, Bulacan
Indeed, since all subsequent solo flights of the 7K-T variant (except Soyuz 13 because that too had solar arrays) never last beyond 2 days because of chemical battery limitations. It might be that Cosmos 496's service module was even a leftover 7K-OK or 7K-OKS hardware
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,268
Reaction score
231
Points
78
Yeah, that's what it sounds like, Soyuz book mentions it was an already built ship (number 33 I think it was). Some post Soyuz 11 modifications, but removing solar wouldn't be as simple as just removing the arrays on a finished ship.
I'm guessing Zak there just assumed it had none and power saving sounds plausible enough to explain 6 days. Chertok is inconclusive on this too.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,268
Reaction score
231
Points
78
Some more thoughts (I like dropping info all in one place as I find it in case someone out there Googling finds it helpful, considering how spread out it is online):

For one, I've settled on operating voltage range between 34 V down to 23 V. This was so for Soyuz-TM and it probably did not change. Silver-zinc also seems to be known for a pretty flat voltage curve, so I've estimated that down to 10% charge left, at which point it drops much faster from 32 V to 23 V. Also as far as -TM goes, the warnings seem to go off when 24.3 V is reached, seems reasonable for 7K-T as well.

Found a curious thing: Soyuz-TM solar panels are stated to output 26 A at 34 V at a maximum. So 0.88 kW, just a bit over Astronautix's claimed 0.84 kW average consumption. Seems a bit too close to be a coincidence, even being completely different ship generations, my first guess is that allows it to meet the max power demands and have some left over to charge the buffer battery. For 7K-OK Chertok mentions 23 to 25 A needed to charge the battery, which I'm interpreting as "worst case, maximum power drain isn't above 850 W (25 A at 34 V)".
7K-T of course has no solar panels so charging is irrelevant, but I can extract info from it. So feeling a bit more confident about picking 0.84 kW, or something in the ballpark, as the base consumption rate on top of which I can add the equivalent for certain systems, like SSVP or IKP, when on. Having an actual value makes it easier for the individual systems I do have numbers for.

On that note, the INT dial now displays the current voltage, as calculated from the current battery charge, low voltage signal is tuned for 24.3 V on the main battery, and main, backup and SA batteries are in the code. Battery life is just a bit under 48h currently, not counting the backup battery, and SA battery is similar to the backup in capacity.
Next is actually making main and backup interchangeable for when main is about to die, working in the consumption variations I have for the moment, and ultimately the nuclear option: power goes out, ship is dead. Dead electronically that is, switches still move and of course, backup battery can still be connected from a dead main battery (independent bus).

1666753108044.png
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
200
Reaction score
69
Points
28
Location
Bangkok
Hi Diogon,

i am trying to follow your flight tutorial ... really helpful, almost managed to do a full mission, but still something i am doing wrong, so please if you could explain i would be highly appreciated.

1) when you need to set the orbital period in the "globe" ... i saw that in the pdf manual you can control/set also the decimals after the minutes (the 2 red digits), but both using the english / russian text i don't get these two digits to appear ...is a my computer graphic issues? maybe screen resolution?

2) about setting the "globe" once in orbit...not sure if i am doing correctly: once in orbit i open mapMFD and i read off the lat/long position, than i move the globe with the inner/outer knob to have the crossair to the same approx lat/ong (=as written in the globe chart (the grating...)) .... and i also see if they coincide with the values displayed on the globe lat / long indicators (left/top) ... is ok doing like that?

3) didn't get how to engage "orientation to the sun" via M-16 command: basically once in orbit i enter into prograde attitude, once the orientation is established i get sensors errors 1 deg, than i switch the mode off via K-2, i wait to be in day light to see the sun and i do: K-4 to activate the BDUS and then M-16, in the HUD i got the message that the soyuz is rotating to acquire the sun but it seems never enter into the attitude, it keep slowly spinning and i never see the "45K aligned" message ... do i need to be in free drift with all rates to 0-0-0 deg/sec before to engage this mode? or am i not engaging the program K-4 correctly?

3) how to use P-6? when i am suppose to use it? you didn't mention it in the manual as well as in the flight doc but i saw you add it in your command matrix...

5) about the rendezvous ... i am practicing using the scenario you provided at approx. 100km distance ... at 30 km i engage the igla for approach ... i saw it fires thrusters and it Chage orientation but i arrived at approx. 5-6 km with still more than 20 m/s velocity and it didn't null it, basically i just miss the salyut .... the breaking burn (to null the relative velocity) was supposed to be done by the igla ? of should i fire the SKDU manually ? if so, when? (i guess it may also be a my computer issues, as i saw that with the vizor implemented i now have very low fps ... ) .... i loaded that scenario with the two vessel docked, i undock and go away few kms than i engage the igla and try the approach again and this time it docked. So maybe i am missing a manually activate SKDU burn , after the one done to intercept the salyut with transX?

thank you for any suggestions.
nice craft...
 

Attachments

  • test 1.JPG
    test 1.JPG
    11.2 KB · Views: 4
  • red digits in manual.JPG
    red digits in manual.JPG
    11.6 KB · Views: 4
  • russian no red digits.JPG
    russian no red digits.JPG
    16.3 KB · Views: 4

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,268
Reaction score
231
Points
78
Hey, thanks for the feedback

1) when you need to set the orbital period in the "globe" ... i saw that in the pdf manual you can control/set also the decimals after the minutes (the 2 red digits), but both using the english / russian text i don't get these two digits to appear ...is a my computer graphic issues? maybe screen resolution?

This one is weird. I've been somewhat dreading resolution issues, since I'm testing on one machine/screen only. It's 1080p but I run it windowed at slightly less than full screen. But not sure yet if that explains it, the first counter looks fine. As I understand it, Orbiter operates on the fixed size textures. Just to be sure, this is with D3D9 right? And it's just for the period counters? So the rest of the globe instrument, the clock's elapsed time counters, digital unit's Delta-V counter, all good?
Edit: actually, even the "90" is missing the contour around the digits, which should be fixed in the texture. Can you confirm if this bit of "Sirius7k_Dynamic_Displays.dds" in Textures\Sirius_7k\ looks like this? You might need something like Paint.NET to open it. Maybe there's some conflict with an older version of the texture.

1667062932182.png

2) about setting the "globe" once in orbit...not sure if i am doing correctly: once in orbit i open mapMFD and i read off the lat/long position, than i move the globe with the inner/outer knob to have the crossair to the same approx lat/ong (=as written in the globe chart (the grating...)) .... and i also see if they coincide with the values displayed on the globe lat / long indicators (left/top) ... is ok doing like that?

Yeah, that. In real life I guess all they had was looking out of the windows/vzor, and it kinda helps that it's a fixed inclination, so it's a matter of "how far in a straight line from Tyuratam are we". But that's not always easy even in Orbiter without MapMFD. Especially since the Soyuz 18-1 scenario launches into a sunset.

3) didn't get how to engage "orientation to the sun" via M-16 command: basically once in orbit i enter into prograde attitude, once the orientation is established i get sensors errors 1 deg, than i switch the mode off via K-2, i wait to be in day light to see the sun and i do: K-4 to activate the BDUS and then M-16, in the HUD i got the message that the soyuz is rotating to acquire the sun but it seems never enter into the attitude, it keep slowly spinning and i never see the "45K aligned" message ... do i need to be in free drift with all rates to 0-0-0 deg/sec before to engage this mode? or am i not engaging the program K-4 correctly?

I'd recommend killing rotation before turning on any of the orientation modes. If that doesn't help, stopping the program (K-1 modes off), killing rotation and re-starting might work. First step is a pitch rotation until the ship's +Y (side facing away from Earth on prograde mode) is within 90 degrees of the sun. Then it aligns the roll channel, and finally does pitch again until it's within 6º of the sun. There's a chance one of these thresholds might fail, and so far I haven't been quite able to reproduce it consistently, but when it has happened reseting helped.

3) how to use P-6? when i am suppose to use it? you didn't mention it in the manual as well as in the flight doc but i saw you add it in your command matrix...

Thanks for pointing it out, forgot to leave a note in. But for now it's very minimal. Basically, depending on whether the Free Gyros ("off") or BDUS ("on") are selected, the maximum deviation in attitude when the Inertial Orientation mode is on is either 8º or 6º, respectively (if that is exceeded, the mode is automatically switched off). In theory, since Inertial actually corrects the attitude in pitch/roll/yaw when each changes by more than 2º, this condition should never be reached. I'm still not sure from what I've read if Inertial actually corrected back, or simply stopped rotation over a certain threshold, and over time an error would accumulate and reach either 6º or 8º, at which point you would need to re-orient the ship. Lately I've been leaning towards the latter.

Anyway, whenever programmed manoeuvres (in attitude) are implemented this will play a bigger role, since choosing one or the other had an effect on how quickly it rotated, and for example with the free gyros the manoeuvres were done only in roll and yaw.

5) about the rendezvous ... i am practicing using the scenario you provided at approx. 100km distance ... at 30 km i engage the igla for approach ... i saw it fires thrusters and it Chage orientation but i arrived at approx. 5-6 km with still more than 20 m/s velocity and it didn't null it, basically i just miss the salyut .... the breaking burn (to null the relative velocity) was supposed to be done by the igla ? of should i fire the SKDU manually ? if so, when? (i guess it may also be a my computer issues, as i saw that with the vizor implemented i now have very low fps ... ) .... i loaded that scenario with the two vessel docked, i undock and go away few kms than i engage the igla and try the approach again and this time it docked. So maybe i am missing a manually activate SKDU burn , after the one done to intercept the salyut with transX?

Yes, my code is too realistic, it even simulates Igla unreliability :D
No, I've since noticed this too, and yes, Igla should be full auto.
For the last version I changed the scenarios a bit to have Salyut a bit further away on launch time, but the pre-rendezvous scenario is still based on the older case. So since Igla was working every attempt on that one, I figured it was ok since the flight profile would always be very similar (foolish, I know). But the other day I did a flight from launch with the new Salyut position, started the approach under seemingly the same conditions (transX setup, phasing orbit of 250 km, approach from below, Igla on at 30 km) and Igla just refused to do any burns. I think it's skipping something in the sequence and probably "thinks" it's already done a burn or two which it didn't. I'll need to setup a convenient scenario to reproduce it and debug it. During the approach, up until 1 km or so, how do the "Burn_seq" and "LOS burns values change?

I'd have to double check during approach specifically, but I've been mostly keeping stable 60fps. I've been concerned if some things might break at lower frames, and don't want to discard that, but since we apparently had the same issue, frame rate might not be the issue here. Hopefully. I'd expect thruster burns to be less accurate but not cease to exist. But it is strange you get it on a scenario which for me works, since in that case the initial conditions are the same (speed, trajectory).

The battery stuff is mostly done for now, IKP was the plan next but since discovering that and if it's also happening to others, I think I'll tackle Igla next, can't stay like this. I was going to revisit it anyway, since right now the way the relative velocity is calculated is very sensitive to rotation, which leads to high and false readings during rotations. I'd also like to eventually review the orientation autopilots, since they were done pretty early on and I might be able to do a bit better.
 
Last edited:

thermocalc

Active member
Joined
Aug 18, 2014
Messages
200
Reaction score
69
Points
28
Location
Bangkok
Hi Diogon,

Thank you for your fast reply, I am not so fast as you …

1) About the globe and missing red digits … thanks to your guide I find out what I was doing wrong; I just reinstalled a new orbiter 2016 + your new version and everything is ok, I get the red digits to set the decimals part of the orbital period both using Russian and English cockpit (before I just unzipped your new version on my old installation, so some files were not properly copied/updated) ... basically i saw that in the texture folder there is only a english folder, containing not all files resident in the texture folder itself; in my case i saw a russian folder (=meaning that i did it, coping all russian files, before to copy the english files into the texture folder, but i also saw that the file with the digits is not in the english folder, so it was supposed not to be changed, as i didn't realise it, when the new revision come out i immidiatly copied the english folder and so i overwrite the new file with red digits with the old one, and even going back to russian i was still coping the old file without red digits....sorry for the confusion.

2) ok, thanks to confirm.

3) ok, indeed calling mode-off and killing rotations than solar orientation did engaged.
I realized that when it got mad I was in orbital orientation established in orbital pitch rate, than I called mode-off but of course the angular rates were not zeroed … upon zeroing them and go to solar orientation everything worked as you said … thanks.

4) about the gyros and BDUS … sorry, it WAS described in the new manual, I just missed it, so you didn’t forget to mention it, I just missed to read it, now everything is clearer

5) ok…I will try to re-check the scenario and I will also try to plan the rendezvous from lift off and I will let you know…maybe it will take me few days to try it out…
about the flight guidance modes: .... I did see that when the igla was running there were some sort of “sequence numbers” … I remember to have seen 3 and 8 I guess … is it possible for you to explain which number correspond to which phase? So I may try to follow more closely what igla is doing at each step?
Anyway, I will try again and report to you all events.

Nice to see the battery is almost over and you were already thinking to implement the programs…that’s would be really nice.

A side question about SKD DV burns …. I saw that once you know how much DV you need to burn, say 30 m/s, by activating the accelerometer and firing the SKD when the accumulated DV in the HUD get to 30 m/s you may cut off the engine; but all this is done looking at the HUD … how this “cut off” was supposed to be performed by the crew? Using the programs that you were mentioning you are going to implement?
Or were you suppose to set the DV in the DV counter next to the reserve DV counter (i saw that it is set to 50.5 but the number can be changed with the knob below, but it never change upon firing the SKD) and upon ignition it was supposed to count down to zero, signaling the crew when to cut off the engine? or the engine was automatically cut off?

very weird automation/avionic compared to Gemini/Apollo S/C back then ... still i am amazed by the simplicity of the cockpit and instrumentation design, so that after all they were using much more automation than US spacecrafts at that time .... or in reality the crew had to rely heavily on ground communications to know the spacecraft system status, orientations, orbital data and so on .... ?? just wondering...

Thank you for now.

I would like to discuss with you some others Soyuz issues, general topic not specific to this project of your, can I send you a PM to avoid cluttering this post?
Thanks!
 

thermocalc

Active member
Joined
Aug 18, 2014
Messages
200
Reaction score
69
Points
28
Location
Bangkok
Hi Diogon,

I just tried again the rendezvous from the default scenario “Soyuz 18-1 pre-rendezvous”.

As I noticed that in the VC I get only 18-20 fps while in HUD view I got 55-60 fps (depending if the earth is in view or not) I tried to run the mission almost always in the HUD view and so I also took some screenshots along the way, you can see them sequentially in the zip file, I tried to save one of them anytime I saw something changing in the HUD, like: igla number, LOS burn or Burn seq counter…here are a summary of what I noticed, all details can be read off from the HUD data following my trip.

I engaged IGLA at about 28.5 km from prograde orientation.

From 28.5 to 17.7 km target range I had “igla 1” , “LOS burn”=0, “Burn seq”=0 , DO was firing (ELS indicator)

From 17.3 to 16.7 km I got “igla 12”, “LOS burn”=0, “Burn seq”=0, DO and DPO lights were on/off in ELS indicator

From 16.6 to 15.2 km I got “igla 4”, “LOS burn”=0, “Burn seq”=0, all jets off

At 14.8 km I got “igla 9”, “LOS burn”=0, “Burn seq”=1, DPO firing

At 14.6 km I got “igla 11”, “LOS burn”=0, “Burn seq”=1, SKU firing

At 14.5 km I got “igla 13”, “LOS burn”=1, “Burn seq”=1, SKU cut-off, and DO/DPO firing

From 14.5 to 14 km I got “igla 13”, “LOS burn”=1, “Burn seq”=1, and DO/DPO firing

From 13.4 to 12 km I got “igla 8”, “LOS burn”=1, “Burn seq”=1, and DPO firing

At 11.9 km I got “igla 12”, “LOS burn”=1, “Burn seq”=2, DPO firing

From 11.9 to 9 km I got “igla 12”, “LOS burn”=1, “Burn seq”=2, and DPO firing

Actually from 8.9 to 2.9 km I saw that igla was alternating from “igla 12” to “igla 4” and viceversa many times ...

At 2.9 km I had 25.8 m/s CVEL from dockingMFD, I was in “igla 4”, “LOS burn”=1, “Burn seq”=2

At 2.0 km I saw a change to “Burn seq”=4, the rest was still the same: “igla 4”, “LOS burn”=1, and the CVEL was 17.9 m/s on dockingMFD

After nothing more happened, rapidly the Salyut passed away, the target range drop to approx. 1.5 km, the CVEL drop to zero and then started to increase, as well as the target distance, when I was far away 2 km I took the screenshot, and it was still in “igla 4”, “LOS burn”=1, “Burn seq”=4

At approx. 4 km, 5 km away from the station I saw again DO/DPO activities switching between “igla 4” to “igla 12” in trying to keep centered the station in the docking HUD box (see my screenshots).

I don’t know if I missed the “Burn seq”=3 from 2.9 km (when it was still at 2) to 2.0 (when I saw it was 4) as i was not looking at it or it didn't happened.
(i guess between 2 and 4 there should be a 3rd burn...)

hope this help.

***

Anyway, I have the following questions now before to try again from lift-off:

What is the meaning of “igla 1, 4, 8, 9, 11, 12, 13 modes which appeared in the HUD?
And why there are not the intermediate numbers: 2-3-5-6-….?

LOS burn I guess it is line of sight burn…right?

What is “Intz” ? I saw tha while in “igla 12” it was always changing its value, while on all others “igla” numbers intz was always zero.

Last LOS roll ? why also this sometimes was changing and sometime not?

thanks!
 

Attachments

  • ezyZip.zip
    5.6 MB · Views: 3

thermocalc

Active member
Joined
Aug 18, 2014
Messages
200
Reaction score
69
Points
28
Location
Bangkok
i forgot two others issues:

while the target distance on the hud is almost the same as the distance in the dokcing mfd, why the target range rate is very different from the CVEL ?

next, if you see my screenshots, sometimes you see over imposed to the main hud some weird imagines of the soyuz external green parts ... well when i was taking the screenshot i paused orbiter, than go to VC view to see the ELS display and than back to HUD view ... and upon coming back the double imagine was there, upon unpausing orbiter the superimposed imagine disappeared almost instaneusly ... (just in case you noticed and were thinking why i saved such weird imagines) ... sometime is not there as i save the screenshot immidiatly (withoug hitting F8), but sometime i forgot and i saved once back to hud view and the double imagine was there.
 

diogom

Well-known member
Joined
Aug 2, 2010
Messages
1,268
Reaction score
231
Points
78
Hey, thanks for the data. Most of that is debug information basically, but I'm glad I left it in. I'll have a look later on, compare to what I see.

I don't have much of a bearing on whether the Igla code is an overcomplicated mess or not, but I approached it as a sequence of several different states, each does it's own thing, and the code cycles through them as needed. These are on the upper left as "Igla x":
  • 1 is the initial rough orientation in pitch and yaw towards Salyut, it only runs once;
  • 2 you can't really see, because all it does is tell Salyut to start it's own Igla, and it's also a decision point based on the initial distance and speed;
  • 3 is the DPO translation correction. It's meant for the final phase, to keep Soyuz from drifting off to the sides;
  • 4 is the fine orientation in pitch and yaw, to keep it pointed at Salyut;
  • 5 is orientation in roll, to align the docking ports on the final phase of the approach;
  • 6 and 8 are the DPO pitch flips to 180º and 0º - so state 6 face away from Salyut, do the burn, then state 8 to face Salyut again;
  • 7 is the burn state, it's either an SKDU or retro burn, depending on that burn_seq and other parameters. burn_seq defines the speed target, for example, so state 7 knows when to stop burning;
  • 9 and 10 are like 6 and 8, but it's pitch down to 90º or pitch up to 90º - this is for the initial phase of the approach, the Soyuz uses the SKDU to cancel the lateral drift since it's more efficient that way (the DPO thrusters are too weak at large distances). So if a braking burn was just made facing away from Salyut, and a lateral burn is next, it chooses state 10. Otherwise, it chooses state 8 to point at Salyut again;
  • 11 is a dedicated state for that burn at 90º;
  • 12 is a special case of roll alignment to point the lateral drift vector towards the ship's +Y. There will always be some lateral drift which builds up over time, because the orbits of the two ships are different. Basically since Soyuz could only pitch 90º in the down direction (due to the antenna's gimbal range and position), you want Soyuz to be moving "up" relative to Salyut, so that when it pitches down 90º, it's burning in exactly the opposite direction.
Burn_seq was my way of changing the speed targets and the sequence, so the algorithm knows when to choose each state. It always starts at 0, and depending on the inital approach speed and distance when Igla is turned on, it decides on the next value. For example, 6 is to slow down to 0.3 m/s under 200 m, and 8 is sort of a loop which redirects to burn_seq 6 if the speed gets too high. LOS burn is a counter for how many of the 90º burns have happened, because throughout the approach, there are fixed distances which trigger one of those. Every time one happens, or isn't needed, it increments. So throughout the approach, these two values guide the sequence by keeping track of where it is in the sequence.
For a ~30 km start, after states 1, 2 and 4 run once, it should first use state 12 to roll correctly, then do a 90º burn, loop on state 4, and then at 10 km or so do the first braking burn. It's also possible it has to roll again after that first 90º burn, depending on the trajectory.

Intz was something I had to come up with for state 12. I get the angle between the drift vector and Soyuz's +Y axis to know when they are aligned, but was having trouble because it all broke down when the ship is rolling, it failed to stop at the right time. So now, when Igla decides it needs to roll using state 12, it saves how much it needs to roll. Then, as state 12 rolls it, it integrates the angular velocity over time, which is equivalent to "how much has it rolled so far", this is Intz. At the appropriate accumulated value, it starts cancelling the roll. So now, instead of comparing with the actual drift vector until the difference is small enough, it's a "dumb" "roll by x degrees and it should be close enough". Closed loop vs open loop, I guess.

On paper it makes enough sense to me, but I reckon with all the different thresholds, it's kinda hanging on wires and there's a lot of potential for specific situations to break the whole thing. I think the best I can do is gradually catch as many as I can and account for them.

As a side note, I'll try to work something up for the next one to have the Vzor "off" when not needed. If it has a significant impact in fps, it shouldn't be forced on. IRL the peripheral screens have shutters, and I think they have a lid to put on the central screen.

A side question about SKD DV burns …. I saw that once you know how much DV you need to burn, say 30 m/s, by activating the accelerometer and firing the SKD when the accumulated DV in the HUD get to 30 m/s you may cut off the engine; but all this is done looking at the HUD … how this “cut off” was supposed to be performed by the crew? Using the programs that you were mentioning you are going to implement?
Or were you suppose to set the DV in the DV counter next to the reserve DV counter (i saw that it is set to 50.5 but the number can be changed with the knob below, but it never change upon firing the SKD) and upon ignition it was supposed to count down to zero, signaling the crew when to cut off the engine? or the engine was automatically cut off?
I actually haven't seen any direct references to the counter decreasing during a manual burn, but maybe I missed/forgot something. It would make sense that it did and I think that's the case, but the info I've seen is more along the lines of knowing how long a burn should take. In any case, it was also used by the automatic burns, in that case they would input the delta-v and the program would use it for the burn. It's also likely they could have a semi-auto SKDU burn: since there's a "SKDU impulse" command on the KSU, and the separate "SKDU on/off" buttons on the main panel, I'm thinking through the buttons it was fully manual, but through the KSU it would start when you commanded it but turn off when the input Delta-V is reached. The idea with the main programs (as in Manoeuvre and Descent) is they consist of several "subprograms" (like orbital orientation) and commands (like activating the accelerometer), which are turned on sequentially on a time scale. The crew was supposed to be able to command each step manually in case the timing unit failed to, so it makes sense that option would be available.
But basically I'm leaving the VC side of the accelerometer for when the programs are implemented.

I would like to discuss with you some others Soyuz issues, general topic not specific to this project of your, can I send you a PM to avoid cluttering this post?
Sure, no problem.

while the target distance on the hud is almost the same as the distance in the dokcing mfd, why the target range rate is very different from the CVEL ?
That has to do with how the distance is calculated. Angles and speeds are calculated based on distance to Salyut's centre of mass, but for the displayed distance I adjust to distance to docking port. But the docking port is some 7 m away from the centre of mass of Salyut, plus it's not very well tuned. But even at small distances it shouldn't have a big impact.

next, if you see my screenshots, sometimes you see over imposed to the main hud some weird imagines of the soyuz external green parts ... well when i was taking the screenshot i paused orbiter, than go to VC view to see the ELS display and than back to HUD view ... and upon coming back the double imagine was there, upon unpausing orbiter the superimposed imagine disappeared almost instaneusly ... (just in case you noticed and were thinking why i saved such weird imagines) ... sometime is not there as i save the screenshot immidiatly (withoug hitting F8), but sometime i forgot and i saved once back to hud view and the double imagine was there.
Only when paused, right? That has to do with the camera resetting. On HUD mode, I'm forcing it to the Vzor's point of view on every frame, because if you switch to VC, the camera position changes and it needs resetting when you come back to HUD view, I might be missing a way to separate both cameras. So it looks through the BO, since it's still located near where the seats are. But yeah, Orbiter only updates the position when you unpause.
 
Top