Jump to content

KOSMOS 3/14/2015 RD-170 Family Released!

CardBoardBoxProcessor

By CardBoardBoxProcessor
in KSP1 Mod Releases

 Share

Recommended Posts

CardBoardBoxProcessor

CardBoardBoxProcessor

Posted
  • Author
Posted

At work. Nothing to do. Looking at Proton Rocket. RD-210 engine is used in a cluster of 4 in the second stage and 1 modified with gimbals engines for the forth. The Proton would be 3 meter Kerbal Kosmos scale..

Should I make egine made of clusters of four or just allow for 4 to be attached.

Link to comment
Share on other sites
JoseEduardo

JoseEduardo

Posted
Posted

still good news that we have a chance of having a KOSMOS Proton :D

btw, i don't donate because our communist president is screwing the economy, the dollar is getting really high and things are getting expensive each day, otherwise i would gladly donate :blush:

btw i know this isn't the topic for it, but since you're talking about future plans, do you have any plans to update the Dragon? :D

Link to comment
Share on other sites
CardBoardBoxProcessor

CardBoardBoxProcessor

Posted
  • Author
Posted (edited)

What is a dragon? lol. but it is possible. but... the rela Dragon 2 is sort of ugly so I don't really want to bother lol.

Hrm. URM-3 (which would be PRton sized) is totally different than URM-2 (which is similar to URM-1) so it will looks different than the tohers. which should be fine I suppose. Simply scaling things up is boring.

Edited by CardBoardBoxProcessor
Link to comment
Share on other sites
CardBoardBoxProcessor

CardBoardBoxProcessor

Posted
  • Author
Posted

Dat A5

25155539.jpg

in other news.. URM-3 tanks would be different. For example the secound stage tank has no space between upper and lower tanks. just one common divider dome.

Phase%20IV%20Configuration.jpg

Where as Angara is more liek there is sapce between the upper and lower tanks. should we allow for each on each size of dcontiune this vast difference between URm-2 and URM-3?

4530324_orig.png

Basicaly multiple cofigureatiojn options for URM-2 and URM-3 or do you like them havign a difinit difference between the 2?

Link to comment
Share on other sites
Sage

Sage

Posted
Posted (edited)
Dat A5

http://kosmos-x.net.ru/_nw/34/25155539.jpg

in other news.. URM-3 tanks would be different. For example the secound stage tank has no space between upper and lower tanks. just one common divider dome.

http://www.ilslaunch.com/sites/default/files/Phase%20IV%20Configuration.jpg

Where as Angara is more liek there is sapce between the upper and lower tanks. should we allow for each on each size of dcontiune this vast difference between URm-2 and URM-3?

http://www.spaceflight101.com/uploads/6/4/0/6/6406961/4530324_orig.png

Basicaly multiple cofigureatiojn options for URM-2 and URM-3 or do you like them havign a difinit difference between the 2?

I'd say to make the three sizes slighty differents. Like having a common color scheme/style, but with unique twist to each of them: for the URM2 the common bulkhead is nice (it works for Saturns, too). For the URM-3 you could base it on the first stage of the PROTON, with a central OX tank and several lateral LF tanks, but that might be a bit too extreme and weird :P

Edited by Sage
messed up names
Link to comment
Share on other sites
MaverickSawyer

MaverickSawyer

Posted
Posted
For the URM-3 you could base it on the first stage of the PROTON, with a central OX tank and several lateral LF tanks, but that might be a bit too extreme and weird :P

Not really weird... Throw a node under each tank, and you've got an option for a high thrust 2.5m core engine, and the six other nodes could be, say, vacuum-optimized engines. Switch them with an action group, or even decouple the center engine and have a docking port underneath.

Link to comment
Share on other sites
MaverickSawyer

MaverickSawyer

Posted
Posted (edited)

Okay, possible bug...

When using the KOSMOS pack engines, I get uncommanded movements in all three axis while under MechJeb (dev build 363 at the moment) control. Mainly, this manifests itself as a severe roll, but pitch and yaw transients do build up with time. It seems that the engines may be moving around on the base of the rocket... not sure.

I do have Kerbal Joint Reinforcement and Tweakable Everything installed, as well as the latest version of the URMP plugin.

Anyone have any ideas as to what may be causing this... anomaly?

EDIT: Yeah, definitely an engine/MJ interaction. Seems that whatever gives the engine gimbals differential authority is causing the issue.

Edited by MaverickSawyer
Link to comment
Share on other sites
MOARdV

MOARdV

Posted
Posted
Okay, possible bug...

When using the KOSMOS pack engines, I get uncommanded movements in all three axis while under MechJeb (dev build 363 at the moment) control. Mainly, this manifests itself as a severe roll, but pitch and yaw transients do build up with time. It seems that the engines may be moving around on the base of the rocket... not sure.

The only ones I see that have a lot of wobble under MechJeb control are the RD-58SS and the RD-0440. The first one has a big gimbal range, and it uses a Firespitter plugin to animate the gimbal hardware of the engine. I suspect (but haven't verified) that the firespitter gimbal movements are adding to the gimbal range, so there's more control effect than MechJeb expects. With the RD-0440, it has two gimbals (one on each of the vernier thrusters), and I think MJ only looks at one of them, so it only considers one off-axis thruster for steering.

Link to comment
Share on other sites
MaverickSawyer

MaverickSawyer

Posted
Posted
The only ones I see that have a lot of wobble under MechJeb control are the RD-58SS and the RD-0440. The first one has a big gimbal range, and it uses a Firespitter plugin to animate the gimbal hardware of the engine. I suspect (but haven't verified) that the firespitter gimbal movements are adding to the gimbal range, so there's more control effect than MechJeb expects. With the RD-0440, it has two gimbals (one on each of the vernier thrusters), and I think MJ only looks at one of them, so it only considers one off-axis thruster for steering.

Okay, that explains it. The problem is most pronounced with the RD-58SS.

New problem: even when I have manually disabled the gimbals and tuned gimbal range to zero at the VAB, they unlock again after time acceleration while on the ground. Not sure about an in-flight unlock... haven't gotten that far yet.

Link to comment
Share on other sites
MaverickSawyer

MaverickSawyer

Posted
Posted (edited)

Uhm... Why is the dual-mode NTR getting an ISP of 280 in vacuum during operational use? It says it's supposed to be pulling 910, but I'm not seeing that.

EDIT: Further testing has revealed it to be isolated to the dual-mode NTR. Using the dedicated NTR version of the RD-0440 yielded the proper ISP curve. Also ran into the previously mentioned issue with MechJeb only seeing one of the vernier engines, but you mentioned you have a fix in the works for that, so no new news there. I'll take a stab at tinkering with the .cfg to see if I can do anything from that end.

EDIT EDIT: I've switched the placement order of the engine MODULE elements of the .cfg to put the main engine first. Don't have the time to try it now, but I'll test it first thing tomorrow and let you know if MechJeb sees the main engine first.

Final edit: Yes, the .cfg rearrangement did fix the MechJeb issue. Need to do that to my LANTR .cfg now.

Edited by MaverickSawyer
Link to comment
Share on other sites
braxfortex

braxfortex

Posted
Posted

First post here (long time lurker), so I apologize if I missed something important or am not following expected standards for posting.

I think I found a bug with the double Balka wings. I couldn't reliably get the full 400 ec/s that they should reliably get in almost all circumstances. It looks like there are two panels to 'activate' in the GUI, one actually unfolds and activates the panels, the other the hub. In the part.cfg file for them, each have 200 ec/s assigned to them, but one of them doesn't actually point at the sun and seems to be a virtual placeholder that just helps rotate the hub into place. After searching some old posts in the original release thread, I found how to fix the problem. Here is what fixed things in the part.cfg file for me:

PART
{


// --- general parameters ---
name = Kosmos_Balka_PanelBlock1
module = Part
author = Kosmos Team


// --- asset parameters ---
mesh = model.mu




// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z


node_stack_top = 0.0, 0.381, 0.0, 0.0, 1.0, 0.0, 1
node_stack_bottom = 0.0, -0.381, 0.0, 0.0, 1.0, 0.0, 1
// --- editor parameters ---


category = Utility
subcategory = 0
title = Balka Solar Wings Block
manufacturer = Kosmos Spacecraft Design Bureau
description = These absolutely massive duel solar arrays are so large they have earn the name of solar array wings. However they provide no lift and are easily destroyed by atmospheric pressure. They have the ability to deploy and pivot each array separately and each array can rotate around the central rotary hub to assure that they always assume the most effective line of sight rotation to the nearest star. 


// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,0,1


TechRequired = experimentalElectrics
entryCost = 312000
cost = 69000


// --- standard part parameters ---
mass = 1
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 8
maxTemp = 3200


//MODULE
//{
//    name = ModuleDeployableSolarPanel
//    
//    animationName = open_right
//    raycastTransformName = sunCatcherRight
//    pivotName = ArmLeft01_main
//    resourceName = ElectricCharge
//
//    chargeRate = 200
//    trackingSpeed = 0.1
//
//    powerCurve
//    {
//        key = 206000000000 0 0 0
//        key = 13599840256 1 0 0
//        key = 68773560320 0.5 0 0
//        key = 0 10 0 0
//    }
//}


MODULE
{
    name = ModuleDeployableSolarPanel

    animationName = open_panel
    raycastTransformName = sunCatcherLeft
    pivotName = ArmLeft01_main
    resourceName = ElectricCharge


    chargeRate = 400
    trackingSpeed = 0.1


    powerCurve
     {
        key = 206000000000 0 0 0
        key = 13599840256 1 0 0
        key = 68773560320 0.5 0 0
        key = 0 10 0 0
     }
}




MODULE
{
    name = ModuleDeployableSolarPanel

    animationName = rotary
    raycastTransformName = sunCatcherRight
    pivotName = Main_Rotary_Pivot
    resourceName = ElectricCharge


    chargeRate = 0


trackingSpeed = 0.1


    powerCurve
     {
        key = 206000000000 0 0 0
        key = 13599840256 1 0 0
        key = 68773560320 0.5 0 0
        key = 0 10 0 0
     }
}


//none below
}

I simply switched the lower block with the upper block, and moved all of the ec/s into the 'open_panel' block. If this is useful, you may want to make the change to the SSPP pack. The switching of order may not have been necessary after further study, but moving all of the ec/s into the one block does seem to be.

Link to comment
Share on other sites
CardBoardBoxProcessor

CardBoardBoxProcessor

Posted
  • Author
Posted
First post here (long time lurker), so I apologize if I missed something important or am not following expected standards for posting.

I think I found a bug with the double Balka wings. I couldn't reliably get the full 400 ec/s that they should reliably get in almost all circumstances. It looks like there are two panels to 'activate' in the GUI, one actually unfolds and activates the panels, the other the hub. In the part.cfg file for them, each have 200 ec/s assigned to them, but one of them doesn't actually point at the sun and seems to be a virtual placeholder that just helps rotate the hub into place. After searching some old posts in the original release thread, I found how to fix the problem. Here is what fixed things in the part.cfg file for me:

PART
{


// --- general parameters ---
name = Kosmos_Balka_PanelBlock1
module = Part
author = Kosmos Team


// --- asset parameters ---
mesh = model.mu




// --- node definitions ---
// definition format is Position X, Position Y, Position Z, Up X, Up Y, Up Z


node_stack_top = 0.0, 0.381, 0.0, 0.0, 1.0, 0.0, 1
node_stack_bottom = 0.0, -0.381, 0.0, 0.0, 1.0, 0.0, 1
// --- editor parameters ---


category = Utility
subcategory = 0
title = Balka Solar Wings Block
manufacturer = Kosmos Spacecraft Design Bureau
description = These absolutely massive duel solar arrays are so large they have earn the name of solar array wings. However they provide no lift and are easily destroyed by atmospheric pressure. They have the ability to deploy and pivot each array separately and each array can rotate around the central rotary hub to assure that they always assume the most effective line of sight rotation to the nearest star. 


// attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision
attachRules = 1,0,1,0,1


TechRequired = experimentalElectrics
entryCost = 312000
cost = 69000


// --- standard part parameters ---
mass = 1
dragModelType = default
maximum_drag = 0.2
minimum_drag = 0.2
angularDrag = 1
crashTolerance = 8
maxTemp = 3200


//MODULE
//{
//    name = ModuleDeployableSolarPanel
//    
//    animationName = open_right
//    raycastTransformName = sunCatcherRight
//    pivotName = ArmLeft01_main
//    resourceName = ElectricCharge
//
//    chargeRate = 200
//    trackingSpeed = 0.1
//
//    powerCurve
//    {
//        key = 206000000000 0 0 0
//        key = 13599840256 1 0 0
//        key = 68773560320 0.5 0 0
//        key = 0 10 0 0
//    }
//}


MODULE
{
    name = ModuleDeployableSolarPanel

    animationName = open_panel
    raycastTransformName = sunCatcherLeft
    pivotName = ArmLeft01_main
    resourceName = ElectricCharge


    chargeRate = 400
    trackingSpeed = 0.1


    powerCurve
     {
        key = 206000000000 0 0 0
        key = 13599840256 1 0 0
        key = 68773560320 0.5 0 0
        key = 0 10 0 0
     }
}




MODULE
{
    name = ModuleDeployableSolarPanel

    animationName = rotary
    raycastTransformName = sunCatcherRight
    pivotName = Main_Rotary_Pivot
    resourceName = ElectricCharge


    chargeRate = 0


trackingSpeed = 0.1


    powerCurve
     {
        key = 206000000000 0 0 0
        key = 13599840256 1 0 0
        key = 68773560320 0.5 0 0
        key = 0 10 0 0
     }
}


//none below
}

I simply switched the lower block with the upper block, and moved all of the ec/s into the 'open_panel' block. If this is useful, you may want to make the change to the SSPP pack. The switching of order may not have been necessary after further study, but moving all of the ec/s into the one block does seem to be.

but do the animation work properly?

Link to comment
Share on other sites
braxfortex

braxfortex

Posted
Posted
but do the animation work properly?

They sure do. At least they work the same as before I made the change. I noticed that the animations cut short if you activate one module before the other is done animating. That's the same the original way and with my change.

Link to comment
Share on other sites
CardBoardBoxProcessor

CardBoardBoxProcessor

Posted
  • Author
Posted (edited)

Good news. the Ambient Occlusion burn has begun. The RD-170 family will soon be in it's final skin ^_^ They are real lookers!

I definitely over did it on the Detail but I have been waiting and plotting to make these engines since their last iteration and I can finally make them as I want and more. And thanks to MOARdV for the plugins and NoMrBond for the awesome math(which i am terrible at) and cfg work they will be the best yet!

Edited by CardBoardBoxProcessor
Link to comment
Share on other sites
Sage

Sage

Posted
Posted
Good news. the Ambient Occlusion burn has begun. The RD-170 family will soon be in it's final skin ^_^ They are real lookers!

I definitely over did it on the Detail but I have been waiting and plotting to make these engines since their last iteration and I can finally make them as I want and more. And thanks to MOARdV for the plugins and NoMrBond for the awesome math(which i am terrible at) and cfg work they will be the best yet!

Ouch, I hope you have a good cooling system for your computer ;)

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...