john_smith_account

No. I use this as my Debug ROM for all modding now, and it performs identical to the original.

I dunno, I don't have Pro.

Sorry, I guess the same problem is bound to happen more than once. For the original game maps, actor relocation works fine though.

Completely off topic, but your maps always look amazing. I keep wanting to explore those areas. Could the error be caused by the lighting? Try building the map in v04, indoor to test it. Use v04, not v05 to test since v05 seems to add lighting whether you want it or not. You can hack in the skybox manually after the build to see if it makes any difference.

No, Zora's don't need 00C5. Just Kokiri and towns folk. Doors are transition actors, and are handled by the transitions\spawns tab.

*REMOVED*

This patch resolves issues related to the DMA mappings, which can cause mods not to work on some emulators. http://www.sendspace.com/file/5cypap Examples: 1964: You can enter a map created with SharpOcarina only once. If you enter it again, it will fail to load. This patch will fix that. PJ64 v1.6: is more passive aggressive, preferring to freeze randomly during gameplay. Short Version(for those in a hurry to mod): 1. Copy down current ROM settings in your emulator from a working copy of the Debug ROM. 2. Apply patch. 3. Refresh your ROM listing. 4. Apply settings to the newly created ROM. Long Version(for those who want to understand how this works) Each resource with in the ROM(actors, objects, scenes, maps, skyboxes, etc.) is broken up into it's own file. The DMA(dynamic memory allocation) table it's self is also a file. I'll not get into all the details on how the DMA table works. Simple version is that it maps memory so you can compress the files easily. The problem is two fold here. Number 1, the DMA table is used to CRC the ROM. Some emulators, and real hardware rely on the CRC. On real hardware, for instance if the CRC isn't correct, the ROM doesn't boot. Number 2, the DMA table maps the memory for the entire ROM. If a mapped address is altered outside it's original mappings, it can cause crashes, and freezes. Even on emulators that don't care about the CRC. How this patch works: The DMA table is actually a tad longer than it has to be to allow for new entries. Since the DMA table is it's own file(not part of the code) it can be even be moved and extended as much as one needs. The game quits reading the DMA table when it hits the first blank entry, 16-bytes of 0's. All I did was cut a line of 0's from the end of the DMA table, and place them right after the entry for the game's code. I then ran rn64crc to fix the CRC. This method allows one to develop the ROM, altering all resource files(actors, objects, scenes, maps, skyboxes, etc.) without the DMA tables giving you grief. This method is convenient in that it allows you to make the changes you need to the DMA tables after you've completed developing, rather than having to update the tables with every alteration you make. When you are done, and want to restore the DMA tables(for use on real hardware, to compress the ROM, etc.) the process is easily reversed. How to reverse it: Cut the line of 0's just after the entry for the game's code, and place it back at the end of the DMA table. Run a CRC fix.

Loose the 00C5 group, it is only need for the actors I specifically listed it for earlier. Try other variables for the Goron first, to establish if the problem is related to that variable or the actor as a whole.

Try the jabo 1.6 fix, created cooliscool. 1. open the ROM in a hex editor 2. In the header there should be the ROM name, something like "LEGEND OF ZELDA". 3. In typo over mode, typing over the original text and not adding bytes to the ROM, rename it to anything else. The classic fix was used "LEGEND OF DEBUG" This fix is so crucial, I have it applied to default ROM.

The problem you are describing is caused by is actually by the programmers being "clever". What takes awful long to load is the background image for the inventory screen. It gives some pluggins/emulators problems. Even on a real N64 it loads slow sometimes! MM's Inventory loads fast! Why? It lacks that stupid background image. This problem was solved once, but the fix was hoarded, and since lost. But if it was fixed once, it can be fixed again. Any of you mighty ASM wizards what to take a stab at it? I'm willing to help.

No, the idea that the actors and groups had to be above the other resources was on OLD mistake. I was the first to make the mistake, right after Dark_Link-77 invented the method. I did not realize at the time what the real problem was. Any resource can be anywhere in the map, and adding the actors to the bottom is actually the best method. I keep saying it, though no one is listening, the CRC matters on anything that falls within the DMA memory mappings. I have a super easy fix(I hope to release tomorrow) but for now your maps may continue to fail, even if you do everything right. Don't give up! Help is on the way. Hey spinout! How you been?

Child zelda no, but talking to her triggers a cutscene. When loaded in a different environment, you'll find her staring out a window that isn't there, and she still goes through her intro induction cutscene without missing a beat. Adult zelda, there is more than version of. The tower version is crazy event dependent. Child Malon might work well for you. She is more event dependent than scene dependent. Load the version(variable for the actor) from the market, and the version from the castle, side by side to cover both events. Don't worry they won't ever appear side by side. The ranch version(variable) will only show up after you wake talon.

Very nice. Good contribution.

Kokiri are scene dependent. Let me save you a lot more pain. Actors that are picky: Kokiri are scene dependent, and age dependent. Requires at 2 groups/objects to load. Group 00C5 + another group. Carpenters are scene and age dependent. Nabooru is age, and event dependent. Malon is scene, and event dependent. (Maybe age too not sure.) Talon and Ingo are scene, age, and event dependent. Cursed, and uncursed house of skulltula npcs are represent by two differnt actors. Actors that are not picky. Common NPC's, town and Village actors. Work fine anywhere any time. Requires at 2 groups/objects to load. Group 00C5 + another group. Most Guards, Gorons, Zoras, and Gerudo should all be ok, with the exceptions of ones tied to events like the Zora looking for Ruto's when you find her note, or the dying guard in the back alley after Ganon invades, ect.

Whats going on is that you've chosen event dependent. Saria has at least 3 separate events that decide if she is in front of link's house, at the meadow, or at her own house. She might also be scene dependent, I can't recall. I'm not even going to get into all the hoops you'll have to jump through to make them work. You'd have to want them BAD to make it worthe the effort.

I used to use that one, but TIG's exporter it MUCH better. Flawless, and groups your material lists automatically. seacrh TIG obj exporter on google. I'll post the modded version of TIG's importer and exporter later I use some time later. OZMAV r76 dumps textures. Again, google is your friend.

1. Never mind about OZMAV2. It's not important at all, and your efforts are better sent on Sharp Ocarina. 2. You did not make a bad choice! You chose the simplest method, which is easiest for most modders to understand. Consider spinout's own words... It does work well for collision, and it would be a pain, and I can't see how the results would be justifiable. Most users will never appreciate the difference. And honestly us more advanced users who would already have work arounds. Once users get to to the level they need such features, they can use the rather easy work arounds. You can always makes the changes in a far distant release, or even start a SharpOcarina2. Right now the time would be better spent on working out the bugs and adding useful functions to the current system.

Yeah, I borrowed the pic from your post.... Aw the memories. It's not a bad actor, it's just 2 Jabu Jabus is too much.

For me it was the Ocarina Platform.... Part 1 I started Zelda hacking with just a Gameshark, and a real N64. I started with beta quest . My personal favorite moment in beta quest was the ranch, because you could could have child link a horse. I never mapped beta quest, because I realized practically first thing they were just uninitialized cutscenes. I did, however map out every valid normal exit in the game. But it's the ocarina platform that got me here. I joined ZSO, the end all site for Zelda hacking at the time, for only 1 purpose... to have someone give me a code that could get me on that platform without the game crashing. No one ever did. If anyone had, I would have left and never come back. All I really ever wanted was to get on that platform. So I ended up staying to learn enough to make that single code. When actor hacking came out I finally had what I needed to finally step on that platform. Still one of my favorite moments in Zelda hacking. End of Part 1

Tried 2 more XP systems, a windows 7 system, a different ROM, and updating the .DLL's. Nothing. I give up, could someone (Not XDaniel, I've bothered him enough) just dump me the maps for me to try. Please (Side note: I tried OZMAV2 on a OLD p3 laptop last night. And it ran, and looked fine! That must be some efficient coding XDaniel. Good job!)

So I am the only one who OZMAV2 doesn't dump maps for? Is it my OS maybe? Windows XP? It creates 2 folders on start up dump and one I *think* is called extc (not at home to check), or something like that. Then... nothing. Am I missing something here?

I guess it doesn't really matter if OZMAV2 can dump. Are the dumps produced by OZMAV2 any better? I've got the OZMAV r76 dumps, which I already put in the effort to get working in Sketchup. Also anyone else having luck importing the original maps to sketchup?

Hello everyone. Got a copy of OZMAV2. Went to the command line, and turned on .obj dump. It didn't work. I tried all the releases of OZMAV2. No dumps. So, I assumed after trying it on a second system that .obj dump in OZMAV2 was nonfunctional at this time. I spent some time this weekend, and created a method for getting the .obj's generated by OZMAV r76 imported *perfectly* into goolge sketchup. Why bother? To create modded versions of the games original maps of coarse! I've even modded some ruby scripts to make the job easier. The imports are perfect to the original, all verts, and almost all faces are correct. However... Then I read I something stating OZMAV2 *CAN* export objs. *Mind blown* Were my efforts wasted? Is OMAV2 already dumping sketchup importable .obj's? Also, before I make a fool of myself and post my methods for perfect sketchup ports, does anyone else have an alternate method for getting the maps out of the ROM and into sketchup? Any input on the topic is welcome.

Thanks for all the positive response. The txt file included gives all the details on how it was created. http://sketchup.goog...7f9&prevstart=0 The sketchup map's creator offers to give details, and resources to port other DOOM maps to sketchup. The method Arcaith describes might work better, or be combined with the original porter's methods to produce faster/better results.

It's the first map from DOOM. Enough said. http://www.sendspace.com/file/eic9g0