Super Mario 64 Online

After checking one of my older e-mail accounts that I haven’t been using for years, I have noticed an uprise of many messages via the e-mail system of this (long outdated) blog regarding the connection of SM64O M:X and Net64+ as well as questions regarding the connection of the SM64O source code and the sm64 decompilation project (aka sm64-decomp). Since no one else here responds to them (Tarek701 has long since abandoned this project here; especially after TechTools stopped selling and supporting FlexROM III), I would like to elaborate on a few points and clarify some things to avoid future misunderstandings. I also disabled this blog’s e-mail system since we no longer support this project. So consider this article the ultimate capstone.

SM64O M:X and Net64+

First of all, there is no connection whatsoever between SM64O M:X and Net64+. Furthermore, SM64O M:X has long been abondoned. Even though both had more or less the same purpose, Net64+ is a completely separate project to which we have no connection. In addition, SM64O M:X was a much more advanced and complex project than any other project in this direction. On closer inspection, the newer Net64+ 2.0 seems to be closer to what we had already achieved years ago. Unfortunately, this project has probably been discontinued indefinitely as well, but there are many more that allow you to play Super Mario 64 online with others. For example, there is currently sm64js. A very ambitious project that I am very excited about.

SM64-decomp and SM64O Source Code

As for the leaked source code for SM64 (also known as SM64-decomp), again I would like to stress that we have no connection to this project. We had already decompiled SM64 years ago, documented where necessary and created our own mods for it. In fact, the decompilation process itself was the easiest part, but the most difficult part was the documentation and naming, which we never fully completed. SM64-decomp is therefore, as far as that is concerned, much further along than our project ever was. I just want to dispel the rumors that we “stole” anything. This is not the case. We had decompiled SM64 first, and documented this decompiled source code extensively where we found it necessary. But we decided to make the decompiled source code only available to a few users, and wrote an additional program, so that the source code was only accessible through this program and otherwise remained encrypted.

This guaranteed that the project could not be easily copied and completely modified or the source code leaked. We developed our own game engine that served as a framework for our SM64O project and had made the source code available to some users. Basically it was intended to make modding for SM64 easier, but was mainly explicitly tailored to SM64O. It had a so called “Mission Editor” which allowed placing, moving, removing, etc. of objects, a “GUI Editor” which allowed to create customized GUIs for dialogs, etc. It also had its own scripting language, Mario64Script, which can be compared to “Tweaks” in Skelux’s Level Importer, except that Mario64Script was much more advanced. Also, the SM64O engine had an animation editor, GFX editor and palette editor, as well as a physics editor, which allowed changing certain physical aspects in the game. These included gravity, wind, as well as physics components we programmed ourselves, such as weather (snow, rain, etc), soil, etc.

All in all, SM64O M:X was probably the most complex SM64 online hack ever built. I am not aware of any SM64 hack that has modified the core functions as extensively as we did with SM64O M:X. Unfortunately, our project never gained the notoriety we had hoped for, mostly due to miscommunication on our part. Tarek701′s native language was German. In his earlier days, his English skills were not sufficient enough to adequately express the technical terms and contexts in English. This made it sometimes very difficult to follow his trains of thought, nevertheless he always convinced us with the results (which we understood even without language). Unfortunately, most of the project’s source code is lost and was privately hosted on Tarek701′s repo server, to which I no longer have access to and only responds with an 404 error.

Closing Remarks

Of course this website will remain as a piece of Mario 64 hacking history and since I still have access to the FTP server and the original host provider, it will stay that way for a long time. We can rightly and proudly say that SM64O M:X was the first online hack for SM64 ever, which at the same time was also the first ever successfully modified recompiled proper decompilation of SM64. (even though our decompiled code was only sparsely documented). Thank you to everyone who was involved, played or helped with this project back in the day. It was a great time back then and I’m glad that I met a lot of nice and funny people while working on this project!

No, currently we don’t have any updates available for SM64O M:X, as it’s a really hard working thing. But trust me, v1.0 is gonna be awesome.
All I want to say is, that another three FR3-256M FlexROM III,256Mbit,32Mx8,45ns came. So, we have now have a total amount of 23 FlexROM emulators.

Currently, 12 devices are being used by SM64O players, while 11 are still available. You might ask, why so less? A lot of people play SM64O, so why are there still so many available? To answer this in a short matter: You need some qualifications to get a FlexROM server. A lot of people got their money back, yes I really paid it back in full sum. From now on, you also need a special qualification to get a FlexROM server. I remember, when I sold my older FlexROM servers, half of them were full of, how shall I call it, useless stuff. Also, the servers were quite unpopular and so a lot of electricity is wasted and so the money.

So, I decided, that you need some qualifications to be able to buy one of the FlexROM servers.

• You have to be on SM64O M:X for an amount of full 2 years. (I might do some exceptions if the 2nd requirement is good enough)
• You need to have a quite popular status.
• You always need to know your “current” theme, which is run on your server. Your current game “theme” may change every 4-5 days.
• Your SM64O server needs a special kind of “quality”. No one really likes servers that are crappy build and every 4 year old could do with their LEGOs.
• You should be always actively working on your server! I’m not forcing you to work on it every day, but be as much active as you can, because inactive servers or even worse stuff like unmoderated servers are just lowering your karma.

And I finally decided to make FlexROM III servers “FREE” as it makes no sense anymore to sell them. However, this FREE does not mean that you can simply ask for one and get it, you will most likely get qualified for it and probably get a recommendation from one of my moderators or personally from me. To get US to notice YOU, we have added a new rating system, called: “Server Karma”. This is a “class” system:

1. Guests can’t karma rate servers.
2. Normal Users(legitimate registered users of SM64O M:X) can karma rate servers. Their power is about 0.345 points high.
3. Veteran Users are also normal users, but who played longer than one year, and can still karma rate servers, but their rate is more valuable than of normal users. Their power is about 0.797 points high.
4. Super Users are special users, who are known and have popular servers their self or played and won many official SM64O M:X matches, and can also karma rate servers, but their rate is even more valuable than of veteran users. Their power is about 1.343 points high.
5. Moderators have the highest karma rating power. It’s about 2.345 points high.
6. The Owner(me) isn’t actually rating servers, but only does if it’s a really special thing. The karma rate power is exactly 5.

To be qualified for a FlexROM III server, you need atleast 120 karma rating points. This still doesn’t mean however that you’re clearly getting a FlexROM server! This just means that you’re qualified for getting one. As there are many other popular servers who want a FlexROM server, it will be decided by the highest karma rate. The server with highest server karma gets FlexROM for 1 year, the 2nd place gets it for 6 months, the third place gets it for 3 months and fourth place gets it only for one month. And this goes on and on. It all depends on your server karma. After a whole year, it will be re-decided again. Also, if you had a FlexROM server in the last year, you can’t get one again in the next year. You more likely would have to wait another year to be on the challenge again.

If it should happen on coincidence, that two or more servers have the exact same karma (which I doubt) then all servers get one more week time for users to rate karma.

Selling Custom Stuff on SM64O M:X Master Server Shop

A new update arrived! From now on, you can sell your custom-made SM64O M:X stuff for “real” money. You can sell gamemodes, ASM Hacks, SM64 Hacks(Special one’s), Weapons, own made Mario Skins or even models, etc.

The max price allowed is 5$.

A lot of work has been done again. This will be the last update until the autumn holidays.
Biggest improvement was this time, thanks to the help of UGotBalls (his SMWC Profile here), the physics and graphics engine by SM64.

Here’s also a preview of how it looks like currently:

(Click on pic, to see in full size)
Yes, the trees are glitched up. I’m not sure why, but UGotBalls said, it was because he had to rework on the polygon commands, which also meant that he had to remove some of the pseudo 3D object commands.

I never thought we could improve it that far. UGotBalls worked long on it and decided to help me from now on with SM64O.
Several physic updates, like “props” and several other stuff has been made. UGotBalls said however, that it still needs a lot of fixing. Some collision commands are still not working yet, meaning that this should remain as an alpha feature. And so it will! Also, SM64O M:X 0.8a is supporting Mega Debug 3.0 and finally a GUI Enhancement has been made. (Yes, I’m actually talking about an in-game GUI Library. You can use it through C, Lua or C++)

Mega Debug 3.0 supports now big things:

• Toolbox. (Let’s you load props, objects, etc. into your server. It’s the new spawning method. It also allows you to download online content and load it directly into your server)
• Mission Editor (Allows you to edit, control everything in your server about objects. This includes players too) -> It’s a nice GUI and very user-friendly.
• Server Control (All server-specific stuff. Like server title, server description, passworded(yes/no), admin panel (who shall be admin or super admin?), and of course a special page on server control, in case some add-on wants to place a value textbox for some function into that page.
• NEW music stuff! You can now directly import your MIDI, WAV music directly into the server and let it play! (Yes, WAV music is finally supported too. The most is done through emulation)

Also, we’re also including the Mega Debug 3.0 source code. It’s written in Lua. Feel free to edit and change it to your own. You can also release it soon in the forums, but please give messiaen and us credits then.

Currently, we’re giving out some new alpha/beta keys again. We allow 100 people to test the new awesome graphics update. Look at the “SM64O M:X Beta” page to register and ask for a key.

———-
For the others, normal users, we released a new update to fix some bugs and added now a kind of “chat” and finally released MegaDebug 2.3, which is not supporting the features of Mega Debug 3.0

For those who aren’t sure what MegaDebug 2.3 is:
MegaDebug is the very improved Super Debug by frauber(aka messiaen). Here is an old video:

Super Debug featured changing music, spawning/controlling/editing objects, changing collision type etc.

Mega Debug however, features the same like Super Debug, but a lot more. Like the admin menu, editing real-time RAM code, etc.
Mega Debug 2.3 cleans up some stuff and is a bit easier to handle now. Instead of pressing several D-Pad Buttons to change pages, you can simply select now on the main page between 4-9 pages. The main page has two pages, as the letters on PJ64 screen are too big. To change the page, simply press the (Next page) button.

Other updates are simply a new chat and we fixed around 3-4 exploits, that could be used to play with any mario object.

SM64O Forums
The SM64O forums has been down for a while, but after we announced the alpha/beta SM64O, we will need it more than ever. That’s because, we need people that find bugs and report them to us. This means, that the SM64O M:X forums will stay “exclusive” and is only available to legit alpha/beta users. The public opening will happen after we released the 1.0 of SM64O M:X, which will be probarly february 2014. There’s a lot to do now and we also wish that some people are going to help us with coding, graphics, etc. If you want to apply to help us, simply contact us through my e-mail: hans.merzen@web.de. Of course, you can also PM me(Tarek701) on SMWCentral.

FlexROM was gone for a while and it went down 3-4 days ago. This had a reason. Finally, after waiting for months (!) the new FlexROM devices came!

I’ve had a little contract with TechTools and so I had the ability to buy 20 FR3-256M FlexROM III,256Mbit,32Mx8,45ns EPROM, FLASH, SRAM Emulators.
Yes, it supports finally 32MByte. For usually one FR3-256M costs $2399.00. Now multiply this by 20. I would’ve paid 47,980$ for such twenty things. TechTools however gave me 50% less of the price! This makes 1199.50$ multiplying by 20: 23,990$. Awesome!

So, I have now twenty of these fine things and set them up 3-4 days ago. It took me a while, so don’t worry.
Those, who still had the older 10 FR3-64M (64MBit FlexROM) may not be frustrated. I sold them to order another three FlexROM III 256MBit Emulators. However, they will most likely appear in the next 3-4 months only. (Blame TechTools)

The Story:
I’ve ordered the new FlexROM III Emulators over 6 months ago, it took a while progressing the stuff. Usually it should take 4 months, however took 2 months longer, because TechTools had a “business” problem on working on their website, making the support less and work lower. Now after 6 months they’ve appeared and happy that they finally came.

You may ask, how to set them up? Well, as usually: You don’t need to! They’re done and ready and just need to be used. However, I will allow the user to set the voltage of the device. To prevent damaging, I’ve programmed a little plugin (hard-coded), that will prevent you reaching a voltage higher than 5. (As TechTools states in their manual, FlexROM isn’t made for “super” high voltage stuff, so any higher value can damage it.) To ensure, that you don’t do shit on purpose, I’ve done a little “real-life” thing, which can’t be cracked unless you come into my house. (Lel)

FlexROM III – How it works for SM64
FlexROM is really one of the less really good EPROM, FLASH, SRAM Emulators I’ve ever seen. Yes, it haves some disadvantages like, that it cannot handle super voltages (> 5V), but offers a high downloading speed. (Exactly: 2.5MBits per sec)

Now, we actually need a way to get it to work?
For this, I’ve simply bought a high-speed server, that transfers all stuff from FlexROM over my server PC to all clients. So, when buying one of my FlexROM III Servers, you actually buy a part of my Server PC too.
My Dedicated Hosting service supports:
“Intel® Core™ i7-4770
Quadcore Haswell
incl. Hyper-Threading Technology

RAM 32 GB DDR3 RAM
Hard Drive 2 x 2 TB SATA 6 Gb/s 7200 rpm
HDD (Software-RAID 1)
Class Enterprise
Connection 1 Gbit/s-Port
Guaranteed Bandwidth 200 Mbit/s
Backup Space 100 GB
Inclusive Traffic 20 TB*
”

(Don’t worry, it’s purpose is not only SM64. Of course, I will balance it out, so nothing is disadvantaged later)

So, any information sent from FlexROM will be transferred over the Dedicated Hosting Server to all clients connecting to it. The FlexROM emulates the Z64 Code (SM64.z64) in a very fast way. Then you simply need my modified PJ64 Emulator, that connects to the server. Then you get a high-speed result in your emu screen. If some hardcoded stuff in the game can be bypassed, we could see FlexROM’s true potential. Bypassing the object limit is already possible in some ways and it works perfectly with FlexROM without lag.

The best on FlexROM is, that you can write in “real-time” mode (actually while the game is running) into ROM and RAM at the same time. Of course, ROM Editing won’t affect the game directly (only if you restart) but RAM Editing is completely in real-time and you can use C coding to access these IN real-time! You also get special software, that allows you to do several stuff. Through the “QuickLoader” for example, you can load written C code directly in the FlexROM device and send it over your server directly to the clients. So, when doing real-time RAM stuff or making some custom stuff, you can make the client directly download it. Remember, that you can’t transfer any EXEs or DLLs. The code routine is also checked and the code you receive is only ran from the emulator itself, preventing any inappropriate behavior by the host. Alternative you can also use QuickLoader to monitor the current voltage, reset status and target activity.

Attention! If you want to load binary or hex files you will need to use RTLOAD32 (RTLOAD16 isn’t really useful for N64 stuff, but could be used for “short” stuff. It can actually save some space)

To increase the downloading time, you will need to set the /V0 Parameter. Usually, FlexROM verifies the current contents and notices if something has changed. This allows you a way better control over your server and has a nice anti-cheating method. However, through the /V0 parameter downloading speed will be increased for clients, BUT the verifying process is skipped, which means that no changes in contents are noticed. So, only do this if you either have an own anti-cheating method or if it’s really necessary, when transferring some special files.

To not confuse SRAM with RDRAM (DRAM) -> The RDRAM is protected by SRAM, making the RDRAM into a RDSRAM. (Rambus Dynamic Static Random Access Memory) Through this, you can edit real-time RDRAM, that directly affects all clients! The SRAM is then modified through this. The clients receive the SRAM data, the unmodifiable (static) data. This has a very big advantage: It will prevent cheating 100%.
In the SM64 ROM Server Panel you can select, which Super Admin should have access to RDRAM data. Only do this, if you’re completely sure about what you’re doing!
So, you can also choose between a time corridor you want to update the SRAM data, as it doesn’t needs a “periodic” refresh like (R)DRAM.

The SRAM information is LOST, after you turn off the server. (aka the FlexROM device) This means client data will be not saved on anyone’s PC; neither the host’s nor the client’s! This has an advantage, but a big disadvantage: On the one side, it prevents stealing any RAM Data from a server, making you completely save against any stealing methods, on the other side however special values like RPG or other variable values cannot be saved into ROM folder. For this, I’ve created a method in a little FlexROM III plugin, that allows you to target the SRAM routine and save every information from the client to the host’s folder. If the server is re-hosted again, the ROM data will be identified with saved SRAM data, then load in RDRAM and the build-up process begins. At the end SRAM data will be set up. You can set if the SRAM data should be saved to your folder every 5-10 minutes or do it manually through actions (like if the player presses save, then HIS SRAM data will be only saved. Is recommended, as it’s faster and won’t really affect the SM64 Server) Also, before I forget: If clients send their Client-RAM information to the Server-RDRAM (aka Server-SRAM), then the Client-SRAM (on the client) gets compared with the Server-SRAM. If everything went right, you get a callback and the result is finally changed in Server-SRAM and then transferred to all Client-SRAMs (Except value and personal stuff like some variables.) generally for all objects and actions.

The call methods for saving SRAM Data to Host’s folder are:
void AttemptSaveSRAM(U32 Bottom, U32 Top, *ServerFolder);

Bottom is the start address: 0×00000000 and Top the End address: 0xFFFFFFFF. *ServerFolder is the pointer to the address, that leads to your server Folder. You don’t need to do anything to it.
Ex.:
void AttemptSaveSRAM(0x001C987A, 0x001C9880, *ServerFolder);

This would save any Server-SRAM AND Client-SRAM from 0x001C987A till 0x001C9880.

void AttemptSaveCSRAM(U32 Bottom, U32 Top, *ServerFolder);

This would save any Client-SRAM to Hosts folder, but leaves out server-sided stuff. (Like current object position in server, level data, weather stuff, server textures, etc.)

void AttemptSaveSSRAM(U32 Bottom, U32 Top, *ServerFolder);

This would save any Server-SRAM to Hosts folder and leaves out any client stuff.

To load SRAM, the codes will be pretty much similar. Simply replace “Save” with “Load”:
void AttemptLoadSRAM(0x001C987A, 0x001C9880, *ServerFolder);
This loads the saved SRAM from the folder (server and client!) to current RDRAM(aka RDSRAM).

void AttemptLoadCSRAM(0x001C987A, 0x001C9880, *ServerFolder);
This loads the saved Client-SRAM from the folder to current Client-RDRAM aka Client-SRAM.

void AttemptLoadSSRAM(0x001C987A, 0x001C9880, *ServerFolder);
This loads the saved Server-SRAM from the folder to current Server-SRAM aka RDRAM or RDSRAM.

If Mario for example presses a “!” you can make this code load. You can do it through C like showed up there(but need to hijack of course the current address.) or through a subroutine jump:
ADDIU SP, SP, $FFE8
SW RA, $0014 (SP)
[Current Button Code]
JAL -$01978C20
LW RA, $0014 (SP)
JR RA
ADDIU SP, SP, $0018

-$01978C20 is a pseudo-call, that calls FROM (remember, you’re not able to call FROM RDRAM to SRAM) the SRAM to RDRAM. (Everything under $00000000 in addressing is SRAM!)

To hijack an object in C, you simply need a way to make the *Obj Pointer point to the object you want. You can do this through RAM Editing the behavior. (go to the behavior code, that loads the usual routine, stop the real-time mode and change the behavior loading code to 0×80400000 aka 80 40 00 00 00 00. Then write your code into 0×80400000.) After you did this, you go to your C code and write your code. Then load it into 0×80400000. If you’re done, press refresh and turn on again the real-time mode. The code should be now executed. (Remember, behavior scripts are executed every frame through a loop) Remember, if you have another behaviors that you want to hijack too, then you shouldn’t use the same address like you did on others, unless you’re making a global thing and extending the line on behaviors.

The FlexROM III Servers offer:

• 1GB RDRAM (A lot of freespace)
• High-Speed Downloading, 2.5Mbits per sec.
• Several anti-stealing, anti-cheating methods
• 24/7 Server Support.
• A good admin panel, allowing people to also moderate your server.
• Real-Time RAM Editing, affecting directly all players.
• DMA Transfers WAAY faster than before.

Prices on the FlexROM III page!

SM64O M:X has a lot of fixes and additions to the ROM. The main features are mostly about compiling MIPS R4300i Code. Yes, you might ask, how compiling binary code? Well, it’s not really compiling. More likely it’s a better method to “hardcode” things into game, through ASM. Let’s make an example.
We have the code:
LUI T0, $156C
LW T1, $3FFC(T0)
LW T2, $1880(T0)
BEQ T1, T2, Equal
NOP ; Delay Slot
LW T3, $3FFC(T0)
ADDIU T4, T3, $0001
SW T4, $3FFC(T0)
Equal:
JR ra
NOP ; Delay Slot

This code is a simple branch on equal code. Easily manipulative, as you see. I could simply set it to a branch on not equal code, the game wouldn’t even notice it. (With game I more likely meant the PJ64 Engine I’ve built in there, that checks for game changes, etc.) To prevent this, this code gets compiled to a shorter code, which parts the code into more than 20 parts! The code also changes and transfers itself on a lot of random addresses, so people cannot change it unless they find the current address part, which is nearly impossible. This was really hard work, as I had to do it for EVERY code. So, I’ve written with some help of Nexus some codes to make everything compatible. Instead of rewriting PJ64′s way on processing MIPS code, I simply wrote a code, which parts the “emulated” MIPS CPU into two Main MIPS CPU’s: The Main MIPS R4300i and the Pseudo MIPS R4300i. The difference is just, that pseudo MIPS is completly random and encrypted and compiled Main MIPS code.

So, the code up there is then compiled to pseudo MIPS:
LUI T0, $FFFF
LW T1, $000F(T0)
LW T2, $F000(T0)
JAL $9D00007C ; For example
NOP ; Delay Slot
LW T3, $0000(T0)
ADDIU T4, T3, $0000
SW T4, $0000(T0)

_0x0e39:
JR ra
NOP ; Delay Slot

You notice, that after JAL no values are given anymore aka $0000. This is one advantage in pseudo-MIPS. Instead of placing the values there, they’re declared through the JAL code and doesn’t interrupt the usual routine. So, those $0000 are more likely pointers to the values, but those pointers are not constant or static, they’re completly dynamic and even point to pointers, and these pointers point then to other (more than 5) pointers and the last one first, points to the actual value. Of course, this can be very frustrating for the game, as it starts to lag the game. (You know, every opcode takes a specific amount of machine cycles) To prevent that, the pseudo-MIPS is mostly done through the PC’s CPU. So, if you have a good processor, that haves more than 2.1GHz, then you can expect the usual 60FPS and you won’t even notice that something changed. Now, at the beginning of the code with LUI T0, $FFFF. You also noticed, that the code is $000F, then a $F000 follows. This is also made on purpose and gets aggregated with the pointer’s value. A really complex thing, I have to admit. But it prevents now a lot of online ASM hacks or any other kind of in-game modification. Of course, you could edit your ROM, but that wouldn’t change anything, as the ROM has already another encrypted format + when joining a server you WILL have to download the cache from that server, which automaticly replaces your whole ROM to original.

UPDATES:

• Compiling MIPS code.
• [ADD] Weapons! (Written in C and compiled to MIPS through MinGW) Added a pistol (the projectile is that bullet, which gets shoot from those things, ah damn I forgot the name.) -> Also, in PJ64 there’s a template code on how to create a weapon, with a projectile in C.
• [ADD] Support for the SM64 Game Engine to be used with SM64 Online. (Attention! The professional version will of course not allow the source code of SM64O, but you can use C# for coding RAM Objects and stuff instead of using C. You also can use the animation editor, you can integrate some RSS Feed stuff and use output PHP in the dialog boxes, etc.)
• [ADD] Added a better MIPS R4300i Manual. It includes now the basic stuff from loading/storing addresses and values, branching, subroutines, etc.

Sorry, this time again patches:
People were recently using floating exploits/hacks to float in air. It’s getting annoying, really. Stop it finally.
Then there was an attempt to simply edit server-objects by fucking around with my networking principle. This is also patched now.

Okay, today some patching updates again, since a while people were complaining about guys, making TAS Bots to go through walls and glitch in their servers. It was complicated to patch this somehow, as I wanted to allow modding ability to the emulator GUI. But I didn’t thought those guys could find out how to hook it into R4300i RAM. So, I made a couple of game fixes, like the going through wall glitch. If someone is trying it again, and he has success, then mario simply respawns. It’s also not possible anymore to slow down your client, which is needed for good TAS’ing. Still, there are tools, which recorded TAS’es, which could be used. To prevent that, button checks are now introduced for servers. If buttons are pressed a lot in less than 1.3 secs, mario simply respawns again. Trust me, it will only happen if you use bots, Mario would never respawn if you use your hands, because it’s impossible to reach that high amount of speed. Then TAS’es can be delayed, so I thought about adding another method: Emulator Check. It checks if any external program is playing around with R4300i RAM and tries to slow down the R4300i CPU. If someone does, it immediatley disconnects you from the server. But, you will leave a server notice to the server host. So, if you slow down your CPU, you get disconnected, the others will see in Chat: “XYZ has been disconnected, because of modifieing his R4300i CPU”. This is a good way for admins, super admins and hosts to find out if he does it again and so you can handle this better than before.

• [FIX] TAS’ing in servers eliminated, through several methods.
• [ADD] New way on how to check for buttons.
• [ADD] EmuCheck.

Today, I’ve released the new r57 of SM64O M:X. Yes, I’m sorry. Actually, I’ve wanted to release this version on June 11, but well… I had to fix some errors, which occured.

UPDATES:

• [ADD] EEP Savefile feature.
• [ADD] New menu layout.
• [FIX] Exploit patched.

Then to something else. The last 6-7 days, some hackers discovered a little exploit, that allowed to change server-sided stuff. They used some MIPS Assembling and discovered how to trick the server. I’ve patched this once for all now.

Today, I was working with the save file. (.EEP) Through this, you can save your current state to the servers ROM folder. Those savefiles are ordered and store the binary data, which is responsible to check if the ROM save file is yours.

With the savefiles you’re able to save in future RPG stuff or anything else. Of course, it will be saved on the ROM folder of the Server or else this wouldn’t make much sense. Lol. Just saying: The .eep files are not compiled or anything, allowing the server owner only to edit the files. If you notice, that he cheats or changes your values, then stop crying. Go to the forums and post it into the “Drama” forums, so in future people won’t join that server. No, really. I don’t have the fucking time to write another compiling algorithm just to prevent “cheating” hosts. If a server owner is cheating, then leave the server and don’t play it.

I will release the new revision tomerrow.

Today, we’re going to release another version of SM64O M:X

UPDATES:

• [ADD] Able to code gamemodes now.
• [ADD] Limited Vehicles
• [ADD] Mega Debug v2.0 (The very improved one. Super Debug by messiaen was old. We improved with Mega Debug A lot of stuff! It contains the admin menu, build menu, etc.)
• [ADD] Lua script support for in-game and tabs for PJ64 2.1 ME.
• [FIX] Polygons are dynamically now. This should prevent the messed up shit in future.

Upcoming stuff:
Improving SM64 Physics Engine.
The SM64 Engine(more specifically: N64 Engine) has a lot of nice features, but some of them are pretty glitched up and have to be bypassed through complex coding. We’ve decided to improve the SM64 Engine, like it’s physics engine etc. -> This will be done through the emulator, for the most. Next will be “Dynamic Lighting”. For example, you set an invisible object, with no purpose. The Emulator can get this object, and emulate dynamic lighting. Through Glide64 coding, we can actually make this true. This would mean, that we get a really fucking new SM64, however still with old classic mario, etc.

We’re going to add projectile physics, in this case emulated bullets. As you know, an object costs a lot of RDRAM in N64. When a server haves over 20 players, shooting all around, it still can be annoying. Yes, of course. The server can have over 100MB RDRAM, but still it could crash several ROMs, because the original N64 never had a lot of RDRAM like that. Through this we’ve decided to make emulated objects, which don’t really exists. But those emulated bullets can be seen by everyone who uses PJ64 2.1 ME. But because PJ64 2.1 ME MUST be used to play SM64O, everyone will see it. But it doesn’t really exists, the bullets. However, the actions are programmed and so the player dies if the bullet has hit him. The best on this thing is: We have a way better control of emulated bullets, than in-game (actually existing) bullets. For example, it’s really hard to set the right configuration when bullets are shot in-game. Speed, gravitation all that can be sometimes completly messed up. With emulated bullets, we can easily send the packets outside of the game and create actions from them into game.

Now to graphically stuff:
I said, that we’re going to add Dynamic Lighting.
Pretty nice, or? This should give SM64 a more better atmosphere and should allow others to make better hacks. I will release the modified PJ64 2.1 emulator soon, however without the features, which were only supposed to be for SM64O (like the gameshark patcher, login, etc.) and I will add the cheats tab, of course, which doesn’t exists in our version, to prevent hackers and cheaters.