Releases · Timmy-the-nobody/ClassLib

03 May 08:29

v1.10.3

12c8073

v1.10.3

Full Changelog: v1.10.2...v1.10.3

refactor: correctly timed "Spawn" event on client

In v1.10.0, I delayed the "Spawn" event on classes/instance to next tick on the client to ensure that the instance had correct IDs in the callback of this event (because on networked classes the ID was set after the instance was created)
Now for networked instances the ID is internally set in ClassLib.NewInstance , making it possible to have a correctly timed "Spawn" events

Assets 2

03 May 08:05

Timmy-the-nobody

v1.10.2

538cc2a

v1.10.2

Full Changelog: v1.10.1...v1.10.2

style: remove redundant isClassLibInstance func
This is just a minor change, ClassLib.IsValid is used over isClassLibInstance added in 1.10.1

Assets 2

02 May 15:55

Timmy-the-nobody

v1.10.1

2e7a767

v1.10.1

Full Changelog: v1.10.0...v1.10.1

fix: add missing instance validity checks in ClassLib internal functions

Assets 2

02 May 10:50

Timmy-the-nobody

v1.10.0

231fd41

v1.10.0

Full Changelog: v1.9.1...v1.10.0

Support late events dispatch on the client.
e.g: The server creates a broadcasted instance, and directly call a remote event on it:

before: The client aborted the dispatch since at the time the event was received the instance wasn't replicated on the client yet
now: If the instance isn't found, a spawn listener will be added to the class to dispatch the event once the instance is created

This also delays the “Spawn” event until the next tick on the client, to ensure that the id property is set to the correct value when the event is called.
It is because the id property can be adjusted on the client when the instance was created from the server on networked classes, and this happened after the “Spawn” event, so calls to object:GetID didn't return the correct ID in this case.
(This is subject to change, as I don't like the delay between the actual spawn on the client and the “Spawn” call)

Assets 2