Super Mario 64 Online

Today, I’m telling now how you connect to servers in future + telling you the newest updates.
Let’s start.
Well, Kaillera, a known n64 server connection client to play multiplayer games online, used a very stupid way to transfer data over server to client.
SM64O M:X 1.0 solves that, or better “PJ64 2.1: Mario Edition”. This is a modificated PJ64 2.1 version, which also uses one of the best graphic plugins out there: “Glide64″. PJ64 2.1(ME, short for Mario Edition) uses a special way to transfer data.

There are two connection types: RToR(ROM to ROM) and PRToR(Patched ROM to ROM). The difference between two:
- RToR is directly connected to the server ROM and copies the whole ROM files to the computer. RToR won’t be used anymore, in this case.
- PRToR is also connected to ROM, but very differently. While RToR receives directly data from the server ROM, the PRToR type will download all files in an encrypted cache.dat file and patch this one into your RAM (RAM = your current process in real-time, while the game is running. So, your ROM won’t be harmed in any way).

The PRToR has now a patched RAM, you. You have now a client-side RAM. Now this one has to be connected to the server-side RAM somehow. This will be done through the “Server”. The ususal server transfers data between you(the client-side RAM) and the server-side RAM. The server checks constantly for updates, like objects, interactions, etc. -> If someone for example deletes an object, this will be sent over server to your client-side RAM and so the program patches it into your RAM. So, this is a simulated explosion for example.

Ex.:
Yoshi gets killed on server-sided RAM. All client-side RAMs receive that “byte of information” and this will be directly patched into their RAMs.

Before we had an idea: To prevent hackers, just let them do what they want. If they explode for example Yoshi on their own ROM, it won’t be seen by others. Still, it would cause errors, because not only server-sided information is transferred. So we decided to make this a bit better.

All doings on server-sided RAM will be received and sent to all other client-sided RAMs. If Player A walks, everyone else will see it.
But now, there’s something better. To let clients send information to the server, in this case client-side RAM to server-side RAM. But this is very complicated. For example, now someone could edit the real-time RAM memory and send that information to server-sided RAM. So, we decided to prevent all core functions of Mario 64. In this case, some stuff can’t be transferred and never will be. To prevent this, we’ve wrote a long line of C code, which declines special RAM addresses to be transferred over server. For example, deleting objects. But to make it more dynamically we’ve introduced the trusting system:

- You; The You-Trust means, that you can modify all objects, which were spawned on your RAM, in this case, everything spawned by yourself. You can delete them, modify them, etc. This “You” only appears on your name, cause You is You. Lol.
- None; The None-Trust appears on all other names of clients, who didn’t give trust to you. This means you can’t modify or do anything with the other clients objects, in this case, you have no access to them, but of course you can interact with them. Like if it’s an item or a button. However, even this can be modified to make it uninteractable.
- Build; The Build-Trust allows you to build(spawn) own objects on people’s objects. For example, someone build a house, you can spawn on those “objects” your own objects. However, you still can’t modify the objects by the client, who made the house. You also can’t delete or do anything with it.
- Full; The Full-Trust gives you the permission to completly modify someone elses object. You can do anything with it. Modify it, delete it, etc.

But how is this done? Well, this is a special system.
Well, I said, that the server receives every action you do. Some actions are prevented, so if you try to delete an object on your RAM, it won’t be transferred over server. Through the auto-correction system, the object will appear again on your RAM, because it never disappeared. Now, we’ve decided to link objects to server-sided RAM, but in a dynamically way. If some person tries to delete your object, the server-sided RAM receives that request and checks if the person is in your trust list (full trust). If not, nothing will happen, if yes, the object will be deleted for all client-sided RAMs and of course also on the server-sided RAM.

The next thing is: “Administration”. There will be 3 kinds of admin, while the third one is the highest of all:
- Admin; The usual admin is able to “wand” all objects, meaning he is able to delete all objects he wants + he is able to view what modifications has been done on the object, however he can’t modify the object on his own and/or ban a player for “infinity” time. An admin can ban players up to 12000 minutes.
- Super Admin; The usual Super Admin is able to “wand” all objects, like admin, but he is this time able to modificate objects by others on his own. He’s also able to modify the server properties like the server title, server description and the amount of Max Players, max objects, etc. He can be also called Co-Host, because he can take the place of the Host and manage the server on his own, while the Host isn’t here. Super Admins can also ban players forever. Super Admins can also change the Level, meaning changing the level for example from Bob-Omb Battlefield to Peach’s Castle.
- Host; The usual Host is the main controller of the server. He can do everything like the Super Admin can, however he has complete control of the “console”, where he can type in commands and execute server-sided commands; This can be MIPS R4300i ASM or C code. Like you want. The Host is also able to shutdown the server and a lot of other stuff. I think that’s pretty clear.

So, you should be careful how you give trust or admin.
Through this awesome combination, this will make SM64O M:X one of the safest online multiplayer hacks.

In my next article, I will talk about how to create own “gamemodes”, and compile code and several other stuff.

Now to the SM64O M:X 1.0 r14.
UPDATES:

• [ADD] Trust system -> None, Build Trust, Full Trust.
• [ADD] Administration -> Admin, Super Admin.
• [IMPROVEMENT] Improved networking.
• [ADD] Hardcoded several important behavior functions, a lot of object functions and of course the trust and administration system. This prevents cheaters to play around with this.
• [ADD] Beta Gamemode: “TDM” -> Team Deathmatch. This works yet just with fists and is pretty buggy.

More is coming soon!