Airikita

You should really mod a ROM before leaping into a whole re-design... I've been taking baby steps to re-design Zelda OoT, and it's not something you just leap into without experience. You should practice a few years before jumping on the modding wagon, because booooyyy, you're reminding me of a few people who quit within a few years with the same ambition. You should study a ROM's structure, architecture, design, and how it works before grabbing a runaway train. Let me say this: every N64 ROM works differently on how it renders models, so your best bet is to use an existing ROM, study the shit out of it, and try to do something from there. Without proper planning, and taking things slow, you're going to run your head into pavement.

I'm sure there's a balancing point... I see people are okay with no cutscenes, but I can also do extremely short cutscenes. Picture Gohma, but instead of seeing her crawl the ceiling, and falling down, she's already in front of Link, waves over him, and the battle starts. I also realized that without cutscenes, it can also ambush the player. So I will have to figure out some way to make a balance. I think for Minibosses, there's no need for a cutscene, which I wanted to make it feel more like a Zelda II game. Could depend on where the boss appears too...

Because I can still integrate cutscenes, it will just be a different set of work is all. Also, it is still possible with other means. So I'm asking if people prefer cutscenes over not having them at all. I could still start the battle, and give the boss title when you enter the map. Don't worry about how I worded it, I'm looking for people's opinions.

The cutscenes will be based off of the cloned boss, but the battles won't be as custom or as intense. I can build a boss off of existing functions, but the cutscene would clog the progress with that. The cutscenes won't be greatly expanded on, maybe altered slightly to introduce the boss (taking Gohma's cutscene for example where it zooms in on her, animation, then title, that's it). Without the cutscenes I can give the boss battles more flexibility. It's not a matter of what I'm going to do with the cutscenes, it's how much I will be able to do with the bosses. Question is are the cutscenes THAT important to sacrifice a super intense boss fight over? The question is expandability. Cutscenes in bosses are quite inflexible... Also, I was going to build bosses off of enemies (easier way) without cutscenes, but if the cutscenes are THAT much more important than just making a perfect boss, then I'll see what I can do.. EDIT: I should include that this does not mean all bosses will be void of cutscenes, only custom ones since I'm basing them off of 2D games (Minish Cap, Zelda II, etc...), so I plan on excluding cutscenes.... but if you're DYING for cutscenes on every boss, then I'll attempt something.

Vote for ZEY to determine what set of bosses it will have... 1. Bosses with no cutscene, but intense, dynamic, and customizable/flexible VS 2. Bosses with cutscenes that have enhances for better challenge. You people know my skills by now, but if you find the 2nd option more important, then I'll have to juggle integrating the better of both worlds, which will take a lot longer. I was thinking of emulating Zelda II bosses (some of them) and other concepts. Boss cutscenes are integrated in their AI, and while I can clone a boss and spin off of an existing cutscene, manipulation would still be restricted. Also, vote based on how much you care about cutscenes under these circumstances.

Ah well, it's possible that expanding it did it, but it works fine on Nemu, just not N64...

Of course URA was MQ... Nintendo still goofed and didn't do it properly.

I'm actually beginning to think it's from my RAM Expansion hack, but I'm not sure... fkualol: did you 00-out the old location? Remember, my gameplay_keep spot (the old spot) was erased. You might have moved it, but left the old gameplay_keep still there. My issue seems to be that I erased the old gameplay_keep and moved it so I could make it bigger. EDIT: I could also blame the fact that I'm using a counterfeit ED64Plus, but eh... maybe anyone with a better Everdrvie64 can try.

Yup, something else is fixing it... everything else seems fine except for Navi's orb and the glow effect.... not sure what else was affected.

I just found out today... and I feel your pain. D: I have code hooks and custom actors where gameplay_keep used to be. ------------------------------------- EDIT: ------ It seems to affect some things... mostly the orb Navi uses, and the glow effect. I don't know what else it will affect...

!!!!!WARNING!!!!! MOVING GAMEPLAY_KEEP FROM ITS ORIGINAL LOCATION CAUSES TEXTURE GLITCHES ON CONSOLE!!!!!!!! (Navi and etc...) There may be some magical solution to this, but NO, DON'T MOVE IT!!!

It's a step in the right direction, at least now maps are viewable. :3

Hm... I would prefer it in a page like "My Content" but not the same page? Another option in the menu for followed topics in the UserCP would be great for this.

Holy crap... nice. XD

I was thinking of something along those lines, but I would want him to jump higher than that... of course I guess I could force Link to jump higher from his values. I was focusing on Epona since I was able to expand her file... surely I could do the same for Link's file, but his file is already so massive I'd likely have to re-locate a file below his to another spot... I'm not sure if I can move ovl_map_mark_data... ---------------------------------------- EDIT: ------ Flow chart of ZEY, currently deciding on how to set up Lost Woods path after I finish working on the beginning cutscenes... not sure if I should work on maps yet since the tools to make them aren't hardware-compatible yet? Also, Unicat is still not working on hardware until further notice. ----------------------------------- EDIT 2: --------- Vote now for Bosses to have cutscenes or not: https://www.the-gcn.com/topic/2868-choose-between-boss-concepts/ -----------------------------------

At least it will work for maps and solid models, I haven't been able to test any other models with transparency yet... Unicat is now invisible, but I'm pretty sure the FC command is wrong for console. Although removing the FC command doesn't do anything for it either... I disabled other parts of Navi all except her orb, so I'm not sure why it is what it's doing... My other insight was how she looks squinted at the upper-left corner of Navi's orb on console, but I made a cleaner rendition of the display list aside from the squinting by comparing it to similar attributes: Removing DE 00 00 00 08 00 00 00 doesn't change anything. Best bets would be to find an object that uses similar F5, FD, and maybe F2 commands that has transparency, but Unicat seems to be special because there's no real match... EDIT: Uhhhhh.... why are you using a flower for FD 10 00 00 04 05 67 B0? (maybe I'm mistaken, but I managed to get a flower in Unicat's hair when adding E8 00 00 00 00 00 00 00 before F5 50 00 00 07 01 40 60... -------------------------------------------------------- EDIT 2: --------- Would like it so that textures are added after the display list, that way I can inject the display list separately without having to re-point things, or measure before converting.

I hope whoever cracks it figures it out, I'm sure it will be good.. I'll be sticking to N64 OoT though, for reasons.

No differences from non-crash damage to error damage. Mupen doesn't crash during test, only N64... I suspect it's some sort of RAM issue, but this would be easily resolved if Epona just reset correctly, I will have to observe what function is being used after Epona halts. EDIT: ------- Maybe this might help, if I knew where the functions were in Debug: https://www.the-gcn.com/topic/2656-zelda-oot-debug-crash-debugger-combination/page-2?do=findComment&comment=42541 ----------------------------------------------------- EDIT 2: --------- Error has been resolved... odd the error only occurred on the N64 considering the issue, but I made it more iterative instead of one big chain of checks. Apparently removing Link's reference to a pointer to Epona before she was halted was sending some sort of red-alert to the N64... anyways, issue solved.

Valentines Day is overrated, just like Christmas. It's just a way to get guys to buy expensive bouquets or chocolates just to impress the girl, and this one holiday just has fictitious values placed on relationships. I knew some girls who were like "if my bf doesn't get me a v-day gift, I guess he doesn't love me" that silly pick the petals notion of "he loves me, he loves me not..." it puts a problematic systematic view on how love should work. I won't say it's entirely bad, but it isn't always a good holiday, and love should be unscheduled. Valentines day makes love scheduled, and it puts pressure on people who are honest lovers who, when give a gift on Valentines Day, can't really do it on their own time where it would be a hell of a lot more meaningful. V-day makes it scheduled in a way that, when an honest lover DOES express his/her love, it doesn't hold the same surprise value because it's so scheduled. Really stupid holiday. -------------------------- EDIT: -------

I tried changing its behavior on Epona backing up to test using a different value... although I have fixed her crashing when running forward, it doesn't repair her backing up issue... It works in most situations except for backing up, which I haven't tested all scenarios yet... I am forcing Epona's status value to change too which is what prevented crashing when running forward. She will halt and stand still in other scenarios, but backing up causes her to be stuck in an endless animation loop which makes her appear to moonwalk, so she isn't resetting properly. --------------------------------------------------- EDIT: Exception thrown by what is likely to be the Peahat: The address in ExcectPC is not Epona's address.... Snapshot of when the console crashes, viewed in this frame on Nemu: I'm not quite sure where to go from here... either the address in ExcectPC or I use RA to backtrack...

Perhaps I didn't find it... anyways, thanks.

I hear your C-hacks crash on console, and my hacks don't. I use MIPS ASM in par with what the hex actually uses in the ROM, nothing is off from what I've coded, except a minor flaw with Epona, but I don't know what kind of restrictions registers would yield.

Show Errors is on, and it doesn't crash or show the error... the crash only seems to happen on console.

Crash test: Doesn't crash: