pap1723

Makes complete sense. I appreciate the great work you have done (and are doing) on SSTU! You have always been helpful enough to us at RO where you don't natively support it, but you have helped us with questions on how the modules / parts work for our own configs. That has been very good for us!

Thank you, I will! Just out of curiosity, why not support FAR as it is a better representation of real aerodynamics?

Any chance that the Space Shuttle Wings could be made to surface attach instead of Snap node attach? Snap node attached wings do not work with FAR and I wanted to include some configs for this.

Yeah, I was being specific in order to try and best explain the specific use case. Your way is much more flexible and has much better long term use for more people than just us. The area in red are representing Blue Skies Technology: https://www.wikiwand.com/en/Blue_skies_research It essentially means there is materials and electronics research that are independent of specific applications, but are necessary for more advanced technologies. We have used them to essentially limit things so players cannot rush engines to the end of the tree.

@ev0 I am wondering how hard the following would be: Add a hook into HETTN that basically does this: IF ParentNode contains "materialsScience*" or "electronics*" { Never remove node } Put that feature in that I can backport to a 1.3.1 release Thanks!

first

Yes, this should be easily doable with MM code... @PART[*]:HAS[#techRequired[wantedTechToChange]]:FOR[zzzzzTARDIS] { techRequired = newTechToChangeTo } I am almost positive that syntax above is correct, however, I may have forgotten something simple.

@a_schack and @Steven Mading I have been following this string of comments and ideas surrounding the missions and find many of your thoughts and ideas that are raised here, interesting. The gating is something that is done so that players cannot land someone on the Moon in 1952. There needs to be proper structure and groundwork laid, but in KSP, it isn't completely possible without having "gating". With the new version of RP-0 that will be coming out, many of these early exploits are not possible. But, all of that being said, I have taken the advice of adding a strong NOTE to the Moon mission to let the player know that they need to upgrade the Astronaut Complex to allow Flag Planting.

Hello @Mandella, RSS for 1.3 ***might*** break certain parts of saves. We are adding Ceres and Vesta, as well as the 5 moons of Uranus. Ships that are in orbit, or on their way somewhere might not be where you expect them to be. If you do not have things interplanetary, it should not be a problem.

RP-0 uses USD normalized to 1965 and then divided by 0. There are no tourist contracts available.

So, i went ahead and created one. All credit goes to @meyerweb! https://pap1723.github.io/RSSResonantOrbits/

No fixes have yet been released. I have taken on some other projects that are occupying my time. I will try to get to this soon.

Done!

As an example. I have resized the SSTU-ST-GEN-DSP-ISS to rescaleFactor = 1.83.This gives me very accurate (almost exact) sizes of the ISS Solar Array Wings. I wanted to do the same thing for the SSTU-ST-MST-ISS and I rescaled that to 1.83 as well, but the solar array model ST-MST-ISS stays at the default scale.

@Shadowmage Thank you for your continued help in answering my questions! I am now working inside the SSTU_MODEL in order to change the statistics of the Solar Panels, and it is working great! The one thing that I cannot figure out, is how do I change the scale of the 3D model to increase the sizes for the SSTU_MODEL configs? Thank You! Pap

Hello @Steven Mading I just looked at the syntax of the contract and it is correct. I believe that you might have just come across an error that sometimes happens with Contract Configurator. Did you try transmitting the science to see if that checks off both boxes?

Thank you @Shadowmage for the great response, as usual! What I was trying to do is to have less Solid Fuel available at the default scale. As it is right now, the Interstage Decoupler (without any modifications) fires for longer than I want it too (too much fuel available). I was trying to cut that in half. An off the wall question...and no is a perfectly acceptable answer, I want to work on creating FAR configs for the SSTU-SC-E Wings. However, with the Wings and the Strakes integrated as one piece that is not possible. Is there any chance you could provide me with them as separate parts and allow me to redistribute just them within the RO mod? Thanks, Pap

Hey @Shadowmage, I am still loving everything about SSTU and I have modified almost all of the configs to make things RO compatible. I am trying to determine how I can change the amount of solar power that is generated from the Static Solar Panels that are integrated into models (currently, it is the SSTU-SC-A-SM) but I know it will be others down the road. MODULE { name = SSTUSolarPanelStatic suncatcherTransforms = SC-C-SM-Suncatcher1,SC-C-SM-Suncatcher2 resourceAmount = 1 } That is obviously the relevant code, but what is the resourceAmount = 1 signifying? Is that 1 EC per second? The other strange one I came across is the Interstage Decoupler. I figured out how to modify a lot of the values, but I cannot get the Fuel to scale correctly. Here is the relevant data from stock SSTU: RESOURCE { name = SolidFuel amount = 70 maxAmount = 70 } MODULE { name = SSTUInterstageDecoupler ... defaultModelScale = 5 resourceVolume = 1 engineMass = 0.15 engineThrust = 500 scaleThrust = true thrustScalePower = 3 useRF = false fuelPreset = Solid ... } I have changed the values to the following, and the thrust values and everything works right, but the amount of Solid Fuel is not scaling in a way that understand. @MODULE[SSTUInterstageDecoupler] { @resourceVolume = 0.1 @engineMass = 0.1 @engineThrust = 50 @thrustScalePower = 2 ... } Thanks again for your help and for the great mod!

@NotTheRealRMS The issue is with the wings, elevons and tail for the SSTU Shuttle. FAR cannot have wings that are node attached, they must be surface attached in order to work. You should be able to accomplish that through the CFGs with MM.

@Shadowmage Yep! That did the trick, now if I want to fine tune it a little bit, that will be easy enough to do. Thanks!

Hi @Shadowmage, I am hoping you can help me understand the numbers I am seeing. I am trying to set sizes of the engines and to then determine what the Mount Sizes will be. Can you help me with the math and how it all works? Here are the modified numbers of the RD-0110: @engineScale = 1.5646 @engineSpacing = 2.3 @engineMountDiameter = 1.9 @diameterIncrement = 0.1 If I clear the mount to be nothing, the mount is still set to be 2.2. I cannot figure out why it defaults to this when none of those values are set above and the mountSizeMult = 1. Thanks for the help!

Will that screw you guys up at all? @Galileo

@Gleisix. Unfortunately, it might break when the new release happens. We are adding Ceres, Vesta and the 5 major moon ms ot Uranus. This may or may not effect the location of your crafts. That being said, there will most likely not be a release for quite a while.

Hey @nightingale, I have a question on a DATA node. If I have a current contract that requires you to have crew on a vessel, can I use the DATA node later in the contract to get the names of the crew that is on board? What I am trying to do is to have 2 vessels rendezvous in orbit and then to have them both have to safely return their crew. I have tried to just sepcify ReturnHome, but it can be completed and checked off by either vessel. Thanks! Pap

Thanks for the note and idea! I have modified the contracts to take this into consideration. Pioneer 10 flew some 130,000km by Jupiter and Pioneer 11 and both Voyagers were closer. I have set both Saturn and Jupiter to be flyby of less than 150,000km and Uranus and Neptune to be less than 100,000km. Fun fact, Voyager 2 flew within 5,000 km of Neptune atmosphere!