• Content count

  • Joined

  • Last visited

Community Reputation

137 Excellent


About Thrimm

  • Rank
    Rocketry Enthusiast
  1. 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
  2. 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.
  3. I think that Ground Construction can be used already, it's just not a requirement for the mod to function - I will think about adding a dedicated "construction module" part that will serve as a basis for your base building. USI-LS is currently in testing and I think looks promising so that will be implemented in upcoming patch. I have no idea about CKAN, I've never used it. I can ask CKAN moderator to add this mod however. I'm glad you like PD!
  4. Just left click on the airlock hatch.
  5. Quite interesting concept. The prices are surely not balanced and your suggestion is definitely a step in right direction. I'll add this to the update. Regarding the habitation, I'm testing different options right now as I really want to make this mod compatible and useful with other base building mods - starting with MKS. Right now I added to my domes a shared living space modifier, 500 months to large ones and 300 months to smaller ones. They have 0 crew capacity, as the idea being that the domes themselves only make other modules more enjoyable and comfortable to live, but not offer much more on their own. Where there are few Kerbals in the base, they have pretty decent hab time, and that was intended, but once it gets crowded the hab times decreases quite dramatically. I'll be happy to compare my results with you and figure out what the best settings might be. I made a bunch of other domes that I'm testing currently that have been specifically designed as crew quarters so those might work differently. Also regarding the airlocks, their crew capacity will be gone with the next patch as I intend to make them hollow with animated doors, much like the other parts this mod provides. I'm also working on adding more dome friendly interior addons, such as greenhouses and plant pods, trees (as suggested earlier in the thread here) and maybe custom processing plants. But that's later down the road. The next update, which is going to be released relatively soon as I just need to make sure that all the animations are working correctly together and rework some models to support them, will add a bunch of new domes, new airlock behavior (model is largely the same, but with interior) and make them shippable in containers. I'm also experimenting with making tunnels behave as KAS pipes and MKS Flex-o-tubes. If this works and you will be able to walk inside, this is the way to go in my opinion. And hey, I'm glad you like my videos
  6. Hi, it turns out that I forgot to add the appropriate module to the airlock! I'll be fixing that with next release, but for the time being you can just add the following to the airlock.cfg: MODULE { name = ModuleScienceContainer reviewActionName = Review Stored Data storeActionName = Store Experiments evaOnlyStorage = True storageRange = 2.0 } It should fix the problem. Post a picture of your base please, I'd love to see it!
  7. Hello guys! A quick update on what's been going on for the past months with this mod. As we have no real news from SpaceX about the design for the split body flaps, I tested multiple different options myself. I tried adding them as built in parts to the landing legs, to the body of the spacecraft and unfortunately none of those solutions seemed to work. What I was getting was some level of control over the ship, but nowhere near what is needed for realistic reentry let alone flipping the vessel for landing on Earth (without reaction wheels that is). Problem with this ship design is that is looks like a bullet and really wants to fly straight, so adding small control surfaces doesn't really counter that. Also, for some reason FAR enforces somewhat strange orientation of the vessel even in level flight (rotated by about 60 degrees, on fin facing down) and I'm not exactly sure how realistic this is - and it is important because if want to stick to original SpaceX concept of having control surfaces for pitch and yaw only, then the roll problem has to be tackled separately. I've been toying around the idea of making the ship modular, so command pod, fuel tank, engine mount, cargo bay, engine mount etc. so assembling a crew or tanker version of this ship would be possible, as well as any other type of monster you could come up with. It would require some changes to the overall shape of the mesh but it might be possible - I would like to hear your opinions on this. Last, with all of the aerodynamic problems listed above, I decided to acquire the Aerospace Toolbox for Matlab and I will use to calculate real aerodynamics of the vessel and then transfer the approximated values to the game. At least we might hope it will be realistic and maybe we will find if there are some real problems in the design, and not just the game related ones. On top of that there are still optimizations and patches for RO. I have mostly finished working on RealFuels patch, but I have little experience with other parts of RO, so if anyone would like to contribute it would be greatly appreciated. Another thing I tested is adding the heatshield as a separate part that is in fact a heatshield, not just a decoration. It is possible and I think it would add to the realism, but we're limited by game aerodynamics (docking port already causes issues sometimes, adding extra drag to one side).
  8. For the moment, you need to use KAS to do so, or add a Konstruction port and dock two components together, and then fix them. That's how I do it now most of the time. I feel like I owe you guys an update on what's been going on with the development. Among other things, I wanted to make domes deployable from a container that you can ship in a cargo bay. Problem is, that it's really difficult to make a simple animation for deploying rigid domes, that doesn't look like they are inflatable. But that's a minor point. Second problem is that I wanted to make airlocks hollow with animated doors that you can open and walk through. This as you have probably figured out causes issues with the dome walls themselves, so the domes now need to have a second order animation for adapting to the airlock while it is present. On top of that, attachment nodes in stock KSP cannot be animated so I would either need to fix them in deployed position or make/use a module that animates them, like IR or Konstruction ones. This is already getting complicated as you can see, even from the end user perspective (multiple animations available once you dome is deployed and it would be very glitchy, as it would be up to you which part of the dome transform to fit the airlock). As for docking the tunnels, I tested an experimental ring docking port and in principle it works. It's a part that has the shape of the tunnel, hollow inside, that you attach to the airlock and to the tunnel and you can now dock them together. There are only two problems with it: you often end up docked rotated and it looks bad, and it increases part count by quite a lot - now a connection between 2 domes need 7 parts instead of 3. I tried adding some sort of locks to ensure correct rotation but that didn't really work. I have made a number of models for new dome types but they are not implemented because I wanted to figure out the shipping problem first. As you know, I'm not good at C# so I also started learning the language to make the needed modules, but I have rather limited time and therefore it is taking some times (ok very long time). Nevertheless, I'm prioritizing this mod for the moment over SpaceX ITS and directing all my available resources to its development. Anyway, I'm really happy that you guys enjoy the mod and I can promise you I'll do my best to keep it updated and expand it in the future. The bottom line here is that I greatly underestimated the amount of time and effort needed to implement the features I want and greatly overestimated the amount of spare time I have - but I'll do my best anyway. Cheers!
  9. Yes it does work with 1.2.2 and regarding your second question, you can either use Extraplanetary Launchpads, Ground Construction or any other mod of your choosing. Or you can do it the way I've done it:
  10. I wanted to make things simple and start with just removing homesickness if a dome is present in your base. Or at least greatly increasing hab multiplier. As for the topic of IVA-less things acting as IVA spaces, I'm not sure how it could be done. However, MKS from @RoverDude uses some sort of distance detection for vessel interaction (namely scavenging) and since Kerbal are technically vessels, maybe there is a way to tweak this behavior into acting as if there was an atmosphere inside the dome. I'm not sure, one thing that I'm not is plugin specialist
  11. It's not the size, but so many conceptual changes + functionality extensions and new parts that it might be impossible to maintain compatibility. Also, I am thinking about adding some features explicitly related to MKS. I think that setting up a domed base should have some benefits (apart from killer looks obviously), so I was thinking that if domes removed kerbal homesickness that would allow building a permanent colony. If you guys have some other base building mods that would work well in this regard let me know, I'll try to make them compatible. As for Kerbalism compatibility, I'm working on it, but I would love to hear what features you would like to see implemented. Thanks for all your support!
  12. @JadeOfMaar awesome looking base! As for the floors, I'll add extra nodes as well as some texture tweaking with the release that is coming up. Although the update is getting so bit that it might actually be split in two.
  13. You can still use it with the latest version of KSP, that is why it's not updated. I'll update it as soon as there is something new to add. Which might be sooner than you think
  14. Added to the to do list.