SquadJS
SquadJS copied to clipboard
Add Partial Layers to server object for MOD support
This Pull Request attemps to add partial layers to correct various issues when a server is running mods.
The benefit is that certain layer properties should be guaranteed across mods and the base game, which will fix a number of plugins breaking when either the current layer or the layerhistory is null.
this.server.on(NEW_GAME ...)
this.server.updateLayerInformation();
https://github.com/Thomas-Smyth/SquadJS/blob/f34426d61f5f24c183c7d3baaf913fdda203378a/squad-server/index.js#L187
A lookup into Layers can fail, this creates a layer object containing null;
data.layer: {layer: null, time: ... }
We also send this layer object into server.layerHistory
this.layerHistory.unshift({ layer: null, time: data.time });
this.server.UpdateLayerInformation()
https://github.com/Thomas-Smyth/SquadJS/blob/f34426d61f5f24c183c7d3baaf913fdda203378a/squad-server/index.js#L400
Same as above, we set this.server.currentLayer to null.
This code may need some stylistic changes. It also needs extensive testing, particularly around NEW_GAME, when we may lose RCON while the server loads the next map.
Additionally, I feel like this code would better fit inside of the Layers class, as an additional method for keeping this clearly defined, but I haven't investigated changes to that effect.
These change were successfully tested on TT this weekend.
As of right now, there doesn't appear to need to be a delay on NEW_GAME.
I did notice one issue, with DBLog:
With the NEW_GAME regex capturing and firing on mods, and thus capturing some garbage data for mapclassname, the current graphana panel linked with it needs a few queries adjusted.
The current graphana panel uses mapClassname and LayerClassname for displaying level/layer history, which in our case might not be ideal.
In the worst case, this causes confusion when viewing data via graphana. And at worst, it may break other Queries people have written specifically on mapclassname/layerclassname vs map and layer respectively, again due to confusion. All properties will be set, but may not be as expected for mods (mapclassname)
This has been running stable at TT for some time.
I'm not sure if anything needs to be done, but it should be viable to merge.
@ect0s is this still good to be merged?
I feel like this could be redone a lot cleaner.
It currently does work, and I've been running this for a long time, but there may be implications inside plugins to look at.
One of the issues would be missing properties when a "partial" layer is generated, should some plugin or other code depend on it being there.