Jump to content

benjee10

Members
  • Posts

    923
  • Joined

  • Last visited

Reputation

4,344 Excellent

Contact Methods

Profile Information

  • About me
    Salmon of Knowledge
  • Location
    United Kingdom

Recent Profile Visitors

32,901 profile views
  1. I'm afraid the answer is going to have to be 'try it and see what happens...' - as far as I'm aware, the module should be able to attach a prop to any named transform on the kerbal rig. However, I've only tried it with the helmet transform, and that's what we focused on during development, so your mileage may vary. Afraid I don't know what transform it would default to if you removed the attachTransform line, or if the module would even work at all without it. With a backpack you might also run into issues with the stock backpack/accessories being visible (since you would be able to equip both). We have a disableHelmet line specifically to deal with this for helmet replacement but I don't think we have a provision for this for other parts of the mesh. Best of luck!
  2. Yeah stuff like this is to be expected with the dev version - basically I am planning to overhaul the hatch textures on the existing parts to match the new parts better, so I didn't bother to add the old one to Z1 yet, which is why it's just a void
  3. my best explanation for this is that the solar arrays are cursed or haunted I'm unable to replicate this issue myself but I know lots of people have reported it. No idea what could be causing it. I am currently in the (very slow) process of completely remaking the solar array parts from the ground up, so hopefully that will fix the issue.
  4. Yes, just go into GameData/Benjee10_MMSEV/Parts/ and open up base_turbineHighDensity.cfg in NotePad or something similar, and change: maxWindTolerance = 3.0 to: maxWindTolerance = 10.0
  5. So to clarify you are welcome to make a part that fits with SOCK & release it however you please, so long as that part doesn't make use of models or textures from SOCK itself. So if you wanted to make your own Buran aft section that works with SOCK that is no problem. However, you may want to hold fire: There is still a lot to be done on Buran but I'm hoping to get back to it soon. The entire rest of the orbiter needs new textures to fit with the fully-tiled Buran look, and I need to make a new set of front landing gear & a variant of the cargo bay to fit it (Buran's landing gear are on the cargo bay rather than the nose). I'm wondering if people's preference would be for me to release the parts as they are finished (e.g. release just the aft section) or to wait until the whole craft is done.
  6. Yes exactly! So basically for simplicity and to keep the plugin compatible with any planet pack (without requiring special configs), the wind speed is based on atmospheric density. 100% wind speed is the base wind speed at seal level on Kerbin (i.e. at 1 atm). The wind speed is then multiplied by atmospheric density, so for example on a planet with 0.1 atm you would get 10% wind speed, or at 10 atm you would be at 1000% wind speed. Then, depending on your difficulty settings, wind speed gets randomly multiplied by anywhere between 0-200% at regular intervals to simulate changing weather conditions, and then each part's efficiency is multiplied by the relative angle to the wind direction. So you can reasonably estimate what wind speeds you could encounter by looking at the sea level pressure of a planet and then allowing for up to double that. Worth noting that the plugin does account for altitude (i.e. the actual pressure at your craft's location), so conditions at high altitudes on Eve are significantly different to at sea level. I believe we designed the tolerances on the parts such that you can get away with using standard turbines on Eve's highest peaks. Having said that I've just noticed that the heavy-duty deployable turbine's wind tolerance is much too low - it should be 1000% too. I should probably patch that...
  7. As a general rule of thumb, lightweight turbines are best for planets with a lower atmospheric density than kerbin, and heavy duty turbines are best for planets with higher atmospheric density. The standard turbines will work in either, but less efficiently. All turbines are destroyed beyond a certain atmospheric density, so expect them to break if you go too deep into Jool's atmosphere for example. The androgynous port is a new type of port, so will only dock with itself. The small low-profile 0.625m port will dock with the stock Clamp-O-Tron Jr. however.
  8. I’d call it feature complete in that I’ve covered the scope of what I was originally planning. There are certainly things I’d like to add if and when I have the time, but don’t count on it!
  9. The orange tank parts in this aren't actually particularly good for representing SLS since they're first and foremost meant to resemble the Shuttle/Jupiter tanks. Proportions aren't quite right and lots of details are wrong (LOX feed line number/position etc) so I wouldn't want to add a single part 'SLS' replica when it doesn't actually do a very good job of being a replica! The only reason there's a single part shuttle ET in the first place is for CoM reasons when building a shuttle, and I think even then that's pretty much obsolete now you can configure fuel flow. Wanted to gauge opinions on what the best way of handling propellant for the Orion service module would be - AIUI the AJ10, auxiliary engines and RCS thrusters all run on the same propellant and pull from the same tanks, so the most 'accurate' way of doing it would be to have the service module contain only Lf/Ox and have the RCS, aux engines, & OMS engine all run on Lf/Ox. Alternative is to stick with the current config whereby the RCS & aux engines run on mono prop, the OMS runs on Lf/Ox, and the SM contains a mix of both. Or (to keep the functionality of the aux engines being a backup to the OMS & draw from the same pool) have the aux engines run on Lf/Ox instead of mono prop. The final option would be to have the entire thing use & contain only mono prop.
  10. No plans to change existing parts I'm afraid, and besides 5m is the closest standard size for the Space Shuttle ET/SLS core stage. Generally we try to arrive at KSP sizes by multiplying the real world size be 0.625 and then rounding to the nearest KSP increment. The shuttle ET is 8.4m diameter which scales to 5.25m in KSP, so while marginally undersized 5m is closer to the 'correct' diameter than 5.625m would be. Starship is slightly larger at 9m diameter so that works out at 5.625m. 5m is the best fit proportionally and keeps everything simple in terms of adapters etc.
  11. No plans for this right now as that would set a precedent for including all sorts of previous/proposed Orion designs, which isn't something I want to commit to at this stage. There will be an update that comes along with Orion to ensure that everything works with the latest KSP version and includes the latest dependencies, but I don't intend to add any new features/parts or do anything art-wise with the rest of the mod. The current Orion parts will also be deprecated.
  12. The way it works is that the solar arrays work just like any other (have a deployment animation, track the sun etc) but there is a robotics module on the same part which just adjusts the angle of the panel. The only drawback is that you can adjust the angle of the panel when it's underplayed too, but the simplicity, flexibility and the fact that it keeps it as a single part outweigh that IMO. I hadn't considered that as a possibility for HabTech, but it's certainly an interesting idea... Might be something worth implementing as an optional extra/alternate config. The only issue with it is that a) robotics joints are fairly unstable over multiple warp/save/load cycles (not an issue for the Orion arrays as they're a single part) and b) manually tracking the panels would be a pain & wouldn't work during timewarp.
  13. Happy SLS rollout day (feels strange to have finally reached it)! To celebrate I have been creating a revamped Orion spacecraft. I was hoping to have it ready for today, but as always real life had other ideas. Still, here are a few in-progress shots of what you can expect (art is not yet final): Featuring white, black & reflective foil variants. This is a ground up remake of the entire spacecraft, so it won't be a drop-in replacement for the existing parts. The current plan is to split Orion out into a separate mod. At this point I don't intend to update anything else in reDIRECT & don't want to create an expectation to do so, and also don't want to tie people into using the very memory intensive reDIRECT orange tank parts if they'd prefer to use another mod. The plan is to include the Orion spacecraft, as well as abort tower and adapters to various standard sizes. Custom parachutes will also be included. The AJ10 engine is also getting a revamp, finally with emissive textures & a higher level of detail. Breaking Ground users will also be able to adjust the sweep of the solar arrays, just like on the real spacecraft! No ETA for release yet but I will keep you all posted.
  14. No plans for this I'm afraid as the amount of new texturing required would be immense, but here's an interesting fact - the concept artist for For All Mankind used a screenshot of SOCK as part of the concept work for Pathfinder: Look carefully at the front section, the tile layout matches this screenshot exactly:
×
×
  • Create New...