micha

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?

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?

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?

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.

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.

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?

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".

Really? I couldn't repo with that. Could you please try the 0.7.1 release and see if it works for you?

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

@DrPastah: Did this happen with the KEES Test experiment? Looks like I didn't port a particular commit from my dev branch to the release so any custom-built experiments won't work with contracts. Should work with the original 4 experiments though.

Oh poo. Why didn't i see this earlier (and yes i checked the forum! ) Might have to make a hot fix for the release now - thought I'd fixed this particular bug but it seems to keep coming back.

Ok people, release 0.7 (yayy, we actually finally made it to the release!!) is out. As nobody raised any real concerns with the last beta, I'm crossing my fingers that things will go just as smoothly for the masses and you all enjoy a fairly stable experience Have at it! EDIT: ... and 0.7.1 is out - a small hotfix which fixes experiment recovery for contracts for custom KEES experiments.

...! That's interesting. I'll have to see if I can disable that somehow. You can't do anything with the parts in the VAB anyway as they don't have colliders.

What do you mean by "Basic Mode" and "Advanced Mode"? The Kemini experiments never show up in the VAB directly, they show up when you right-click on a Mk1 command pod and use the "Add Experiment" menu item.

Just FYI, I'm currently the official maintainer of Nehemiah's mod collection until such a time as he is able to resume this hobby. As far as the Kemini Environmental Effects Study is concerned, I've just made a pre-release which allows people to add additional experiments to it just by editing the configuration files. I think I've also finally squashed the bug about experiments not being recognised properly when they are returned - you should no longer have to use the workaround of re-attaching the PEC after landing! Please continue any further discussions for this mod here.

Just FYI, I'm currently the official maintainer of Nehemiah's mod collection until such a time as he is able to resume this hobby. As far as the Kemini Research Program is concerned, I've just made a pre-release which allows people to add additional experiments to it just by editing the configuration files. Please continue any further discussions for this mod here.

Assuming no major issues are found I'm planning to make a proper release within a week. It -should- be safe to upgrade anyway but as I did tweak the savefile a little i wanted to see whether anybody has any problems with that first.

I've made a pre-release with quite a few changes. Here is the link to the GitHub release and changelog. Warning: This release may break save-games, and is not backwards-compatible, so take a backup of your saves before installing! I'd love to get some feedback on the KSPedia and the ability to add new Kemini and KEES experiments just by editing configuration files. Of course, any bug reports are very welcome as well. EDIT: I'd especially like some help from people who have established save games with this mod to see if the changes affect their saves or not.

I've made a pre-release with quite a few changes. The OP has been updated but here is the link to the GitHub release and changelog. Warning: This release may break save-games, and is not backwards-compatible, so take a backup of your saves before installing! I'd love to get some feedback on the KSPedia and the ability to add new Kemini and KEES experiments just by editing configuration files. EDIT: I'd especially like some help from people who have established save games with this mod to see if the changes affect their saves or not.

Autoloading still works in 1.3.1

I haven't worked out when it works and when it doesn't, but sometimes text changes are applied and other times not. It's very frustrating. And no, it's not fixed in the latest PartTools. EDIT: Ok, so it looks like the following happens: When you first create an entry in the KSPedia using the KSPedia tool, it sets up the information in the XML file, and copies any text into the XML. But if you change text in an existing item, it does not get updated! However; if you delete all the <text>...</text> tags out of the XML, it will now take the text directly from the prefab when re-generating the AssetBundle. Of course, this only applies for existing items; any new items have the same issue as above. TL;DR: After adding any new entries using the KSPedia tool, open the kspedia XML file and delete all <text> tags out of it to ensure the text is taken directly from the prefabs. Looks like my main issue has been not capturing sharp-enough images from the game itself. They looked fine in-game, but were horrible in the KSPedia. I've since been paying more attention to the quality, and there's a particular zoom-level in-game where the textures suddenly "snap" into focus. My new captures have been at that zoom-level and they look much better in KSPedia. So to re-cap, in my experimenting I've found that for the smallest KSPedia filesize and best image quality, you will want to import your images as "Editor GUI and Legacy UI", then add them to your prefab as "Raw Image". This can more than halve the final size compared to importing the images as Sprites, regardless of whether you then use the Sprite texture as a "Raw Image" or an "Image" in your prefab. I've also got up to half-a-dozen or more separate images on a page instead of using DMagic's method of combining them all onto one big image. The benefit, apart from being able to freely re-arrange them in Unity, is that you can re-use them on other pages without them taking up more resources. There may be benefits to doing it DMagic's way though; I haven't actually profiled the game while it's running.

I've finally managed to get started on a set of KSPedia pages for NEOS. Early feedback appreciated; download this file (for future readers: the link will probably break after this feature is complete) and put it somewhere in GameData.

I've done some more testing and while the filesize is definitely smaller with textures, the display of the images is less sharp than if you import the image as either "Editor GUI and Legacy GUI" or as "Sprite". Adding them as "Image" or "Raw Image" doesn't seem to make a difference here (although obviously if you use "Image" then you have to import as "Sprite"). But nothing I do seems to make the images properly sharp like in your KSPedia entries. Yes exactly Hmm, ok, but how do you line them up with the text? I've had a look at your GitHub repo for the images and yeah, you just have the lines as part of your images, but that must have been a royal PITA to line up...? I guess it is what it is..!

Not sure either; but I found a reference about it being very expensive to create the sprites (both CPU as well as RAM) on every draw and it being better if you just want to draw a texture to use the raw images. Can't find the reference again now. It's also possible re filesize that I forgot to uncheck the "Generate Mipmap" bit for the sprites; I can experiment more. Another general question to the KSPedia creators: what's a good way/utility of making the stock-alike white lines at 45̈/90deg and image borders that link text to images in KSPedia entries? I've noticed a couple of mods have the same look.

Ok, a couple of pointers/additions which stumped me for a bit; especially setting up Unity. When setting up your KSPedia Unity 5.4.0p4 project you have to add the following before you can get started: The correct PartTools package for Unity 5.4.0p4 - get it from this forum thread. TextMesh Pro - get it from the Asset Store within Unity. The free one will do. The patch to get TMP working (linked from the same thread as the PartTools package) The built-in fonts - "Amaranth-Bold" and "OpenSans-Regular" (You don't need to add these to your Asset Bundle). Restart Unity after doing the above! Apart from that the OP's post is still accurate, except when adding images to your KSPedia articles. Do NOT add "Panel -> UI -> Image". When adding images, make sure you add a "Panel -> UI -> Raw Image", then select the image file you imported into Unity for the texture. This drastically reduces filesize for your resulting KSPedia files as well as runtime resources. Also, for larger KSPedia's, it may be useful to split it into several files. Simply create more than one asset bundle; either one per page, or one per sub-section as you see fit, then assign the various prefabs and other assets to each asset bundle. You can still use the same categories, just don't assign a prefab to the top-level category. EDIT: The last paragraph may not be correct; it worked for 2 files, but more than that breaks the KSPedia in-game; still experimenting.