Session rework #401
Session rework #401
Conversation
… still need changing and/or adding. Some notes - A lot of cleanup needed, the classes implementing `ISession` and other interfaces are still missing several methods/properties - Some changes to trading sessions will be needed, as they aren't stored in a single trading-only-sessions list - `TickRateMultiplier` methods will need changing to actually use the reworked - `ISession` and the other interfaces will have to be moved to the API - The API should preferably expose abstract session classes to ensure any additions will be compatible in the future due to older implementations inheriting new members - The location (and existence) of `IIdBlockProvider` is subject to change - it may get removed, renamed, moved, etc.
… session-rework # Conflicts: # Source/Client/Comp/Game/MultiplayerGameComp.cs # Source/Client/Comp/Map/MultiplayerMapComp.cs # Source/Client/Comp/World/MultiplayerWorldComp.cs
- The session is only added if there's any pause lock added by a mod - The session will only pause itself if any of the pause locks does so as well - Once we update the API to include sessions, pause locks should be marked as obsolete
It was causing issues, and everything works fine without it.
Also error for semi persistent data sync now says writing semi persistent instead of exposing
The intention is to move it to MP API as a way to provide a way for other mods to interact with the session manager. Currently needs a little bit more documentation (currently all documentation was moved from SessionManager).
Removed `ISession`, `IExposableSession`, and `ISemiPersistentSession` in favor of abstract classes `Session`, `ExposableSession`, and `SemiPersistentSession`. There was likely no class besides `Session` that would implement `ISession`, so it was removed. The other 2 were removed in favor of turning them into abstract subclasses of `Session`, which will allow for expanding them further in the future, and prevent people from implementing both interfaces (which was not supported). All the xml docs were moved from interfaces to their respective classes.
|
Pushed a commit that removed |
…MP API This is done in preparation of an update to MP API
- Added a single parameter (Map) constructor to all `Session` subclasses with docs to inform devs using the API of a mandatory constructor - `ExposableSession` will now be provided the `Map` parameter by the `SessionManager` - `SemiPersistentSessions` won't sync a map on a per-session basis, instead being provided the `SessionManager` map
It first checks if it's a subtype of `Session`, and will show an error if it isn't
|
I've added a sync dict entry for |
|
Working a bit with the new sessions, I've encountered a specific (and possibly rather niche) scenario. I'm in a situations where I need to keep an event/quest/etc. map temporarily paused and alive. The mod itself would do it itself, but due to needing for syncing and some patches, I'm in a situation where it's not possible. Keeping the map paused is rather easy with the sessions. However, this still requires the "keep alive" aspect implemented, so this made me wonder: Would it be worthwhile to include to include Anyway, this is just a minor thing to possibly consider. Checking this PR made me realize there are conflicts, so I'll look into resolving them in the next day or two. |
… session-rework # Conflicts: # Source/Client/Comp/World/MultiplayerWorldComp.cs
|
Merged with the master branch and resolved the merge conflicts |
Complement of rwmt/MultiplayerAPI#11
|
Merged |
Changes/additions:
SessionManagerSessionManagerwill handle storing and processing all the sessionsSessionsManagerforMultiplayerWorldComp, as well as one for eachMultiplayerMapCompThingIDs for thatSessionManagerSessionclass has been added which should be used by mods implementing their own sessions(should we removeISessioninterface and just useSessionclass?)Sessionclass includes a basic implementation for handlingSessionIdSessionclass includes an empty virtual implementation for some methods which not all mods need to implementTheSessionclass exists (as opposed to just usingISession) as a way to make it easy to expand it without requiring the mods to update - theSessionclass will contain the basic implementation for all new methods in the future (should we do it with other interfaces?)Session,ExposableSession, andSemiPersistentSessionwere created instead of using interfaces to make it simpler to expand them in the future without requiring mods to update (by adding empty virtual methods as needed). Their respective interfaces were removed as they now served no purpose.Sessionclass includes a static methodSwitchToMapOrWorldfor convenienceSyncSessionWithTransferablesMarker.DrawnSessionWithTransferableshas been included, somewhat based on howThingFilterMarkers.DrawnThingFilteris implemented, used for syncing Trasferables inISessionWithTransferablessessionsISessionWithCreationRestrictions- they sadly need to be initialized to work (static members in interfaces seem to not be available in .NET used by RimWorld)Some things that could be done:
Sessionto the manager, only the session itself (if it'sISessionWithCreationRestrictions) checks if it should be added - any sessions already existing don't check against the one being added. This could be changed to work both ways.Things left to do:
ISessionManagerMultiplayerAPIBridgethat will be included in updated MP API for accessingSessionManagerISessionWithTransferableswill require proper<see cref=""/>tags once included in the MP API.Things that will need to be moved to MP API:
Sessionclass - possibly could use a renameISessionManagerinterfaceIPausingWithDialog, as it seems to be right nowISwitchToMapbe included (and potentially expanded)?Testing: