allmhuran

Members
  • Content Count

    1,435
  • Joined

  • Last visited

Community Reputation

598 Excellent

2 Followers

About allmhuran

  • Rank
    Senior Rocket Scientist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well, I have not been here for a while. I have so many hopes and questions, but I will limit myself to two. Q: Does KSP2 use the core KSP1 code in any way, or is it a rewrite from scratch? More specifically, is it coded using Unity's new Entity Component System and Job System? I realise that this is not something which comes naturally to physics simulation due to the physics-interdependent nature of the parts on a craft. Do colonies "do stuff when you're not there"? For example, does a colony produce and / or consume resources over time? Can I, for example, set up a mining colony on the Mun gathering Helium-3, which keeps producing as long as the snack supply is maintained with regular missions from Kerbin? And could I eventually set up snack farming at that colony in order to make it a self-sufficient producer? And if so, is there any kind of balancing mechanic which would prevent me from creating a self-sufficient-resource-production colony, turning on max time warp for a few seconds, and having effectively infinite Helium-3 as a result?
  2. The trick, as I recall, was to alpha as many mechas as possible with 4 simultaneous PPCs before they had a chance to start up.
  3. That last bloody GBL mission where you have to jumpjet up through the hole in the ship was so frustrating. Actually, GBL is the one I remember the least, except for that mission and the one prior (in which activitision valiantly attempted to to make a river and waterfall using their engine which had absolutely no ability to do rivers or waterfalls) Edit: Oh yeah, and the underwater mission, I think that was also GBL
  4. LOL! They are battletech mechs, they must use battletech loadouts
  5. Gfycat extract for those at work/on teeny devices/etc. Note: The embedded version of the gfy is of much lower quality here than directly on gfycat, not sure if this is always the case with gfys.
  6. I just tried the new release of this, thanks for keeping it going. Path mode seems to have an issue if you save a path and then want to use it again when reloading the kerbal save file. I had a path going around the KSC, but when I reloaded the game the first point of the path was in a different position and pointing up at the sky. Might be to do with the rotation of kerbin or its orbit around the sun? It seems like the path tool needs to store its reference frame.
  7. Unless @Grease1991 just means making sure the wheel is straight and level in the hangar? I never actually used adjustable landing gear, but I can see how that might be useful. Attach the part with the wheel strut at whatever angle you like, and have the actual wheel bit then align itself with the cardinal axes in model space. I don't know how important that would be anymore, since you can switch the rotation gizmo to absolute coordinates and turn on angle snap, although this will align the part as a whole, not just the wheel.
  8. For sure, it would be silly to remove the feature entirely unless a better solution for common use cases is developed. Forcing it to be on (even for some subset of parts) is the issue.
  9. Interesting. I recall you also mentioned that the grass around the runway seemed to be continuously calling collide events. Is that a direct result of having a physic material assigned?
  10. I doubt that the current implementation of autostruts is the only possible solution to that problem.
  11. After 12 months hiatus I finally decided to check whether various things in KSP had been fixed to the point where I could get my mech project restarted. So far things are looking promising!
  12. Solved with lots more investigation: Using rigidBody.gameObject forces a walk up the tree, since the physicsless part has no rigidBody (or rather, setting this flag causes the rigidBody to be ignored or removed at runtime). To return the actual physicless part, use the collider instead.
  13. I'm actually playing around with the code myself locally. The current version has a few issues with hit normals and penetration, I look forward to seeing what you've chanaged. For now I've commented out everything regarding "fulllyPenetrated" (sic) in the code
  14. Nah, they're used in different spots. For example, GetComponentInParent is used for the lasers, FromGO is used for bullet hits. But the difference is that when making the FromGO call it uses hit.rigidbody.gameobject, vs hit.collider.gameobject for the other call. So the two lines of code operate differently. Switching everything to the hit.collider.gameobject.getcomponent version makes it all work as expected, I've recompiled it myself and everything is fixed. I have an issue open on the BDA git site showing where to make the changes.