# Developer Update - 27 August 2026 **URL:** \ **Category:** Dev Updates\ **Created:** [August 27, 2026, 7:36pm UTC](https://ask.vrchat.com/t/developer-update-27-august-2026/48877 "2026-08-27T19:36:07Z")\ **Posts on this page:** 1\ **Showing post:** 38

**Author:** ![Dor](https://yyz1.discourse-cdn.com/vrchat/user_avatar/ask.vrchat.com/dor/32/16396_2.png) [@Dor](https://ask.vrchat.com/u/Dor)\ **Post date:** [September 4, 2026, 12:05pm UTC](https://ask.vrchat.com/t/developer-update-27-august-2026/48877/38 "2026-09-04T12:05:41Z")

Something I neglected to ask with the variable bit widths - is cross platform parameter sync going to change at all with this? Currently we’re required to keep parameters in the same order, with the same type (due to bit width, but float/int are probably interchangeable, though untested), I’m presuming the only new caveat is same bit width too? Also on the topic of bits, any chance we could get new Parameter Driver operators to set/unset bits (if it’s one entry, it should display up to 32 bits as this may be used locally as well, and for synced parameters highlight the “synced” bits in some way like an alternate background), as well as the option to copy parameters from X bits to Y bits, this could be used, for example, to “pack” multiple parameters in multiplexing systems. Right now without horribly inefficient animator logic it’s practically impossible to set every bit in an int by a bool or set multiple bools via int bits (it’s possible, but it spans multiple frames due to multiple transition evaluations, or requires defining hundreds of transitions, one for each possibility, instead of nesting them), requiring us to create multiplexing int(s) alongside multiplexing bool(s), with these options we could slow down updates to as little as 1 bit per parameter update regardless of type, or reduce wasteful allocations and instead allocate just the the largest bit width used, and fill it with smaller types when the “large” types aren’t currently being synced. An alternative to defining specific additional operations, though I suspect far less likely (especially since you don’t want to encourage further uses of animators for logic, but I’d hope that any alternative we get would support this in the future so this work could be translated whenever the animator exodus happens), maybe an expression operator, where a parameter list is converted to variables (since parameter names aren’t always valid variable names conversion in some form would be necessary, I’m imagining A through Z), and an expression could be performed using them, i.e. `C = A + B; D = (B & (1 << 3)) != 0; E *= 3;` This would give us access to a lot of mathematical operations that are either impossible, impractical, or require complex (blendtree) setups. Also yes this should probably be a canny, but given the discouraging comments towards continuing to use animators for logic (despite not having an alternative yet), I have no reason to believe this would be considered unless it’s confirmed otherwise, so I rather ask here while it’s on topic. --- _[View the full topic](https://ask.vrchat.com/t/developer-update-27-august-2026/48877)._