Multiplayer support

[vlazed]

Expanding many of SMH's features to support multiplayer would unlock collaborative workflows for animation. This issue shall report methods for making this possible.

This feature may come closer to the end of the roadmap. Nonetheless, we should keep this in mind when it comes to adding to or changing different SMH features.

[penolakushari]

probably SMH will need some way to "assign" entities to players that first record on them, to prevent others from creating animations on them and having issues with playback. system like this could also allow to share same animation data with others on entities, so everyone sees same keyframes rather than their own, like how it was before.

it could allow for someone to load in their animation, and then give access to collaborator to animate some elements while they work on other, like foreground/background animating and etc. technically feature like this may also need to be able to work together with CPPI, or prop protection addons

[vlazed]

So the first time that entity gets a keyframe from, say, Player A, SMH sets its owner into the entity: ent.smh_Owners[A:SteamID64()] = true. The server could also keep track of selected entities from other players, so it broadcasts that Player A now owns the entity.

Then any attempts to select Player A's entity will be denied, unless Player A adds two other players: Player B and Player C. Then we'd just update the smh_Owners field.

I think having some perm hooks like CanKeyframeEntity or CanLoadAnimation would be good, too. The amount of control an animator can have depending on their role on a server would require some thought

[penolakushari]

yeah, probably there could be a thing where superadmins on server would be able to select anything, though otherwise by default could have a system where the first dibs is the true owner who gets to set permissions, with perhaps ability to relegate total control to someone else, or just give access to playbacking an entity, recording keyframes and etc. what i also remembered, is perhaps also be able to have ownership per keyframes too, but that could be quite a data load there. at the same time, it could open up a possibility to be integrated in gamemodes like some gartic phone animation mode, though that also could require being able to limit timeline range that can be recorded in...

[vlazed]

For permissions, the player can set some defaults in their settings. Those get applied anytime an entity gets keyframed first. There could also be an allowlist for steamids as a setting, so other players can quickly see other keyframes from the entity.

Keyframe ownership is interesting. This would just be the case where all entities have at most one owner in the smh_Owners field. It's simpler to think about it this way

[penolakushari]

another thing i just thought up, how would saving be handled in shared animation? as perhaps if there's multiple people working on one animation, some single person or several should be able to save whole thing, or quicksave/autosave, to counter possibilities where host would suddenly lose connection, or whole electricity at all lol

[vlazed]

Saving could be a part of the permissions system. Then those who can are only allowed to save to their local filesystem, or optionally to the server. Of course, saving to the server or client could be determined by the server owner. It might also be necessary to make delays for save requests, to prevent any malicious spamming to the saving feature. There could be a small server-wide delay to prevent a team of users from saving big data all at once, and a longer player-only delay that prevents the spamming itself. Just some ideas if saving ever becomes a server thing

In case the owner of the shared animation loses connection (and electricity), then ownership could be passed down. The hierarchy could look like this:

1. A "successor", if they are in the server
2. friends or group admins
3. first-join-first-own basis
4. optionally give to the server owner or an admin

If none of the above are met, then the data can be deleted immediately from the server to save up memory, with optional exit saving if the user has permission

As for autosaves/exit saves, I thought those would have to be done on singleplayer. Exit saves and autosaves can certainly save data to the clients only. One thing that I'm wondering about is a way to improve performance when saving data. From my experience, I've noticed autosaves with big animations tend to slow down my experience at intervals, to the point where I've temporarily disabled the feature via convar.

I think the bulk of the performance drop comes into converting a table to string in the client, so I'm thinking an asynchronous file.Write binary module could help relieve that. e.g. this repo provides such a feature.

[penolakushari]

probably solving multiple people trying to save smth on server could be done through queue, sort of how that netstreamlibrary does it from what i recall, so it's not everything being sent at once, but in sequence to each player. i was mainly thinking about host themselves losing connection, but yeah good call to also consider clients getting thrown out. does autosave still lag if the save is being done towards the server? or we're not gonna be doing autosaves to server, though perhaps as safety, there could be some way servers would know which player made saves, and then uphold some filesize limit so people wouldn't be able to spam storage with smh saves?

[vlazed]

I think a serverside queue would work. Then players can't spam the save button until their out of the save queue and after their allotted save time has passed.

It would simplify the problem further if autosaves aren't allowed to go to the server; despite that, I predict some people would want that feature anyway. If so, then we'd need a simple system for ensuring players don't exploit saving files (tracking recently saved players)--that would be hard to exploit since it's all validated on the server anyway.

Also, I think saves will still lag regardless if it is done on the server or client: it's the serialization and writing operations that's laggy. The server/client would need to copy and serialize all the animation data into a text file. (LZMA) Compression also doesn't help because that also uses up CPU time. That's why having this done on a separate thread would ensure there's no sudden lag spikes for (auto)saving

Maybe the saving doesn't have to happen on the same tick? Just use multiple file.Appends. Not really sure how one would split up keyframe data though, as the whole thing would need to be serialized first, rather than piecewise