1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Fougerite

Jan
22
by DreTaX at 9:05 PM
(3,968 Views / 3 Likes)
14 Comments
I feel like facepunch writing posts about progress....

Anyways, finally I had the time, and I got the communication between the client and the server using the SecureBlackboxAPI. Thank god I finally found that since I mentioned this is the third time I was re-writing this crap out of nothing. (The SSL part) Now I just need to finalize the communication between the client-server, and ensure they are sending and reading the messages in the good way. I also have to make sure that If someone would block the communication I would immediately make the client exit. I also have to do a handler at the server side to be able to handle multiple connections at the same time, which shouldn't be too complicated I guess.

After these things are done, I will give @Snake the hand to make sure the It is secured mostly in the client side.

From that point I guess I could do a test with my guys, then do a show off test with you guys, and then some minimal modifications at the server...
Jan
13
by DreTaX at 1:50 PM
(3,396 Views / 5 Likes)
4 Comments
Since you guys asked me about RustBuster, currently I rewrote the SSL part 2 times now, since as I mentioned before the Microsoft SSL API failed to work on Mono, and Mentalis API only works on .NET 1.0.....

I rewrote the SSL part, and successfully switched the client side to SecureBlackBox's API which supports .NET 3.5 and even has a mono version compiled.

I also rewrote the self-signed certificate generator, since It didn't correctly generate a valid one for the server side. Seems to be good now.

Now only the server side remains, if It works and I can send message vica versa, It should be no time to finalize this.
Dec
29
by DreTaX at 11:51 AM
(4,348 Views / 0 Likes)
18 Comments
While RustBuster has It's own version to check, should It change the version of rust?
This means that only those people can join who are clearly using the updated rust.

I was also thinking that if the original steam files were changed steam might update rust itself again. Ew
Dec
22
by DreTaX at 11:47 PM
(4,894 Views / 3 Likes)
13 Comments
Rustbuster is able to detect modified assemblies, while RustBuster cannot be modified itself too.

Detections are going forward, hacks are detected on injections.

Dec
21
by DreTaX at 12:26 AM
(2,744 Views / 0 Likes)
1 Comments
Me and Snake got inactive for a time but now we are trying to finish this in a couple of days.

The program only lacks the communication between the server and client, version check, and some other hack check possibilities.

People will be able to add servers by a help of an ini file to the server browser. Sponsored servers will always be at the official page tab and others.

https://www.dropbox.com/s/rs61zne5mueyo2o/2015-12-20_02-03-04.MP4?dl=0

No worries guys, we will be getting this done soon.
Dec
12
by DreTaX at 8:17 PM
(3,486 Views / 0 Likes)
15 Comments
I will be debugging today the misterious unity crash log, we will see how It goes.

Got instantly busy due to a private project that I got for Pluton team. Can't say much, It's secret for now ;)
Sep
02
by DreTaX at 12:06 PM
(4,847 Views / 2 Likes)
17 Comments
@Snake and I have been working on a client side anti cheat, which will be able to fuck up injected/premade assembly hacks externally.

Our first aim is to make sure that RustBuster is safe to use, and encrypted. We might be willing to provide Developing API on It, and It will be able to unbind/log hack button keys.

Of course we will have to make sure that nobody can ever play out the client, neither the server.

We are currently working on the encryption part. Once we got It ready, there is a huge chance that server owners might need to pay for It (Don't get us wrong, writing stuff like this is time taking as hell)

It will support Experimental/Legacy and ONLY Pluton/Fougerite.

We will be denying the usage of Oxide since our code is not even going to support It at all, and no. We won't be adding support for It. The code most likely going to be private, we don't want people to find easy ways to bypass things in It.
Aug
20
by DreTaX at 3:41 PM
(4,161 Views / 0 Likes)
16 Comments
I will be updating Riketta's Client side and see what can I do with It.

The latest source is at him with a different system, we will see how we got with It.

The release will be closed source, and It will not be compatible with Oxide.
Feb
24
by mikec at 7:18 AM
(2,922 Views / 4 Likes)
13 Comments
Just a heads up. I closed a bunch of issues, and finished the new command parsing. It works really well. Many other bugs have been fixed. But I am really proud of the command parser. You no longer need to put names of players and items in quotes, but you can if you want to. Type all in lower case, or caps lock ON. Makes no difference, it is case-insensitive. You can even mis-spell item names and player names, and if you got most of it right, it will still locate the correct player or item. If you can't remember whether a blueprint is "BP" or "Blueprint" just type either one, the parser knows what goes with what. As you can see in the examples below, you need to spell a player's name about 60% right to make sure it matches. Or put it in quotes. You can also just eliminate spaces from a player's name instead of quoting. Works just as well.

Code (Text):

/give blueprntz 556 ammo 556 )))00)
quantity = 556
testStr = ammo )))00), bestName = Рачок))))00)
itemName = 556 Ammo Blueprint...
Dec
16
by mikec at 10:32 PM
(1,799 Views / 1 Likes)
0 Comments
TL;DR: Javascript cannot handle 64bit integers - SteamID as a number - without losing precision in as many as 3 of the least significant digits. Therefore, when presenting a SteamID to Javascript - Player.SteamID & GameID, Entity.OwnerID & CreatorID, and so on - it will always need to be a string, not an int or a float. I am adding a new property .UID to Player and Entity which will return the Uint64 value directly, without conversion to string. Python handles 64 bit integers differently and has a maxint value equal to Int64.MaxValue, and so a SteamID64 won't lose precision.

You might remember me scratching my head about this: Fougerite MC

I was completely wrong. Not even close. The correct answer is that Javascript uses IEEE-754 double-precision floating point format for all numbers, integers and floats. Even though this format is 64 bits wide, the maximum value for a integer in Javascript is 2^52 -...
Powered by FireDaemon