This should do it. You need to create a text file in your main directory (the one with your .dme file in it) and name it the same as what you put for UPDATE_FILE.

Players will automatically see what's in that file in a panel for updates.

If you choose to change that file while people are playing you can use the proc refresh_updates() to give each player a copy of the new file.

ckey isn't what I wanted.

Also, your refresh_updates() proc should be a /mob/proc, otherwise you won't be able to properly access the variables of the caller.

And, you're also not calling ..() in world/New(), which again, will break the game.

It won't break the game if he appends New() and Login() with everything I added instead of copy pastaing it in.

Nadrew wrote:

What happens if said person has spaces in their key? lowertext() won't strip those.

In that case write their name with a space. Spaces are a natural element we all should be used to. Names with crazy capitals are more of a worry in my opinion.

Dangerous Dave for example. If you can't work out that there's a space in that then god help you.

DaNGeRous DaVE. If you can't get that name 100% right then I completely understand.

With all due respect, Zecronius, there are a few issues with your implementation that fall upon your 'personal opinion' and should not be in place for plug-and-play code, which yours makes an attempt to be.

Specifically, first you are making plug-and-play code and then you are telling him to do specific things to make it work. It's evidenced to be plug-and-play by you making a Login system that would give him the verb. You're telling specific things by telling him to put it in different places from just copy and paste.

For simplicity's sake, and actual usefulness, sticking to one or the other might be preferable.

Second, you're making assumptions about the opening topic's admin system, and how it should be done. This is evidenced by you going so far as to make a new proc called "give_admin_commands". This should not be done, as it was not part of the request in the opening topic and can cause both confusion and issues down the line.

Next, the implementation of your new admin system isn't very versatile and would require both the creation of each proc as well as the placement into that specific proc, as opposed to just making it a proc of /datum/admin and then giving all types of /datum/admin.

Next-- Standard is to use the ckey. While you personally may find it fine to use spaces, and find it insulting to consider the possibility that someone might not know about the space, that is not the standard usage and it's better to conform to the language's standards when providing help to someone. It'll also make at least one less thing to worry about (your glorious spaces) if you just use ckey, and since you didn't explain it to the opening topic for why you used key instead, that's vastly preferable.

Next, you didn't call any previous overrides or the base procs by adding ..() to any of the procs provided. While this may be fine for the proc you made, it's not fine in the procs that you chose to override-- The reason for this is that you don't know what the rest of the codebase looks like and it can easily break it if it is already overridden. This would be less of an issue if you didn't have the code as plug and play, as explained before.

Finally, you weren't consistent as to how you handled the 'magic text'. Much like a 'magic number', in large code bases, it can cause an issue. You chose to #define the file name and not #define the key of the person who is being given the verbs, and so making it require more looking when that should not be required. If you handle it in one spot, you should handle it in another-- Even ignoring code standards, consistent handling of code and such things is usually important

With all of those points in mind, here is my proposed solution, which tries to fix them and provide all of the functionality of Zecronious's proposed solution. It is directly based off of his, and credit should go to him as well for it working.



Person who made the opening post, I urge you to read this entire post, make use of this snippet of code if it assists you, and be mindful of what you need to do in order to get what you want.

Have a wonderful day.

Note: I have not covered everything, of course, and there are very likely issues in the code I myself provided. This is to be expected-- But I will say that it is superior in standard, versatility, and robustness to the previously proposed code.

Edit: Zecronius, please note that this reply is not meant to be insulting to you. It's meant to point out issues, why they are issues, and then offer solutions. Furthermore, I do thank you for putting forth an effort to assist the opening poster regardless of the issues that the effort had. It's good to try. There is less wisdom, though, in ignoring good advice-- Specifically, Nadrew's here.