v1.10.14

Full Changelog: v1.10.13...v1.10.14

v1.10.13

Full Changelog: v1.10.12...v1.10.13

fix: inexistent table.HasValue call

v1.10.12

Full Changelog: v1.10.11...v1.10.12

feat: BaseClass:Clone constructor varargs
chore: rollback to previous sync-all way on player join

Support varargs to pass in the constructor of the class we clone an object from
The Clone method got an update on the docs: https://timmy.gitbook.io/classlib-1/scripting-reference/baseclass#clone

v1.10.11

Full Changelog: v1.10.10...v1.10.11

chore: validity check in SyncAllClassInstances

Make sure the object is valid/isn't being destroyed before marking it for synchronization.

v1.10.10

Full Changelog: v1.10.9...v1.10.10

perf: less objects sync net usage on player join

All instances of a networked class will be sent to the player on join at once, instead of sending 1 paquet per instance
This will avoid sending the class name for each instance, which can make a significant difference if many objects of a networked class exist

v1.10.9

Full Changelog: v1.10.8...v1.10.9

feat: treat broadcasted values in ClassLib.Clone

v1.10.8

Full Changelog: v1.10.7...v1.10.8

feat: SetValue values handler in Clone method

Previously, instance:Clone only copied the classic keys/values of the cloned instance, now it will also call SetValue on the new instance for values defined with SetValue on the target instance, and thus correctly trigger “ValueChange” events on the clone after its creation.

v1.10.7

Full Changelog: v1.10.6...v1.10.7

feat: number/integer check when setting "id" value

v1.10.6

Full Changelog: v1.10.5...v1.10.6

perf/refactor: value-based IDs for better change handling

Before, instance IDs were stored as a simple [key] = value on the instance, now it uses an “id” key with ClassLib.SetValue to allow easier
ID change catches
I first planned to create proxies for __index and __nexindex metamethods on the instance metatable, but after some thought I came to the conclusion that it would consume more by catching changes this way
The upside is that scripters have more control over ID overrides, which can be useful in (very) special use cases
The downside is that scripters can cause chaos if they call object:SetValue("id", something) without knowing what they're doing

v1.10.5

Full Changelog: v1.10.4...v1.10.5

perf: reduce all network events size by -16 bits