Jump to content

Nertea

KSP Team
  • Posts

    4,722
  • Joined

  • Last visited

Posts posted by Nertea

  1. The trusses are now done and will be in the next version of NFP!

    So, on to more random ideas. I was building a moon base, and was thinking that the structural fuselages that I was using for habitation tubes were a bit lame. So, I thought I might give a nicer looking hab tube a shot.

    tubeconcept.png

    They're supposed to be covered with spacesuit-style insulation material and be generally cool for use in ground bases and space stations. I mocked up a basic one, one with a viewport and one with an airlock segment. They're obviously quite WIP and would get more detail and proper textures. 1.25m size class... I suppose if I did one of these I would also do a couple of hub components. Anyone interested?

  2. These are actually around 2.5m already! So you'll easily be able to slide a 0.625m (or a little larger) probe in the empty bay.

    truss_stuff.png

    They are calibrated to be stackable and fit the modular girder pieces on the side like above without overlapping. The performance use won't be too bad, as all the trusses are identical in outer structure (and can thus share a texture). Only the insides will be different.

  3. So, despite the existence of quite some similar stuff from Kommitz, I'll probably finish off my truss set. I mean, it was already unwrapped, so it's pretty much 80% of the work done. Plus, I want to make some specific NFP-matching fuel tanks and such.

    So, here's what I had made. There's an empty purely structural truss, one with the sides cut out that will be attachable inside, one with a stock-style liquid fuel tank, and three NFP fuel tanks (Hydrogen, Xenon, Argon, try guessing which is which :P). Additionally, a 2.5m to large truss adapter, and a bonus skeletal 2.5m to 1.25m adapter.

    trusses.png

  4. It's super pretty! Would you mind if I used the design for an example NFP ship with the other mod packs stripped out? Credit would of course be given ;).

    Regex is correct on all counts--that's an NFP structural adapter with docking ports on capacitors arranged around a central core (those NFP structural parts are beautiful. I really wish there even more of them.)

    More will come!

  5. So I have a large number of engines that have slightly asymmetric thrusts (a rotation is created at high thrust). This is pretty vexing, and I'm not exactly sure why it occurs. So I thought I'd ask for help.

    1) The part's root (with the PartTools component) is centred directly on the Unity origin and contains the engine mesh, colliders and the thrust transform. As I understand it this defines the CofM

    2) The thrust transform is directly below the origin, pointing exactly straight down (typed the rotation in numerically) and aligned exactly with the origin in all but one direction (again, numerically entered).

    This seemed correct. Am I doing this right? Because some of my engines have an offset thrust and some don't. Anything else I should be taking into account? I can also add pictures if it would help.

    - edit: This is being tested with infinite fuel + a single MK1 command pod. So other parts shouldn't interfere.

  6. If you are planing to be modeling the lander pod after this:

    Then, you should put the docking port on the bottom, surrounded by the engines, as that seems to be what is shown in the picture

    There's no docking port, but there's a 1.25m node with room for one so it can be added at the player's discretion. I'm not a fan of integrating docking and other functions into parts so much. The service pod I did there was an anomaly :P.

    @m00f:

    The landing leg housing intersects a lot with the part it is attached to. Also it would be better if it was shorter, if possible. About the height of a landing pod.

    I'm just writing this because i've been struggling to make a realistic atmospheric lander for duna which can also carry a small rover. Your stuff would help a lot as it seems. But here is another suggestion: How about a cargo hold along the lines of this

    http://kerbalspaceprogram.com/st-spacet...-program-v1-0/

    The leg is pretty much scaled right off the picture, I'm not really going to change it. It intersects because it is supposed to be part of whatever you attach it on to - I quite like the look. If you attach it to a skeletal truss, for example, it still looks contained. I have no plans at present to make any cargo bays either, though I always want them when I'm actually playing KSP, I don't quite have the motivation at the moment.

    Nert, what modeling software do you use? (Cinema 4D, Sketchup, Blender, etc)

    A really old version of 3D Studio Max.

  7. Hi,

    So I have a module that modifies properties of a ModuleEngines module from GUI buttons. The actual game effects of the code are fine, but there is one issue: the activation of the module. It appears that OnFixedUpdate only runs when a part is actually activated, usually (always?) by a staging event. This is problematic because you can also activate a ModuleEngines module via the GUI right click menu, which activates the engine module just fine outside of staging, but which doesn't enable my addon module.

    I know that I can use part.forceactivate() to force the activation of all a part's modules on load, but that forces activation of ALL the modules on a part. In my case that means that the ModuleEngines would also be forced active, which isn't the end of the world, but is also bad because engines will get activated without player input. So, is there an equivalent way to force the activation of a single PartModule? Or am I misunderstanding how this works?

    The easiest solution is moving my code from OnFixedUpdate to Unity's default FixedUpdate and so it will run when the actual GameObject was active, which is pretty all the time (evidently with some checks for editor 'n such). However, that's not the most elegant solution, and I'd still like to know whether this is possible.

  8. I had some spare time so I have been testing the new parts. First of all, nice work. I especially like the stock-a-like look and the fact that the parts are versatile so you can use them in other crafts.

    Things I noticed during testing:

    - the landing legs bug you mentioned

    - when going EVA from the pod or grabbing the ladder in space the kerbals will do a 180 or 360 spin. Also on the ground the kerbals move faster across the service container ladder than the pod ladder

    - balancing of the parts is alright for me, nothing seems to be out of line (did a landing, ascent and rendezvous on Duna, had a reasonable amount of fuel left at the end)

    - perhaps you could create a nosecone part for when you don't use a parachute or jr. docking port, with maybe a functionality (science, probe, antenna)

    Looking forward to the release!

    Thanks for testing! I'll look into those issues when I can. I might make a part for the top eventually.

  9. I uploaded the various bits for anyone who want to test them, to test. The landing legs are still giving me some grief, they work some percentage of the time, but sometimes seem to stop working for no apparent reason at all. Most other things are done, though I have some texture work to do on the ends of the service pod and the internal fuel tank of the fuel pod.

    Appreciate any comments on balancing as well.

    I threw together rough IVAs (basic modelling, no textures) also for testing.

  10. What about a (relatively) simple sphere display overlay? Provide a model of a sphere with a standard cylindrical UV set, so that your resource abundance pngs map directly to their 'correct' locations on this sphere. Using a partially transparent shader of some sort, instantiate the sphere for each planet, for each resource map at the correct centre coordinates so that it's overlaid atop it. Display, say, one at a time.

    You could even then allow people to provide a gradient map along with their abundance png, which you could index into to colour the sphere for different resource colourmaps.

×
×
  • Create New...