Jump to content

Taverius

Members
  • Posts

    758
  • Joined

  • Last visited

Everything posted by Taverius

  1. None apart from the ones you already know of for making engine autoshrouds not appear in parts list and the ladder/hatch ones. Ah btw, don't use .tga unless you really have to - its not compressed to .dxt on load, and ends up using ~3x as much memory. Your choices are .png: small on disk, makes small zips, no mipmaps unless ATM is installed, full color accuracy. .mbm: small-ish on disk, good load time, mipmaps, but huge zips, lossy compression - .dxt with custom header - will not respect truecolor flag in unity, always uses compressed color formats. ATM fixes the TGA compression bug and the png mipmap bug, of course.
  2. Its something you can add as a tag to a collider in Unity, and it tells KSP you cant attach things to them - useful when you're doing stuff like the shielded Mk1 Clamp-O-Tron, because you tag the colliders on doors with that, and you can still attach stuff to the rest of the part. Not sure if that's only 0.25. Also, the MM files replicate everything you did in the replacement .cfgs - there should be no need for the part.cfg files. Will look at the new version soon
  3. Ah. Well you want to look at zTVPP-Squad-Engine-Extra-SmallEngines.cfg zTVPP-Squad-FuelTank-Extra-SmallFuselage.cfg zTVPP-Squad-Structural-Extra-SmallFuselage.cfg Do the node fixes as an MM patch using :Final, and you should be golden.
  4. Uh, I can, but how will that help you find out which of your mods is messing with the nodes? I'll try to work out something later.
  5. None whatsoever, for a number of reasons: All SCRamjet research is top-secret, nobody has idea about the true stats except a very few things that can be gleaned from what we've seen of the tests, these being: You build the plane around the engine, not the other way around. The thrust is too low, fuel usage too high to use in SSTOs, so they're only really useful for low-payload surface-to-surface applications. The /minimum/ velocity at which they work is (quite a bit) higher than Kerbin's orbital speed. By the time you're going fast enough to light them, you're in orbit already. Anyway who tells you he's working on scrams does not understand what he's talking about. Well, unless you assume what little we've seen was all misdirection and the governments actually have awesome scrams that do everything including make coffee & fries and we just cant see them - but you can argue for anything if you're willing to put up with such silliness.
  6. You need MM 2.4.x for those to work. Also, you know about the 'NoAttach' tag, right?
  7. Got a few more models we're hoping to get ready, and it always depends on where DYJ is off to for work, but hopefully? P.S. I also clamped scaling so you cant make hourglass wings, fixed a bug that allowed some height offsets to creep in when moving the tip, redid the cost support to scale properly, fixed a whole number of wrong values that gave incorrect lift and CoL, and added support for a FAR 0.14.2 feature.
  8. Nah - FAR doesn't support trapezoids with non-parallel wing and root, and the values we use for stock lift are based on FAR. I'd rather not introduce things that stop the wings behaving like they're supposed to for their shape.
  9. Yup, control surface thickness symmetry has been F1XX0R3D. Also, SP+ pWing, and:
  10. @SirSock: I think that's possible, although I don't think FAR supports that kind of distortion - control surfaces are attached at the leading edge, and giving them a sweep doesn't do what you think it does here, so they would behave as if they had not been angled that way. I'll think about it, but once we figure out /how/ to rotate the transforms, its trivial to add tweakable buttons to make a control surface match the leading/trailing sweep of the wing its attached to. Aything manual would likely be via tweakable, as we'd rather not add another mouse command.
  11. Assuming it is a bug, its with FAR. Show it to ferram4, see what he says.
  12. You messed up something with your install. Try KSP 0.24.2, 32 bits if you're on windows, with only B9 installed. We don't do rescales, and the Altas is there only because Stock and KW don't have a truly low-profile 2.5m lander engine.
  13. Yup. ATM fixes all the bugs with texture loaders - we converted to png so you don't need to use ATM. It makes the package smaller as a bonus.
  14. The correct value is 650/2 for DRE You're free to tune them to whatever you want, of course, but that's the intended value. No idea - I haven't had the chance to play with KSPi since 0.23.5. Remember to avoid Tweakscaling ... pretty much all B9 parts. Including the engines, the default TS exponents are way off.
  15. I'll check the basic jets again with DRE, thanks
  16. The thing that cause slowdowns are particles that are being drawn in the scene. Nothings runs unless the effect is active, and the code is nothing compared to the drawcalls for your typical translucent texture.
  17. You can spawn the effects anywhere you have a transform so long as you have a PartModule to call a normal effects node. For example, the FSanimateGeneric PartModule can call an FX at the start and end of an animation.
  18. Docking nodes also work as decouplers. This is covered in the wiki.
  19. It requires though to use, and lots of reading stuff and messing with floatCurves
  20. Uh, It all looks correct here. Are you using DRE? 5.2 was missing some MM code to adjust the heat production we set for DRE, and they would overheat in a flash. We haven't done much past talking about it and trading pictures of starship bridges. K3|Chris is working on getting the S3 done, since that already has a model and quite a bit of IVA. That will probably be ready in time for 0.25, and the HX is the next one in line.
×
×
  • Create New...