[1.12.X] Tantares - Stockalike Soyuz and MIR [16.1][28.05.2024][Mars Expedition WIP]

[Beale]

[Beale]

|



1.5m Variant.

[Beale]

And complete... well, almost.

[Beale]

Fairings.

[scottkiller2000]

Im having an issue where some craft files wont load because there missing a part called kornocopus solar panel and a docking port anyone else had this issue?

[Beale]

Just now, scottkiller2000 said:

Im having an issue where some craft files wont load because there missing a part called kornocopus solar panel and a docking port anyone else had this issue?

Sorry yes, some of the craft files are out of date and use lost parts. I'm in the process of replacing them.

Do you know which files so I can remove those?

[scottkiller2000]

Ah ok no worries give me 5 mins and Ill get a list for you

[scottkiller2000]

@Beale

Heres that list for you

TKS (Missing Docking Node and Solarpanel)

SPEKTR (Missing Docking Nodeand Solarpanel)

SOYUZ (Missing Docking Node and Solarpanel)

SALYUT 1 (Missing Docking Node and Solarpanel)

PROGRESS OLD (Missing Docking Node)

PROGRESS MODERN (Missing Docking Node and Solarpanel)

POLYUS (Missing Docking Node and Solarpanel)

PIRS (Missing Docking Node and Solarpanel)

NI LUNAR EXPEDITION (Missing Docking Node)

MIR (Missing Docking Node and Solarpanel)

MARS LK (Missing Docking Node and Solarpanel)

LK (Missing Docking Node)

KVANT 1 (Missing Docking Node and Solarpanel)

ALMAZ 1 (Missing Docking Node and Solarpanel)

[Beale]

2 hours ago, scottkiller2000 said:

@Beale

Heres that list for you

Thanks, hmmm some of those are very new so I would expect they should all still work.

Do you have the latest release of both mods? (Tantares and TantaresLV).

 

GitHub

Craft File! ( I am really pleased with the Spacecraft separation on this one ;^] )

To finish:

• Sounds and FX (Really custom sound effects are needed, this is so weak right now).
• Calm down the Soyuz vernier engines, they are too responsive and make the SAS go a little proactive.
• Decoupler - hot-staging plate like the real Soyuz.
• Fins.
• Some secret new utility parts (That I've tried to emulate in the above craft file).
• Rest of the 1.25m and 1.5m variant parts (Hopefully these will be easy).

[scottkiller2000]

@Beale huh wierd i just downloaded from the front page so ill redo and go from that link lets see what happens

Edited May 26, 2019 by scottkiller2000

[scottkiller2000]

hello, solved a couple of them but most of them are still having that error @Beale

[Beale]

4 minutes ago, scottkiller2000 said:

hello, solved a couple of them but most of them are still having that error @Beale

Thanks to confirm. Okay I will dig through the existing bunch and remove.

[Beale]

A little QOL part.

Could be useful for a few craft, but really it's just cool to see your upper stage vent away.
This part acts basically as a Liquid separatron, with very low thrust and low ISP (It has since been reduced to 1 ASL).

It can be shut down if you activate it accidentally, but be aware because it will vent what you have pretty quick

[Beale]

GitHub

Craft file.

New sound effects,
New fuel vent.

[Well]

6 hours ago, Beale said:

New sound effects,
New fuel vent.

Thanks for this little detail that adds a lot to the feel of the launch. 

[Well]

For the craft files errors, that because KSP now write in the craft files what "mod" module you use... like Mechjeb / KIS or other stuff like that...

That a little annoying, but that don't block the loading of the craft, that just show the fact a module of the craft can't be loaded.

Generally loading the craft and re-write it remove the error.

[Electr0ninja]

I was testing the mod in 1.7, and it appears as though the starting command pod does not experience atmospheric drag.
Thus the command pod plummets through the atmosphere to its death on reentry. I tested this using the aerodynamics overlay.

Part name:
A-1CS 'Rullendemann' Crew Module

Edit:  @Beale I went and sifted through the part config files and you seem to be using the same drag model and constants as the Mk1 command pod. The Mk1 command pod seems to handle drag appropriately, so I am unsure as to the cause of this bug. My best guess is that the drag cube is wonky, so I posted it below. It might be the 4.172E-07 bit, but I am unsure.

 

Spoiler

    DRAG_CUBE
    {
        cube = A, 1.138,0.7383,0.7278, 1.137,0.7377,0.7222, 1.213,0.5631,1.128, 1.213,0.971,0.1315, 1.169,0.7384,1.035, 1.169,0.745,0.9837, 4.172E-07,0.02188,0, 1.25,1.09,1.25
        cube = B, 1.138,0.7383,0.7278, 1.137,0.7377,0.7222, 1.213,0.5631,1.128, 1.213,0.971,0.1315, 1.169,0.7384,1.035, 1.169,0.745,0.9837, 4.172E-07,0.02188,0, 1.25,1.09,1.25
    }

Edit of an Edit: If you wish, I can just make a giant rig of all the tantares parts and test to see which of them experience the same phenomenon.

Edited May 29, 2019 by Electr0ninja

[Well]

I have actually a question...

i've started to play with Tantares and Universal Storage 2 (Universal storage bundle now Communauty ressources pack.)

And now all my tantares craft have embbed life support ressources.... but i don't use them, i don't have any life support mod...

So i understand why but i found that a little strange. I've see the compatibility patch for TAC Life support is writed like that :

@PART[Andromeda_Crew_1]:FOR[TacLifeSupport]

Maybe i'm wrong but i think he need to be :

@PART[Andromeda_Crew_1]:NEEDS [TacLifeSupport]

Sorry if i have missunderstood something

[Marcelo Silveira]

@Electr0ninja, that is a weird behaviour indeed. Try commenting the DRAG_CUBE module to force ksp to use an automatically generated drag cube.
Drag_Cubes are defined with 8 segments each with three values (Area, Drag coefficient and Depth comment explaining this) 

Face	|X+			X-			Y+			Y-			Z+			Z-			center			Bounds extension
value	Area	C_d	Depth	Area	C_d	Depth	Area	C_d	Depth	Area	C_d	Depth	Area	C_d	Depth	Area	C_d	Depth	X	Y	Z	X	Y	Z
A	1,138	0,7383	0,7278	1,137	0,7377	0,7222	1,213	0,5631	1,128	1,213	0,971	0,1315	1,169	0,7384	1,035	1,169	0,745	0,9837	4,17E-07	0,02188	0	1,25	1,09	1,25
B	1,138	0,7383	0,7278	1,137	0,7377	0,7222	1,213	0,5631	1,128	1,213	0,971	0,1315	1,169	0,7384	1,035	1,169	0,745	0,9837	4,17E-07	0,02188	0	1,25	1,09	1,25

The 4.17E-07 is just the bounding box center in the X coordinates. I'm not completely  sure what is causing the issue.

 

@Well, yup. It should have a NEEDS node instead of a FOR. I would recommend using :NEEDS[TacLifeSupport]:FOR[TacLifeSupport] 

[Electr0ninja]

@Marcelo Silveira Good idea with the automatic Drag_Cube generation.
After commenting out the drag cube configuration, the pod experiences aero forces again.
However it experiences like 5%-10% more drag than I expected. But for automatic generation, it ain't half bad.
So it does appear that there is some kind of parsing error in the Drag Cube configuration, or I am missing something.( It is completely likely that I am missing something )

Edited May 29, 2019 by Electr0ninja

[Marcelo Silveira]

2 hours ago, Electr0ninja said:

@Marcelo Silveira Good idea with the automatic Drag_Cube generation.
After commenting out the drag cube configuration, the pod experiences aero forces again.
However it experiences like 5%-10% more drag than I expected. [~snip~]

ok, this raises some questions for me.

1. Are you testing just the A-1CS capsule or are there any other parts in the vessel like parachutes and stuff?
2. What do you mean by 5-10% more drag than expected?

Edited May 29, 2019 by Marcelo Silveira

[Daniel Prates]

hey @Beale can I ask you something? Your command pods (well actually I've only seen it in 'trippleboks' but I assume all of them are the same) have a 'clear scape hatch' button, which ejects everything in front of the upper attachment node. The "C" letter makes it rest just above 'crew report'... I can't count the times my soviet-a-like moonshot ended with a kerbal being stranded on the Mun after I accidentally clicked the wrong button, wanting a crew report but ending up throwing away my docking port (EDIT: though with KAS an engineer can actually attach it back, which I did a couple of times. It made me adopt the practice of ALWAYS carrying engineers with attachment tools in any complex mission, which is one of those things that make modded KSP so great).

I'm not saying "could you remove that pls", but rather, what's the idea exactly? I mean, kerbals can easily exit from the main, side door. Is there a relevant use I am not quite understanding?

Edited May 30, 2019 by Daniel Prates

[Electr0ninja]

@Marcelo Silveira
Answer to the first question: Just the command pod and a single parachute, the one that fits in the indent. But I also did a run with nothing attached earlier with the same effect,
Answer to the second question:  It just seemed to slow down a little too fast. But that might just be subjective. The overheat bar didn't even show up from a standard LKO reentry.

Edited May 30, 2019 by Electr0ninja

[Cheesecake]

7 hours ago, Daniel Prates said:

hey @Beale can I ask you something? Your command pods (well actually I've only seen it in 'trippleboks' but I assume all of them are the same) have a 'clear scape hatch' button, which ejects everything in front of the upper attachment node. The "C" letter makes it rest just above 'crew report'... I can't count the times my soviet-a-like moonshot ended with a kerbal being stranded on the Mun after I accidentally clicked the wrong button, wanting a crew report but ending up throwing away my docking port (EDIT: though with KAS an engineer can actually attach it back, which I did a couple of times. It made me adopt the practice of ALWAYS carrying engineers with attachment tools in any complex mission, which is one of those things that make modded KSP so great).

I'm not saying "could you remove that pls", but rather, what's the idea exactly? I mean, kerbals can easily exit from the main, side door. Is there a relevant use I am not quite understanding?

Thats because in reality the crew doesn`t leave the capsule at the side-hatch. They leave it at the top hatch. Thats because the capsule can fall over and then the side hatch is blocked.
This can happen in KSP too.

[Beale]

On 5/29/2019 at 4:38 AM, Electr0ninja said:

I was testing the mod in 1.7, and it appears as though the starting command pod does not experience atmospheric drag.
Thus the command pod plummets through the atmosphere to its death on reentry. I tested this using the aerodynamics overlay.

Part name:
A-1CS 'Rullendemann' Crew Module

Edit:  @Beale I went and sifted through the part config files and you seem to be using the same drag model and constants as the Mk1 command pod. The Mk1 command pod seems to handle drag appropriately, so I am unsure as to the cause of this bug. My best guess is that the drag cube is wonky, so I posted it below. It might be the 4.172E-07 bit, but I am unsure.

 

  Reveal hidden contents

    DRAG_CUBE
    {
        cube = A, 1.138,0.7383,0.7278, 1.137,0.7377,0.7222, 1.213,0.5631,1.128, 1.213,0.971,0.1315, 1.169,0.7384,1.035, 1.169,0.745,0.9837, 4.172E-07,0.02188,0, 1.25,1.09,1.25
        cube = B, 1.138,0.7383,0.7278, 1.137,0.7377,0.7222, 1.213,0.5631,1.128, 1.213,0.971,0.1315, 1.169,0.7384,1.035, 1.169,0.745,0.9837, 4.172E-07,0.02188,0, 1.25,1.09,1.25
    }

Edit of an Edit: If you wish, I can just make a giant rig of all the tantares parts and test to see which of them experience the same phenomenon.

Very strange issue this is occurring with the manual drag cube fixes. The capsule has always had issues in the past, but the manual cube usually fixed that. 

I will investigate further, thanks for digging into it.

Anybody else have this problem?

8 hours ago, Daniel Prates said:

hey @Beale can I ask you something? Your command pods (well actually I've only seen it in 'trippleboks' but I assume all of them are the same) have a 'clear scape hatch' button, which ejects everything in front of the upper attachment node. The "C" letter makes it rest just above 'crew report'... I can't count the times my soviet-a-like moonshot ended with a kerbal being stranded on the Mun after I accidentally clicked the wrong button, wanting a crew report but ending up throwing away my docking port (EDIT: though with KAS an engineer can actually attach it back, which I did a couple of times. It made me adopt the practice of ALWAYS carrying engineers with attachment tools in any complex mission, which is one of those things that make modded KSP so great).

I'm not saying "could you remove that pls", but rather, what's the idea exactly? I mean, kerbals can easily exit from the main, side door. Is there a relevant use I am not quite understanding?

This gave me a little chuckle I see the issue!

I suppose we can just rename that "Remove crew hatch" or similar to move it away from the crew report button - as Cheesecake mentioned, yeah this is to replicate the IRL function of the Soyuz hatch the two-seater Soyuz capsule for example has no door and any future Soyuz revamps will probably have no door (spoiler alert ).