micha

v2.0.0.6 is released for KSP1.11. Fixes a few issues and adds more part configurations. Please see the Changelog. Notably the StockFreedomAddon configuration is now enabled by default to have less restrictions. Also the "Enable Optional Passable Parts" option now takes effect immediately making it easier to tweak a parts' passability on the fly.

I've not been able to repro. Can you please send me a save-game and detailed instructions to repro? I enabled "Enable Optional Passable Parts" then made a part surface-attachable passable and added a couple of Radial Attachment Points and some more pods to those. Single CLS. I then removed one from symmetry, the craft remained as a single CLS. I then re-rooted the craft and again, the craft remained as a single CLS.

Release 1.3.6 is out. I've added some inventory to the pod and made most parts able to be cargo in-line with similar stock parts. I'm open to any balancing suggestions though.

Is there a reason that parts have a stack limit? Seems that volume/mass restrictions of the container would have covered it along with a "canStack" flag if a part should not be stackable for some reason. Alternatively could we add a "0" or "-1" value to indicate that a part can be stacked infinitely (assuming volume/mass limits are maintained)? Also it would have been great if the game could calculate a parts' volume (if not explicitly provided) based on its dragcube thus automatically making all parts up to a certain size storable in inventories. It's a lot of work for modders to explicitly add inventory support to all of their parts.. (yes, I'm lazy! ) Thanks for the awesome update and keep up the great work!

Thanks, especially for showing that the hatch EVA button still works. I'll take a look. https://github.com/mwerle/ShipManifest/issues/7 EDIT: Figured out a fix; will come Soon (tm).

Nothing at all? If the part which the crew member is in has a hatch then the Kerbal should go on EVA. If it has no hatch, then an error message should show up. It works for me so if the error persists, can you please share the log file and/or your save file so I can check?

Release 2.0.0 is out! This release breaks compatibility with KSP versions prior to v1.3 due to the addition of localisation. More languages welcome! It also adds support for KSP1.11's inventory and EVA construction modes - you can now bring a KDex on a maintenance mission and have an Engineer attach it to an existing craft. Enjoy and please let me know if there are any issues.

Donations to allow me to quit my full time job and work on this instead? FIrst of all (I haven't had a chance to test yet) it is highly likely that this mod continues to work just fine in 1.11 - have you tried it? If so, it would be valuable for me and the rest of the community to post your test results here along with any issues. Secondly when I do get around to verifying/updating it, I will post here. Sorry, but modding KSP is a volunteer project for most, if not all, modders, with at best the occasional beer token. Asking for updates shortly after a KSP update drops is considered quite rude in this community and has, in the past, led to some modders quitting entirely. Please be respectful of the many unpaid hours people put into this.

Working as intended. If you don't like it, uninstall KSP-AVC. Awesome update! Looking forward to getting some time to playing around with it. Might even be able to finally remove KIS-dependency from NEOS now! (Love KIS, just dislike dependencies..)

Hi @santiagokof I had a quick look and it's not difficult to add resizing the windows, but it will take some time. Certainly something I'll look at for the next release. In the meantime I've just released a small update to finally release @Grassland's chinese translation - thank you so much and sorry for the long delay!

I tried hard to make it easy to adapt to any developer environment.. let me know if you have any questions. All you should have to do is to set the KSPDIR variable in the ShipManifest.User.props file.

Hi Tokamak, Could you detail exactly how you try to move the kerbal as well as what settings you have in SM? Do you have ConnectedLivingSpace installed as well? Any other mods? A log file would be really useful... and ideally a savegame (with no required mods) which can repro the issue. Just had a quick play and I can't repro.. @Papa_Joe Hello and greetings Long time no see, I hope you're keeping well! Did you manage to get things compiled and running?

@capi3101 Can you please try https://github.com/bfishman/Docking-Port-Alignment-Indicator/releases/tag/6.9.1.1 @BenJee Ditto for you - I'm really sorry, but I didn't see your message from way back in July until just now..

Thanks. Looking in the log file, it seems DPAI is having some issues finding valid docking ports with your craft. Any chance of isolating the craft files where you got that error and uploading those? I'm guessing one of the rather large number of mods you're running has a custom docking port which is causing issues.. that said, DPAI shouldn't ever throw a nullref exception so I'll see if I can make it a bit more robust as well.

I'm really sorry, but I'm seriously busy with work (as in dayjob) right now. I will take a look as soon as I can, but that may still be a few weeks away... Please ping me again if you haven't heard by the end of the month.

Not a known glitch... will take a look.

Hi @Grassland, yes, you understood perfectly, thanks Copy the english version to "sm_dictionary_zh-cn.cfg" and then replace the english strings with Chinese. That would be awesome!! Sorry for the slow reply - I was away scuba diving this weekend.

The way to do it is with mutexes, but yes, it would halt the main thread while the second thread is busy writing the data to disk. If the main thread execution speed is of paramount importance, one approach is to always have the second thread at a lower priority. Then when it gets asked to perform the (lengthy) operation, it grabs the mutex, takes a copy of the data [1], releases the mutex, then performs the operation. You always want to reduce the amount of time that a mutex is locked. So in this case, the memory copy is relatively fast. In comparison, disk access is magnitudes slower, even on SSD. By working with a copy of the data, the actual write to disk can occur over many many frames without impacting the game. It will only use cycles on another core, or any left-over cycles in each frame. [1] That, of course, depends on the operation. In this particular case that's an option. But if the worker thread needs to modify the data then it's often not possible. Depending on the algorithm, it can still be improved through a combination of read and write locks, rather than the "hammer" of fully exclusive locks all the time. Using separate Read and Write locks allows for interleaving of operations, assuming that makes sense for the given task.

Marked latest release as compatible with KSP1.10 on SpaceDock and GitHub.

Marked as compatible with KSP1.10

Seems to be working fine with KSP1.10. @SkiRich I think so; at the very least, CLS makes use of it. It controls whether or not Living Spaces are connected. So even though the ships may be docked together, if the hatches are closed, CLS treats the ships as separate Living Spaces and stops Kerbals from transferring between them. Could be useful for example if you have "Hot Seat" installed which makes Kerbals move around, but you don't want them to enter a particular part of your ship.

Tested and marked compatible with KSP 1.10.x Should probably just mark it as compatible ad-infinitum until some distant future update breaks something fundamental..

Congrats on the nominal launch! Looking forwad to verifying the orbit myself later Remember everybody: Back up your saves, ESPECIALLY if you play modded, before upgrading! Ideally you should keep your "active" game completely separate from where you download updates (whether through Steam, Gog, etc). That way if an update breaks stuff, you still have the old version to play with while you figure out what broke and why.

Oh? I really need to learn more about Unity, I vaguely thought coroutines were basically a wrapper around threads. But if they run on the main thread there's no way for them to take advantage of additional cores. Just had a quick read and the main benefit seems to be that they can spread their execution across multiple frames. Good if there's some overhead left in each frame, not so good if the frames are already "full". In other words, highly dependant on single-core CPU speed + game load.

That makes sense, thanks. Fairly trivial to implement - logger writes to disk and, if log-to-screen is enabled to a queue, then the main thread's OnUI dumps whatever is in the error queue to screen. Unity is fragile though.. "Handle With Care" LOL