Super Mario 64 Online

No, this isn’t really a new release. This is more an explaintation, how future code is compiled.
Before, in SM64O C:X, we’ve used a very crappy way to do this. Now, we have a better way.

As you know, our main coding language will be C. Nothing else. Of course, you want now to release your code, but mainly as a patch. This works good at all, but people are able to recreate the patch in C and steal your code and/or claim it as theirs. So, we’ve decided to make a better compilation and this time, the machine binary code will be compiled too. For this, we’ve created an own algorithm, which does that for you:

For example, we write following C code:

#include
#include "explode.h"

void _start(void)
{
asm volatile("la $gp, _gp");
PrintXY(50,50, "Hello World");
}


A very simple C code. This one gets compiled usually to GameShark code. With PJ64 2.1 ME, the code gets compiled to machine binary into a .bin file. This .bin file can be then patched inside the ROM. However, as I said, you’re able to recreate that code from scratch.

So, we’ve decided a better method. When your code gets compiled, it will be compiled into a special compression/hash format. As you know, it’s not revertable, so better have a backup of your original code.

Then you can easily patch the patch file through PJ64 Patcher. This patcher allows to patch those special compression/hash formats. This should finally prevent stealing code.

Next:
Gamemodes!
Well, I’ve decided to write a new interactive feature, which allows you gamemodes. A gamemode is a setup, which allows you to manipulate all world settings and code some special features into it, a gamemode in this case. For example “Team Deathmatch”. The world settings are not directly changed, but a code is inserted, which allows to fight between mario and mario. In this case, you can also kill an another mario. (Also a compiled function; We’re using a special function, which says; If Mario A hits Mario B, send this to server, check if Punch was true, then send damage to Mario B. Mario B = damaged)

But the cool thing is, you can use gamemodes to change world settings, light, shading, etc. to configurate the gamemode and make it comfortable.
Also, the world settings, doesn’t even have to be written in C, just as simple $ commands. Example:

//environment
$EnvGuiServer::SimpleMode 0
$EnvGuiServer::SkyFile Add-Ons/Sky_Sunset/Sunset.dml
$EnvGuiServer::WaterFile Add-Ons/Water_Default/default.water
$EnvGuiServer::GroundFile Add-Ons/Ground_Plate/plate.ground

$EnvGuiServer::SunFlareTopTexture base/lighting/corona.png
$EnvGuiServer::SunFlareBottomTexture base/lighting/corona.png
$EnvGuiServer::DayOffset 0
$EnvGuiServer::DayLength 300
$EnvGuiServer::DayCycleEnabled 0
$EnvGuiServer::DayCycle Add-Ons/DayCycle_Default/default.daycycle
$EnvGuiServer::SunAzimuth 315
$EnvGuiServer::SunElevation 28
$EnvGuiServer::DirectLightColor 0.968628 0.835294 0.796079 1.000000
$EnvGuiServer::AmbientLightColor 0.600000 0.500000 0.400000 1.000000
$EnvGuiServer::ShadowColor 0.525490 0.560784 0.682353 1.000000
$EnvGuiServer::SunFlareColor 0.100000 0.100000 0.100000 1.000000
$EnvGuiServer::SunFlareSize 3
$EnvGuiServer::VisibleDistance 900
$EnvGuiServer::FogDistance 500
$EnvGuiServer::FogHeight
$EnvGuiServer::FogColor 0.580000 0.680000 0.940000 1.000000
$EnvGuiServer::WaterColor 255 255 255 128
$EnvGuiServer::WaterHeight 0
$EnvGuiServer::UnderWaterColor 51 153 153 77
$EnvGuiServer::SkyColor 1.0 1.0 1.0 1.0
$EnvGuiServer::WaterScrollX 0
$EnvGuiServer::WaterScrollY 0
$EnvGuiServer::GroundColor 0 128 64 255
$EnvGuiServer::GroundScrollX 0
$EnvGuiServer::GroundScrollY 0
$EnvGuiServer::VignetteMultiply 0
$EnvGuiServer::VignetteColor 0.000000 0.000000 0.000000 0.392157


This is the environment control. With this, you can set things, when the gamemode is started.
If you want to run code, just put it inside the folder later. You should call the file server.c and player specific stuff player.c

Through this, we were able to code a little checkmate deathmatch. You can also write it in ASM; but then you will have to use “labels”.

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!

After my SM64 Hack wasn’t really successful, and a lot of retards couldn’t post good levels, I decided to work again on SM64O. This time, I’ve had to rework it again, as you know, I lost all data for SM64O. This time, I made some backups of SM64O everywhere, on USB Cable, external harddrives, etc. SM64O M:X 1.0 is a complete new start, but should allow the same again. By of now, I’ve added the “basic” stuff in there, like the multiplayer code:

• [ADD] SM64 Multiplayer. You can select Mario or Luigi (The Luigi made by VL-Tone) and modify the color of it. When saved, you will be play as that character. Of course, you can change the clothes everytime.
• [CHANGE] Modified PJ64 2.1 -> Glide64 Support
• [ADD] DesynchFix 2.6 (This fixes desynch up to 97%, thanks to messiaen, kluxy, etc.)
• [ADD] Extended SM64O up to 64MB. (With ROM_Extender by Skelux)
• [ADD] Project 64 2.1 supports now up to 500MB RDRAM for you.

Project 64 2.1 – RDRAM
RDRAM is provided through PJ64 2.1 settings. However, with the modified version of PJ64, you’re able to accquiere up to 10MB RDRAM. (While you had 4MB and 8MB) How does this work?
For example, you join with your ROM to another ROM’s server. (Which is also a ROM) Then we have a ROM to ROM (RtoR) connection. Through this we get a client-side RAM and a server-side RAM. The server-side RAM contains all game activities like an exploding object. The client-side RAM just receives this call from server-sided RAM.
Ex.:
0x803A5C9D is Yoshi for example (Not really) -> When Yoshi explodes, the server-sided RAM (ROM) will notice that first. This callee will get posted to all client-side RAM’s, through simulating the call there. So, the exactly same machine code format will be pasted into your RAM. So your RAM will also target on 0x803A5C9D, cause you will download caches from there, which will be patched into RAM directly when you join a server.
(Example: Your ROM haves to be completly fresh and clean. When you join a server, it downloads caches as cache.bin, but converts them directly on your PC to cache.dat (so you can’t steal stuff). That cache.dat will be then patched into your RAM, directly when downloading is done and your character gets load.

So, but isn’t it dangerous to paste the exactly same code into client-sides RAM? For example: Yoshi explodes call on server-side RAM will be also used on client-side RAM. Modifieing this could allow to hack the server and play around with it;
Well, that isn’t true. There’s still our master server. This master server registers changes made on the server. If this change was made from a client, the client will be deleted from the server and disconnected. But the next is, that the Yoshi callee is not in direct connection with the server. It resembles a client-server architecture. You and the server are completly apart from eachother. Making it impossible to modify the server-sided RAM. An exactly explaintation of “SM64O client-server architecture documetation” is here:
SM64_NetworkDoc

Now to something else;
As I said, the RDRAM is there to emulate RAM for your ROM. If you join a server, which requieres 8MB RDRAM to run, it will automaticly set it. It will always auto-set to the correct RDRAM value, which can range from 500KB RDRAM up to 500MB RDRAM. To start a server, which emulates up to 500MB RDRAM, we’re providing FlexROM III, which emulates enough RAM memory for your ROM server. It has fast downloading and desynch is eliminated to up to 97%.
Soon, you will be able to buy them.