You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, players and entities must be online in order to call any of their ObjectRef methods. This is problematic for instance because player meta is inaccessible for offline players, or because a mod might want to continue manually managing and simulating on its own unloaded entities such as trains or carts on a fixed schedule.
Solutions
Once all ObjectRefs have UUIDs (which must not concern itself with this feature request yet), we could add an API along the lines of core.get_offline_entity(uuid). This would return an offline entity corresponding to the UUID. Offline entities should be a different type from ObjectRefs 1 (which are already a hacky mish-mash type of entities, invalid entities, ..., and players). Initially the API might be very minimal, providing for example:
Getters and setters for everything that is persisted: Position, velocity, acceleration, entity name, ...
Getters and setters for staticdata
A way to teleport an offline entity to a loaded mapblock ("returning" it), where it is then activated and turned into an ObjectRef.
A way to remove them.
For the implementation, we'd need a global lookup table from entity UUID to offline entity data on the SQL side of things to separate entity storage from mapblock storage.
Care needs to be taken when it comes to consistency and backwards compatibility.
Analogeously, we would want offline players. I think no new tables are necessary here. Instead of staticdata, players have meta (#6193), and players have a few more persisted properties, such as look direction.
Alternatives
For player meta specifically, a simpler API should possible, as ruben pointed out on the issue. (This misses / doesn't conveniently cover some use cases such as teleporting an offline player, though.)
There was a PR which just used player ObjectRefs, which I think was a mistake: #9177. It seems the suggestion of offline players was already floated back then.
Mod storage offers an okay alternative to offline player meta these days, but is inconvenient to use. For example you have to manually ensure that associated data is properly deleted when players are removed.
The "manually simulated offline entities" use case currently is possible to implement using dirty hacks. When you want these entities to teleport / return to loaded mapblocks, you have to spawn a new entity and somehow earmark the old one for deletion (for example using sequence numbers); you can't guarantee that the old entities will ever be loaded again and then properly deleted.
Additional context
Footnotes
Offline entities may very well be a sensible superclass for online entities, but I would be careful with inheritance here. Perhaps offline entities should really be something like a persistent "entity storage" member. I usually separate entities into a "persistent" and ephemeral table on the Lua side. ↩
The text was updated successfully, but these errors were encountered:
Problem
Currently, players and entities must be online in order to call any of their ObjectRef methods. This is problematic for instance because player meta is inaccessible for offline players, or because a mod might want to continue manually managing and simulating on its own unloaded entities such as trains or carts on a fixed schedule.
Solutions
Once all ObjectRefs have UUIDs (which must not concern itself with this feature request yet), we could add an API along the lines of
core.get_offline_entity(uuid)
. This would return an offline entity corresponding to the UUID. Offline entities should be a different type from ObjectRefs 1 (which are already a hacky mish-mash type of entities, invalid entities, ..., and players). Initially the API might be very minimal, providing for example:For the implementation, we'd need a global lookup table from entity UUID to offline entity data on the SQL side of things to separate entity storage from mapblock storage.
Care needs to be taken when it comes to consistency and backwards compatibility.
Analogeously, we would want offline players. I think no new tables are necessary here. Instead of staticdata, players have meta (#6193), and players have a few more persisted properties, such as look direction.
Alternatives
For player meta specifically, a simpler API should possible, as ruben pointed out on the issue. (This misses / doesn't conveniently cover some use cases such as teleporting an offline player, though.)
There was a PR which just used player ObjectRefs, which I think was a mistake: #9177. It seems the suggestion of offline players was already floated back then.
Mod storage offers an okay alternative to offline player meta these days, but is inconvenient to use. For example you have to manually ensure that associated data is properly deleted when players are removed.
The "manually simulated offline entities" use case currently is possible to implement using dirty hacks. When you want these entities to teleport / return to loaded mapblocks, you have to spawn a new entity and somehow earmark the old one for deletion (for example using sequence numbers); you can't guarantee that the old entities will ever be loaded again and then properly deleted.
Additional context
Footnotes
Offline entities may very well be a sensible superclass for online entities, but I would be careful with inheritance here. Perhaps offline entities should really be something like a persistent "entity storage" member. I usually separate entities into a "persistent" and ephemeral table on the Lua side. ↩
The text was updated successfully, but these errors were encountered: