Project Soyuz 7k.dll

So it should be something like 5 kg for the DO ? That mode is very economic.

At least it will avoid to pump Dv on the main engine ;)

LOL, yes. I am not sure with the numbers, I am still checking them. But about 25 kg hydrogen peroxide leaves a proper dV in the main engine tanks.

Also, it is mentioned that the DPO can't be used for deorbiting, since the tanks are too small, thus the backup engine.
 
Also, it is mentioned that the DPO can't be used for deorbiting, since the tanks are too small, thus the backup engine.

Yes, that makes sense and explains why the backup engine was removed from the Soyuz-T. A current Soyuz TMA-M could certainly use it's linear attitude thrusters to deorbit.
 
Think I may have another one. The Ion sensors slightly mis-align the soyuz. Its only a ~15º yaw difference, it "flies sideways" a bit. I don't know if its relevant, or if the sensors are meant to have some innacuracy?
 
Yes, that makes sense and explains why the backup engine was removed from the Soyuz-T. A current Soyuz TMA-M could certainly use it's linear attitude thrusters to deorbit.

Yes, that replaced the backup engine. It might take a while longer, but it will work.

Also, the main engine of soyuz is pump fed, I would appreciate it later (not in the first versions), if you can't throttle it, but just turn it on and off, with the engine "slowly" starting up (Can't tell about the actual time it takes to start such a small engine, but approximately 1 second would work).

---------- Post added at 08:50 PM ---------- Previous post was at 08:47 PM ----------

Think I may have another one. The Ion sensors slightly mis-align the soyuz. Its only a ~15º yaw difference, it "flies sideways" a bit. I don't know if its relevant, or if the sensors are meant to have some innacuracy?

Not sure there, but the output of the sensors is also wrong - it should be two dimensional (pitch/yaw). also I noticed a strange glitch in the angles, the angle of the ion sensor can't reach 180°, but does strange switching from 90° to 270°
 
Think I may have another one. The Ion sensors slightly mis-align the soyuz. Its only a ~15º yaw difference, it "flies sideways" a bit. I don't know if its relevant, or if the sensors are meant to have some innacuracy?
(Issue#15)

Noticed that too. I think that my formula is wrong, or that I use the wrong functions to get the vectors.

Will investigate. -> Fixed, it's awesome what you can find when you dig on the OF SDK pages... Now the ionic sensors return a positive or negative number of error degrees, and only for the Y-axis (Yaw), as it is supposed to be (from what I read in Soyuz, an Universal Spacecraft). :)
 
Last edited:
(Issue#15)

Noticed that too. I think that my formula is wrong, or that I use the wrong functions to get the vectors.

Will investigate.

Do you use atan2?
 
No, just an awful combination of GetPitch() & GetYaw(). Surprised it gives an almost decent approximation.

Code:
double abs_yaw = GetYaw()*DEG;
if (GetYaw()*DEG > 90)
{
	abs_yaw = GetYaw()*DEG-90;
}
if (GetYaw()*DEG < 90)
{
	abs_yaw = GetYaw()*DEG-90;
}
if (GetYaw()*DEG > 270)
{
	abs_yaw = GetYaw()*DEG-450;
}

double abs_pitch = GetPitch()*DEG + 90;

if (GetYaw()*DEG > 180)
{
	abs_pitch = 180 + fabs(GetPitch()*DEG-90);
}
if (abs_pitch > 270)
{
	abs_pitch = abs_pitch-360;
}

	len = sprintf_s(buffer, "Ion err.");
	skp->Text(20, linespacing*235, buffer,  len);
if (ion_proc < 1)
{
	skp->SetTextColor(0x00C800);
	len = sprintf_s(buffer, "%.0f°", [B]fabs(abs_yaw)+fabs(abs_pitch-90))[/B];
	skp->Text(150, linespacing*235, buffer,  len);
	skp->SetTextColor(0xFFFFFF);
}
 
Last edited:
Little thing I noticed. After EVA, BO pressure is 765, not 760. And you said to keep an eye for mass changes, during EVA it goes from 6963.00 kg to 6875.00 kg. (fuel tanks 100%)
Edit: More on mass changes, the combined mass of the BO and SA+PAO after separation is lower than the whole craft joined toghether
 
Last edited:
during EVA it goes from 6963.00 kg to 6875.00 kg. (fuel tanks 100%)

That should be the mass of the crew+EVA suit.

Does the mass goes back to 6963 kg when the 'naut ends EVA ?
 
Then it's "normalno", expected Ummu behavior.

Currently re-coding the whole "status" part to solve the load/save problems with meshes, that's the current priority because I want this core part rock-solid before I deal with other things.

---------- Post added 11-25-11 at 01:07 AM ---------- Previous post was 11-24-11 at 11:16 AM ----------

I've redone the whole flight sequences part (to reflect structural changes), and made it save/load proof (at any time of the flight), much better than in the v0.12 alpha. That was quite a lot of work, but that's the core of the addon. :coffee:

I also completely reworked the aerodynamic model of the SA, it now matches much better with the figures I've read here and there.

The drawback is that I, in a very temporary fashion, disabled the VC feature ; it has to be rebuilt too, but only after the behaviour of the "core" has been thoroughly tested. Just want to be sure there aren't any conflicts.

I hope to release another alpha tomorrow. ;)
 
Would be nice if you can make a next version this weekend, from next week on, I will be offline for some days and can't test it... ;)
 
There is a good hope for this to happen, since the Probe suddenly enlightened me on how to make screen resolution adaptative HUD text. Much much better.

:hailprobe:

---------- Post added at 11:44 PM ---------- Previous post was at 09:41 PM ----------

Just got another idea for the display :



In fact, it could be moved to lower left, in place of the left MFD :hmm:

---------- Post added 11-26-11 at 12:58 AM ---------- Previous post was 11-25-11 at 11:44 PM ----------

Alpha release v0.13 out. :coffee:

Notice I also added a thumbnail for the scenario editor, wasn't exactly the hard part :lol:
 
Ok, 101, orbital insertion scenario:

Jettisoning the BO takes two presses of the J key.

On a first attempt, no matter how much I pressed J, the SA wouldn't separate. Soyuz state would increase with every press. It worked fine in following tryes though, maybe a random thing.


So far, nothing else.
 
Jettisoning the BO takes two presses of the J key.

Known issue. In fact, I was thinking to make something like : first strike, pyro devices armed, second strike, pyro devices fired. I would of course extend this to the even more critical PAO separation. And change the key to Shift-J, a safeguard seems required there (oops, we're stranded in orbit, I hit the wrong key, sorry :lol:).

On a first attempt, no matter how much I pressed J, the SA wouldn't separate. Soyuz state would increase with every press. It worked fine in following tryes though, maybe a random thing.

That one is weird. Tell me if it happens again.

---------- Post added at 11:34 AM ---------- Previous post was at 11:23 AM ----------

Ok, my turn :
When you get out of range of the tracking stations, the warning lights that indicates there is radio contact don't switch off, unless you are in the "Telemetry Data" HUD submode.
(Issue#016)

Suggests that the check for the status of those lights is executed inside the condition "HUD mode = Telemetry Data".

-> Will modify the conditions that control those lights. -> fixed

---------- Post added at 11:39 AM ---------- Previous post was at 11:34 AM ----------

If you tap "J" repeateadly, the SoyuzState variable increments indefinitely.
(Issue#017)

This should not happen ; the sequence of events will be messed up if the value is not correct. The thing is that you have control on this variable for the first events, but the later ones (parachutes sequence) is automatic.

-> Will add a condition in the method that checks keyboard input. -> fixed, in fact you now have to press Shift-J instead of J. Also the "double tap" was removed.
 
Last edited:
Ok, gave it a test with the save/load. Quicksaved on various parts of the flight (BO sep, PAO sep, different parachutes, antennas deployed, EVA, etc) and all seems fine on loading. BTW, I assume the HUD's missing after PAO separation are intended to be missing? (maybe cause theyre not needed?)
 
BTW, I assume the HUD's missing after PAO separation are intended to be missing? (maybe cause theyre not needed?)

Yes, that's it. But it is not intended to stay like, maybe there will be a message like "inactive mode" or a skip of those modes.

Could you post a screenshot of the HUD on your computer (unless you have a 1024x1280 5/4 screen like me) ? Just to see how it behaves on a different resolution/screen format.

If someone has a 16/9, I'm really interested, too.
 
Last edited:
Yes, that's it. But it is not intended to stay like, maybe there will be a message like "inactive mode" or a skip of those modes.

well, you could also simply have the HUD page signaling "Missing data". Or limit your HUD to the data, that was displayed in the real Soyuz. You could for example also include the program timer display in the HUD, maybe just as vertical scrolling view of the full one (like the real Soyuz TMA does now).
 
This is how it looks in my screen (full screen)

picture.php


Though, I usually use Orbiter in window mode. In window, the HUD is slightly over the fuel and RCS box on the top left.
Don't know how's my screen, all I know is I took the screenshot in 1024 x 768 res.
 
Back
Top