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.

Sorry, for answering now: I experienced a harddrive crash and lost all my data I had on it, including SM64O C:X 2.0.
SM64O C:X 2.0 should be the biggest update ever, since it fixed a lot of original game bugs, source code, etc. This all is now gone and big work has just been destroyed. Because of this, I can’t restart again, since I lost all source codes to modified PJ64 and stuff. This is the worst thing, which ever happened to me. This means, SM64O C:X is no longer under development and has been stopped working on. I’m very, very sorry for this, but I lost everything I had and didn’t have any backups of SM64O C:X 2.0

The forums have been disabled too, you can upload your files via RTS64. People can download it from their.

Goodbye, everyone. It was a great time.

Currently, I’m not done with the last stuff on SM64O C:X 2.0. So it has to be delayed for some days, I’m sorry.

Hello, everyone!
We’re back at SM64 Hacking (again). The months went gone so fast, but well let’s see…
Someone called “Celux(Skelux)” released a multiplayer hack to the public for everyone to use in the Kaillera client.
I want to tell here, that this hack is not any affiliated with SM64O C:X
We use a very different way, because as you can see in Skelux’s hack, it uses one camera for 2 players, which can be very annoying. SM64O C:X doesn’t has that problem. Every player has it’s own camera and isn’t bound on another players. This was done with a very complicated hack, which still runs fine. We also don’t use the kaillera client, we use our own modificated version of PJ64 (now called: SM64OCX.exe), which contains an own big master server, with servers. However, those servers ARE the SM64 Games, not like the Kaillera client!

This time in SM64O C:X 2.0 Beta we want to add a lot of new things such like new mario animations. As available in older updates you can create own mario animations for weapons, etc. However, some weapons don’t have animations, which caused that mario is stuck at the moving animation, which looks very ugly(O_o). So I want to create some default holding weapon animations, if the creator of the weapon mod didn’t made any special animations for mario. Another point is to create new characters to play with: Guess what first suggestions came up? Yeah! Yoshi. And indeed, Yoshi will be soon playable, with correct moving animations and all that stuff we need.

As of now, we released a new revision, which contains some new beta stuff:

• [FIX] Wall glitches.
• [FIX] Rain/snow doesn’t go through walls anymore.
• [ADD] Added some nice gamemodes for your server(Inspired from UT2004): Assault(Do missions and the first team who success, wins), Double Domination, etc.
• [ADD] Super Debug can be now used by admins and super admins, however… it’s limited. Admins just get a half to see of Super Debug, while super admins get to see the whole rest. However, only Host can use the last page, which allows to configure the server. (Safety purpose)
• [CHANGE] Desynchronisation is still a big problem, I now did bought a completly new server and set it up to be used as master server. It decreases desynch about ~78% even with MaxPlayers 40.
• [CHANGE] As you saw up there, the maxplayer count has increased to 40 players.
• [MOD] You can now use C to mod SM64OCX.exe. It’s limited, but you can create own Tabs for example. -> To prevent modders to create cheats, we also changed the way of how server/client stuff is transferred. This does make it impossible to modders to create cheating tabs.
• [ADD] There’s now a new Debug menu called: Mega Debug, which is a GUI(in SM64O C:X, in classic mario style ) and contains normal Super Debug options + some nasty features like doing real-time stuff to the ROM. (Can be only used by Host) For example, you can write a real-time ASM code, which directly affects the server. You can also choose C or LUA(limited).

Super Mario 64 – Source Code in C

Currently, we were able to extract a Z64 file… No, we didn’t decompressed it. We were able to restore the real original files from 1995/1996 of SM64! The same we did with our modificated version of SM64O C:X and we found a lot of errors in code. (This was caused by hack programs, those don’t have the source code, which means that every mod isn’t really correctly working)

We now choose that we’re going to release a part of our SM64O C:X Source code. (This means Server Source Code (SSC) and client Source Code(CSC). ) -> In the server source code you can edit some features we added, like the vehicle support… Everything! Just the main source code for the game isn’t available due to copyright issues. (I’m very sorry about that) Just stuff that has been added by us, is editable and you can create own features for it! In CSC you can edit the layout of the GUI (Remember, this just affects the client which has the mod!) and add own made textures for SM64O.

Please remember to update your mod when a new SM64O C:X version has been released, because new versions can cause errors to older versions. Due to safety, we also added auto-disabling method for mods, which aren’t working for the most current SM64O C:X version.

SM64O C:X – Projectiles(and projectile physics too)

We’re currently working at better projectiles (as suggested by several users) with better projectile physics. This is possible and will be done in the next time. Desynch of projectiles are highly possible, which is a problem. Preventing it isn’t really working, but there are couple of ways to rewrite some parts of the original mario 64 objects. For example, I’m going to rewrite some big sized objects. Yep, I’m going to make them less big to make them fast transferable over the server.

Hello, this is the final release of SM64O C:X. Yes, it’s sad, but true. SM64O has currently over 30,000 registered users, while only 1300 till 3000 are active. I’m thanking everyone for those great years, and this time, it’s really the end. However, the game will run forever, if there are master server problems or the hoster changes the service, then I may fix it. Last thing: This game will not be developed anymore, but you can still(if you’re new) get it, it doesn’t costs anything. Just go to the link and send the details I’ve wrote there.

(The forum has been closed also.)

UPDATES:

• Infinity boundary patch. This patch allows to build very big levels, which has no boundary.
• Variable Dialogs(VD, more later)
• MIDI has been removed and replaced with Ogg Vorbis sound(short: .ogg)
• Event/Action Patcher. Allows you to patch VE/A’s to the game. (You will type in text files like this: OnMarioTouch -> Mario -> Kill)
• Added new weather effects: Storm rain with thunder, etc.

VD(Variable Dialogs)

Well, you know VE/A, don’t you? It’s a new feature that was released in 1.2 of SM64O. It is really great so far for making RPG’s etc., but there’s a little problem:
You can’t use variables in Dialogs (yet). I decided to allow the user to make variable dialogs. Such like the old saving method of SM64. When you activated the button, then you could decide:
Save or not save. This was an boolean variable. But the best example would be: Koopa Troppa. When he asks you to race, then you can choose Yes or No. If you choose yes, then the variable of it gets set to 1 and with a easy: OnVariableTrue or If -> <<var:cl:koopa>> == 1 etc. You could call up the timer, etc.

EULA License expired:

We had a deal with the nintendo corporation, which expired yesterday the 23 july 2012. This means, SM64O is no longer a legal modification. We used (even before the deal) PPF Patches for our SM64 modification. However, after we made the deal, some people shared this online ROM over several hosting services. As of now, you’re not allowed to it. So we please you to remove all SM64O ROM’s from the hosting services. Upload the PPF Patch instead.

Okay, after some month I came back again with a new update for SM64O.

UPDATES:

• [ADD] Variables for Events/Actions. You are now able to define own variables. (Ex.: OnMarioTouch -> Object -> Define_Variable -> [TextBox1] [TextBox2] {TextBox3}) In TextBox1 goes the variable name and the third textbox is the Object you wanna point to, which means addresses. So you have to know the address of an object. If you don’t know it, then just go in First Person and look at the object and chat: /getAddress (You will get the address of the object, the address of the actions and functions + the address of the color etc.) (More about Variabled Events/Actions = VE/A very down)
• [ADD] default weapons: Pistol and Sword.
• [ADD] NEW! Character menu to change the colors of your Mario.
• [ADD/FIX] Mario64 Launcher = When PJ64CX.exe gets started, then Mario64 Launcher checks for updates and replaces changed files. (This has been made to the own safety. Don’t blame me for this, blame the exploiters. This little update means = No changing UI anymore, etc. No changing original files anymore.)
• [CHANGE] Client/Server Communication improved. Every packet is now encrypted as MD5. The reciever will check the original packet with the MD5 and load it. MUCH SAFER!
• [PATCH] Celux’s Boundary Patch. (Allows you to import bigger levels.)
• [FIX] Symbols and letters like ä, ö, ü, ß and others are now displayed correctly.
• [DEL/ADD] Stupid hack I made for position/synchronisation fix has been deleted and replaced by Synch Fix by Distra, which works a lot better.
• [ADD] NEW!! Animation hacks! They allow you to create custom animations for mario or just call up existing one’s already. To make custom animations go to Create -> Animations -> New Animation -> PlayerType -> Mario, Enemies etc. (Now you can see the display screen with the 3D object and there are arrows with X,Y,Z. Press record and move them to create the animation. Then you can generate a C script what actions shall happen when Mario does that animation, or you can manually write yourself a C script. Variable Replacers are <<var:player:animXYZ>> and <<var:player:animaction>>.)
• [CHANGE] Server’s have now instead of 2 Server Types(Public(Internet), Passworded) now 3 Server types(Public, passworded, Private) The private function just doesn’t let the person enter the server. Just the host and people you wrote on the white list. White list is on Start Server -> Options -> White List.
• [ADD] NPC Dialogs can now have layouts.
• [CHANGE] Imporved C Scripting a lot. You’re now able to point at objects. For example (*Obj)->_0x164 = (*Obj)->x_pos;

VE/A – Variable Events/Action : How to use it?

It’s not that hard. There’s an officiall manual to the rest of the VE/A Tutorial.(VE/A functions, If Statements etc.). This here is just an instruction:

The first thing we have to know: Variables!

What are variables? Variables are places where you can store numbers in. But also strings(words) can be put in there.

Defining variables:

OnMarioTouch -> Object -> Define_Variable -> [Clocknumber] [2] {No Address needed}

Now the variable Clocknumber contains the number 2!

Now, for example, when you want your Variable to be displayed as text, then you have to replace the text part with the variable. We call it: Variable Replacers.

OnMarioClick -> Client -> PrintXY(80,80, “The variable Clocknumber contains: <<var:obj:Clocknumber>>”)

It would now print, when you click:

“The variable Clocknumber contains: 2″

THERE IT IS! Finally the 1.0 of SM64O C:X is released!

You can now press Download and following the instructions.

Thank you to all testers who helped here. We were working hard on the officiall 1.0 and it’s ready for release till i fix the last bugs on the list. After the Beta Test, the officiall release will occur. You don’t have to pay anymore for keys. You just need a valid N64 console + a valid Super Mario 64 Cartridge (US Version) else we will not give you a key. To validate, you’re speaking the truth, you have to take a photo of your N64 console + your SM64 (US) and send it to me. (I also want to see, the proof you’re having the US version.)

So, after all, we fixed a lot of bugs and added some new various features for SM64O C:X 1.0

Upcoming Updates, SM64O C:X 1.0 will add

• RSS Feed Blog feature. You can always update Dialogs, if you link them with your Blog.
• TT64 In-game Editor. Allows you to directly edit in the full TT64 Edit mode or you can use the play mode instead and modify the object variables.
• Actions/Event System. It allows you to put Actions/Events on the object. Example: OnMarioTouch -> Object -> Collision -> Off (If Mario touches the Object, then the object will have no collision anymore. You can change that again by using the “Wrench” and set Collision on On again.)

There are more things to come, but it’s too much to tell them right now.

BTW, all Beta servers are down, but for the beta testers:

You can still play the beta in SinglePlayer. But tomerrow, the beta will be updated with the officiall version. (Beta users don’t have to post their N64 console etc. again.)