Convars and Commands

Sanity check this for me. Do the naming of these make sense to you?

There’s discrepancies here that I don’t like.

ServerVar cannot be changed by remote clients, but ServerCmd can be called by remote clients.

AdminCmd can only be called by admins or the server host.

UserVar is the same as a UserInfo convar in gmod. So you can change it on the client and the server can retrieve that value from the player class. Is the naming unobvious, are people going to try to access the uservar on the server?

One thing I think I’ll do with UserInfo is be able to add members on entities with an [OwnerVar( "var_name" )] attribute. Throw an exception on server if they try to set it, but if they try to read it, look at the entity, find its player owner, and get the user data var of that name. That’ll make me feel better about the accessibility of this.

Anything else standing out as fucked?

14 Likes

So, if I got this straight,

ServerVar cannot be changed but can be read by remote clients.
ServerCmd can be changed and read by remote clients.

AdminCmd can be read changed and read by admins

UserVar can be changed by the client and be read by the server, which in my opinion would ease some networking, and could make it easier on the developers, because it would allow a quick and easy way to get a variable from the client.

If I got it right it looks good to me.

1 Like

This system is just perfect. Plus it takes admins into consideration. :ok_hand:

1 Like

I’m fine as long as there’s documentation on the wiki, gmod already has some confusing naming conventions here and there.

2 Likes

Kind of right… ServerVar can’t be read by remote clients - it’s server only. ReplicatedVar can only be set by server admins but can be read by clients too.

3 Likes

Well lets try to avoid that?

2 Likes

Please let us change the ConVar/ConCommand name, and don’t bind it to the name of the method/property, if you haven’t done this already. Add a constructor with the name parameter for the attributes.

1 Like

Already can m8

12 Likes

This is exactly how I do it in my game (technically), and so naturally I think it’s great :+1: as for the naming I don’t think it’s overly fucked… I think it makes sense regardless of the discrepancy with ServerCmd and ServerVar behaviour.

2 Likes

It takes a second for everything to click and make sense but I don’t really see anything that stands out as being particularly fucked. OwnerVar I’m not sure about though, it sounds like a good addition but I can’t think of any applications for it off the top of my head.

What defines who can and cannot set/call ReplicatedVar/AdminCmd? Is it a users.txt setup or something different?

2 Likes

ServerCmd seems a bit confusing to me. if ServerVar can only be read by the server, that would make me think ServerCmd could only be called by the server, not clients.

And OwnerVar might be confusing because AdminCmd can only be ran by admins. OwnerVar sounds like something that can only be set by the owner of the server / host

2 Likes

Nothing seems outwardly confusing to me.

Had to give the screenshot two looks, though, before I got a basis for what was what. I guess it’s a bit weird to create commands like that but I’ll assume that’s because I’m used to automatic generators that people have made in Garry’s Mod.

1 Like

Yeah, but I think you need to also look at it from a beginniner standpoint. Like if someone is just learning how to make mods you want them to be as well named as possible so it’s less confusing. It would just make me mad if I learned I was using it wrong just because I misinterpreted the name

1 Like

As a Beginner, this naming seems straight forward and descriptive enough, except for 1 point:
The distinction between UserVar and ClientVar is not immediately clear, meaning I would have to look into their distinctions on docs more than once. However, I can’t think of a better way to name them both and they are not at all counter intuitive.

I think the most important thing about these names is to keep keywords like User, Client, Replicated, being used consistently across all names.

In my head, being uninformed about other concepts and names, when I read these I would start to form the definition of User as being how you reefer to something from a remote client, from the perspective of the server, while Client as how you reefer to something from the remote client from its own perspective, and Replicated as something controlled by the server, but that the remote clients also get to see.

This is all fine until these abstract, fuzzy half-definitions are challenged by other names/structures. So that has to happen as little as possible.

Example: If I eventually see a method that creates a timer called startServerTimer but that timer gets replicated to client, that would be confusing for me.

4 Likes

The only thing that worries me is the admin command attribute.

I think permissions check (including console commands) should be more generic, it’s cool to have a default AdminCmd attribute as long as it inherits a more general Cmd(Func<Player, bool> checkPermission, string Help, ...) attribute or something, which checks if the player is admin according to the default admin system.

The idea of this is the ability to easily define arbitrary permissions for commands, be it a user group, playtime, job or health or whatever of the player executing the command.

2 Likes

I would say that ideally you would integrate those things into the game mode itself rather than using console commands, though? But more permission options is better for moderation as well anyway.

1 Like

Console commands and convars are fine for what they are, they are one of the few mechanics familiar to all Source games players and they certainly have use in many gamemodes, especially having such a nice console as S&Box seems to have.

My concern is more that dictating the default admin system is bad without proper generalization and ability to achieve similar goals by creating your own attributes similar to AdminCmd.

2 Likes

I think this is a great idea that gives more power to devs, but streamlining is also important. Having a basic set of Cmd/Var types like we have here is good for those that don’t really need the extended kind of control. Otherwise the default stance of making a convar/command enforces you needing to put your own permissions check into using them, which can open up holes for newer people.

A good compromise is instead of lumping it into the existing identifiers, there be a separate identifier. For example, a GroupCmd and GroupVar that includes the perm argument you’re suggesting, and then people can choose to handle those themselves. Having it be too generic will ruin the readability. Even in my example, I’m assuming you already know about ServerCmd. Someone sees “GroupCmd” and may not be able to distinguish what realm it’s made for. As @ubre and @garry concurring, we’d want to avoid confusing naming.

I can’t tell you how many Garry’s Mod addons had a simple admin command added but forgot to actually validate if they were admin, leading to servers burning until enough complaints got through. It’s why they eventually add ULX support which has the perm system built in and handled. Familiar in application always, but when you actually sit down and make one people tend to miss things.

1 Like

As I said, it’s fine to have a default AdminCmd attribute just as Garry showed us. I don’t suggest you creating your own custom concommand types when you don’t need them.

I’d like to see AdminCmd above some default console command, go to its definition and see that it’s an extension of a more generic attribute that I can use to base my own concommand type upon with a custom permission check.

UPD:
Example: AdminCmd would check something like player.IsAdmin in its permission-checking code written by Facepunch.
I would also like to have superadmins and moderators on my server and create identical SuperAdminCmd and ModeratorCmd attributes, which would check player.IsSuperAdmin and player.IsModerator respectively, so I’d need a nice way to do this, which would be a generic attribute which serves as the base for AdminCmd and using which I can create custom command types with my own permission-checking code.

3 Likes

Despite knowing well what “UserVar” implies, it still irks me as something very unintuitive. Especially right next to “ClientVar”. My first guess without knowing would be that it’s for remotely connected clients?

Something like “InfoVar” or “ClientInfoVar” or “ClientNetworkedVar” would go a lot farther.
The word User doesn’t imply anything differently than Client does to the uninformed.

Of course, if the purpose of it were shown when you hovered over it, it wouldn’t much matter in time. But I’d rather the name give an actual hint as to its purpose anyway.

Everything looks pretty good otherwise. Nice to see that the move to C# doesn’t necessarily make code less readable at a glance.

3 Likes