Solved Ddraw.text not working after Rust update

Its fixed only if there is Admin flag on sended user, on default players still nothing shows((

 

Hello Wulf,

I have a question about this and your plugin ChatHead.
I would love to be able to use the ChatHead plugin again but with ddraw.text not working for normal players it will be impossible ofc.

That workaround you are speaking of, is that something that would be hard to implement into your ChatHead plugin?
Are there any downsides or consequences to this? You did mention that the players don't actually have admin rights using your method, that would be preferable indeed.

I hope you are able to inform me about this.

 

Thank you for your response Wulf,

Alright, that is to much of a risk which I wouldn't like to take. I thought by fake admin rights you meant tricking the server into thinking that the player is flagged as admin with full rights so the ddraw.text would work again for them.

So if text does not work anymore, could I replace ddraw.text with ddraw.sphere to indicate that someone did send a message in chat?
If you have the time for it, could you show me how I could do that if I would want to do that inside ChatHead.cs?

Could I try to replace the ddraw.text with the following?
target.SendConsoleCommand("ddraw.sphere", 0.1f, "#229954", player.transform.position + new Vector3(0, 1.9f, 0), 1f);

 

Alright, thank you for clearing this up for me Wulf.
There must be some way to prevent people with the admin flag from doing any harm.

I have been looking at the raidtracker plugin because I noticed that there is a script in place that does the thing you suggested, adding a temporary admin flag to players. This code is used to add a flag:

Code:

if (player.net.connection.authLevel == 0 && !player.IsAdmin) {
        if (!flagged.Contains(player)) {
              flagged.Add(player);
              player.SetPlayerFlag(BasePlayer.PlayerFlags.IsAdmin, true);
              player.SendNetworkUpdateImmediate();
         }
}

and to remove the flag after when it is not needed anymore:

Code:

if (flagged.Contains(player)) {
          player.SetPlayerFlag(BasePlayer.PlayerFlags.IsAdmin, false);
          player.SendNetworkUpdateImmediate();
          flagged.Remove(player);
}

The flags are stored in a list called flagged:

Code:

private readonly List<BasePlayer> flagged = new List<BasePlayer>();

But somehow when I try to use this inside ChatHead it does nothing for me.
Could you point my in the right direction maybe?

 

Thanks for another blazing fast response Wulf,

I manged to get the flagging part to work, ddraw.text shows for all players now like it used to, thank you for this workaround!
Although you mentioned that the risk of abuse is small, I want to make it risk free. So I have been looking around for a way to block native admin calls and fully rely on Oxide permissions like you mentioned, but without succes.

Do you know a place where I can find more information about this subject?

 

Hi Wulf,

Yes I found out about the god and noclip being client side which is unfortunate, so there is no way of detecting someone has god or noclip turned to true? Anyway, I will use CommandBlock | Oxide to block the other console commands that are detectable server side.

For the flagging I now use this code (in case it helps others):

Code:

if (!player.HasPlayerFlag(BasePlayer.PlayerFlags.IsAdmin)) {
      player.SetPlayerFlag(BasePlayer.PlayerFlags.IsAdmin, true);
      player.SendNetworkUpdateImmediate();
      // Do Something with ddraw here
      player.SetPlayerFlag(BasePlayer.PlayerFlags.IsAdmin, false);
      player.SendNetworkUpdate();
} else {
      //Player is already admin, you can use ddraw here
}
return;

This code is originally from PersonalBeacon for Rust | Oxide, so thanks to Mordenak and redBDGR for this code!
So basically the admin flag is added and immediately removed, so I think the risk is at minimum level indeed.

Wulf, as you are more familiar with potential risks and dangers, could you help me understand what could go wrong when using this code?
Is there any way other then CommandBlock to prevent this? In my understanding players are only able to use god and noclip if they are fast enough to type the command in the console (impossible without a script). Even if they manage to do so the noclip and god would be useless as the admin flag is also removed immediately.

Correct me if I am wrong.

 

@Elephant47 afaik, if someone has some kind of software that would let them execute commands within this time period, they will be able to execute almost any commands that someone with ownerID would be able to execute. There was a way to make this a bit safer, and that was to grant the person access to the IsDeveloper flag, which gave some more restrictions to the commands that could be executed, but i think this method of dealing with this was removed. I have never seen, nor heard of anyone being able to execute commands in these time periods but that doesn't mean that it can't or hasn't happened.

 

Yeah whoops, didn't think of that So does the IsAdmin flag only give access to clientside commands like debugcamera & other similar things?

 

@redBDGR and @Wulf ,

Thank you for the useful information, I didn't know about the IsAdmin flag being worthless with most commands so that is good news.
redBDGR, so like you said, it is not impossible to use a script to enter client side commands like noclip, god and debugcamera. But I am wondering what the use of those would be if the players that managed to enter these commands will lose their admin flag in a matter of milliseconds? I tried removing the admin flag while flying around with noclip and I got immediately banned for cheating on my own server (Not a very well thought out move I have to admit ).

So I think the client side commands are pretty much useless to someone who wants to abuse them, but things like the give and grant commands (if they listen to the IsAdmin flag) are more of a concern to me. So for that purpose I was planning to use Wulf's CommandBlock but for some reason it displays an error message and does not actually block commands anymore unfortunately. I have tried to find a solution myself but I did not understand the error message, I think it has something to do with the arguments of the function OnServerCommand.

I believe that once CommandBlock is working again and I block all server side admin commands that it would be safe enough to give normal players the IsAdmin flag. Please let me know if you are planning on fixing your CommandBlock plugin Wulf, or is it just broken and unfixable?

 

Awesome Wulf, thank you for the effort.
I look forward to seeing CommandBlock get an update that will resolve the current issue.

 

Code:

// BasePlayer
public bool IsAdmin
{
    get
    {
        return this.HasPlayerFlag(BasePlayer.PlayerFlags.IsAdmin);
    }
}

...These are the reasons why i don't adopt this method in any of the plugins i do maintain and neither into any of my private ones which formerly used ddraw methods.