Project Soyuz 7k.dll

[N_Molson]

Created a BO dll, and coded the "BO spawn" when you separate.



Still a few unexpected bugs to fix, though.

 

[N_Molson]

Fixed the "unexpected bugs" and created a PAO .dll.

No pic, for some reason all the "picture galleries" related pages of OF are down this night. Will add later.

I will have to play with the thermal cover mesh to make it "ripped" after separation.

 

[diogom]

:thumbup:
You could upload it to a place like Imageshack, and copy the link here.

 

[N_Molson]

Messed up the thermal covers to make them look "teared", also a few very short-lived particles to make the explosive strings detonation visual :



---------- Post added at 10:03 PM ---------- Previous post was at 06:03 PM ----------

The "Telemetry Stations" idea works. When in the dedicated submode, orbital data displays on the HUD, as long as you are in a 3000 kilometers radius of Baikonur (and I mean spherical path on the surface). When you are out of range, the data is replaced by "--", and you are flying "blind".

Now I'm ready for tracking stations long/lat coordinates, if you have them. :sweet:

Inside station range :



Outside station range :



Of course this was an experiment, data available on the HUD will be refined.

Oh and I added a shortcut so that you can switch between 3 main engines modes : KTDU-35 main, KTDU-35 backup, 4x 10 kgf.

Edit : I think that the left MFD is going to be completely disabled. More room for HUD data, and gives the spacecraft a "primitive" feeling. On the left, when in the stations range, we could allow Align Planes, SyncMFD, MapMFD (the essentials to perform a rendez-vous or make a "cowboy reentry"). Maybe SurfaceMFD during reentry. For docking, the default MFD is too good for 1970's :lol: Maybe some kind of "ILS", returning your approach errors in degrees at relatively close range (< 10 km). :hmm:

 

[Grover]

is it even possible to restrict Orbiter's MFDs? if so, i think a blacklist method is better than a whitelist method, because some addons like checklist MFD or Tetris MFD would be a nice addition

 

[Urwumpe]

is it even possible to restrict Orbiter's MFDs? if so, i think a blacklist method is better than a whitelist method, because some addons like checklist MFD or Tetris MFD would be a nice addition

You can at least blacklist the default MFDs, never tried it with add-ons.

 

[N_Molson]

There is an "USER" category that includes all addons MFD. I'll try this.

And there is a radical option as backup : disable the MFD screen when out of communications range.

Remember : we're simulating the Soyuz 7K-T. A spacecraft that has only 48 hours of battery power, primitive electronics, and mostly analogic/electro-mechanical instrumentation.

 

[4throck]

Regarding MFDs, I'd create a configuration file for those available, and within that what's functional when in range.
That way, if in the future someone does a dedicated MFD (why not ?) we could use it without having to recode the ship....

Regarding the stations, I'm now testing the base configs. Only the known bases, still no ships, we can discuss that latter. I'll post the link latter.

 

[Urwumpe]

That way, if in the future someone does a dedicated MFD (why not ?)

What kind of dedicated MFD do you mean?

 

[4throck]

For example, instead of Map MFD we could have a Globus/Spaceflight Navigation Display MFD. Or at least something that replicated its function. The same goes for the "Program control indicator"(see http://www.orbiterwiki.org/wiki/Sirius-7K_IDS :tiphat: ) . Don't know what would work regarding the programing details, but in theory it would make sense to have adapted MFDs for each technology or spacecraft family.

-------------------------------

Ok, I've uploaded the base files here: http://www.freefilehosting.net/orbiter
I've added Habana and the Russian launch sites, besides the NIP sites.

 

[Urwumpe]

For example, instead of Map MFD we could have a Globus/Spaceflight Navigation Display MFD. Or at least something that replicated its function. The same goes for the "Program control indicator"(see http://www.orbiterwiki.org/wiki/Sirius-7K_IDS :tiphat: ) . Don't know what would work regarding the programing details, but in theory it would make sense to have adapted MFDs for each technology or spacecraft family.

You could also use the new IDS of Soyuz TMA as reference and simply reduce the number of options for the less capable Soyuz family members.

 

[N_Molson]

In an ideal world, where time, documentation and skill would be infinite, a fully functional VC and multiple 2D panels for every gauge and switch would be the answer.

I will release the source code with the .dll anyway.

 

[4throck]

Don't complicate things too much We don't need panels or VC to make things interesting.

Here's something I'm working on: "Tech level" HUD repaint.
Instead of color you would change the HUD style. This would be the 60's Soviet version:

Some MFD "styled" with gauges instead of the default "phosphor green" look is all I'm thinking of. Not a full system simulation!

 

[N_Molson]

That's a good idea, even if I still believe that MFD have to be limited.

What will make the decision is gameplay. Docking to an orbiting Salyut is probably going to be hard enough given the low Dv of the spacecraft ; I'll see which informations are critical and which aren't. Also it will require a near-perfect launch timing, but that's another story.

Worked on the EVA logic, now the EVA begins inside the BO as I wished. When you press the EVA key :

1st time : the cosmonaut seals his suit, and begins to drain his portable O2 reserve. He remains attached to the Soyuz, meaning that you can manoeuver as you wish. The BO has to be pressurized at this moment, once the suit is on you have to close the SA/BO hatch, depressurize the BO and open the EVA hatch to proceed to the next step.
2nd time : stand up EVA, the cosmonaut can see outside but is still attached to the Soyuz.
3rd time : leap into space, the attachment is cut and the UMmu receives a 500-600 N impulse to slowly clear the hatch, simulating the cosmonaut muscular energy.

Also I'm going to limit greatly the default UMmu RCS fuel reserve, to give a bit of realism. Like you begin the EVA with 10% RCS fuel. You're not supposed to go far away anyway

In this pic, we are between step1 and step2, ready to get the torso out :



No, I'm not going to Uranus with that hardware :lol:

---------- Post added at 04:58 PM ---------- Previous post was at 01:19 AM ----------

Playing a bit with the HUD appearance :



Amber looks good, remember monochrome computers...

 

[Grover]

looking good! how were the discussions for a lunar mission going? mostly, how would a lunar-stack be assembled and perform TLI? i was thinking of a wierd lunar lander with a docking port at the fore and aft (similar to W&NMs ATV2) with an assembly as such:
FORE Soyuz> >Lander< <High-Energy Stage =<

where the High Energy stage would supply TLI and TEI dV, Backup Life support (since a soyuz like support system might struggle to match 10 days of autonomous flight), and the lander in between would serve as extra living space as well as the actual lunar lander

any further thoughts on how this hunk of Russian engineering can become a hunk of Russian engineering around the moon?

 

[N_Molson]

This hardware exists, it's the Soyuz LOK (built, never flown) and the LK Lander (built, tested successfully in LEO), mounted on the N-1 ("flew" 4 times, more than 200 seconds in total).

 

[Grover]

so you'll use REAL tech in its theoretical specifications? i should get on wikipedia now and check them out

thanks

 

[N_Molson]

:lol: I don't plan to make this ; the amount of work to have a decent simulation would be insane. Also there is a "sovetic lunar program" addon in progress if I'm right. However I still plan to finish the Lander I started last year, that would be in a near tech perspective (2015-2020), and work with a Soyuz TMA-L, as it was proposed by Space Adventures, when Thorton will get time.

Here we are working on the 7K-OK, 7K-OKS, & 7K-T (the TM was for ASTP).

Now if you make me a nice model of the 7K-L1 (Zond), I suppose it's something I could do (since there is the excellent Proton LV addon).

 

[4throck]

The Soyuz family tree! I created that graphic uploaded it into Wikipedia so long ago. Interesting to see it posted here, it's almost like as if it is returning home.:thumbup:

Lets stick to 7K. There's a LOK-LK addon in progress complete with VCs so let's not mix things.

At most, we can think, in the far future, to do the ASTP (7K-TM) just because the adapter meshes exist and we also have a nice Apollo waiting.





Regarding the Zond, you have this: http://www.orbithangar.com/search_quick.php?text=zond&submit.x=0&submit.y=0

Regarding the LOK / LK, you have [ame="http://www.orbithangar.com/searchid.php?ID=5004"]http://www.orbithangar.com/searchid.php?ID=5004[/ame] and another addon in progress (real panels and VC).

But both of these missions have little to do with our early Soyus.

 

[Izack]

The Soyuz family tree! I created that graphic uploaded it into Wikipedia so long ago. Interesting to see it posted here, it's almost like as if it is returning home.:thumbup:

I hate to say it, but there's a typo in the title... :shifty: