micha

Members
  • Content count

    615
  • Joined

  • Last visited

Community Reputation

240 Excellent

About micha

  • Rank
    Sr. Spacecraft Engineer

Contact Methods

  • Website URL www.micha.name

Profile Information

  • Location London, UK
  • Interests Computer (games); Motorbiking; Scuba-diving; reading; travelling; ...

Recent Profile Visitors

1914 profile views
  1. Hi Galimba, Thanks for the kind words. The general idea is at least 3 launches (although of course you could try to do it in an all-in-one launch using MOAR BOOSTERS): 1) Launch the lab and dock it to your station. 2) Launch a station mission carrying the lab equipment using the Lab Equipment Container. The desired lab equipment must be loaded in the VAB. Dock this to your station and you can now install the Lab Equipment into the Lab using the right-click menu (I can't check right now but it's either by right-clicking on the lab itself, or on the Lab Equipment Container). 3) Launch a station resupply mission with an "ESC" container. Load the desired experiment(s) into the ESC in the VAB. Dock this to your station and you can now install the experiment using the right-click menu (again, not sure whether it's the menu of the lab or the ESC). Please note that Lab Equipment can only be installed into the correct Lab, and an Experiment can only be installed into the correct Equipment, so if you take the wrong Equipment or Experiment to your station it may not be able to be installed. You might want to try a dummy test on the launchpad before doing actual launches. If you still have issues could you attach some screenshots showing the exact problem? Thanks, - Micha.
  2. KDEX Continued Kerbal Dust Experiment v1.11 for KSP1.3.1 A one-part science mod with individualised science results for lots of places. Originally by masTerTorch.
  3. The NEOS mods also take time and are aimed at long-running orbital experiments.
  4. If anybody wants to test it and provide feedback, I've pushed a new DLL which supports KAC integration. Whenever an experiment is started, a KAC alarm will be generated which will trigger 30s before the experiment or experiment step is completed. Simply download the DLL and replace the current one in NehemiahInc/NE_Science_Common/Plugins with the new one.
  5. Send me the files or even better create a git pull request and I'll add them for the next version.
  6. And now available via CKAN Please note that this is not an automatic update. The mod is now called "Nehemiah Engineering Orbital Science" and conflicts with the older ones. Also, CKAN now only offers the full install, if you want only part of the mod, either download it directly from GitHub, or delete the relevant sub-folders from the install. The old ones will be removed from CKAN at some point in the not too distant future.
  7. Suggested layout of Unity?

    Yeah, that's how I did my KSPedia; I meant, do you / would you include the KSPedia into your Mods "Parts" project, or keep it as a separate project even though it's for the same mod?
  8. Suggested layout of Unity?

    So I was curious and attached the PartTools script directly to a part instead of an empty GameObject and exported that directly. Apart from having to fix a rotation, it got loaded into KSP no worries. This seems to indicate there's no particular reason to use an empty GameObject for your KSP parts in Unity?
  9. Suggested layout of Unity?

    Ok, cool, thanks guys. So a single Unity project with a single Scene, add a GameObject for each separate part, add PartTools to it, and all the bits for each part. Use additional empty GameObjects for layout/grouping purposes, and show/hide parts as and when needed. KSPedia in the single project as well?
  10. Suggested layout of Unity?

    Wait... "As long as the Part Tools script is added to each individual part (the object created when you drag the model into the scene)" - I've been attaching the PartTools script to the GameObject, not to the imported object (as per some tutorial I read a long time back). Ie: Scene - - GameObject (PartTools) - MyKspPart (Mesh, Mesh Renderer, Collider, Material/Texture, ...) Should PartTools be on the object itself? In which case what's the point of needing the empty GameObject at all? Or did I just misunderstand something.
  11. Suggested layout of Unity?

    The largest part of a Unity project is the "Library" folder which should never go into an SCM. So I'd save about 20-odd MB unifying all the separate projects (about a dozen). Mostly it's a management thing. You're right, time spent opening Unity isn't such a big deal I just thought I'd list it as I noticed loading the "all-in-one" project took quite a bit longer. Not sure how you manage multiple parts in a single scene. Aren't they all supposed to be at "0,0,0"? In which case they'd all be on top of each other? What benefit is there in having multiple parts in one scene? > But really, the best option is whatever works best for you. Sure; but given my noobishness with Unity, I'd like to stand on the shoulders of giants and see what has worked best for others.
  12. Just trying to gauge Best Practices while I'm upgrading the Unity projects for a large-ish mod I'm maintaining (I'm not very experienced with Unity). Do people use a single Unity project into which they put all of their parts (albeit in different scenes)? Or do people use one Unity project per part? Or something entirely different? The current layout is a bit of a mish-mash, some parts are grouped into a single Unity Project, others are in their own so I'm trying to see what the best way forward is. As far as I can see: Keeping each part (or small set of related parts) in separate projects: Pros: Fast loading allows multiple people to work on the project as long as they don't work on the same parts no need to worry about global namespace Cons: Need to maintain Unity project settings and add-ons and plugins (such as PartTools) separately for each project, taking up additional space in the repository and bigger chance for misconfiguration Maintaining a single Unity project (and separating parts into suitable directories): Pros: A single unity project easy to double-check global settings (eg, "Visible Metafiles" or the PartTools "GameData") single copy of plug-ins/addons potential for shared assets Cons: Slow loading more chance for conflicts if multiple people are working on the project more care needed to keep namespace "clean" (ie, must name all assets uniquely) What do people think?
  13. Oh ok - that explains your bug report more too. Because you're commenting in the development thread i thought you were using the latest. You can download directly from the release thread linked in the op (sorry on phone so difficult to add links). Ckan will be a few days yet - i only asked to update last night. Normally automatic but the package name changed. EDIT: CKAN is updated now. Please note that the mod is now simply called "Nehemiah Engineering Orbital Science".
  14. Really? I couldn't repo with that. Could you please try the 0.7.1 release and see if it works for you?
  15. Ok based on testing it only affected custom-build KEES experiments, not the original 4. Nevertheless I hotfixed the release and 0.7.1 is out. Thanks to everybody for playtesting and bug reporting