[1.12.X] Tantares - Stockalike Soyuz and MIR [26.0][18.12.2023][Soyuz Revamp Again]

[hraban]

Looks very nice

Is the 'half-sphere' included in the decoupler?

Yes Beale,

the upper 'half-sphere' of the service-module-tank is included. For the decoupler I chose a V-Strut. That looks nice and comes closer to the original. The prototype was a X-Strut.

Edited October 27, 2015 by hraban

[minepagan]

I am looking, but it looks to be very aeroplane focused... What is the benefit for space capsule?

Check these out:

https://kerbalstuff.com/mod/1022/%27MK1-2%20%20Pod%27%20IVA%20Replacement%20by%20ASET

https://kerbalstuff.com/mod/1232/KSA%20IVA%20Upgrade

https://kerbalstuff.com/mod/1120/MK3%20Pod%20IVA%20Replacement%20by%20Apex

https://kerbalstuff.com/mod/1020/ALCOR%20IVA%20Patch

[Beale]

Check these out:

https://kerbalstuff.com/mod/1022/%27MK1-2%20%20Pod%27%20IVA%20Replacement%20by%20ASET

https://kerbalstuff.com/mod/1232/KSA%20IVA%20Upgrade

https://kerbalstuff.com/mod/1120/MK3%20Pod%20IVA%20Replacement%20by%20Apex

https://kerbalstuff.com/mod/1020/ALCOR%20IVA%20Patch

Ah okay.

I think the problem is a huge greater workload. For example, I need separate configs for those who have stock, RPM only and RPM+ASET. Three IVA productions for one part!

They are very pretty props though.

Speaking of IVA...

Excuse the somewhat rushed prop layout, I was intrigued to test this internal in-game!

The view for docking is great!

Very cramped!

[Cdodders]

It's no longer available. The current decoupler between the Soyuz SM and CM replicates the TM and TMA variants of the Soyuz where the lattice structure is covered by thermal fabric, though, *hint hint*, it would be nice to see an alternate decoupler with a lattice structure.

Blue Streak/Europa is 1.73m in KSP, so 1.875m is a close enough approximation, so I don't plan on making it scaleable to a large size. I don't want to break career too much.

Black Arrow is actually too large in Tantares. It should be around 1.25m. I've included configs to make it smaller, but not larger.

Any specific reason you think those parts should be allowed to scale to 2.5m?

Just that it would then be compatible with the Centaur from FASA, enabling the building of the later iterations of BLACK PRINCE.

One thing I have noticed that bothers me slightly, the second stage engine for BLACK ARROW has no gimbal, which means unless I install reaction wheels, it just tumbles

[CobaltWolf]

Just that it would then be compatible with the Centaur from FASA, enabling the building of the later iterations of BLACK PRINCE.

What if you had a 1.875m centaur?

[VenomousRequiem]

What if you had a 1.875m centaur?

Shameless self promotion! How dare you promote such a wonderful and amazing mod on this thread. The positively amazing developers of the wonderful mod BDB would be very disappointed in you.

On a more serious note, will there be a 1.5m option in the tweakscale configs for the Soyuz rocket?

Edited October 27, 2015 by VenomousRequiem

[Svm420]

I think the problem is a huge greater workload. For example, I need separate configs for those who have stock, RPM only and RPM+ASET. Three IVA productions for one part!

Truly the RPM author intended the current RPM pros as demos/proof of concept. Not really to be so heavily used as they are by the community. The reason that is is they were for a long time the only available props for a functional IVA. SOme have come and gone making a more unique IVA, but most haven't put the time in the the ASET author has. THat is why i think for future IVAs why not discontinue the creation of plain RPM and adopt ASET props. Most who are going for a functional IVA via RPM would likely welcome the improvements available with ASET. WOuld anyone be opposed to beale just using ASET instead of RPM/RPM&ASET so he only has to make a stock IVA and 1 functional IVA? IF y I just think it would be a good investment of the future. Also do you make the files available someone else would need to make an IVA for your parts available? I have no idea what someone would need, but I wondered if this was possible to help them help you.

[CatastrophicFailure]

Just throwing this out there, might not be specifically Tantares related. I'm getting a weird "game goes nuts, only one part rendered" error when trying to load a vessel in flight that has the small docking port/parachute. Everything seems to work fine with this craft UNLESS I go elsewhere (tracking station, random game crash), then reload it, so I *think* it may have something to do with the engine "shroud" that ends up stuck to it after decoupling the port from the main craft. So to be clear, the problem vessel gets launched as part of a larger craft, there's an engine attached to the top docking node. If I separate this craft and land it in one go, it seems fine. If I separate it, then come back, game goes nuts. Here's the code, which in fairness does NOT mention Tantares:

[EXC 15:20:19.288] ArgumentNullException: Argument cannot be null.
Parameter name: key
	System.Collections.Generic.Dictionary`2[Vessel,FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI].TryGetValue (.Vessel key, FerramAerospaceResearch.FARGUI.FARFlightGUI.FlightGUI& value)
	FerramAerospaceResearch.FARAeroComponents.FARAeroPartModule.Update ()
[EXC 15:20:19.288] NullReferenceException: Object reference not set to an instance of an object
	FerramAerospaceResearch.RealChuteLite.RealChuteFAR.get_groundStop ()
	FerramAerospaceResearch.RealChuteLite.RealChuteFAR.get_canRepack ()
	FerramAerospaceResearch.RealChuteLite.RealChuteFAR.Update ()
[EXC 15:20:19.301] NullReferenceException: Object reference not set to an instance of an object
	CameraTools.CamTools.FixedUpdate ()
[EXC 15:20:19.302] NullReferenceException: Object reference not set to an instance of an object
	FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.RebuildAllMeshData ()
	FerramAerospaceResearch.FARPartGeometry.GeometryPartModule.FixedUpdate ()
[EXC 15:20:19.312] NullReferenceException: Object reference not set to an instance of an object
	FerramAerospaceResearch.RealChuteLite.RealChuteFAR.get_groundStop ()
	FerramAerospaceResearch.RealChuteLite.RealChuteFAR.get_canRepack ()
	FerramAerospaceResearch.RealChuteLite.RealChuteFAR.Update ()
[EXC 15:20:19.312] ArgumentNullException: Argument cannot be null.

This just get spammed to the log unless the game crashes outright.

[curtquarquesso]

Shameless self promotion! How dare you promote such a wonderful and amazing mod on this thread. The positively amazing developers of the wonderful mod BDB would be very disappointed in you.

On a more serious note, will there be a 1.5m option in the tweakscale configs for the Soyuz rocket?

I believe there is currently. You can scale the entire thing to 1.5m. I've got some custom parts in the works that make the core stage 1.5m on the top, and 1.25m on the bottom, as well as altered engine models. Too lazy at the moment to finish it up.

[grayal]

Hello Beale and all interested,

the lattice framework Decoupler has reached final status.

http://imgur.com/a/gjUF6

Awesome!

When can we get it?

[hraban]

Awesome!

When can we get it?

Earliest on October 30, 20:00 Central European time.

[VenomousRequiem]

I believe there is currently. You can scale the entire thing to 1.5m. I've got some custom parts in the works that make the core stage 1.5m on the top, and 1.25m on the bottom, as well as altered engine models. Too lazy at the moment to finish it up.

Altered engine models? Like how the real one looks, where it kinda tapers down a little at the engines on the second stage? I don't really know how to describe it but I think you know what the second stage(or third stage if you fancy) of the Soyuz looks like.

Edit: It seems like your dropbox link to the Tweakscale config is broken! Seems to throw up a 404.

Edited October 27, 2015 by VenomousRequiem

[Beale]

Good news. 1.0.5 brings right-click crew transfer. Meaning crewed parts that don't require an airlock are now possible.

I am modelling TMK, but hatches were a nuisance across so many crewed parts. So I ask, those in favour of some station parts without hatches?

On TMK (MAVR design study) I have a question. Any more information on the 'Earth return' component. It is described, but not sure how the capsule fits into the overall shape.

Edited October 28, 2015 by Beale

[hraban]

Good news. 1.0.5 brings right-click crew transfer. Meaning crewed parts that don't require an airlock are now possible.

I am modelling TMK, but hatches were a nuisance across so many crewed parts. So I ask, those in favour of some station parts without hatches?

Good news!

Thus, the hatches of the inflatable habitat can be omitted. This makes the parts smaller and more manageable.

Thumbs up for no-hatches parts!

[davidy12]

http://www.astronautix.com/craft/tmk1.htm

try looking at astronautix

- - - Updated - - -

It would be launched on an N-1 first of all. Then when it got into LEO, it would perform TMI/TVI. Apparently it had a booster in the back fueled by Kerosene with 350 ISP and it made one major burn to get it on course. It'd drop the booster after TMI, flyby Mars, then come back with minor corrections with some sort of SPS. I think they relied on something similar Zubrin's mission plan with a 2 year free return on a 6 month transit. However, I've flown to Duna dozens of times. And I've simulated flybys but not once have I gotten an encounter with Kerbin almost instantaneously.

- - - Updated - - -

Hope this helps Beale.

Edited October 28, 2015 by davidy12

[curtquarquesso]

Good news. 1.0.5 brings right-click crew transfer. Meaning crewed parts that don't require an airlock are now possible.

I am modelling TMK, but hatches were a nuisance across so many crewed parts. So I ask, those in favour of some station parts without hatches?

On TMK (MAVR design study) I have a question. Any more information on the 'Earth return' component. It is described, but not sure how the capsule fits into the overall shape.

Wow. That's great news! Making hatches optional actually gives use for dedicated airlock parts. It has always felt really cheat-ey to be able to EVA from any part.

Few thoughts on IVAs.

ATV: Is there any way you could reuse old assets? this iteration was one of my favorite overall IVAs. If you could remove the windows, and revamp some textures, you'd really cut down on the amount of work needed. PorkJet's Nomex CTBs really made the IVA feel great.

Cygnus Enhanced: Same as ATV basically, just narrower and longer. Just an empty can with a bunch of CTBs

Progress: The control blocks don't need IVAs, as they're not accessible by crew anyways. They're basically just fuel tanks. The Orbital modules could use IVAs though. They could basically use the Soyuz OM IVA minus the window.

Salyut/FGB/TKS: Theoretically, you could remove the hatches from a lot of these parts, but I'm unsure of how much that would annoy some people. I thought about the idea of a Vega_Crew_A extension, but why not just make another one that's longer? It'd cut down on part count. There's little chance you'd use a manned block that short and that wide.

TMK: I'd revamp Salyut/FGB/TKS before you tackle TMK. There's a lot of assumed hardware heritage there, so you could nail down the style before you make a bunch of new parts. TMK can mostly be made out of the existing parts anyways. Don't make more parts than you have to.

I'll always take revamps and improvements over new stuff. Heh.

Soyuz Docking Mechanism Update:

[spoiler=Spoilered as to not take up the entire page. ]So, I've run into a road block.

As Beale pointed out, if you do not follow instructions, and extend the probe while docked, and then undock, or load the scene in that state, the spacecraft explodes just a little... Because of that possibility, I've tried to dummy-proof the docking ports. Granted, it's really not that hard to use the docking ports properly, because if you dock normally, you'll never need to extend the probe while docked, and all will be fine, but, for the sake of safety, I've tried

The verdict is complicated: In the stock Shielded Clamp-O-Tron .cfg file, there's a parameter called deployAnimationController = 1 When 1 is a value for this, the docking port will not be allowed to animate while docked. In game, this is why you can't open or close the inline, Mk2, and shielded docking ports while docked.

The issue is this: This parameter activates in the acquire/magnetism stage of docking, not in the docked stage. This means, that if I enable this parameter, once you're soft-docked, you can no longer retract the probe to hard-dock. I experimented with stock Clamp-O-Trons and confirmed my suspicions.

As you can see here, the docking ports are trying to dock, but the I-Beams are in the way. While they're separated, I can't close the shields in the same way I can't retract the probe on my ports. Very frustrating.

Unfortunately, without writing a crazy plugin, there are limitations within the game that make dummy-proofing the ports difficult. As soon as the ports acquire, you can't retract the probe.

There are three solutions:

1. Remove soft-docking feature, but still allow docking port animation. It'll look cool, but it'll make no difference whether the probe is extended or retracted. Solely for RP purposes.

2. Allow soft-docking feature and animation and assume that people won't use the ports incorrectly. I've not been able to accidentally blow any ships up with these ports. The actions need to make things explode are very deliberate.

3. Both options. Option 1 could be included with vanilla Tantares, and I'll host and maintain the soft-docking ports somehow.

I'm actually thinking about sending a message to one of the KSP dev about this. If they made the deployAnimationController activate when ACTUALLY docked, instead of when you're in the acquire stage, it could allow further development of add-on soft-docking ports.

Anyways, please let me know what you guys think.

[pTrevTrevs]

Progress IVA should be more cramped and cluttered than the Soyuz OM IVA, since Progress carries very many things in its CM. Newer Progress models actually have water tanks in the CM instead of the center part (I forget what it's called in real life), so you could add that too. Honestly, I would rather see IVAs for Salyut/Mir/TKS before IVAs for cargo ships.

About the docking ports, I think it would be interesting to have to follow a set procedure for docking with them. It would feel more immersive, and as long as you prominently display the instructions somewhere, people can't really blame you for problems caused by using them incorrectly.

[MK3424]

Yeah, keep this way of docking and mention the procedure in the description.

If people complain.. they probably haven't read the description.

[Beale]

Wow. That's great news! Making hatches optional actually gives use for dedicated airlock parts. It has always felt really cheat-ey to be able to EVA from any part.

Few thoughts on IVAs.

ATV: Is there any way you could reuse old assets? this iteration was one of my favorite overall IVAs. If you could remove the windows, and revamp some textures, you'd really cut down on the amount of work needed. PorkJet's Nomex CTBs really made the IVA feel great.

Cygnus Enhanced: Same as ATV basically, just narrower and longer. Just an empty can with a bunch of CTBs

Progress: The control blocks don't need IVAs, as they're not accessible by crew anyways. They're basically just fuel tanks. The Orbital modules could use IVAs though. They could basically use the Soyuz OM IVA minus the window.

Salyut/FGB/TKS: Theoretically, you could remove the hatches from a lot of these parts, but I'm unsure of how much that would annoy some people. I thought about the idea of a Vega_Crew_A extension, but why not just make another one that's longer? It'd cut down on part count. There's little chance you'd use a manned block that short and that wide.

TMK: I'd revamp Salyut/FGB/TKS before you tackle TMK. There's a lot of assumed hardware heritage there, so you could nail down the style before you make a bunch of new parts. TMK can mostly be made out of the existing parts anyways. Don't make more parts than you have to.

I'll always take revamps and improvements over new stuff. Heh.

Anyways, please let me know what you guys think.

Progress IVA should be more cramped and cluttered than the Soyuz OM IVA, since Progress carries very many things in its CM. Newer Progress models actually have water tanks in the CM instead of the center part (I forget what it's called in real life), so you could add that too. Honestly, I would rather see IVAs for Salyut/Mir/TKS before IVAs for cargo ships.

The TMK is mainly me playing around at the moment, I would not expect it before other parts.

To talk of IVAs, the news of 1.0.5. IVA shader might mean big things, but I need to wait. It would be a huge benefit if I could share textures for IVAs (Since they are usually so AO heavy, this has not been practical yet).

people can't really blame you for problems caused by using them incorrectly.

They totally can, I have worked in customer service in the past

[CatastrophicFailure]

I like the idea of a little user-error risk in docking. It would justify all the DERP's and other escape systems on a space station. After all, there is a historical precedent for docking disasters...

[Svm420]

Anyways, please let me know what you guys think.

Definitely try and get ahold of the devs as now is the time this could be fixed and would be a great improvement for KSP. Matter of fact I recommend PMing NathanKell as he will probably be the mostly likely to respond and understand the issue. You have this feature way to hyped to toss it now . It is just too cool!

[MK3424]

Soyuz Docking Mechanism Update:

[spoiler=Spoilered as to not take up the entire page. ]So, I've run into a road block.

As Beale pointed out, if you do not follow instructions, and extend the probe while docked, and then undock, or load the scene in that state, the spacecraft explodes just a little... Because of that possibility, I've tried to dummy-proof the docking ports. Granted, it's really not that hard to use the docking ports properly, because if you dock normally, you'll never need to extend the probe while docked, and all will be fine, but, for the sake of safety, I've tried

The verdict is complicated: In the stock Shielded Clamp-O-Tron .cfg file, there's a parameter called deployAnimationController = 1 When 1 is a value for this, the docking port will not be allowed to animate while docked. In game, this is why you can't open or close the inline, Mk2, and shielded docking ports while docked.

The issue is this: This parameter activates in the acquire/magnetism stage of docking, not in the docked stage. This means, that if I enable this parameter, once you're soft-docked, you can no longer retract the probe to hard-dock. I experimented with stock Clamp-O-Trons and confirmed my suspicions.

http://i.imgur.com/2BtIZePl.png

As you can see here, the docking ports are trying to dock, but the I-Beams are in the way. While they're separated, I can't close the shields in the same way I can't retract the probe on my ports. Very frustrating.

Unfortunately, without writing a crazy plugin, there are limitations within the game that make dummy-proofing the ports difficult. As soon as the ports acquire, you can't retract the probe.

There are three solutions:

1. Remove soft-docking feature, but still allow docking port animation. It'll look cool, but it'll make no difference whether the probe is extended or retracted. Solely for RP purposes.

2. Allow soft-docking feature and animation and assume that people won't use the ports incorrectly. I've not been able to accidentally blow any ships up with these ports. The actions need to make things explode are very deliberate.

3. Both options. Option 1 could be included with vanilla Tantares, and I'll host and maintain the soft-docking ports somehow.

I'm actually thinking about sending a message to one of the KSP dev about this. If they made the deployAnimationController activate when ACTUALLY docked, instead of when you're in the acquire stage, it could allow further development of add-on soft-docking ports.

Anyways, please let me know what you guys think.

And what about disabling the right click menu of extend/retract once you're hard docked?

[curtquarquesso]

And what about disabling the right click menu of extend/retract once you're hard docked?

That's the whole point of the deployAnimationController parameter. It disables extending and retracting while docked. My issue is that it disables the extend/retract ability too early, and you can't retract the probe to dock. So basically, you're just stuck in soft-dock.

This whole point is moot if I don't use the parameter, but it's dangerous for people who want to "experiment" with parts.

EDIT:

While I was looking for the pictures of the old ATV IVA, I ran across this guy.

Is there any way this early part could make a comeback like that great looking 0.625m NERVA engine did? The one pictured would make a really great wide-nozzle 1.875m or 2.5m Apollo CM MonoProp engine. Sorry to bring up old work.

Edited October 28, 2015 by curtquarquesso

[minepagan]

That's the whole point of the deployAnimationController parameter. It disables extending and retracting while docked. My issue is that it disables the extend/retract ability too early, and you can't retract the probe to dock. So basically, you're just stuck in soft-dock.

This whole point is moot if I don't use the parameter, but it's dangerous for people who want to "experiment" with parts.

Well, not all experiments end well in real life.....

- - - Updated - - -

EDIT:

While I was looking for the pictures of the old ATV IVA, I ran across this guy.

http://puu.sh/er8tj/e46db3a5db.jpg

Is there any way this early part could make a comeback like that great looking 0.625m NERVA engine did? The one pictured would make a really great wide-nozzle 1.875m or 2.5m Apollo CM MonoProp engine. Sorry to bring up old work.

YES! MAKE THAT A 1.875m MONOPROP ENGINE! PLEASE PLEASE PLEASE PLEASE!

​sorry.

[Beale]

While I was looking for the pictures of the old ATV IVA, I ran across this guy.

http://puu.sh/er8tj/e46db3a5db.jpg

Is there any way this early part could make a comeback like that great looking 0.625m NERVA engine did? The one pictured would make a really great wide-nozzle 1.875m or 2.5m Apollo CM MonoProp engine. Sorry to bring up old work.

Well I did remake it, kinda!

Though there is quite a bit of difference.

Perhaps yes, one day, a MonoProp engine would be a good idea!