Jason777

DeathBasket, that is an inside map Ironically, the texture coloring comes out fine if I enable the Outdoor setting... but vertex normals are absolutely horrible (even with your fix). So, I have to fall back on having it as an outdoor map. Also, having everything the color of white gives everything a green tint. The only way I found around this was to use an older version of SharpOcarina (v0.4b; v0.5 and v0.6 darken the textures way too much). The textures are slightly darkened in the older versions but it looks a hell of a lot better than what it was with the newest one.

That is quite impressive! I'll be sending a PM your way tonight with details and necessary files once I finish cleaning up the parts I want to be showcased in the trailer

Heh, I'm about 99% sure that you have the right thing in mind

If you can submit an example of his work, I would be happy to give him the position. If he's willing, that is.

Title says all. Basically, I need someone to make a trailer of a small mod I am currently working on. I will not go into specifics as to what the mod is because I want it to remain largely a secret until its release (which is very soon). I am requesting for someone who meets the following prerequisites: Has a decent amount of experience working in the field of video editing. Can produce quality work under a very short amount of time (I'm talking about a week and a half). Can keep a secret. For those of you interested, send me a private message with an example(s) of you work and I 'll get back to you as soon as possible.

Most of the things you're asking for can be found on the wiki: http://wiki.spinout182.com • BGM music values can be found on the wiki. • Adding an alpha channel to a texture is done through SharpOcarina. You should have certain textures set aside in groups in the OBJ that you can edit individually through the Rooms tab. • Texture animation is possible through hacks (we haven't completely cracked the formula in the game), but at the moment it doesn't work with SharpOcarina. • The floating particles are an actor. You can find the actor list on the wiki.

There are things like this already out there that spinout has made such as the God mode and Tool Box hacks. It's specifically for maps and not individual objects, though... I still think that it would be cool to have a certain scene set aside (I always use 109 or 107 for testing purposes) specifically for this hack.

Okay, here's the deal, my room looks like this in SharpOcarina: ... But in-game it looks like this: Any ideas on what may be happening to my textures after conversion and injection? I was thinking that it might have to do with my environment colors but I really can't say for sure since messing with the environmental values doesn't leave any noticeable results.

JSA did recreate the Eagle dungeon in OoT But yes, I imagine that a Zelda 1 mod would be a lot simpler than any other mod.

Not to go off-topic, but what exactly are relocations and how do you know when to generate one? Maybe we could fix nOVL's source... I seem to have this idea that relocations are made whenever there is a need to store or load data from a virtual offset or whenever you need to make function call to a function within the actor. Basically, anything having to do with virtual offsets when transfered to RAM. Is this correct? I'm too lazy to look up the definition.

With exits it's all about setting certain collision triangles to a specified polygon type. The polygon type holds a single nibble (half a byte) that tells you what exit to take as defined by the exit command header. Check out these two pages... (0x13 exit command): http://wiki.spinout182.com/w/Maps_and_Scenes (Polygon Type Definition): http://wiki.spinout182.com/w/Zelda_64:_Collision_Format In SharpOcarina, you can set certain collision groups to certain polygon types. For transition actors, your problem is that you aren't fixing the "Front" and "Back" values appropriately. You should see those boxes in SharpOcarina under the Transiton and Spawns tab. Read the map and scene documentation page and look for the 0x0E command.

Nicely done! I tip my hat to you and Flotonic on a daily basis

I've never played any of the Star Fox games besides maybe the first few missions of SF64. I would probably look into a new game either way.

There is indeed! If you haven'g noticed the bar at the bottom of the browser which tells who is online, there is a chatroom you can log into there.

All this new information that's been flooding the forums is great stuff! It's even better that some of the new members are ASM hackers since that seems to be a dying race in the modding scene Welcome and thanks for your contribution!

Heh, this all you need to know to be able to use the actor: I do plan on making a video, though.

I seem to have figured actor 0x0187's variable and how to have it attached to a switch flag. I haven't yet tested it (I'm in school), but after looking at the disassembly of the actor's initialization function for a few minutes I'm pretty sure this is correct. After all this arithimetic, the Variable should be equal to the switch flag of your desire... (Variable >> 10) & 0x3F = Switch Flag OR... (Variable >> 10) = Switch Flag For example, variable 0x0FFF attaches to switch flag 0x03... (0x0FFF >> 10) = 0x03 (0x03 & 0x3F) = 0x03 If anyone wants an explanation of how I figured it out, I can post a complete disassembly and commentary on the initialization function. Anyways, I'll update this post later today to see if it works. EDIT: Yup, it works. So here's how you should set up actor 0x0187's variable... Only a little bit of math is required: (Everything should be in Decimal Format) XX = Switch Flag ((XX + 1) * 1024) - 1 = Variable Why do we multiply by 1024? Well 1024 is equal to 2 to the 10th power. We simply reversing the rightward bit-shift of 10 bits. (Approximation) Variable >> 10 == Variable / 2^(10) (Reverse) Variable * 2^(10) Why do we add one to the switch flag at the very start and subtract one from the result at the very end? Well, this is to take care of floating point issues since were only using unsigned 16 bit integers. In the end were basically reversing the arithmetic to solve for the variable: (Variable >> 10) & 0x3F = Switch Flag Convert the variable back to hexidecimal and you should be good! For example, let's say we wanted to attach switch flag 0x38 to a clear trigger. We would play actor 0x0187 in the map and then set our variable to 0xE3FF... 0x38 = 56 in Decimal 56 + 1 = 57 57 * 1024 = 58368 58368 - 1 = 58367 58367 = 0xE3FF in Hexidecimal SOURCE Disassembly of actor 0x0187's initialization function with comments: data_80B9CFD0: sw a1,4($sp) Preserve a0 in stack + 0x04 lh v0,28(a0) v0 = Actor Variable li $at,1023 $at = 0x03FF lui t0,%hi(data_80B9D054) t0 = upper part of address of function_80B9D054 in RAM andi t8,v0,0x3ff t0 = (v0 & 0x03FF) sh t8,28(a0) Actor Variable = t8 sra t6,v0,10 t6 = (v0 >> 10)... sra is used for signed variables lh v0,28(a0) v0 = Actor Variable = t8 andi t7,t6,0x3f t7 = (t6 & 0x003F) sw t7,336(a0) Actor + 0x150 = t7 beq v0,$at,$L000000 if (v0 == 0x03FF) goto $L000000 addiu t0,t0,%lo(data_80B9D054) Delay Slot: t0 = lower part of address of function_80B9D054 in RAM slti $at,v0,601 $at = (v0 < 0x259)... I do not know why this matters bne $at,$zero,$L000001 if ($at) goto $L000001 li t9,600 Delay Slot: t9 = 0x258 b $L000000 Default: goto $L000000 sh t9,28(a0) Delay Slot: Actor Variable = t9 $L000001: sh v0,28(a0) Actor Variable = v0 $L000000: jr $ra return sw t0,332(a0) Delay Slot: Actor + 0x14C = t0 I basically was paying attention only to arithmetic was that performed on the variable and noticed how the original value of the 16-bit variable was shifted to the right 10 bits... which left only 6 bits to take notice of. I then realized that the highest value possible out of 6 bits is 0x3F which happens to be the last switch flag available. Then I noticed that t7 held the value of the switch flag after all the arithmetic was performed and stored it at (*(uint_16*)(Actor + 0x150)). Really, the arithmetic of (t6 & 0x3F) was unnecessary so t6 actually holds the final value. Also, (*(uint_16*)(Actor + 0x150)) seems like an area of the actor that holds what switch flag it's attached to and (*(uint_16*)(Actor + 0x14C)) holds a conditional function jump? EDIT2: Variable arithmetic in hexidecimal... XX = Switch Flag YYYY = Variable ((XX + 1) * 400) - 1 = YYYY

I added that document to the Wiki awhile ago and have slowly been adding onto the puzzle actor list...: http://wiki.spinout182.com/w/Modification_and_Addition_of_Switches

Alright, one last question. What part of actor 0187's variable specifies which switch flag its attached to? The variable doesn't give away a whole lot but I imagine it's something like XXFF + (??00 * N) where XX is the switch flag... Or is not even within the variable but the XYZ rotation/coordinates?

Wow, I actually got excited for moment... Eh, looking at Naxylldritt's old maps isn't necessarily a bad thing though.

Petrie, so if I'm understanding this correctlly, any puzzle-based actor (gates, doors, blocks, etc) can be added to clear trigger simply by adding in this actor to the map and adjusting the variables of said actors accordingly? If so, that's exactly what I've been needing for awhile.

:') I can't wait till I'm older..

http://www.ign.com/blogs/amani2/2011/11/30/my-boyfriend-proposed-to-me-by-hacking-zelda 'Nuff said. A little bit late, but I think a round of applause is needed for this clever guy. *claps, etc*

Sorry for a double post, just decided to share a drawing I made today. I don't really know what to think of it... It may kind of obvious when I say that I had the super awesome and totally badass character of Demise in mind when drawing this:

I can probably make a few sketches for enemies and clothing designs. I may take a stab at drawing a main character design but I'm usually disappointed with the limitations of the N64's polygon limit.