Adds Public Terminals

[AtnerNT]

Purpose

This PR adds public terminals which are able to send and receive departmental requests. While the UI has tabs for them, this PR does not add the terminal news and manifest and they are merely placeholder pages until their respective features are worked on. This PR also maps some of these terminals onto Ministation for testing purposes, (Some in Command, Security, Science, Cargo, Medical and Engineering)

Partially addresses #2324

The menu to send a request:

What is seen on receiving terminal(s):

What is seen on non-functioning pages:

Notes:

This PR moved the public terminal prefab into a new folder and renamed it (So prefab variants didn't clog the wallmount folder), however as a result this broke alot of the prefab references in other scenes like Outpost, Pog, and BoxStation. So these objects have been removed from these scenes temporarily, hence the scene changes.

Also, both the station timer and voltage at the bottom are working, it's just that APCPoweredDevice always seems to report back 0V.

Changelog:

CL: [New] Adds Public Terminals and there ability to send and recieve departmental requests

CL: [New] Maps Public Terminals to Ministation

[PerfectTangent]

state that you're modifying maps, please. I was working on maps as stated here https://discord.com/channels/273774715741667329/285240893160685570/982666550047821904

Very cool PR, regardless.

[AtnerNT]

@PerfectTangent That's my bad I thought you were only touching fall, they are very minor changes, I can remove them if it's gonna undo alot of your work

[PerfectTangent]

Thanks, could you do that, please? My changes are not so easy to redo.

[AtnerNT]

Alright that undoes the map changes, that will break tests though, so will need to wait to merge this PR until @PerfectTangent 's map changes are merged.

[PerfectTangent]

as a general thought, why do we need different types of terminals for all the different departments? I feel like these terminals don't need to be variants. They can just read the job of the person logged in.

[MaxIsJoe]

Terminals shouldn't be variants, they should have an enum that the mapper sets and having it as enum allows players to build terminals themselves.

[PerfectTangent]

that still doesn't explain to me why we even need to differentiate between different types of terminals. If the functionality is the same, and the main concern is permissions, then simply checking what permissions the currently logged in character has seem sufficient. It makes terminals more flexible and doesn't even require mappers and engineers to select types at all.

[MaxIsJoe]

that still doesn't explain to me why we even need to differentiate between different types of terminals. If the functionality is the same, and the main concern is permissions, then simply checking what permissions the currently logged in character has seem sufficient. It makes terminals more flexible and doesn't even require mappers and engineers to select types at all.

When you make a request to a department that request is sent to that department only and nothing else. That's why you need to know the difference between every terminal.

[PerfectTangent]

When you make a request to a department that request is sent to that department only and nothing else. That's why you need to know the difference between every terminal.

if people are logging in, then that's not required. It can all be virtual. Anyone who has the access would see the request. Tying it to specific terminals is just a needless limiting factor.

[MaxIsJoe]

When you make a request to a department that request is sent to that department only and nothing else. That's why you need to know the difference between every terminal.

if people are logging in, then that's not required. It can all be virtual. Anyone who has the access would see the request. Tying it to specific terminals is just a needless limiting factor.

That's not how that works on SS13 and should not work in that way at all.

Here's an example of why it shouldn't work like that, you want to request the chef to send pizza to cargo but you instead login as the head of personal; the chef sees that and immediately thinks command wants it instead of cargo. or you try to urgently request security during a comms blackout to come to medbay but you logged in as a scientist, security gets confused and comes to science instead of medbay.

Requests are sent from a department to another, not from a person to whole department. Your job means nothing because you are requesting something for that specific department and your access should not confuse other people about it.

[MaxIsJoe]

I should also mention this but they're called "Public terminals" for a reason, meaning that people only need to prove that they're crewmates to access them and that's it. The ID is only meant for modules that are going to be implemented in the future like the newscaster, but generally speaking any crew member with an ID card no-matter their job or access should be able to open a public terminal and do things without the heavy need for access unless for specific job specific things (I.e : Librarians having the ability to write and curate news.)

[Fr-Dae]

What is seen on non-functioning pages:

Notes:

I am reposting my question here, would it be possible, when a request/message is marked as "read" or "completed", to that it is moved to an "archive" folder and not deleted. This would be useful for other people in the service, or for the command to follow the news and the life of the station, life the history of wall terminals

also, it would be great if the AI could access the terminals

[Fr-Dae]

it's so easy to solve the problem RP speaking

from: sender to: recipient subject : message:

ex

from : Hop's Office to : Brig subject: [urgent] strange noise in medbay message: Hello, could you please go to medbay thank you

[MaxIsJoe]

it's so easy to solve the problem PR speaking

That's exactly how it works in the screenshots

[Fr-Dae]

it's so easy to solve the problem PR speaking

That's exactly how it works in the screenshots

PR = RP, translation fail if, as in an email, the 4 fields are correctly filled in. it's roleplay, if they are filled in any way, it's also roleplay

=====

and about my asking , do you think it's possible ?

[PerfectTangent]

That's not how that works on SS13 and should not work in that way at all.

Here's an example of why it shouldn't work like that, you want to request the chef to send pizza to cargo but you instead login as the head of personal; the chef sees that and immediately thinks command wants it instead of cargo. or you try to urgently request security during a comms blackout to come to medbay but you logged in as a scientist, security gets confused and comes to science instead of medbay.

Requests are sent from a department to another, not from a person to whole department. Your job means nothing because you are requesting something for that specific department and your access should not confuse other people about it.

Again, I see no reason to do it this way. It just limits things and adds a lot of bloat dealing with individual consoles. There isn't anything that fundamentally prevents someone requesting things on behalf of a department. If the HoP wishes to place a request for cargo, they should be able to make a note that it's for cargo in the request rather than specifically use the cargo terminal. Checking access on the user is quite enough to control who can request what for whom.

[PerfectTangent]

the request console exists to expedite the process of getting gear from cargo. If you have one in your department, it cuts a trip directly to the cargo office. But if you must make the request from within a specific department console that you are currently not in, it doesn't save you work. If the process is virtualized, then it saves you time pretty much no matter where you are because any available console can do the job.

That method is far more effective at doing what it's supposed to do; save you time.

[MaxIsJoe]

There isn't anything that fundamentally prevents someone requesting things on behalf of a department.

That's the point.

It just limits things and adds a lot of bloat dealing with individual consoles

How does it add bloat? Away from the fact that i disagree with the variant approach that atner made there is no bloat anywhere in this nor is it limiting anyone with anything, in-fact; it's opening more opportunities by giving people more ways to communicate information with other departments openly without restrictions You know what is bloat? Having to add a system to restrict players from interacting with other people, having to manually configure access for each terminal which is unnecessary data for a device that's supposed to be used by ANYONE, having to also add more ways to make sure that when people build terminals they assign the correct access required by that terminal, having to also created a bunch of checks and networking to make sure that all these don't fall apart; and let's not forget about the bugs that will appear all because we wanted to add a layer that's not even meant for an object that is meant to be used publicly by anyone.

I'll repeat this again in-case it got lost in this huge paragraph, the public terminal is a telecommunications device that is meant to be used by all crewmembers without restrictions.

[Fr-Dae]

I personally see it as a handbook or logbook,

your access level, like a door gives you access to a certain department, unlike radio which is person to person, here it's a common messaging, the terminals are just a copy. like air, or electrical controllers.

any department can contact, any department, but only the department or the command can read the messages. (active or archive)

I'm not sure if it's a good idea to have a rfid/nfc ID instead of having to swipe the cart ID, but I don't know if the game would allow that.

======= in fact you are both right, let's offer new tools to the players, which offer possibilities, let's avoid that they do anything with it, and let's enjoy the RP what do you think?

[PerfectTangent]

That's the point.

Then why limit it to a specific terminal then? That is a direct limitation being imposed.

it's opening more opportunities by giving people more ways to communicate information with other departments openly without restrictions

this is true whether it's done your way or my way.

You know what is bloat? Having to add a system to restrict players from interacting with other people, having to manually configure access for each terminal which is unnecessary data for a device that's supposed to be used by ANYONE.

You wouldn't have to do that with the method I suggested. Anyone can use any terminal to request anything. That is a more flexible system than requiring a specific terminal to request items for that terminal's department.

having to also add more ways to make sure that when people build terminals they assign the correct access required by that terminal

this is a problem with the current method, as it requires 18 different computers. My suggestion solves this problem, max.

I'll repeat this again in-case it got lost in this huge paragraph, the public terminal is a telecommunications device that is meant to be used by all crewmembers without restrictions.

Odd to restrict it to specific departments then.

[PerfectTangent]

In /tg/, they have it both ways, having department specific consoles and also requiring access to sign the request

If we just make them department-based and totally free to use by anyone, there's no authentication, which is weaker, and you can only make requests from a specific location

if we just make it check access, it is more secure, and you can make any request from anywhere. This is the most flexible and useful option.

[MaxIsJoe]

Dae

I personally see it as a handbook or logbook,

When I mentioned that I'd merge all consoles (and the functionality of laptops/tablets) into public terminals I wanted to turn this into a computer that can be accessed by anyone to do multiple things that are mainly designed for communicating with the station and your own department. Public terminals are a replacement to Tablets, so I can see why you can view them as handbooks when one of their planned functionality was a public notes board.

your access level, like a door gives you access to a certain department,

Again, it's in the name; it's a public terminal meaning that you should not require specific access to be able to use it unless it has functionality that can only be used by specific people. (Look back at my librarian example)

let's enjoy the RP

The public terminal will show it's use more in med to high RP servers as most people will ignore it in lower RP servers. So yeah I hope people enjoy it as is.

Jack

Then why limit it to a specific terminal then? That is a direct limitation being imposed. Odd to restrict it to specific departments then.

Where is the limit exactly and what specific terminal? Did Anter do something that im not aware of that forces consoles to only work one-to-one instead of communicating with all consoles? I can't see any limitations when you can communicate with all departments and one terminal should be able to send the same message to five other terminals that are marked as inside the department of where the requester wants their message to be sent. The reason why i disagree with the variant approach as well is because it adds that restriction you and i are afraid of, because public terminals should be universal objects that can be used anywhere but the department part should only be defined in the requests module to tell other departments where this request is coming from (which can allow antags to sabotage by faking an identity then requesting something as command from a hacked terminal that they changed to appear as if they're requesting it from there)

[Fr-Dae]

> The public terminal will show it's use more in med to high RP servers as most people will ignore it in lower RP servers. So yeah I hope people enjoy it as is.

I've always had trouble with this differentiation of RP "levels", as if there is a right way to do RP,

Obviously if you're playing with beginners you're more flexible to ooc mistakes, lack of knowledge of the keys, the game or the mechanics. like talking about bugs or lag in the game. I don't know if it's a good idea to have a game or not, but I'm sure it's a good idea to have a game.

> it's a public terminal a public telephone, or a public computer in a cybercafé, allows you to communicate privately with your ID to another recipient.

It is still a public phone. if (no idea if it is feasible) the terminal detects the person using it, to sign the request (write or read) so technically, all terminals are exactly the same, all display, but your access level, filters or displays more or less information.

[MaxIsJoe]

In /tg/,

In /tg/ terminals are currently a mess that they've been planning to do the same exact thing that im doing right now from 2021.

mentioning /tg/ inside a PR that is meant to AVOID /tg/ completely because of how messy their current implementations are is not the way to go about it.

[MaxIsJoe]

allows you to communicate privately with your ID to another recipient.

No, it is not. It's a PUBLIC terminal where everyone sees what you do or post on it with your name (fake or real) attached to it.

Stop thinking about this as if it's something from SS13, it's not.

[Fr-Dae]

who cares if we do exactly the same as in ss13? if it's technically feasible and useful for the game?

[PerfectTangent]

Jack

Where is the limit exactly and what specific terminal?

Here, Max. Here is the limitation. Why else would there be 18 department specific terminals? This checking access to use the console is the limitation I am against. We should generalize the consoles and make requests be signed rather than the terminals restrict who can see what so that anyone can use any terminal for any request they want to make.

[PerfectTangent]

going back to your example, If the HoP wants to request a pizza from the kitchen on behalf of cargo, that should be doable on any terminal. The requests themselves get signed and describe what is needed. What terminal it is made in need not matter because it all goes to the server and gets distributed to the people who have the access required; in this case, kitchen access.

[PerfectTangent]

mentioning /tg/ inside a PR that is meant to AVOID /tg/ completely because of how messy their current implementations are is not the way to go about it.

I can't think of a better time to bring up the past mistakes made than when we are trying to improve upon them. Seeing what failed for them is how we improve. Get off your high horse.

[Fr-Dae]

the cook, whether he is at the bar, in the kitchen, or dear botanist, can then consult a terminal with his ID and see that he has an order. The botanist will not see the message. (the request) It's a visual filter. Did I understand correctly Jack?

[PerfectTangent]

the cook, whether he is at the bar, in the kitchen, or dear botanist, can then consult a terminal with his ID and see that he has an order. The botanist will not see the message. (the request) It's a visual filter. Did I understand correctly Jack?

yes.

[MaxIsJoe]

restrict who can see what so that anyone can use any terminal for any request they want to make.

There is no restrictions on who can see or use the consoles. To repeat myself, that enum is to tell other departments what department is making the request and it should be faked in the future. "Required" is not a word I would use because that's Atner, not me who worked on this and he cannot read my mind. and if Atner did restrict something then I would probably correct it when it gets merged because Atner doesn't even use modules which is important to add more functionality to terminals nor does he use the newly added hard disks.

[PerfectTangent]

There is no restrictions on who can see or use the consoles.

There is a clear restriction right in that screenshot: terminal required access

[MaxIsJoe]

There is no restrictions on who can see or use the consoles.

There is a clear restriction right in that screenshot: terminal required access

The only restriction there is is the need for an ID to be able to use the console, but not the access of the ID. if Atner added a requirement for access then that's not how i initially designed it.

The only thing that is needed is this

[AtnerNT]

Any further discussion on this should probably be taken to the discord because this PR is filling up, but Ill weigh in real quick. ->I will remove the prefab variants, they aren't necessary, I mainly added them to make mapping life a bit easier as if you were mapping lots of consoles having to scroll down the very large list of accesses every time was annoying. But it seems there is a consensus on them not being there, so I will remove. ->This was supposed to be a base implementation for Max to build off of as his unity was being a pain and so I didn't do any of the hard drive stuff, I am leaving that to Max for when he continues his telecomms work. ->If everyone is supposed to be able to access a terminal, the mapper can just leave the access as empty (Though ill add a null check for required access to prevent NRE's). The reason it exists in the first place is because a very rough script for terminals was in place when i started working on this (was just checking if terminal was powered and nothing else) and that script had an access field that was unused so I kept it and added it in. ->Though as for my opinion, I agree with max, they are public terminals for general department->department communications and shouldn't really be done personally, as that is what PDA's are for. Signing in right now is purely for the purpose of signing the request with your name. (Helps to stop assistant abuse of spamming command with 10000 requests, lets command know who is spamming them) ->One last thing, I don't know what was being said about 18 departments? There is currently only ten in this context, I thought I would just clear this up.

(Imma just wait until there is a consensus on this topic before I make any commits)

[PerfectTangent]

One last thing, I don't know what was being said about 18 departments? There is currently only ten in this context, I thought I would just clear this up.

ah, I counted the meta files, thereby doubling the number.

they are public terminals for general department->department communications and shouldn't really be done personally, as that is what PDA's are for.

Alright, let me ask then, why even have the consoles? If everyone is going to be able to make requests with PDAs in the future, then won't we just run into the same problem that currently exists in ss13 where people don't use the request consoles because there are far easier to access methods? If the entire crew get PDAs with the same functionality, then what do the consoles add? Max brought up this short coming to me in DMs.

It seems like the actual intended problem to fix (making these consoles useful) hasn't actually been addressed if the PDA is going to (just like ss13) overshadow it.

[Fr-Dae]

make a thread, if you don't want the conversation to be lost x)

[PerfectTangent]

hey, @AtnerNT. I noticed the terminal is not a variant of a base prefab. It really needs to be.

[AtnerNT]

Okay so I have made various changes: -> Terminals no longer need access, access can still be added if need be though. -> You can now view requests without having to login, you now only need to login in order to send requests -> I have made the terminals a prefab variant of Machine Base -> As be @Fr-Dae 's suggestion, terminals now have an "archive", once you complete a request it will be moved to the terminals archive, this allows for you to look back on requests you have already completed, useful for various reasons. Once it is no longer needed it can be deleted (To get rid of spam and the like) -> Terminals will now only send a request once a second, to prevent every frame spamming -> When sending a request, the server will validate that you can actually interact with the terminal before sending the message -> Strings are trimmed down to 200 characters as a safety precaution -> As per @Alainx277 's request, the targetdepartment and senderdepartment and now sent as ints rather than strings (This also results in department options being a drop down which is nice) -> Removes all the prefab variants that were there before. -> Adds an audio notification when receiving a message.

Tests will still be broken due to mapping changes needing to be made, but I will fix those once Jack has merged his mapping changes. As for the discussion on discord, that will be left until telelcomms is further added. This works perfectly fine until the time that it is worked on.

[AtnerNT]

That should fix tests and this will be ready to merge