/tg/Station 13

https://github.com/tgstation/tgstation/pull/61719 has been merged. This means we can have secret content gateways!
So, there needs to be a system for getting them in and out, if we decide that we do want those gateways in the game and enable them in the config.
How do we do this? Someone needs to be responsible for putting the maps in/out of config, which needs a key holder, we need a way to contact the original creator for any updates.
We could use the architecture used for the Admin Application subforum to create threads for gateway maps, viewable only by people posting and the people responsible for updating the maps (maptainers? some volunteer? me? (haha just kidding... unless?))
If forums are seen as too "slow" it could also be discord threads viewably only by those people updating maps?

In my vision, we would be giving the maptainer team a lot of control over this. While they might not have direct access to the box, having them submit maps informally to head admins, or if maptainers gain authority over it, to any key holder, is workable. Inept is unfortunately out of commission right now, so I can't get their thoughts on this.

I don't think we need a subforum or anything, I think just informally working with maptainers is probably the best way to start. The throughput is likely so low that people can be talked to on an individual level.

I could see this becoming a tool for also working with event runners and planning out their things that would turn the magic gamer land of gateways on its head. Haven't put any actual thought into that though.

Will these Secret Gateways be available by any means to non-mappers/admins? I know for a fact that at least one codebase would like access to Gateway content for use in ruins, and this change sounds as though it will make it much harder to adapt such. I'm all for the change if it will enable Gateways on other servers than Basil (Manuel Gateway missions, please?), but I think it's a good question to ask.

The whole point of secret gateways is the map files are not public. Other codebases can have their own secret gateways, it's all config.

This sparked quite a discussion in mapping general.

There was a consensus that having maps outside of version control is bad. Having some random folder that files and configs are dumped in is not ideal from a maintenance standpoint, not to mention the keyholder and access related problems. The org on github does not seem to allow private repos - though I can't tell if that's because of org policy or because of github. I think the former.

So here's how this is working in my head. We create a small, private repo, either on github, or using something like Gitea on the tgstation infrastructure. This would be like the map depot, it would not contain the full tg code, just the map files. We limit access to that repo to the maptainers (+ possible QA) and keyholders/headmins. This repo will be used to hold the secret maps. We modify TGS so that on update it checks this repo and grabs the latest *.dmm files from it and copies them to the relevant folder on the server.

The config file will be managed by the keyholders/headmins just like current config files are. They can enable/disable secret maps at their discretion.

I do not have a good way for contributors to submit their requests. Manually sending dmm files works, but I'd prefer something with git. I am open to suggestions here, though I do like Fikou's idea of using an admin-application style forum. If we were to host our own git instance, we could give secret contributors a repo on it to push their maps to. I do not know how granular permissions are on github (not very I've heard).

At the end of all this: mso and other server people have to do a bunch of work to hook this all up, contributors submit maps for inclusion in the repo, the maptainers are responsible for making a repo of maps available to the server, and the administration decides what runs and when (via config, rotation, manual loading etc). This mirrors what we do with the main codebase, and isolates the ugly business of messing with files on the servers.

I assumed Secret Gateways were for one-off special missions uploaded as events, not a persistent pool of secrecy-gated content. If its a large repo of stuff thats available online and will be played over and over then doesnt that kinda loosen the point, since after an appearance or two people will know where all the crap is? Or am I misunderstanding again.

Not-Dorsidarf wrote: ↑Sun Oct 10, 2021 2:51 pm I assumed Secret Gateways were for one-off special missions uploaded as events, not a persistent pool of secrecy-gated content. If its a large repo of stuff thats available online and will be played over and over then doesnt that kinda loosen the point, since after an appearance or two people will know where all the crap is? Or am I misunderstanding again.

There's no capability to upload these maps via in-game verbs. It requires logging into the actual VM that DreamDaemon is running on and dropping the map files in config/away_missions. Since it involves accessing the game server's filesystem, that needs keyholder. That's not to say it couldn't work like this (change maps does), but that would require someone to code the necessary upload verbs and functionality to clean out uploaded maps when the round is done.

That's not to say the system I'm proposing can't be used for one off event maps, it could certainly have an 'inactive' folder that maps are moved to after being run. One of the main purposes of having a repo here is to mediate access to this folder. There's no requirement that secret maps have any longevity, but there was discussion in mapping general over what I'll call 'seasonal content' - to make up a map or set of maps that is run for a couple weeks or months to allow the playerbase to explore it, which is then rotated out for something new. This is something I'd like to support alongside the one off event maps.

Vire wrote: ↑Mon Oct 11, 2021 4:57 pm

Not-Dorsidarf wrote: ↑Sun Oct 10, 2021 2:51 pm I assumed Secret Gateways were for one-off special missions uploaded as events, not a persistent pool of secrecy-gated content. If its a large repo of stuff thats available online and will be played over and over then doesnt that kinda loosen the point, since after an appearance or two people will know where all the crap is? Or am I misunderstanding again.

There's no capability to upload these maps via in-game verbs. It requires logging into the actual VM that DreamDaemon is running and dropping the map files in config/away_missions. Since it involves accessing the game server's filesystem, that needs keyholder. That's not to say it couldn't work like this (change maps does), but that would require someone to code the necessary upload verbs and functionality to clean out uploaded maps when the round is done.

That's not to say the system I'm proposing can't be used for one off event maps, it could certainly have an 'inactive' folder that maps are moved to after being run. One of the main purposes of having a repo here is to mediate access to this folder. There's no requirement that secret maps have any longevity, but there was discussion in mapping general over what I'll call 'seasonal content' - to make up a map or set of maps that is run for a couple weeks or months to allow the playerbase to explore it, which is then rotated out for something new. This is something I'd like to support alongside the one off event maps.

Ah I see. Well, thanks for clearing up my misperceptions on these.

Not-Dorsidarf wrote: ↑Mon Oct 11, 2021 5:00 pm
Ah I see. Well, thanks for clearing up my misperceptions on these.

Actually, I misunderstood Fikou's response to my question on the PR. You can upload an away mission as you would currently it will load it, and will make correct use of the secret flags, and be cleared at the end of the round. They will not be added to the config or persist when uploaded in this manner.

We will be moving forward with this idea of a repo for the specific purpose of adding and maintaining secret gateways. We will be collaborating with Fikou and maptainers to iron out this system and get it running.

Headmin Votes:
Dragomagol: Yes
NamelessFairy: Yes
RaveRadbury: Yes