 Register - Login |
||
 |
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies |
|
Register - Login |
||
|
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies |
|
| Jul - Posts by messiaen |
| Pages: 1 2 3 4 5 6 7 8 9 10 ... 45 46 47 48 49 50 51 52 53 54 |
| messiaen Catgirl Level: 61     Posts: 1/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hello! Have you seen this video "Luigi is Almost Real 2007" by Starxxon (VL-Tone) at YouTube.com ? http://youtube.com/watch?v=fWKnQaTegNA Comments: Now that's a really stupid post! Shame on me, shame on me... |
| messiaen Catgirl Level: 61 Posts: 2/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| AI guide: http://acmlm.no-ip.org/archive3/thread.php?id=9010 |
| messiaen Catgirl Level: 61 Posts: 3/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| According to http://stifu.free.fr/, smkdan has joined the "Epic Racers" hack, so it seems that the AI is not really 100% figured out yet, judging from the last smkdan post. Maybe smkdan could shed some light on the current problems they are facing regarding the other set of data?! Anyway, I need to check Stifu's notes to see if there is more revelant information, maybe it has more explanations on that other set of data. |
| messiaen Catgirl Level: 61 Posts: 4/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hello, have you guys tried messing up with FlatWorld`s vertices/collision data? For instance, try changing the first 6 bytes of the level vertices at 0x1203000 (See the commented HexData in VL-Tone's first post). What I would like to do first is to set a smaller FlatWorld, because that would be easy using only the four level vertices currrently used. What 3D program could I use to generate these X,Y,Z coordinates ? Also, is it possible to add a few vertices in the level? Next step would be trying a two-island, or two platforms FlatWorld. --- Edit: I will find X Y Z coordenates by altering 0x24 object and manually checking X,Y,Z on Hex. However, whenever I change X,Y,Z coordenates TT64 just saves the object change, not their positions. Anyone else running on this problem? Edit2: Found a Bug on TT64 0.598b! If you change X Y Z using keys J,K,L TT64 won't trigger the Red Save button. Changing with the mouse works fine. Edit3: OK, I got my Little FlatWorld, with correct collision data. I know it is not very impressive, but maybe it will trigger some interest on geometry data. Screenshot (Corrected)  |
| messiaen Catgirl Level: 61 Posts: 5/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
Ops, I just checked and I mystyped some bytes in the collision data  , butanyway what matters is just the idea. I'll correct the screenshot later (Edit: Done!), maybe with a prettier terrain design (Edit: Not done!), and I'll try next to add two little platforms, but I'm not really sure how to add more geometry data. I'm also a bit lost on the SM64 Hacking documents, if someone could help me where to find the exact collision data ROM addresses for some of the levels. --- Edit: I'm not at home, but found this very interesting 0x17 command in HexData.txt 17 0C 00 07 01 20 30 00 01 20 31 08 <------ Loads Polygon & Collision data in Bank 0x07 --From MarioHacking1.5 doc- [17] [0C] 00 [0C] [00 13 B5 D0] [00 13 B9 10] [1]: 17= Copy uncompressed data from ROM to a RAM segment [2]: Length byte (dec 12) [4]: RAM segment to copy data to [5,6,7,8]: Start address in ROM of uncompressed data [9,10,11,12]: End address in ROM of uncompressed data --- So, probably changing this will give extra space for more vertexes and collision data. My noobish question is, what exactly is a lenght byte? Do I have to change this if I'm going to expand the End-Rom address to load to RAM (to include more geometry data) or is this just a fixed number telling my byte number must be multiple of 12? --- [Another Edit] Here is a easy way for finding geometry data: just copy the hex offset of the first warp object of a level, then search for it on the ROM. Go back a little and find the 0x17 command that points to some lenghty hex data. If you want the collision data, go the beggining of geometry and search for the 0040 command. P.S: Why does "Rom addess" at the bottom corner in TT64 shows in Decimal, not Hex? |
| messiaen Catgirl Level: 61 Posts: 6/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hello, Just to update this thread and keep all information here, here is VL-Tone's commented Hex Data for Flatworld Battlefield. FlatWorldBattleFieldHexData.txt Some improvements on the Flatworld Commented Hex Data: 00 00 00 02 <----- Loads 2 collision triangles to [00 00] [00 02] <----- Loads 2 "0000" terrain type (first 2 bytes) collision triangles Also, these are inverted: BB 00 00 00 FF FF FF FF B8 00 00 00 00 00 00 00 <------ End of polygon commands 0xB8 is the command to return from a 0x06 jump and 0xBB is actually the End of polygon command. Since the data is linear, this doesn't really matter here, but it is good to clarify this so that you don't get confused by this when looking at other geometry data. -- Collision Data/Terrain Info Super Mario 64 Level Format Diagram by VL-Tone (Possibly outdated, but still very useful) |
| messiaen Catgirl Level: 61 Posts: 7/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hi VL-Tone, Thanks for information. That is why my experiments were mostly crashing the game, I had just changed the 0x17 pointer. So, it seems I have to work around with these commands : 15 01 00 00 07 00 00 40 <------- Points to level polygons in Bank 0x07 03 86 00 10 07 00 00 D0 <------ Points to a color in current bank (0x07) at 0x00D0 2E 08 00 00 07 00 00 D8 <------ Points to collision data in bank 0x07 17 0C 00 07 01 20 30 00 01 20 31 08 <------ Loads Polygon & Collision data in Bank 0x07 00 40 00 04 <------ Loads 4 collision data vertices So, I added two level vertices and two collision vertices. After changin the four pointers, the level runs, but I didn't get exactly the shapes I was expecting. My six vertices rendered a triangle, while I was expecting some kind of hexagon. Also, the collision data didn't worked very good. That is probably because I don't have any 3D knowledge  . Anyway, it works!--- Edit: I was looking through Flatworld Hex data again, and I think it is probably someting related to the triangle data. As far as the collision, what I get about the command below (of course I could be wrong) is that it tells what to do with the vertices, otherwise just adding collision vertices won't do nothing. 00 00 00 02 <----- Loads 2 collision triangles 00 00 00 01 00 02 <----- Three 16-bit vertices numbers defining a triangle. 00 00 00 03 00 01 My question is, take for instance 00 00 00 01 00 02, the important data is just the 01 00 02 last three bytes, right? What does zero means, is it the first vertice of the collision data or just a blank value? Is this the command that sets the two big triangles you see at TT64 FlatWorld Wireframe collision data? That makes me wonder how interesting would be a "update collision data from ROM" or a "change collision triangles vertexes" feature, if that is how it does works. Also, Could someone help me understanding the command below (especfically the last 3 bytes) ? BF 00 00 00 00 00 0A 14 <------ Triangle command: last 3 bytes point to three vertices (base vertices address + vertex number * 10) BF 00 00 00 00 00 1E 0A Is this the command I would have to change to get what I want from my level vertices? |
| messiaen Catgirl Level: 61 Posts: 8/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
Thank you SO much, VL-Tone! This will come VERY in handy  . Now things are getting clearer!This is also good reading, essentially on the same subject: --- Edit: Hi, I just made a graphical representation of the geometry data of Flatworld Battlefield. Edit2: Er, I'm sorry but that was flawed. First of all, I should have used "Top View", not bottom view". So, the order from top view is counter-clockwise. I'll post it again when corrected. |
| messiaen Catgirl Level: 61 Posts: 9/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
Now I think I got it right! --- I'm trying now to do Flatworld Battlefield with four triangles, using a extra vertex. That is my triangle design:  And these are the most relevant commands (I also changed all the pointers) 04 40 00 00 07 00 00 00 <------ Loads 5 vertices at 0x0000 in current bank (0x07) [Edit: I tried to change byte four to [50], nothing happened. Do I need to change anything at the last three bytes or would that just be necessary if I had another group of 0xBF commands?] BF 00 00 00 00 00 28 14 <------ Triangle command BF 00 00 00 00 14 0A 28 BF 00 00 00 00 1E 0A 28 BF 00 00 00 00 00 28 1E [Edit: looking some geometry data in the ROM, it seems that BF commands are usually used just two or three times after the 0x04 command, and then followed by 0xB8. Have to look further on it]. The problem is that when playing the level, there are only 2 triangles, instead of four! Is there something I'm missing?  With this solved, I could just elevate the Y value of vertex 04 and get a nice mountain .Also, I have a question about this command: 00 00 00 02 <----- Loads 2 collision triangles Adding more triangles is just a matter of changing that last byte (2) to the number of triangles I want? Or is this a command I need to replicate? |
| messiaen Catgirl Level: 61 Posts: 10/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Thanks, now it works . Forgot to switch to counter-clockwise mode! By the way, as long as I go counter-clockwise, it doesn't matter which vertex I begin with, right? Now time to add more vertexes and triangles . |
| messiaen Catgirl Level: 61 Posts: 11/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Yes, I understood that. I thought that maybe the problem was that somehow the 0x04 command had to tell how many vertices would come next, but that doesn't seem the case (that is, unless you add another groups of 0x04 + 0xBF commands, then I think there is some pointing involved, which I'll try to study next with the help of the Hacking Docs). Anyway, it was just a plain stupid mental error, looking at those triangles many times and not figuring out some of them were clockwise. Regarding the collision command, the only way I got it to run was doing the 0x02 command two times, but probably there is another way of doing this I'm not aware of. 00 40 00 05 <------ Loads 5 collision data vertices [...] 00 00 00 02 <----- Loads 2 collision triangles [two triangles] 00 00 00 02 <----- "" [two triangles] --- Screenshot:  There is a problem with the texture, but that is because I was more interested in the 0xBF command X,Y,Z parameters and didn't care for the other bytes. Will try to solve it later. Edit: I replaced Twomp's Fortress with another copy of Battlefield too. I just copied it to 0x1300000 and changed a few pointers (thanks to the ROM banks, this is very easy). Edit2: Good reading for collision data info (and terrain types) |
| messiaen Catgirl Level: 61 Posts: 12/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hi Stevoisiak. I'm very inexperiencied in TT64 and whenever I got a good working geometry I'll sure release the IPS so power users can create their hacks. However, remember that TT64 won't update the modified geometry. This is my latest design, the colored areas have different (crescent) Y values, so it resembles more a mountain than my previous one.  Triangles (Collision / Level Polygon) [0A, 09, 08 / 64, 5A, 50 -> light blue triangles (center) 0A, 08, 0B / 64, 50, 6E] [04, 05, 09 / 28, 32, 5A -> blue triangles 09, 05, 08 / 5A, 32, 50 08, 05, 07 / 50, 32, 46 08, 07, 0B / 50, 46, 6E 06, 0B, 07 / 3C, 6E, 46 06, 0A, 0B / 3C, 64, 6E 06, 04, 0A / 3C, 28, 64 04, 09, 0A / 28, 5A, 64 [04, 03, 01 / 28, 1E, 0A - yellow triangles 04, 01, 05 / 28, 0A, 32 05, 01, 07 / 32, 0A, 46 07, 01, 02 / 46, 0A, 14 07, 02, 00 / 46, 14, 00 06, 07, 00 / 3C, 46, 00 06, 00, 04 / 3C, 00, 28 00, 03, 04 / 00, 1E, 28] I got it to work, but I have no clue how to get the textures right (see Project64 screnshot in the previous post to get what I mean). It is something related to the Bytes 9-12 in the vertex list, but these are over my knowledge and probably very difficult (maybe impossible) to calculate manually without some powerful 3D program. * Vertex list format Bytes 9-12: (S,T) Texture coordinates as two 16-bits 10.5 signed floats. You can change these to affect the scale of the texture. |
| messiaen Catgirl Level: 61 Posts: 13/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hi, the last "height terrain" map was a good exercise but I got a a new project going which Il think will be more useful for pratical ROM hacking. I'm a building a simple "platform" for the original FlatWorld level. In the "height terrain map", I used just one 0x04 command followed by a chunk of 0xBF triangles. For this one, I added a 0x04 especifically for the platform (especially the collision data, as it loads the vertices right away, without pointing at Banx 0x07). That made me wonder that the geometry format is somewhat modular, and that this platform can be easily copied. So, maybe a viable alternative in the near future for making levels from scratch could be a simple "custom platforms/geometry" library. Very limited, but better than nothing! Also, with these platforms, one could make for instance a simple slide level, which I'll surely try when I get this one 100% done. - Edit: OK! The Platform is complete, with collision data. Edit 2: Those were ugly, so I setted a different texture for the ground. Here is a screenshot of 6 platforms in a level:   --- To change the texture, I worked with these commands: FD10 0000 0900 5800 <------ Points to texture at offset 0x5800 in bank 0x09 E600 0000 0000 0000 F300 0000 073F F100 <------ Other Texture Params (Note: the 0x07 is not a bank number) I guess only the first one is really important, but since I was not so sure, I placed all these tree comands before the beggining of my second triangle group (the platform one). This is probably the command that loads the textures (is that right, VL-Tone) ? 1A 0C 00 09 00 CD 34 BD 00 CE 03 D1 <------ Texture bank (0x09) --- Sorry, but I couldn't help coming with this absolutely off-topic association today: if anyone wants to listen what is the equivalent in classical music to low-poly 3D geometry listen to http://www.youtube.com/watch?v=_fClFCEPThc . |
| messiaen Catgirl Level: 61 Posts: 14/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hi Vl-Tone! Geez, I didn't know updating geometry on TT64 was so easy!!! What a positive surprise!! Now can I see my changes on TT64 and "non-hex" users can benefit from this. Here is a screenshot of my test level in TT64, I won't paste directly here because I don't want to flood this thread with images (like I've been doing ).Screenshot For the next version, you could implement more geometry managing on TT64 interface, such as whenever opening new roms giving the option to use standard geometry or to decode and create a reference file for the particular project on the fly. [removed a few useless paragraphs] I want to next study more about the collision data, is there a simple command before the triangle group to set the terrain type or is this more complicated? I really want to try a slide level .--- Edit #983: I'm going nuts! I think I did everything right to make my custom 0x24 model. However, when I try to add my 0x24 object with my new geometry (I used model ID 17, replacinb bubbly tree) it won`t show up in the game. Also, when trying to load the ROM in TT64, I get the following error: Handler not found in object #getProp Script Error Here is all my HEX Data, with comments. The platform has no collision data, as I think that will be included in the new behaviour script. http://rapidshare.com/files/104148491/Plataforma.txt.txt.html --- [Behaviour question, but the question above is more urgent] Edit #523: OK, I'm trying to get my "modular platform". The behaviour bank is now at 0x11B0000, ready to be expanded and the pointers have been updated. Now I'm creating the new Platform behaviour. My question is, where does the 0x2A command kicks in ? Also, the collision data points to the 0x07 bank of the current level, in that case, 0x1200000 onwards ? To make thinkgs more organized, could I make a new 0x17 command in the level script so that it will load all my custom platform geometry/collision in a separate bank? I suppose the 0x2A command goes before the 0x2D one ? (At least this is how I found it in some behaviours, but in others this is inverted). ROM Addr: 011B56C0 Hex Behav: 130056C0 Description: Rotating Platform Behavior (#2, for FlatWorld) 11B56C0/0056C0 00 09 00 00 11B56C4/0056C4 11 01 00 01 Is this the place? [2A 00 00 00 07 xx xx x] 11B56C8/0056C8 2D 00 00 00 11B56CC/0056CC 08 00 00 00 11B56D0/0056D0 0C 00 00 00 80 2A A8 30 11B56D8/0056D8 0C 00 00 00 80 38 39 CC 11B56E0/0056E0 09 00 00 00 |
| messiaen Catgirl Level: 61 Posts: 15/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Sorry, I forgot to provide more details. First, the ROM I'm currently working with has unchanged behaviours, because I didn't want to change too much at once because of possible TT64 crashes. So, my platform still doesn't has its own behaviour code, all I want for now is TT64 to show my model on its interface, replacing the Bubbly tree model. I have a different ROM with behaviours moved to an extended section, however I don't want to test it on TT64 for now before I solve this problem with my model. So, I tried to include a 0x24 object in the game with my platform model and choose a random behaviour (tried a few of them), just to see if the polygons would appear in the game. The error I get on TT64 is occurs during the "Decode Level Scripts" process. I checked again my "jump command", the entry point and Geo Layout pointers, and nothing seems wrong with the pointers. Also, there is something strange in FlatWorld BattleField. Looking at its Hex data, it has three 0x21 commands and many 0x22. However, when you enable it in Toads Tool using a unaltered extended ROM, it seems that the 0x21 and 0x22 commands aren't updated, you still get what was in Bob-omb Battlefield. For instance, I see SEVEN 0x21 commands instead of the three actually found on the ROM. Is this some seriours bug or am I missing something? --- Edit: Ok, I tried something different this time. I changed a 0x21 command: 21 08 10 17 07 00 00 E0 <---- Assigns Model ID "17" to polygons at 0x0E in Bank 07 Now it works, and with a CWC rotaing behaviour, it even rotates . When I get near, the game crashes, but that is probably because I haven't changed that particular behaviour code to adjust to the platform collision.The 0x21 command points directly to the polygons, while the 0x22 command pointed to the Geo Layout, which in turn pointed to the polygons. So, the problem is probably with my Geo Layout. Sorry for the textures of my screenshot, that was a wrong color pointer which was already fixed. I also tried to replace my platform Geo Layout with "FF" bytes (as it is no longer used/pointed at) to see if TT64 could open the ROM, but it didn't work also  , I still get the same error. I even tried changing also the 0x10 command at 0x11FFF00 to see if there was something related. It rotates! To summarize, this is not level geometry but an actual 0x24 object with a custom model. With a lot of work, maybe in the future we could "rip", for instance, the big mushroom platforms at "Tall Tall Mountain" and use them as 0x24 objects within our custom levels. -- Another update: I redid the 0x21 model using a unmodified FlatWorld ROM. This time I left Bank 0x0E untouched (except for a few geometry pointers), as I didn't need a Geo Layout. Bank 0x07 is the same I was using before. The ROM now loads in TT64, but even after deleting the M64GeometryDataFlat.m64, my model doesn't shows up in TT64 interface. Instead, I get just a blank model. In the game, however, it does appears. This time, the Bubbly tree behaviour didn't crashed the platform. Interesting is the fact that you could climb an "invisible tree", so even without a 0x2A command there is some hard-coded collision. [See behaviour thread for more info] Yet another update: OK, I tried repointing the 0x2A behaviour collision data. With the CCW rotation and tilting platform, unfortunately it crashes the game! |
| messiaen Catgirl Level: 61 Posts: 16/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hi, I think I've discovered the function of another behaviour command. Quoting VL-Tone from Editing the RAM objects thread: "While some object indeed have polygonal collision maps (levels, platforms, boxes etc.), many enemies and Mario himself don't use polygons for collision detection. Because of the complexity of the body, and the fact that it's animated, a spherical collision bubble is instead used. There's no polygon involved, it's only a matter of detecting a collision if the distance between objects is less than X. This is how most 3d games worked until more recently when more powerful and precise physics engines were implemented in games" That is what the 0x23 command seems to do (sets a collision sphere). The format is [23] [00 00 00] [??] [?? ?? ??] [0] = 23 is the command byte. [1,2,3] = Always zero, unused? [4] = 00 or 01 (?) [5,6,7]= Some kind of coordinates? On a somewhat related note, both the Tree and Pole Grabbing behaviour share the same 0x0C, which is what happens when you step on the area defined by the 0x23 command: ROM Addr: 00219F44 Hex Behav: 13000144 Description: Pole Grabbing 219F68/000168 0C 00 00 00 80 2C 63 E8 ROM Addr: 0021C8A4 Hex Behav: 13002AA4 Description: Tree Behavior 21C8C4/002AC4 0C 00 00 00 80 2C 63 E8 This could shed some light about: ROM Addr: 0021E3F8 Hex Behav: 130045F8 >>>>>>>>>>Unused Behavior? Which also has the same "0C 00 00 00 80 2C 63 E8". This behaviour also has a 0x27 animation command. So, what else in the game has animation and at the same time can be "grabbed"? --- Edit: Hi, another small discovery! In many behaviours which contain the 0x23 command, there is of course some action associated. I thought that action was determined only by the 0xC command, like the supposed "pole grabbing/tree grabbing" shared 0x0C command. However, 0x10 also plays a big role! I first thought 10 2A 00 [XX] would determine what Mario state (while in the collision sphere area determined by 0x23) would trigger the related 0x0C action. For instance, in the Tree behaviour (see below), we have 10 2A 00 40 [Hmm, 2A, doesn't that sound somewhat familiar?], and the 40 byte means jumping state. If you change it to 02, action will only occur when you "PUNCH" the collision sphere. And if you change the last byte to "04", action will occur when you WALK on the collision sphere. The amazing thing is that when you change 10 2A 00 40 to 10 2A 00 04 in the Tree behaviour, Mario won't climb the tree when you walk into it, but instead it will open it like a door and go to the other side. If you change the last byte to 02, you will be able to GRAB the tree with you! I thought a specific 0x0C call was needed to change the action! ROM Addr: 0021C8A4 Hex Behav: 13002AA4 Description: Tree Behavior 21C8A4/002AA4 00 0A 00 00 21C8A8/002AA8 21 00 00 00 21C8AC/002AAC 11 01 00 01 21C8B0/002AB0 10 2A 00 40 21C8B4/002AB4 23 00 00 00 00 50 01 F4 21C8BC/002ABC 10 05 00 00 21C8C0/002AC0 08 00 00 00 21C8C4/002AC4 0C 00 00 00 80 2C 63 E8 21C8CC/002ACC 09 00 00 00 Also, if you change the 10 2A 00 02 command in the King Bob-omb behaviour to 10 2A 00 40, you won't be able to punch him from the back and grab him. However, if you JUMP on him from the back, you will CLIMB him, like the pole grabbing behaviour! So, the 0x10 is worth studying, for now one could mess just with the "10 2A" command, in objects which have collision spheres. I hope that was useful! |
| messiaen Catgirl Level: 61 Posts: 17/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Well, don't worry about it, there are still lots of things I can experiment with and learn from the documentation. However, could you or someone else confirm the possible FlatWorld 0x21 and 0x22 command listing bug I ran into? [I describe it in the first half of my last post] -- Edit: Hey, look at this, I was just 2 bytes far from getting TT64 to show my model! I went back to my old ROM which had custom Geo Layout for the Platform [the one I uploaded the Hex Data], and my silly error was that I forgot to change the first 0x80 command, which OF COURSE must point to the same entry point as the 0x10 jump command. 80 08 00 00 0E 00 01 70 <------- Special command only used by TT64 to skip to Object Layout (Important) My commands gets listed as 0x22 Number 075 , "Unknown". However, I still think there is something wrong with the listing, as there aren't 75 0x22 commands in the FlatWorld level.  Ops, I have to set my platform vertexes Y values to 0, otherwise I'll get 0x24 Y + vertex Y = double trouble in setting object positions . This now uses a 0x22 Geo Layout pointer.HOWEVER, now that my 0x22 model shows in TT64, it won't show up in the game!!! --- Looking at "Tall Tall Mountain", I realised that many static platforms are in fact 0x43 objects, so maybe this command would be more appropiate for my current purposes. However, this is still undocumented in Mario Hacking Doc 1.5. For now, I'll see what behaviours these 0x43 platforms use and see if they fit on my 0x21 working platform (0x22 doesn't show up yet in the game). Ops, too bad, they use Static & Not solid behaviour, which looks almost like a "null" script but however it does accomplish something in my platform: it crashes the game whenever you walk near it, as most behaviours. |
| messiaen Catgirl Level: 61 Posts: 18/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hi +c0, it's very nice that you found some interesting use for the 0x10 2A behavior command! Unfortunately I didn't have time this weekend to mess with it. You could change the background of Bob-Omb Battlefield to make it a "night" level (has anyone tried this yet?) and then invert the colors of that model (black->white) you used to replace the owl. You would get "Mario rides the moon" .I really liked the way you mixed the two behaviours (Owl + Pole grabbing), perhaps if we categorized some of the 0x0C command addresses we could make interesting things, like a Toad that gives Mario one extra life, or some other mixed behaviors. --- I did something cool with the Mario behavior which will probably be useful for a ROM hack (I'm all for creating a new level with custom geometry/models and hacked behaviors. Maybe a team effort?). Back to Mario, with this code you can change Mario's speed in a certain area of a level, for instance. If you place a 0x24 object and set it to Mario Behavior (2EC0, not acessible in TT64?) in a level, you will get double speed mario. If you put another one, you will get 3x or 4x speed mario! That's interesting, however you can do the same by hacking Mario's behavior: ROM Addr: 0021CCC0 Hex Behav: 13002EC0 Description: Double Speed Mario behavior! 21CCC0/002EC0 00 00 00 00 21CCC4/002EC4 10 05 00 00 21CCC8/002EC8 11 01 01 00 21CCCC/002ECC 11 03 00 01 21CCD0/002ED0 23 00 00 00 00 25 00 A0 21CCD8/002ED8 08 00 00 00 21CCDC/002EDC 0C 00 00 00 80 2C B1 C0 21CCE4/002EE4 0C 00 00 00 80 29 CA 58 21CCEC/002EEC 0C 00 00 00 80 2C B2 64 and now just copy these 0x0C commands again 0C 00 00 00 80 2C B1 C0 0C 00 00 00 80 29 CA 58 0C 00 00 00 80 2C B2 64 09 00 00 00 --> end of behavior Getting this code inside a certain level or area is just a matter of changing Mario's 0x25 pointer: (25 0C 00 01 00 00 00 01 13 00 2E C0 <------ Mario's Pointer from FlatWorld) -- How about a Flying Tree Behavior? How to do it? Well, just copy the two 0x0C butterfly commands and add them to the tree behavior. Simple as that! Other nearby trees will be affected, but that will be solved by extending the behavior bank and creating a new script. Imagine a forest with many trees, but when you find the right one, you will take a tour to the magical island!!  Mario takes a ride! What about some EVIL butterfiles that damage you? That will probably be possible just by combining 0x0C commands! |
| messiaen Catgirl Level: 61 Posts: 19/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Thanks VL-Tone, indeed it was the Geo Layout which was preventing the game from showing the platform. The good news is that now with a working geo layout, the 0x2A (behavior script) collision command works, so I have moveable collision!  0x24 Platforms with custom mode and moveable collision (custom behavior). --- What do you mean by drawing distance? Is this the distance from which the object is visible (this is what I think CellarDweller meant by "Disappear distance" on behavior thread) or is this some kind of distance between where you place your 0x24 object and where it is really drawn? If you mean the former, I'm experimenting on this, but so far I haven't reached a conclusion. Changing the values indeed effects minor changes in disappear/visible distance, but they are very difficult to notice. I'll take a look at other geo layouts, especially in platforms which have to be visible from very far to see what values they use for this. It seems, however, that behavior scripts also do affect this, but there still lots of testing to do to confirm this. When I was still using the 0x21 pointer and rotating between a few behaviors to see if my 0x2A command worked (it doesn't in a 0x21) I remember noticing striking differences in the drawing distance. -- Update: I got the 0x1D scale command to work! It only works when precedeed by a 0x14 command. However, I have no clue how to determine what is the "normal" size value. Unlike Mario, "40 00" in the last bytes will give me a shrinked version. Also, the collision data vertexes needs to be manually scaled, unless there is a behavior script command which also scales the collision. Eventually, TT64 could adjust the 0x1D command on its interface and adjust collision data for it (scale the polygons), but sure there is a long way to go before this. Here is my sample Geo Layout with 0x1D scale command: 20 00 01 F4 04 00 00 00 14 00 00 00 00 00 00 00 04 00 00 00 1D 00 00 00 00 00 40 00 04 00 00 00 15 01 00 00 07 00 00 E0 05 00 00 00 05 00 00 00 01 00 00 00 --- One bug concerning the red box when selecting custom 0x22 models: This is what get when you first decode the geometry:  This is what you get when you close TT64 and open the same ROM again:  Wireframe mode shows correct polygons/collision in both instances. |
| messiaen Catgirl Level: 61 Posts: 20/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Just one simple suggestion: I *really* miss a "Save As" function! It would make backups and testing easier. |
| Pages: 1 2 3 4 5 6 7 8 9 10 ... 45 46 47 48 49 50 51 52 53 54 |
| Jul - Posts by messiaen |
 |
Acmlmboard - 07/23/2013 b378.03 ©2000-2013 Acmlm, Xkeeper, Inuyasha, et al. |
| Query execution time: | 0.049435 seconds |
| Script execution time: | 0.088137 seconds |
| Total render time: | 0.137572 seconds |
