Jason777

I had seen you posting on Unseen64 quite a few times Welcome!

Looking forward to it, xdaniel. Perhaps now I can see how you manage to do the things you do

I think you just need to stop telling yourself you're bad at math and actually try to learn the material instead of giving up as soon as you hear about what is involved. You seem to have this pessimistic attitude towards learning things if people can't guide you every step of the way. My advice to you is that you should really try learning on your own; buy a math book and seriously read it page by page while trying understand what you're reading. Don't just read a lesson and be like "I think I got it...". You have to test your ability to apply what knowledge you have learned. That is the only way to truly comprehend what knowledge you have acquired. tl;dr Quit telling yourself you can't do things or that you aren't good at something. Not to sound corny but you can do anything if you really put in the effort to do so. In the end, you really end up doing yourself a huge favor by pushing yourself to try harder and forcing yourself to actually learn. Reading over my post, I may come off rather harsh but I am giving you honest advice. I'm not going to tell you that you should give up "because life goes on" yada yada. You know what you are truly capable of and I encourage you to try and push those limits or even exceed them. It's not over yet. You don't know how you did and no one is forcing you to quit or give up.

I'll try doing it myself and get back to you about it, Rinku. If everything goes well (I can't see why it wouldn't) then I'll write a simple tutorial.

Well, you heard the man, Rinku! You should check out Hylian Toolbox! You can find it on Maco

A custom map viewer/editor that is specifically for assigning polygon type definitions to collision triangles? I could see something like that being useful. I'll highly consider it. I need to start trying to write programs that use OpenGL and display 3D objects anyways.

Are you planning on making some of the items from ALttP?

This contains some nice information concerning animated textures i.e. such as where the code to animate lies in RAM. https://www.the-gcn.com/topic/600-xdaniels-random-junk/page-4

Awesome! Now if only we could figure out how exactly OoT animates its textures in maps. That way we don't have to use engine hacks to do it and can use what the game already provides.

Aquarhane, you should get NiGHTS for the Saturn and Chrono Cross for the PSX.

Thanks, Secant and Three; I appreciate the compliments! Your maps always seem to have a dark appearence, Secant... I like it. It's too bad that we didn't get to see the Earth Temple have some actors and puzzled placed; I would imagine that it would've given the team a much-needed moral boost. That last map looks like something from Hyrule Castle or a continuation of one of your older maps, Citadel Castor Do you have any maps from Shadowing Dawn? I had always been interested in that project but had joined the community too late. EDIT: Wow, just saw your post, Arcaith. Needless to say, I'm impressed. I recognize some of the maps that belonged to your old Zelda mod, Shattered Realm.

A couple of years ago, I used to be really into making and designing custom maps. I still have quite a few maps on my hand that I think it would be cool to show off and possibly give download links for if there is any demand. Other people should post pictures, videos, downloads of their custom maps, too! I encourage it! Remember that a lot of these are from when I barely started getting into modding and 3D modelling so most of them might not be so great Alright, let's get this started... I'll begin with my finished creations. I helped alphaheiti fix up this map 2 and a half years ago so that he would actually be able to import it: I made the untextured structure of an Ice Temple for a beta restoration project 2 and a half years ago: This here is my baby... this map was the main area of a small mini-mod I was making 3 years ago when I first got into modding. Unfortunately, I never finished the mod. I got -really- damn close to finishing it but I just never got around to it. I would consider it about 90% done: This is part of the above mod. It was meant to be a secret area where you got a incredibly overpowered weapon to just f*ck sh*t up: I can't really remember what I was going to use this map for... All I remember is that it served as a type of entrance map to where you could go into 5 different areas (forest, dungeon, mountains, canyon or river valley, and desert). This map is incredibly old: And now we're starting to get to more recent maps that I've made... Here is a map that I made for Zelda's Birthday II. I have no idea if it is still being used: Now we have come to my unfinished area... Some of these I still plan to finish up. This one is really recent and is basically an abandoned church dungeon: I was inspired after playing some Sonic and Knuckles and started to try and build an Angel Island-esque dungeon. It's been around a year and half since I've touched this so I'm not sure if I'll continue: If any of you guys remember Project Majesty, I had donated this map to that effort. This is one of the maps that I would like to get around to finishing:

Sweet. Hopefully people start developing more engine hacks.

Well I feel like the biggest dunce on Earth at the moment...

To expand upon what mzx said, this can also be seen in lui/ori or lui/addiu pairs. Assembly deals with signed immediates so anything above 0x7FFF has 0xFFFF preceeding it. For example... ori a0, $zero, 0x7FFF^ Register a0 would now be equal to 0x7FFF. Say we go above 0x7FFF... ori a0, $zero, 0x8000^ Register a0 would now be equal to 0xFFFF8000. Going back to what I was saying about lui/ori and lui/addiu pairs... lui a0, 0x8016addiu a0, a0, 0x7FFF^ Register a0 would now be equal to 0x80167FFF. The above was an example of an lui/addiu pair. You can also use a lui/ori pair to get the same exact result as long as the lower 0x16 bits do not go above 0x7FFF. lui a0,0x8016ori a0,a0,0x7FFF^ Register a0 would now be equal to 0x80167FFF. Say we go above 0x7FFF for the lower 16-bits of an address. For example, 0x8000... lui a0, 0x8016addiu a0, a0, 0x8000^ Register a0 would now be equal to 0x80158000. Why? Well that's because 0x80160000 + 0xFFFF8000 = 0x1801580000. However, anything after 32 bits overflows (the one becomes omitted). We cannot do a lui/ori pair when the value goes over 0x7FFF... lui a0, 0x8016ori a0, a0, 0x8000^ Register a0 would now be equal to 0xFFFF8000. 0x80160000 | 0xFFFF8000 = 0xFFFF8000. Say we wanted to put the value of 0x80178000 into register a0, this is what we would do... lui a0, 0x8018addiu a0, a0, 0x8000^ Register a0 would now be equal to 0x80178000. We are using the overflow to our advantage since it basically works as subtraction by taking away 0x00010000 from the current value (whenever you're adding a value over 0x7FFF).0x80180000 - 0x00010000 = 0x801700000x80170000 + 0x00008000 = 0x80178000Sorry for the super in-depth explanation (especially if you already know about the whole signed/unsigned business) EDIT: Apparently I am the one in need of researching signed/unsigned data. Read DeathBasket's post a little ways below.

That is definitely possible; I would just have to adapt code from this actor to work another one. The only thing is that it would require Link to fire an arrow first. Unless, of course, we find a way to shoot arrows (I've been looking for this for the past year and a half).

The way it works is that arrows are continually spawned from the custom actor's position by spawning en_arow_trap once (en_arow_trap constantly spawns arrows). In the custom actor's code, it also calls a function to have en_arow_trap constantly facing Link. The thing is, en_arow_trap does not shoot them; it relies on Link's code to deliver the final touches. In Link's code, I believe there is a place where it clears a flag that makes all arrows that are currently spawned fire. If I remove the proximity check then you can fire an arrow from anywhere in the map and you'll see that an arrow still fires from the pot's location and travels in your general direction. Trying this out in a large map will demonstrate this result quite clearly. Another thing is that it only has Y rotation that is constantly changing to have the actor face Link's general direction. This means that you could be a about 100 meters above the actor and fire an arrow to see that the attacking arrow will shoot and miss by going below Link (this is where some puzzle ideas come to mind). If you want, I can make another release where you can give the custom actor a certain variable to make it have a set rotation to shoot arrows normally and not constantly aim at Link.

You're asking if it's possible to just have Link spawn the attacking arrow? If so, then yes but the arrow will not fire at Link unless you screw with the positioning and rotation.

And here we are: https://www.the-gcn.com/topic/2496-utilizing-en-arow-trap/

ovl_en_arow_trap_util v1 -- 26 June 2013 To turn actor 0x0081 into something useful, I have released the following custom or modified actors (the following are folder names where the actors reside): [*]En_Arow_Trap_Mod : A modification of actor 0x0081 with a few bugs and checks removed [*]En_Vase_Mod : An actor which utilizes actor 0x0081 (highly modified actor 0x0082) [*]Unused_C : A custom actor which was meant to replace actor 0x0081, but was not used The actor within En_Vase_Mod (En_EAT_Util.S or ovl_En_EAT_Util.ovl) is basically an assembly rewrite of the custom actor within Unused_C (ovl_en_arow_trap_util.c) since I was having trouble with the mips-gcc compiler when using C. To use it, basically apply the PPF patch (it patches actor 0x0081 to 0x00D6CE00 and actor 0x0082 to 0x035CE040 in the ROM). If you're interested in only the actor files then look at ovl_En_Arow_Trap.ovl and ovl_En_EAT_Util.ovl. When you want to use the hack, just place actor 0x0082 and object 0x0086 on a map, walk over to where the actor is (if you haven't replaced the model then it is a pot) and then fire an arrow. The result is "Ouch!" Things for future releases: [*]Need to implement collision [*]Need to make a new model for actor 0x0082 (if there is demand) [*]Possibly decrease/increase/remove the proximity check in actor 0x0081 If you don't understand all the files that are included in this source, don't worry; it was mainly included for those that do. Here's a hint though: everything is mainly for use with mips-gcc, nOVL, nOVLIns, and zOVLDis. Devs, look at the Makefiles if you're curious on how to compile these things yourself. nOVL was made by ZZT32 nOVLIns was made by spinout zOVLDis was made by ZZT32 and spinout I don't think I have to explain who all people made GCC If you're interested in making stuff like this, then follow these links for related stuff and tools: [*]https://bitbucket.org/mbr [*]https://bitbucket.org/ottehr [*]https://code.google.com/p/gzrt/wiki/Nintendo64ToolchainSetup Download: http://www.mediafire.com/download/57cyt6mu92zmg6t/ovl_en_arow_trap_util.7z EDIT: I realize now that it would've been ten times more efficient if I had just modified actor 0x0081 instead of modifying 0x0082 to spawn 0x0081.. Herp derp Next release (if there is one)!

Well, I finally got off my ass today and rewrote the actor in assembly just to make sure that it wasn't a problem with my coding... I'm happy to say that the actor works exactly as intended! I will link to a new topic in this thread later today with the custom actor, its source, as well as other modifications I made to get everything working (including the original C actor that I ended up rewriting). Collision will be a part of a later release. In the meantime, I'll be throwing together a model and making a video after I'm done running errands and doing real-life shit today. Happy day

Three (and others i.e. Strati, Airikita, mzx, etc), we should make a personal section on Z64 wiki for you; you have documented so many things that no one has ever really looked into that I would think it all worthy if its own sort-of database... that way we don't have to read through so many forum posts

All that matters is that the overall size of an individual texture file stays within the range of what the N64 can handle (texture cache) and that there are converters that can take that specific texture file format and convert it into a format that the N64 will recognize.

I've been getting pretty into MKWii recently... Does anybody feel like racing me?

What? EDIT: It doesn't matter if there are textures that aren't originally found in-game.