• Content Count

  • Joined

  • Last visited

Community Reputation

689 Excellent

1 Follower

About micha

  • Rank
    Sr. Spacecraft Engineer

Contact Methods

  • Website URL Array

Profile Information

  • Location Array
  • Interests Array

Recent Profile Visitors

3,690 profile views
  1. 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.
  2. 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.
  3. 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.
  4. Marked latest release as compatible with KSP1.10 on SpaceDock and GitHub.
  5. 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.
  6. 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..
  7. 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.
  8. 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.
  9. 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
  10. The proper fix is to figure out what's causing the exception and then fixing that, not randomly removing or disabling features/settings. There's nothing inherently wrong with multi-threading. The most difficult thing about that is to ensure any state which is accessed by multiple threads is properly protected and indeed can be accessed from those threads (some Unity state can only be accessed from the main thread, for example). Haven't hat time to look at the sources recently, but ensure there are mutexes protecting shared resources. In the case of this mod (presumably) you could also take a take a copy of the data into thread-local memory before performing long (compress and write to disk) operations on them to minimise the amount of time you hold an exclusive lock on the data.
  11. Looking great, can't wait to try it! Might have to wait a while though as I'm going to be pretty busy the next few weeks (How do people get on the early-access program? Would have been nice to update some of my mods as I had plenty of time last weekend.. guess you need a minimum squazillion YouTube followers) A question/observation about the Kickback variant though: Why wasn't the new variant Kickback just plain grey? It seems to me the flag decals should have been used to plant the ESA logos over it for the missions instead of making it part of the texture. It's a shame it wasn't made as a generic variant.
  12. An editor is not supposed to be "easy on the eyes". It's not promotional material or something to hang up on the wall. It's a tool to be used and as the ergonomics of it are far more important than the overall look. Don't get me wrong, the design is critical, but the focus is totally different than a customer-facing commercial web portal where the aim is to get the customer to focus on the product, not the usability of the site. Syntax highlighting editors for the same reason. I want to be able to identify the bits I'm currently interested in quickly. I'd be interested to hear from any programmer who prefers a monochrome code editor these days. Anyway, not my decision, just my opinion.