Thrimm

Members
  • Content count

    74
  • Joined

  • Last visited

Community Reputation

165 Excellent

About Thrimm

  • Rank
    SSTO enthusiast

Profile Information

  • Location On the runway
  1. @Galileo thank you for this amazing mod, it's a very needed refreshment from the stock Kerbol system and the planets look stunning! I have a stupid question though, is there any "easy" way that this could be incorporated to the stock game as an extra star system instead of replacing it? I know there are mods that add multiple star systems but I'm unfamiliar with the details on how it's done exactly. I'd love to be able to explore both systems simultaneously though!
  2. Thank you a lot for your reply @PrivateFlip. The station has a slightly eccentric orbit with periapsis of 77,793m and apoapsis of 95,313m, so it is well above the atmosphere (well, maybe not 'well' but still). I'll try docking to something that is in higher orbit and see if the problem persists. You're doing an amazing job with a much needed mod so there is no need to apologize for anything . Actually the entire trip for the SSTO was documented in a video that I will publish today - I'm not sure if there are any additional info you can get from that, but I'll be happy to do more testing for you. Also, no harm was done as luckily Valentina had a quicksave insurance . As I said, this mod is an amazing idea and I absolutely love it! EDIT: It just occurred to me, is it possible that the allowed margin for the orbit the spacecraft will be placed in by the mod had its lower limit in the atmosphere, and this is causing the problem? I don't know how big the margin is, but in the tracking log the MaxOrbitAltitude=103.856 which is ~ 110% of the apoapsis value, so if the difference (~8500m) is subtracted from the periapsis as well, then it would indeed place the vessel in the atmosphere, or at least allow it. I have no idea actually it is just a wild guess
  3. I seem to have some issues with the mod and so far I was unable to determine where the problem comes from. I've tried tracking a resupply mission and a return mission with an SSTO and a simple resupply mission with a regular rocket, without a return mission. In both cases tracking ended normally, but once I order any of those two missions, after the required time has passed, ordered vessel is completely gone (it is actually destroyed by the game, see log file). I have a number of mods installed, so I'm yet to replicate this in a fully stock game, although I kind of need this mod to resupply modded space stations I'm using version 0.24 for KSP 1.2.2. Log files and tracking info: I would be super grateful for any help. Valentina wouldn't mind too I guess. Thanks in advance!
  4. @PrivateFlip Thank you for this mod, it just turned my KSP from tedious to fun again! Stellar idea and awesome implementation!
  5. @theJesuit I have new dome type ready but I wanted to add a bit more before actually releasing the beta. The domes are moving from being merely structural parts to parts with active nodes that will react whether an airlock is attached to a node or not, built in lights and also I want to add some functionality in USI-LS, turning them into efficiency parts. That requires more tweaking than I expected and I also had to completely rework colliders, which was painful. @NNYGamer Once the new functionality is in place the next thing I want to add are plant pods that go with those and even more dome types with specific functions provided LS mods are installed. So plant pods, trees, science labs and workshops are coming soonTM
  6. @JadeOfMaar That's a good suggestion, I just didn't expect anyone to install USI-LS patch without having the mod installed in the first place, but I guess one can never been too sure. I'll add it.
  7. @The-Doctor, as @theJesuit said, for now you have to edit TR config files if you want to be able to remove helmets/suits outside of Kerbin. I can't write plugins and I have no idea if such feature can be implemented. It seems to me that it might be possible, but I lack the skill to do it for now. Regarding the airlocks, just left-click on the side you want to exit. It has automated EVA disabled so you have to pick the hatch manually, just like you would normally do for any other pod. Regarding the compatibility, I'm working on a patch for USI-LS and I see @Gordon Dry here is working on TAC, so I guess patches are inbound I think the logistics system @RoverDude made for MKS could work like this, but then having multiple Kerbals on EVA, each counting as a separate vessel, is not going to be healthy for your fps. I'd rather go for suspending LS for Kerbals on EVA that are inside the dome altogether, but as I said, I can't make a plugin that would do any of this
  8. The domes are rather an eye candy and do not serve a particular purpose on their own. If you want to achieve the same suitless look inside the base you need to edit configs for texture replacer. I have no idea how, or even if it's possible to create a plugin that would detect that a Kerbal is inside a dome and remove the suit for that particular Kerbal. That said, adding some inherent purpose to the domes that would simulate positive impact if any life support mods are present is an idea I'm working on. I'm testing this with USI-LS made by @RoverDude and apart from having arguably cool looking bases, domes give my kerbals hab bonus. You can imagine having a greenhouse specific dome that would act as efficiency part for other greenhouses too. I have no experience with TAC so it's harder for me to talk about it. Regarding your camera issue, I think that it's centered on the root part of your vessel. Usually switching to different camera mode correctly resets the camera to CoM.
  9. This is a dependency update only but more just over the corner. A beta will be probably released tomorrow
  10. I'm reworking the assets currently. Apart from new airlock type (that you can have a sneak peek of on my channel) all domes have to be reworked to be compatible and all new dome types I made too. But, you can still use this mod in 1.3, I've just tested it, it works. Just install it manually. Good luck!
  11. Domes are going to be one of the main focus point of all the bases I'll build but there will be some videos dedicated to the mod specifically. Oh and the update is rather sooner than later - I'm excited myself about it!
  12. Sure! It's still WIP but if you want to try it out and share your thoughts, please do! Download Link
  13. It's not abandoned, there is actually a discussion going on in the development thread about what is currently happening and where we are headed, so check that out
  14. Yes I am. The actual problem that I am facing right now are not the aerodynamics calculations itself as this is rather straightforward, but rather implementing realistic aero behaviour in somewhat simplified model we have in KSP. You see the thing is that you can have a relatively accurate representation of a spacecraft in a numerical environment using complex numerical models and derive some sort of behaviour patterns from it and then you want to implement those patterns in much less sophisticated model that is represented in game, without the loss of generality. This is problematic, because game physics and aerodynamics has to be much less complex to be calculated in real time. It can be relatively easily achieved in the case of planes or simple rockets but here in ITS there are a number of somewhat interesting and non-canon solution that were implemented by SpaceX. Take grid fins for example - they work as a deployable control surface that generates very little actual lift when deployed and close to 0 when stowed. This is impossible in KSP. When a lift value is attributed to a game object it is always there, you can animate it and change its orientation but you cannot suppress it without developing a special plugin for it. Another thing is the vessel itself - it clearly is designed to rely on body lift with legs/fins being stabilizers. This creates another problem, because body lift in KSP follows much different lift-to-drag curve than regular lift does and is also omnidirectional. Regular lift is directional and is governed by an attributed game object. The problem arises when, as is currently the case, you attribute a regular lift to the stabilizers (in order to have them create a force in a specific direction) and rely on body lift for the vessel. This will cause the center of lift of the vessel to be moved very far backwards that will also follow a very different lift-to-drag curve as a function of velocity, resulting in the vessel being extremely nose heavy upon reentry. You could argue that one can add a lift value to the vessel itself to counter that, but then you end up with directional lift only which is clearly not the case in reality, as ITS has a point symmetry - I'm currently exploring that idea. Another thing that is a great simplification in KSP is the absolute lack of influence of airfoil on the lift parameters. That causes enough issues if you want to build a regular plane (especially if you want to copy an existing, real design) but here with all the new solutions such as gridfins, split body flaps and general use of different types of airfoils for the booster and the ship itself simply becomes very complicated. So for example imagine that you have the ITS vessel sorted out by flat out replacing body lift with regular lift and you've managed to make it omnidirectional to represent point symmetry of the vessel. Assuming that your vessel is now maneuverable upon reentry, total lift value you have in the game is now so high that it is unstable when attached to the booster, as its CoL has moved very far in front of CoM. This is an exiting issue in KSP that can be easily visualized if you try to build a DynaSoar replica or in fact put any spaceplane on top of a rocket. Obviously I could just simply increase the lift values for booster fins but that will just move it further and further away from being realistic. So the bottom line is that the main problem lies in finding those behaviour patterns for the spacecraft and the booster in a complex and accurate numerical environment that is provided by Aeorospace Toolbox (which can be very accurate if applied correctly) and the simplifying those patterns without the loss of generality in such a way that they are represented in the aerodynamics model we have in KSP, even with FAR. And since SpaceX decided to use a lot of non-standard solutions, it's currently causing an issue. Thanks, Mark P.S. I'm sure you're aware of this, but to further illustrate the lift problem we have in KSP, check out how the same design will behave in Simple Planes, where you can actually change the airfoil type on the wings and control surfaces.