[h2]Hello Ectypes![/h2] We are trying out this new [i]“Space Log”[/i], as an additional channel of communicating more to the Void Crew community. We want to share more about what we are doing, some of the challenges we experience and what we are working on. We are working on several parallel tracks, developing cool new features and content for the game, as well as bug fixing and improving the quality of the game experience. We hear you, there are bugs that are on the [i]must-fix[/i] list that we are working hard to clear out. Our message to you is: We are committed to both. Please continue to provide us with your feedback, so we can make Void Crew the best it can be. And then some. So, without further ado, our first Space Log: [h1]Carryable items - What can cause problems for players?[/h1] [img]https://clan.cloudflare.steamstatic.com/images//43802314/e52f63d5dfcae47e21b2723621060a4439d143a3.png[/img] Some players are experiencing delays in-game, when inserting carryable items into sockets aboard the spaceship. [h2]Background - Tech talk[/h2] Well… not vital for this fix, but for tech insight: Void Crew is made in Unity 2022.3.4f1 LTS. Overview - Carryables and sockets used to rely on a networking logic flow that relied on locking and unlocking their interactions. Old flow would roughly go as (might differ quite a bit depending on what exact operation you are doing): [list] [*] Lock current carrier [*] Lock carryable [*] Lock new carrier [*] Remove carryable from current carrier [*] Insert carryable in to new carrier [*] Unlock new carrier [*] Unlock carryable [*] Unlock old carrier [/list] This would: [olist] [*] Create a lot of delays for remote players since all of the requests would have to be communicated with the host. [*] Plus, if anything got lost/interrupted in the flow there was a chance that the carriers/ carryables would remain in locked state. [/olist] Even though an extensive work on addressing all the edge cases may have helped with the reliability of the system, it would have been unlikely to fix the delays. With that in mind, we chose to scrap most of the old logic. [h2]Solution - Carryable items rework[/h2] Instead we reworked the carryable logic, to have it rely on ownership based carrying w/o any locks involved and a more optimized networking request flow: [list] [*] Tell the carrier to take/release/eject a carryable [*] Carryable transfers ownership of the carryable if needed (primarily during insertion) [*] On transfer callback (if needed): [*] Carryable ownership gets transferred - the new carrier can do whatever they want with it. [/list] This both should reduce the delays for actions (fewer message exchanges between host and remotes) and drastically reduce the risks of lockups (the object locking logic is gone completely). [h2]Solution being tested - Patch to be released in coming weeks[/h2] These fixes and carryable rework are close to completion, and we are seeing major improvements in the way carryables behave. But, we have to do further testing before releasing, so not quite ready for release yet. But our intention is to release it as soon as possible, and hopefully within the coming 3 weeks. Oh, and lastly… in the previous Update 1.5 we did ship another fix on carryables (Ammo crates), that also partially addressed transfer of carryable ownership and handling process when the owner of the socket is changing. This was to fix the ammo crate deletion logic locking up the ammo socket, if the deletion was done while players were entering/leaving the turret. This helped on some sockets, like the Litany Minigun. Fix further extended - This is now also being extended to other sockets that have extended locked periods for animations, such as the data shard or the homunculus/biomass sockets. Wish you lots of co-op chaos fun, [i]// Kris (Lead Engineer) and Hutlihut Games Crew[/i] --- [h3]Join us on [url=https://discord.gg/joinvoidcrew]Discord [/url]to keep in contact and interact with the community![/h3] [img]https://clan.cloudflare.steamstatic.com/images//43802314/f3fca3cda71652b7aee363dcb0e64e197b18d814.png[/img]