Register - Login
Views: 99771151
 Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies 		05-02-22 10:19:42 PM
Jul - Posts by dsx9069
Pages: 1 2
dsx9069
Member
Level: 14


Posts: 1/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-14-11 06:40:41 PM, in Mario 64 Level Importer (last edited by dsx9069 at 06-15-11 10:21 AM) Link
Originally posted by messiaen
Luckily Cellar Dweller notes cover some of the solidity functions, so I had some starting point. Well, turns out that the game has a limit of 2300 collision triangles in each level. That means that whenever you import a model with more than 2300 faces (and the current version of the importer allows up to 6500 faces!), you'll run into invisible walls each time you step on a collision triangle which exceeded that limit.

But the news is that I got rid of this limitation and my model with more than 5000 faces imported correctly! I will soon release an update to the importer, since this is a dramatic improvement.


Hi, I'm new to the forums and sm64 hacking. Thank you so much for your importer dude! Now for my question, do you have any tips on making level models less "fancy" while sacrificing as little architecture as possible (i.e. using hexagons over octagons to save on triangle count)? And is there any way to know how many triangles are in a model that's loaded onto the importer?

I know that you got rid of the polygon limitation, but just in case there is STILL a limitation with the new importer, it'd be nice to know exactly how to go around this problem.

Also, what scaling would you recommend for importing levels? I guess I'm asking about the pixels to inches ratio between sm64 and Google Sketchup; like for every inch that I measure in Google Sketchup, how many pixels would that translate to in sm64 (because of the +/-8,192 pixels that I'm limited to on the X/Z axes, plus having the right scaling to facilitate the pixels to inches ratio)?

Thanks in advance for your answers, and I open these questions up to the whole community!

EDIT: Experimented with the models and figured out that its safest to use polygons with a limited amount of sides (i.e. NOT a circle). Also found out about the MIDI to m64 converter (GREAT tutorial!).

I'd still like to know about that recommended scaling. It will help me to push the limits of the model's coordinates to the max
dsx9069
Member
Level: 14


Posts: 2/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-15-11 05:08:37 PM, in Help/Questions about Toad's Tool 64 and SM64 hacking (last edited by dsx9069 at 06-15-11 02:09 PM) Link
Originally posted by dVanDaHorns

Thanks man! I found the problem...apparently angled shapes that are textured on the inside tend to glitch (I discovered another similar spot, the rom is working perfectly now. ) Thanks a lot!


Yeah, I noticed that too. For example, I import a completely flat model into sm64, and there are no invisible walls. But for some reason, when polygons are added vertically to the flat model, the coordinates of the center of the model are shifted. The invisible walls are a result of the model extending past the +/-8192 pixel limit on the X and Z axes. And here I thought that my simple house on a lawn model exceeded the 6500 polygon limit'

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 3/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-16-11 02:38:39 PM, in Mario 64 Level Importer (last edited by dsx9069 at 06-16-11 11:40 AM) Link
Originally posted by DarkSpacer
First, there is still a limit, the limit's just increased (current is 6500 polygons).

I'd recommend sacrificing as much detail as possible to make really smooth-playing levels like the original, but still try to make the objects at least remotely look like what they're supposed to look like.

The scaling depends on your 3D program you use to create the levels. Once you figure out the values, you should use the same settings each time you want to make a level.


...what you talking about pixels to inches anyway? Are you talking about textels (how many pixels make up a texture)? Those are two different things...

Oh wait, 8,192 limit--dude, those aren't pixels. IDK what they are but the size of your level depends on that...Sketchup has multiple settings for size values, but there's always a little person in the middle of your scene when you start it up...I haven't tested if he's the same size as Mario, but if you build your level with him there, then delete him when you get a feel for the size, you don't have to really worry about the size value.

Besides, the importer will warn you if your level extends outside the 8,192 limit.


Yeah, I meant the 8,192 textels for each quadrant. But I found a good estimate of my X and Z bounds using a scaling of 500. Using this scale with Google Sketchup, Mario is about 16 in tall and 8 in wide.

On a side note, I noticed a couple things about the dreaded "invisible walls":

- Invisible walls occur wherever your level exceeds any coordinate bounds. Sometimes a level is within bounds when imported, but as MetalMan pointed out, rearward textures can affect the level once its imported. More specifically, I noticed that rearward textures offset/mirror the level's X, Y, and Z coordinates.
- Invisible walls will occur on textured surfaces where the rearward faces have lines. If you have a flat plane textured with grass (just as an example), and you draw a horizontal line underneath that plane (lets say cutting it in half), then you will find the invisible wall halfway through that level (directly above the drawn line).

One could use invisible walls on purpose to create invisible barriers and stuff, especially since it seems easy to produce them (drawing lines underneath planes). TT64 was really helpful in solving the invisible walls problem, as well as picking the right coordinates to hardcode Mario's starting position in any given level.


Is there any way to predict how much rearward textures will offset an imported level? Also, when there are rearward textures/invisible walls, some textures don't behave properly. Is there any way to fix this? I can get around the level offset problem by using TT64 and finding the right coordinates to hardcode the level offset in the importer. Although I know that Messian isn't going to work on room support (like in "inside the Castle" and "Haunted House"), knowing the solution to this one problem will definitely make it possible to add rooms to my levels (I know about the creative method to make "rooms", but I'd love to create interconnected rooms without the need for warps).

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 4/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-17-11 01:00:49 PM, in Which 3D editor are you using? Link
Google Sketchup Pro 8 (5-finger discount;D)

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 5/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-19-11 11:40:25 PM, in Mario 64 Level Importer (last edited by dsx9069 at 06-19-11 08:57 PM) Link
I recently created an intense level for Mario 64. Don't want to spoil too much about it, but it involves a very large tower and rooms inside. A quick run of the world and its stars would take AT LEAST 2 hours, if not more time.

Anyway, my back-breaking work seems to be compromised because I'm noticing a strange bug in the level after it's imported. In the first floor of the tower level, when I jump out of the water onto land, the game freezes. I checked the collisions for the land, and both normal and icy collisions produce the same bug. My level is currently at 4,527 polygons, and I only have one more floor to create. This level is replacing Whomp's Fortress. All the textures involved in the level (with the exception of one, which is on the fourth floor) are sized at 32 x 32.

When I import the level, the importer say's its successful, and nothing else. Is it possible that the game runs out of memory if the level has too many polygons or textures? I'm going to try replacing other levels and see if the bug occurs there too. I anticipate that this level will most likely take up about 6300~6400 polygons.

If I'm omitting information or doing something wrong, please let me know. I can't start working on new worlds with this one unfinished. I'll edit this post with screenshots in a sec. Thanks!


This is the first floor (the latter half).




And this is the where the bug occurred. Mario is jumping out of the water onto land, and the game freezes as he touches the ground.



____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 6/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-21-11 02:26:09 AM, in Mario 64 Level Importer Link
Originally posted by DarkSpacer
...It almost seems to me like your water boxes are defined incorrectly...but that would be a bug in the importer...

Got it. Did you repoint the camera tables? Because there is a normal "on land" camera and a swimming "in water" camera. If the land camera is in an incorrect area of the ROM, the water camera will point to something random and it will freeze the game.

...I wonder if the importer moves data like that...

Your textures are fine, and your number of polygons are fine...

And I've never heard of collision freezing the game, otherwise the majority of people would be going TEH IMPORTER BROKES THE HJACK HELP


...I wonder, just in case it's relevant, what's the non-32x32 texture like?


OMFG. I love you dude. Switching the camera preset to TTM worked (Tall Tall Mountain utilizes both land and water cameras)! Now I can finish modeling the last floor and edit the level in TT64 (which will take forever, because I have a very LIMITED view of the level in TT64).

Oh yeah, the non 32x32 texture is just some grass (for maze walls on one of the floors). I changed it to 32x32 though.

Tested my level collisions and everything works like a charm. The only inconvenience about the level is having to change the camera angle (pressing R) to see correctly throughout the level.

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 7/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-21-11 10:05:05 AM, in Mario 64 Level Importer (last edited by dsx9069 at 06-21-11 07:06 AM) Link
Grrr...Now I'm getting "your obj file doesn't contain texture coordinates..." On the same error, I'm also getting "some textures from your material file could not be loaded."

I'm using a scale of 500, all my textures are 32x32, and the obj material file and textures are in the same folder with the obj itself. I have no clue what's causing this, other than maybe too much textures (There are even 8 versions of one particular texture).

My level is complete at about 6,200 faces.

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 8/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-21-11 06:08:46 PM, in Mario 64 Level Importer (last edited by dsx9069 at 06-21-11 03:24 PM) Link
Originally posted by DarkSpacer
"Level does not contain texture coordinates"..."some textures from your material file could not be loaded"...

Umm...

Wait, you're using a scale of 300...do you have any huge polygons? Because if you do, the texture coordinates for those might be too big for the importer to process...

but why say they can't be LOADED...

...what program did you use to export the textures? And what format are they?

Oh, and what METHOD did you use to apply the textures in whatever 3D program?

EDIT: Found a helpful bit posted by VL-Tone in another thread:

Originally posted by VL-Tone

it gets complicated to manage custom textures when reimporting a modified .obj file.


Not sure what that exactly means, but I think your ROM is running out of memory each time you import your level. I would restart with a clean ROM (extended is fine), and import your level and see if it breaks then.


Polygon size has never been an issue with me. I've had flat squares encompassing +/- 8192 textels that import properly (after triangulation of course).

However, you're suggesting that my problem lies in all the custom textures that I'm forcing the game to handle. This seems to be VERY true. I'm using Google Sketchup, and every time I switch textures, the program adds separate "instances" of each texture as a separate texture in the object's material file. For example, I color the grass with "grass.png". Then I color the wall with "wall.png". But then I realize that I missed a patch of grass and I color that patch with "grass.png". However, because I switched back to the same texture after using another one, the object material file will contain both "grass.png" and "grass1.png". Is there any way to avoid duplicate textures in Google Sketchup?

In order to eliminate excessive textures, I'll use the game's native textures. In GSU, I'll aslo try to color all instances of any texture before going to the next texture. Starting with a fresh ROM is not an option for me, because I used TT64 to edit a couple other levels (to redo all the object placements would be time-consuming and absurd).

All my textures in Google Sketchup cap at 64". This equates to about 814 textels in the game. This is why my texture coordinates haven't been a problem thus far (until my most recent import of the tower level). I might've used 128" for one of the textures though, so I'll check up on that.

My last resort would be to *gulp* start over with a fresh. Let's see if it gets to that:/

EDIT: I'm using a mix of png and jpeg files. Dunno if that also contributes to the texture errors.

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 9/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-22-11 10:04:31 AM, in Mario 64 Level Importer (last edited by dsx9069 at 06-22-11 07:18 AM) Link
Ok, so I minimized my textures in the tower level and imported the level on a fresh ROM. It actually worked! However, when I run the game in Project 64 and go to the designated level (after choosing the Act), the game freezes with a white screen. What could be causing that?

EDIT: The level also imports correctly in the old ROM too However, same freezing problem. I enabled a water box at the bottom of the tower, and the tower spans about 14,348 textels on the vertical axis and 13,025 textels on the horizontal axis (signed textels).

If textures were the problem, the level would've loaded with the messed up textures showing. Something's up with the actual structure of the level or something. Perhaps I placed my water box too low? Or maybe Whomp's Fortress does not have enough memory to handle my tower level?

I would post the screenshot of the freeze, but it's just a white screen. Just stare at a blank computer paper and you'll have a good idea of what I'm experiencing.

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 10/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-22-11 06:37:43 PM, in Mario 64 Level Importer Link
Originally posted by Apache Thunder
Did you try changing the camera preset? I recall seeing someone fix a freezing issue after changing that. (it had to do with the water boxes and the way the camera behaved) Try using a camera preset other then the default one.


Lol, I actually had that problem before (Mario jumping out of the water onto land and the game freezing), but I fixed it by setting the camera preset to 01. My issue now is that the game freezes right after I choose the star (act) of the level to play in.

The level was fine with the new camera preset until I added more polygons to the level and changed around some textures. I guess the best I can do is play around with other cam presets (as well as other obj importer settings). I know the problem lies in my obj importer settings, because my level is at 6200 polygons and has 10 textures. Also, like I mentioned before, I'm sure that the level would still be playable if something was up with my polygon count or textures (because the level was imported correctly).



____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 11/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-22-11 07:40:54 PM, in Mario 64 Level Importer (last edited by dsx9069 at 06-22-11 08:13 PM) Link
Originally posted by DarkSpacer
The only thing I can suggest is to reduce your polygon count. Your level is killing your ROM. I'm sure of it.

EDIT

JUST IN CASE it's not that, try your texture trick you tried erlier, but start with a stripped-down version of your level. Then build up from there, MAKING SURE TO REDO THE TEXTURES IN THE SAME WAY (this means stripping the level of textures each time, then reapplying them one at a time).

As you can probably guess, I'm a bit angry about these kinds of weirdo problems...


Actually, I found out how to get rid of duplicate textures in GSU. I just have to select textures from the "In Model" folder when I want to reuse them on different surfaces

I will strip down the level a little bit to see if there is a difference. I currently have a 1000-polygon pathway around the outside of tower leading to the top, so that'll go first.

EDIT: My level loaded after removing these 1000 polygons, but I have invisible walls and invisible holes. Too bad, because the level design was pretty much flawless. I guess the importer can't handle a lot of polygons properly.

EDIT2:It seems that the invisible walls/holes disappear with less polygons textured. I'm not liking this at all.

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 12/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-23-11 09:00:46 PM, in Mario 64 Level Importer Link
Originally posted by DarkSpacer
dsx9069: I have absolutely no ideas of my own, but here's something that you wrote yourself that's related...

Originally posted by "dsx9069"
- Invisible walls will occur on textured surfaces where the rearward faces have lines. If you have a flat plane textured with grass (just as an example), and you draw a horizontal line underneath that plane (lets say cutting it in half), then you will find the invisible wall halfway through that level (directly above the drawn line).


Hope that helps...


Right, that is true. I've already stripped the outer face of the tower and checked for stray lines. But when I reduce the number of polygons that are textured, the level begins to behave more properly. I think what is happening is that there is some kind of limit on the number of textured polygons that the game can handle.

I'm experiencing slanted invisible walls, so I know that my X, Y, and Z coordinates are fine...

...Wait a minute...has anyone had problems importing a level that utilized negative Y coordinates? There are slanted, invisible walls at Y values in the -6000's. I'm going to check the upper part of the tower to see if this is true. If so, simply offsetting my model should fix the problem.

If not, fml. I'm working on a hub level (but I'll be using a regular level like Peach's slide or one of the cap stages, to avoid complications). Hopefully this one avoids the catastrophes of the tower level.

I know that I complain like a b**** on this forum, but a lot of it is the frustration of seeing hours of work NOT come to fruition. Still, Messiaen has done some GREAT work on the Mario 64 level importer and I hope that he continues.

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 13/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-23-11 09:26:15 PM, in Mario 64 Level Importer (last edited by dsx9069 at 06-23-11 06:27 PM) Link
Originally posted by Gazpacho146
Originally posted by Joe

How many polygons are in your level?

how can i tell how many polygons i have? i'm using a plugin to export my obj files


Are you using Google Sketchup? After you triangulate your model, go to Window-->Model Info. The number of faces is your polygon count.

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 14/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-24-11 03:00:38 AM, in Mario 64 Level Importer (last edited by dsx9069 at 06-24-11 12:02 AM) Link
Originally posted by DarkSpacer
dsx9069, I think you have defeated the forum in one swoop. I've never heard of this and haven't read it anywhere...

BUT that dosen't mean I can't think of an answer...

*overlong thinking cutscene*

(I want to make sure I'm doing this right, so don't laugh as you read the following

***

--Computing level space requirements...~0.5 MB
--Computing texture memory...~400 KB
--Comparing memories...~0.6 MB--max level space: 1 MB
--Inputting level poly count...~6200 polygons
--Extracting size...~0.8 MB
--Refining counts...Done
--Result: Poly memory overwriting texture memory: Level size too big. Consider reducing textures or reducing poly count.
--Checking result...Done
--Considering extra counts...Done
--WARNING: Level is unstable. Advise against adding more than 50 objects.
--Considering level-specific scripts...Done
--Done

--Level stability: Low
--Texture memory has been overwritten by 300 KB
--Compression techniques were applied to this level. May affect level scripts (2 scripts computed)
--This level has a Water Box. Camera presets must match.
--Required non-level-specific scripts will overwrite 30 KB of Geo memory if allowed.
--The collision in this level has been compromised. May affect playability.
--Done

--Read this checklist and procedure dump carefully. This sub-procedure of computational dump will now terminate.

***

...according to this, your polygon count is too high...I didn't consider scripts overwriting things because it's too unlikely...



It seems like I could reduce the amount of textures that occur on each polygon to save on texture space. Like if I have 100kb of texture memory, my level will look less sparkly, but it'll be there in its entirety. This dump log is A LOT of help! Now I see why v15 of the importer "supports" 6500 polygons in theory, but not necessarily in practice.

I will remove the first floor of the tower and increase the size of each texture (to reduce its occurrence). Hopefully this solves my awesome-level-gone-bad problem. Then off to TT64 (which barely displays my level--EPIC!!)

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 15/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-26-11 12:17:58 AM, in Mario 64 Level Importer (last edited by dsx9069 at 06-25-11 09:30 PM) Link
I reduced my tower level to 3,800~ polygons. It imported correctly and all collisions work perfectly. I then began to add objects to the level with TT64. However, after I added about 40 objects and tested the level, it acted kinda buggy. When I select the 3rd act and Mario enters the world, the top icons look glitchy. I modified the level a bit, and now that only happens on the 3rd acts and above when I enter the 3rd floor of the tower. It feels like there is still not enough memory to contain all the textures and object scripts.

I replaced Shifting Sand Land with the tower level (so that I could have the *SPOILERS* Eyerock boss *SPOILERS*). My 3 objects banks are "Desert Objects", "Ground Enemies", and "Tick Tock Clock". I only have about 40 objects added into my level so far.

Screenshots of the glitches:








The game froze when I interacted with one of the chuckyas. Safe to say that object data and other data are being overwritten to.

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 16/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-28-11 09:09:45 AM, in Mario 64 Level Importer Link
I made a new level replacing Whomp' Fortress, and I'm using Bowser's Third Course as one of the object banks. But when I assign one of the objects as Checkerboard Elevator 2 (I loaded the trajectory into the right B. Param) and try to access it in game, the game freezes as Mario approaches the elevator platform. What's up with this?

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 17/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 06-28-11 11:58:13 PM, in Mario 64 Level Importer (last edited by dsx9069 at 06-29-11 01:44 AM) Link
Originally posted by DarkSpacer
dsx, your level looks like it belongs on the Sega Saturn :p

Do any of your objects have undefined models or behaviors? And remember to have your normals facing the right way...

BTW I know why your textures look that way...I don't know how to fix it, though...


My problem with the platform is probably the undefined thing...There isn't a checkboard platform on tracks in Bowser's Third Course, from what I remember (like 4 or 5 years ago). I switched the last object bank to Hazy Mazy Cave (which fixed this problem) and added the other platforms by editing my model. I'm almost done with editing this new level and I'll post on it on Youtube.

Yeah, I can fix choppy textures by manually triangulating certain stuff. I'm just too lazy to go through my model and do it manually though, so I just let the triangulation plugin go nuts.

EDIT(on the texture thing):I should probably use textures that are symmetrical, especially for surfaces like rock and lava. It's not much work to do this though, simply cut out a part of the texture and flip it around, pasting together all the transformations into one new texture. I'll definitely do this for the new level.

SERIOUSLY though, when I load a new trajectory (.txt) into the Mario 64 Importer, Windows 7 gives me an error that there was an invalid input string or something like that. Here's the screenshot:



My level will shortly be complete after solving this issue.

EDIT2:This problem was fixed (as well as the #texture issue in TT64). Simply rebooting my laptop did the trick. Who would've guessed, eh?

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 18/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 07-01-11 04:08:56 PM, in Mario 64 Level Importer (last edited by dsx9069 at 07-01-11 05:48 PM) Link
Originally posted by DarkSpacer
dsx, your level looks like it belongs on the Sega Saturn :p

Do any of your objects have undefined models or behaviors? And remember to have your normals facing the right way...

BTW I know why your textures look that way...I don't know how to fix it, though...


Just out of curiosity, what do you mean by "normals facing the right way"? It seems that I'm experiencing the freezing again as I approach the checkerboard elevator. I'm using the object combo "Checkerboard Elevator 2", which uses the "Checkerboard Elevator Platform" model and the "Platform on Tracks" behavior. This combo is defined because I'm using Hazy Mazy Cave object bank on Whomp's Fortress...so the problem must either be the "normals" thing that you mentioned or maybe the camera preset (what camera preset, if any, is the correct one to use with the checkerboard elevator 2 combo?)

On another note, does anyone have a list of Warp ID's (ALL or MOST of them in the game, not just the first 36 that TT64 comes with)? ZeroOne, it seems that you've documented some of the success/death warps. Any help with warps beyond the regular level warps would be GREATLY appreciated

EDIT: Don't worry about documenting the rest on my behalf, Zero One. I just realized how warps work, and it's easy to spot/change all warps in the game. I can even warp from Castle Grounds to any of the regular levels without spawning the act selector screen. Life right now seems so much easier.

The default success/death warps for all the main levels are:
Area 1
Bom-omb Battlefield - 50/100
CCM - 51/101
WF - 52/102
JRB - 53/103

Area 3
LLL - 50/100
SSL - 51/101
HMC - 52/102
DDD - 53/103

Area 2
WDW - 50/100
THI - 51/101
TTM - 52/102
TTC - 53/103
SML - 54/104
THI - 55/105
RR - 58/108

Castle Courtyard
Boo's Mansion - 10/11

These values are pretty much arbitrary, as a lot of you probably know. For anyone making a hub level, just use one of the secret stars levels for now (until later updates to Messiaen's Mario 64 Level Importer). Each of these levels comes with 14 warps...2 or 3 stars is a good sacrifice for a functional hub level, IMO.





____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 19/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 07-01-11 11:44:28 PM, in Mario 64 Level Importer (last edited by dsx9069 at 07-01-11 10:12 PM) Link
Well, here is one of my successful levels (after failing with the tower level and my original hub lol). As you may notice in the beginning, a "3" displays when I collect my first red coin. How do I change this?

<object width="480" height="390"><embed src="http://www.youtube.com/v/lxj-yXDrSaw?version=3&hl=en_US&hd=1" type="application/x-shockwave-flash" width="480" height="390" allowscriptaccess="always" allowfullscreen="true"></embed></object>

EDIT:
Originally posted by DarkSpacer
Normals are the direction your level polygons are facing.

I don't want to eat up forum space, so if someone wants to shorten the following explanation that would be great.

Polygons have two sides, the frontfaces and the backfaces. You can choose to display only the front faces, or both sides (this is referred to in TT64 as the "culling"). The reason normals are important is that the exporter for Google Sketchup usually exports BOTH SIDES of every polygon. Therefore there are double the polygons that there is supposed to be. Or you could accidentally flip a normal and the level will appear to have a hole in it. Also, backfaces cause some problems in some programs. But we mainly worry about normals in the level itself, because we haven't figured out how to import our own models yet (although from what I get that shouldn't be too big of a problem...we can decode the models, seems like we could redo the poly layout without too much rewriting (compared to the level replacement, anyway)).


Ah, that is what is meant by "normals". Yeah, it is better to design with "cubes" on level models so that only the front faces need texturing. I'm kind of new to the lingo, so thanks for clearing that up.

____________________
H4x0rz 4 lief!
dsx9069
Member
Level: 14


Posts: 20/30
EXP: 10359
For next: 2712

Since: 06-14-11

From: NY, USA

Since last post: 10.6 years
Last activity: 10.6 years
Posted on 07-03-11 10:37:23 AM, in Mario 64 Level Importer (last edited by dsx9069 at 07-03-11 10:36 AM) Link
I'm trying to place Eyerok in a custom level that replaces Shifting Sand Land (area 1), but every time I approach him it freezes (for all acts). Is it that he belongs only in area 3? What camera preset does SSL area 3 use (if not the first preset)? If he can only be loaded in area 3, how do I import my level to area 3 of SSL. Also, if I do this, can area 3 handle 155 objects as well as any normal world can?

EDIT: Okay, changing the last object bank to "Shifting Sand Land" apparently fixed it. And I know that I can only import to area 1.

EDIT2: But Eyerok is not behaving properly. When the battle starts, he pounds on the ground first, then when you go in front of one of his fists, he seems like he's going to do an attack but stays stuck in motion.
Also, I'm trying to use Toad as a model for something else, but whenever he's in an undefined combo, he's invisible. Anyone know a workaround for this?

EDIT3: I have a theory about Toad being invisible. When you are distant from him, he's invisible, and then as you approach him he becomes more visible. Somehow, I think Toad's original model is somewhere between transparent and invisible. But if used with the Toad combo, the Toad model is scripted to become more visible to Mario based on Mario's coordinates from Toad. Is anyone fairly adept at ASM coding to show me which code makes Toad's model invisible, so that I can tack a "NOP" in that address?

____________________
H4x0rz 4 lief!
Pages: 1 2
Jul - Posts by dsx9069


Rusted Logic

Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

22 database queries, 55 query cache hits.
Query execution time: 0.104186 seconds
Script execution time: 0.033179 seconds
Total render time: 0.137365 seconds