---

 E7 00 00 00 00 00 00 00

 BA 00 14 02 00 10 00 00

 B9 00 03 1D C8 11 30 78

 F8 00 00 00 00 00 00 FF

 BC 00 00 08 0E 49 F2 B7

 B7 00 00 00 00 08 22 04

 B6 00 00 00 00 02 20 00

 FC from the obj file (cmb)

 BB 00 00 01 FF FF FF FF 

 F5 10 10 00 00 01 40 50 

 F2 00 00 00 00 00 C0 7C

 FD 10 00 00 09 00 58 00 

 E6 00 00 00 00 00 00 00

 F3 00 00 00 07 3F F1 00 

 E8 00 00 00 00 00 00 00 

---

Originally posted by VideoGuy

---

This isn't technically a help question, but I wasn't sure where else to post this.

http://kotaku.com/5412516/mario-64-used-to-have-multiplayer
Mario 64 had multiplayer?

Knowing how Nintendo is with beta stuff, could this code still be in the ROM? Obviously we're quite a long way away from decoding it, but wild speculation is always nice.

---

Originally posted by messiaen

---

The cheapo is that there aren't 64x64 textures, they have all been resized to 32x32.

The ROM won't open in Toad's Tool 64 since it uses a patch to enable extended memory. Also, for some reason even a modified ROM without the extended memory patch wouldn't work for some reason related to textures. TT64 just gave me a "#texture#" error I have never seen before. Maybe it's because the level uses a lot of textures?

---

Originally posted by Zeldaman

---

fixed my last problem but... how do you place things you can walk where you want em to be, like I saw a feew things on youtube where the island in the sky is on the ground and such like that

---

Originally posted by Treeki

---

How does Lingo work anyway? I always thought it was one of those trigger/event/action drag-and-drop type scripting languages (Which are very simplistic and need a special UI to edit code in) but I don't think something like TT64 would be doable at all in one of those.

I guess I'm probably totally wrong

---

---

on mariopal

  global source,filepath,mariocolz,colnum

  

  --Set currently edited color variable to 1

  colnum=1 

  

  --Reopen the ROM

  source=bagetfile (filepath,"rw")   

  

  --Load 144 bytes from bank 54 (Mario's bank)

  listo=loadlistdec (54,0,144)  

  

  --Create a blank bitmap instance

  canvas=image (16*6,16*6,32)  

  

  --Create an empty list variable (global) to hold current Mario palette.

  mariocolz=[]    

  

  --Reclose the ROM

  baclosefile (source)   

  

  --Initialize color position variable

  cpos=1      

 

  --Set variable tile to a black bitmap square 

  tile=member ("paltile").image     

  

  --Set the source rectangle

  srex=tile.rect    

  

  --Loop through 36 colors

  repeat with i=0 to 35   

    

    --Set the x and y positions for the palette bitmap

    x=(i mod 6)*16    

    y=(i / 6)*16

   

    --Create a color variable containing R, G and B   

    col=rgb (listo[cpos],listo[cpos+1],listo[cpos+2])    

    

    --Add the color to the palette list variable

    add mariocolz,col  

   

 	--Set the destination rectangle for the tile in the palette bitmap  

    drex= rect (x,y,x+16,y+16)  

    

    --Copy the tile in the palette bitmap, colorizing with variable "col"

    canvas.copyPixels(tile, drex, srex, [#ink:0,#color:col])    

    

     --Increment the color position

    cpos=cpos+4     

  end repeat

 

  --Set the content of image member to canvas. 

  member ("mariopal").image=canvas    



  --Call the custom "editcolor" handle to reset editing position in interface.

  editcolor colnum      

end

---

Originally posted by HyperHacker

---

I don't suppose that language of yours offers some way to deal with compressed files? De/compressing them within the program would help prevent n00bs distributing needlessly large files. (Maybe you can use MIO0? ) Base64 would also help.

---

Originally posted by messiaen

---

Noobs actually distribute the whole ROM . What could be done is an external utility (let VL-Tone focus on TT itself) that compresses the ROM after a hack its finished, so that the final ROM is smaller.

On the topic of compression, ZZT has managed some interesting regardings compression, which is to change the compression type used in the Zelda Debug ROM. Surely at this point it wouldn't be practical to do something similar in Mario 64, however if we ever rewrite parts of the engine to get something more like a filesystem, that would be interesting.

Once the new TT is released, I may post a bit more about some ideas I have to make it much easier to add imported models as 0x24 objects. The trick is to avoid using segmented pointers and instead acessing everything from RAM (Mario's uCode supports that, such as on the Mario's face at the title screen, which is a dynamic display list).

---

Originally posted by HyperHacker

---

I was once told that hacking Mario 64 would be impossible, because it's 3D.

---

Originally posted by Tanks

---

I'm telling you Tone... You put Sonic in there and I might just throw the biggest funtastic party of your life right here on the board.

---

Originally posted by messiaen

---

VL-Tone: a question about the bank selector. Is there any risk of having two objects with the same model ID when mixing banks from different levels? Or will this never happen due to the way layout + polygon banks are paired?

---

Originally posted by maczkopeti

---

I tried importing my new level, i opened in toad's tool and after loading the replaced level it gives an error:

Propety not found


#texture

Script Error, Continue?

I also tried it without using the mtl file, same result...

Can you help?

---