Approved Fougerite MC [Deleted]

Status
Not open for further replies.
Yeah, that's fixed in the version I am trying to get in shape to release. Player names and item names in commands are matched with a suffix tree algorithm, similar to autocorrect. Slight misspellings are even tolerated.
 
  • Like
Reactions: Jakkee
mikec said:
I believe I have discovered the reason /addfriend and /share don't work for many people, including myself on my own servers, public and private.
Click to expand...

It doesn't seem to have anything to do with having had your avatar.bin file loaded on a cracked server. I've wiped all player and map data on my FPS players server, and the probem remains. My structures and deployables have an ownerID that is different from my SteamID. So any commands that use SteamID to match players with deployed objects is not working, and it's a mystery when or why this happened.

In the summer I was testing some Javascript code for Magma dealing with player structures and deployables. I have several logs from that time itemizing structures by the StructureMaster.ownerID property. At least as late as June 24, the ownerID property matched my SteamID exactly.

Today, it doesn't. ownerID and creatorID for structures and deployables are set from a property that isn't the same property as is used to set Player.SteamID and Player.GameID.

C#: 
Player.SteamID  == PlayerClient.netUser.userID;
Player.GameID == PlayerClient.userID;
StructureMaster.ownerID == PlayerClient.netUser.user.Userid;
StructureMaster.creatorID == PlayerClient.netUser.user.Userid;
DeployableObject.ownerID == PlayerClient.netUser.user.Userid;
DeployableObject.creatorID == PlayerClient.netUser.user.Userid;

PlayerClient.netUser.userID == PlayerClient.userID == your SteamID.
PlayerClient.netUser.user.Userid == your SteamID, but with 1-5 trailing digits changed

PlayerClient.netUser.user has a value of type RustProto.User. Following the references through Assembly-CSharp, I find the netUser.userUserid property is ultimately set by a uLink method. I have no idea why it's a different number from the SteamID, but only in the last 1-5 digits.

C#: 
  public bool ReadConnectionData(BitStream stream)
  {
    try
    {
      this.Protocol = stream.ReadInt32();
      this.ConnectionMode = (int) stream.ReadByte();
      if (this.ConnectionMode != 2)
        return false;
      this.UserID = stream.ReadUInt64();
      this.UserName = stream.ReadString();
      this.SteamTicket = stream.ReadBytes();
    }
    catch (Exception ex)
    {
      return false;
    }
    return true;
  }

// from uLink.dll
    public ulong ReadUInt64()
    {
      this.\u0023\u003DqDJzoHXuKgfm9_qNnQLOEIw\u003D\u003D(BitStreamTypeCode.UInt64);
      return this.\u0023\u003DqaPxKFHaT1tFG_N7lCKc\u0024N4ZbuXI_EIWX5YzX5DIaw44\u003D();
    }

I need some help from people to figure out what has happened and how best to fix it. You'd think I should just switch to checking Player.PlayerClient.netUser.user.Userid in Rust++. But what about all the plugins written expecting SteamID to match the ownerID of deployables and structures? SleepyOwner, for example, is totally broken now. Wrong owner every time.

Please add this code to a plugin or make a new plugin for it on your server. Get some players to connect, see what the log shows. If you can install Magma, please try that (I'm going to). If you can install Oxide and make an equivalent plugin, try that too. Any clues will help at this point.
JavaScript: 
// should work on Magma and Fougerite, old Jint or new Jint
function On_PlayerConnected(Player) {
    var logmessage = "GameID=" + Player.GameID;
    logmessage += " Userid=" + Player.PlayerClient.netUser.user.Userid;
    Plugin.Log("UseridTest", logmessage);
}
 
...scooting a tumbleweed out of the way....

I learned from my testing this weekend (did anybody else test?) that wiping only avatar files and map save files isn't enough to restore the SteamID matching the OwnerID for structures and deployables. But wiping all server files and re-downloading from Steam cured it.

Unfortunately it did not fix Rust++ /friends and /share commands. I'm running Magma now, and both of them work fine.

So, Rust++ is going back into the core Fougerite.dll. No longer will it be an optional module in the next MC release. I'm going to do a cherry-pick merge and bring the last-known-good code into the current code, while keeping as many improvements made since then as I can. It's just too much a part of Magma/Fougerite to separate it like that.

So, Back to the Future.
 
I refactored Rust++ back into the core this weekend, and it was easier than I thought it would be. The June 16 (approximately) version works (/share /friend, etc). It also saves and loads the friends and share data properly. I'm not really sure when it broke. Do any of the MC releases work?

I've been very busy with my real job since Monday and haven't had a chance to work on it more. I need to merge changes made by me since about a month ago, that are on my fork of the repository. I also need to remove the Microsoft Contracts support. It's probable that adding Contracts is what broke it. I fixed several bugs in Rust++ that were introduced by Contracts, before deciding that I needed to go back to an earlier revision and work forward to fix this problem. Contracts were added by Alex in July, after Rust++ and Magma were split from the core.
 
When he added Contracts, Alex also changed how Rust++ received command and chat arguments from Fougerite. That's when Rust++ commands got messed up. Then Alex stopped contributing and disappeared. Thanks Alex. I have rolled back that merge commit and fixed up the merge conflicts. Microsoft Contracts is no more a dependency.

I won't have to refactor Rust++ back to June to put it into Fougerite core after all. I only had to roll back to July. :) It will remain a module. That code is sound.
 
Not only have I worked out all the issues with the Rust++ commands, I've found out that Rust++ maintains a Dictionary<ulong, string> mapping SteamID to player Name, for every player that has ever logged into the server. This data is saved to cache.rpp, and loaded at startup too.

So, in the upcoming Fougerite MC you will be able to use Rust++ commands like /ban /friend /share /mute /addflags /unfriend /unshare on offline players. You can use a partial player name with any command. If there are more than one matches on- or off-line, a list of matches will be shown, for any command that takes a player name. They all work consistently.

Tomorrow looks like it will be the day for MC7. I'm that close.
 
  • Like
Reactions: Jakkee
Whydoes notlike puttingoxidepluginshere?
theyhaveincredibleprotections
 
Tying up loose ends today to prepare a release zip. I had several additions started before I decided I had to refactor and overhaul Rust++ code. It's been a bit challenging to keep the scope of this release focused on Rust++ broken commands. I have come up with a lot of good ideas for Legacy that I want to implement. But getting the /friends and /share commands working again has to come first. :)

I'll also be posting a bunch of Magma plugins that I have updated: TPMaster, Crush, N4DeathMatch, and of course, MagmaFires.
 
Status
Not open for further replies.

Similar threads

TheKichDM
Approved DiscordBOT + API
Replies
8
Views
690
Releases
TheKichDM
TheKichDM
TheKichDM
Approved WebHooks System Simple
Replies
1
Views
323
Releases
TheKichDM
TheKichDM
TheKichDM
Approved PM System
Replies
0
Views
225
Releases
TheKichDM
TheKichDM
TheKichDM
Approved Money / Shop Basic System
Replies
2
Views
306
Releases
TheKichDM
TheKichDM
TheKichDM
Approved Recycle System
Replies
1
Views
324
Releases
TheKichDM
TheKichDM
Top Bottom
Back