Marcelo Silveira

  • Content Count

  • Joined

  • Last visited

Community Reputation

150 Excellent


About Marcelo Silveira

  • Rank
    The art of gambiarra

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

1,748 profile views
  1. Check your TAC-LS patch at Tantares/Patches/TAC. The :FOR[TacLifeSupport] nodes should be :NEEDS[TacLifeSupport] nodes. If you don't use TAC you can simply delete that patch
  2. Nice work with the antennas you can complement that patch with a %MODULE[ModuleSPU] {} for the command pods and while at it, add a MODULE[ModuleRTAntennaPassive] to them as well, you can simply copy the parts command pod antenna settings. If I remember correctly from the time I played with RemoteTech, you can configure an RTAntenna to not behave as a relay but I'm no longer know how to do this, I might be wrong though so... ¯\_(ツ)_/¯ I made some RT patches a while ago, I can help you if you want. RemoteTach also has a nice guide on configuring parts for RT When finished, you can also make a pull request on github . That would be very helpful
  3. You can use TweakScale for that, the same goes to Sputnik 1 or Luna 2 (use the stock Stayputnik). Some interplanetary spacecraft like Luna 3 would be great I can help with a hullcamVDS patch if you want Luna 4-14 (Ye-6) , they had 3 variations lander, small orbiter and medium orbiter; Ye-8... just the descent module would be great! A sample return version (Luna 15, 16, 19, 20) would be interesting; Venera 2-4 (2MV and 3MV) can be made with the same parts as Ye-6, just with different solar panels; Venera 6-8 (V-67 and V-72) would need a dedicated atmospheric probe but used the same bus as 2MV and 3MV Briz A Soyuz cover. A conical-cylindrical shell with the same texture as the fairings, kinda like the improvised version below
  4. Interesting, the OGO probe core makes for a great rover body. I made some changes to its cfg so it can be used as best as possible as a rover. //Added nodes node_stack_X+ = 0.3125, 0.0, 0.0, 1.0, 0.0, 0.0, 0 node_stack_X- = -0.3125, 0.0, 0.0, -1.0, 0.0, 0.0, 0 node_stack_Z+ = 0.0, 0.0, 0.225, 0.0, 0.0, 1.0, 0 node_stack_Z- = 0.0, 0.0, -0.225, 0.0, 0.0, -1.0, 0 //Optimized ModuleCommand MODULE { name = ModuleCommand minimumCrew = 0 RESOURCE { name = ElectricCharge rate = 0.025 } hasHibernation = True defaultControlPointDisplayName = Forward CONTROLPOINT { name = up displayName = Up orientation = -90,0,0 } CONTROLPOINT { name = reverse displayName = Reversed orientation = 0,0,180 } } } I also copied the cfg to add a ballast version, without ModuleCommand just a Lead block. Its useful for testing launch vehicles
  5. Would it be possible to add a decoupler node to the Olympus S4-2 5m cryogenic tank (I know, it's a reDirect tank) so we can use it like the SLS tank (Olympus S4-JUMBO) that way we can have make longer ETs for heavier payloads.
  6. I don't know exactly how Jso balances batteries, but usually they use the same specific energy (Wh/kg or ElectricCharge/kg ) as the stock batteries. So a battery with 200 Ec should weigh 10 kg (0.01 t in ksp units) because the stock Z-100 stores 100 Ec and weighs 5kg
  7. Does anyone wants a TweakScale patch for the new solar panels? // @PART[nfs-panel*]:NEEDS[TweakScale]:FOR[TweakScale] { %MODULE[TweakScale] { type = free_square } } the new naming system makes things a lot easier
  8. can I say just one thing? WOW! This mod looks amazing! Congrats @benjee10
  9. ok, this raises some questions for me. Are you testing just the A-1CS capsule or are there any other parts in the vessel like parachutes and stuff? What do you mean by 5-10% more drag than expected?
  10. @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]
  11. The checkered pattern was used for ground based optical tracking. If the rocket was all white it would be very difficult to track its rotation using a camera on the ground. That's why many of the early rockets (1960s) have stripes while the more modern rockets do not. The guidance systems inside the modern rockets are supposedly accurate enough so you can rely on telemetry instead of optical tracking.
  12. Using B9PS has its pros and cons. Cons (in my humble opinion): It adds a dependency, which some people might not like... Pros (in my humble opinion): it greatly reduces part clutter. Honestly, I would go for the B9PS option