mzxrules

Good luck fixing this glitch:

The entrance index is a signed value so addressing past 7FFF might not be possible without further modifications. Also, there are a handful of values at the 7FFF end used for resetting the game/exits that change their destination based on the entrance used. Edit: I just remembered why I thought the scene index was a single byte: A single byte is used to store the scene number in the entrance table, so again the limit there is 256

One thing: I got drunk one night and this happened when I woke up: http://cloudmodding.com/wiki.

Eh, I don't think the games are suppose to be plays, rather using terminology that is similar to a play/movie makes sense from a design perspective.

I still think the "dead" pose is related to this: I don't know exactly what animations are being used in the Jabu Jabu sequence, but I think it's something like: Look back -> Knock Back -> On the ground Also like to point out that without the pedestal, there would be a bigger difference between the ground and Link.

Cutscenes don't have a means of positioning actors relative to a location.

http://oot.cloudmodding.com/wiki/Entrance_Table_(Data) You could modify the entrance table so that the child market scenes are loaded rather than the adult ones. The only thing to worry about is that you have to define alternate setups if you wanted different npcs loaded vs child/adult.

To explain Jason's comment further, he's suggesting that the byte-order of the rom file is not correct. Rom's with the .z64 extension are typically (but possibly not always) in Big Endian order, which is the native byte-order of the game. You can easily tell if the rom isn't in Big Endian order by opening it up in a hex editor since there's a string of text that should read THE LEGEND OF ZELDA near the start of the rom. As for the mod itself, I haven't tried it out myself but from what I understand spinout didn't factor in the save format in the hack, so any scene past 101 may either not store permanent scene flags, or go past the allotted space for permanent scene flags and interfere with other "global" flags

I feel like Nintendo did well to put on a good show, I'm just not sure how that will sell consoles. First of all, I thought last year they had a bigger lineup of games coming out. The digital presentation started to wrap things up a mere 40 minutes in Splatoon looks interesting, but from what we've been shown it's miles behind other shooters out there. For me, Halo 3/Reach is my personal favorite shooter due to the level of depth in terms of play styles and customization, both game types and arenas. Smash is smash. The tourney was a great idea, just a little disappointed in that last match. I wish there was more to talk about Zelda U. Everything else seems not that important to me.

So basically you're making the game ignore unhandled exceptions?

Had no internet, so I did what I usually do... just without help. I found a few things not covered/wrong with the 0x11 scene/room command in http://wiki.spinout182.com/w/Scenes_and_Rooms#Header_Commands. 0x11 Skybox settings 11000000 xx0y0z00 x = Skybox number (see the skybox list) y = Cast. 0 = Sunny, 1 = Cloudy. Affects the sun's lens flare, and skybox 1 will load sky/clouds z = Fog. 0 = minimal fog, 1+ = significant fog I made some changes to my scene viewer that allow stats from cutscenes to be printed out, and I ended up discovering two more cutscene commands that either I overlooked or were previously unknown... the 0005/0006 commands. They appear to be similar to camera commands, but I was more focused on getting the cutscene parser to not crash rather than figure out what their purpose is. http://wiki.spinout182.com/w/Cutscenes#Cutscene_Commands With the aid of my program Spectrum, I believe I discovered an "ultimate" memory constraint on object files, as well as a pattern as to how they're allocated. Gameplay_keep, (the object file that's always loaded first) is positioned exactly 0xFA000 before the start of the scene file in memory when in unpaused play state (I found this to be true for the two roms I checked, NTSC 1.0, Debug MQ). Object files are allocated without gaps in-between, thus I believe this means that the sum of the file sizes can't exceed 0xFA000 bytes (i'm not 100% sure that this is the maximum, it might be less. Someone test this). Another thing with objects that I believe will work but haven't tested (but maybe someone else knows this?) is that the ordering of objects within the 0x0E command (Object Listing) does not necessarily matter as long as two conditions are met Object files that need to exist in all rooms must be listed first The order of the objects must be consistent across all rooms for the objects that must exist in all rooms Petrie's Challenge is a modification of the PAL Master Quest, not NTSC. My bad. I wrote my own text dump program for the (language*)_message_static files for every language. There were a number of things spinout's wiki didn't mention NTSC and PAL text bank pointers within code use different formatsWith NTSC, Japanese text boxes are referenced the same as English, but use bank 08 rather than 07 With Pal, for English you have 1 word for textbox id/settings, 1 for bank offset, but for German, French you only have 1 word for the bank offset, relying on order to find the appropriate textbox id/settings English, German, French use the same character set which I think is an 8 bit char set, and so the textbox codes seem to be the same across languages, but Japanese uses jis-shift? which I believe is 8/16 bits, meaning different textbox codes. http://wiki.spinout182.com/w/Ocarina_of_Time:_Text_Format I've been trying to figure out how the game determines where to put room files in memory. I thought I had a pattern but didn't, but at the very least I found that the skybox files are snuggled in between the room and object files.

NTSC 1.0 File Listing PAL MQ File Listing The 1.0 file list has been around for a while, but the MQ one is new, and has been something had been meaning to get around to for a while. These tables are generated mainly by locating different file tables located in code in the debug rom, and finding the corresponding table in the other versions. Edit: File list turned out to be for PAL MQ

New enough to not understand how an emulator works it seems. A rom is a binary that contains read-only data, in this case the entirety of an N64 game that can be processed on by a real n64. (Ex. Ocarina of Time Rom). An emulator is a program that simulates (emulates) a machine. In this case, an emulator emulates an N64 (Ex. Mupen, Project 64). There are no "Project 64 Roms" because the roms were created to be run on an N64. They are N64 roms. You'll need ppf-o-matic to apply the patch to a rom. For the patch to work, you'll also need to have the debug rom (typically named ZELOOTMA.z64). You should make a copy of this file before applying the patch so that you always have a clean rom

Console.WriteLine("Hello!");

Quoting myself to find this info easier/recent observation. an ovl_En_Test instance allocates ~0x918 bytes for itself, much larger than the data blocks that I've been assuming to be the size of the instance (i think? it's 5am). One of the many things I'm working towards is creating a program that can output ovl file data, so I'll be able to understand this more perhaps

@Agnostic Priest, obviously they were building off of source files. It's a million times easier to modify source over reverse engineering your own game. One other possibility is that it could have been easier to test certain things on N64 since it wouldn't require extra software to output to a console window when running a debug build, and doesn't take a minute for the the emulator to boot.

Looks like you'll need to generate the cutscene by hand, but shouldn't be too hard to hex things. I started by downloading the N-rage v2.3c input plug-in, since it emulates a standard 8 kb mem card, and is a bit easier to find the cutscene data in. http://sourceforge.net/projects/nragev20/ The memory pak format seems straightforward. Blocks are 0x100 bytes long, 0-4 are reserved, making block 5 the first block (starting at 0x500) Block 01 contain a block table that denotes what blocks are allocated using a very simplistic format. It consists of a series of 128 short values, and aside from the first 5? values, each short seems to represent one block somehow... 03 seems to denote a free block, 01 seems to denote the start of a file. I think it's used to optimize space by allowing files to be fragmented. Block 02 appears to be a duplicate of block 01 Block 03-04 seems to contain a "file" list, where each file is 0x20 bytes long. Index 0x06 contains a short length value containing the start bank address for the file. Index 0x0C seems to contain the "name" of the cutscenes saved on the memory pak, where 0x1A = A thru 0x1E = E. The first block in the cutscene data stores the header info for the "segments" of the cutscene, or one 01/02 cutscene command pairing as per http://wiki.spinout182.com/w/Cutscenes Each record is 0x10 bytes long, for 15 records (one line is unused) 0x00 is a char used for the segement's "name" 0x04 is probably the end pointer for the cutscene data in ram. Nothing appears at that address on PJ64 0x08 is probably the start pointer for the cutscene data in ram. 0x0C is an unknown short? 0x0E is the number of camera position/focus waypoints. An extra waypoint exists at the end of the list to simplify editing, and should be dropped when copying the data. The following blocks simply contain the raw cutscene data. The first is the data stored in the http://wiki.spinout182.com/w/Cutscenes#Camera_Focus_Points command, followed by the data stored in http://wiki.spinout182.com/w/Cutscenes#Camera_Positions

For swords, my main theory has been that the collision box for swords is a simple line that extends out from Link's hand, but it's probably wrong. The reason for this idea is that it's possible to have a sword hitbox that doesn't match the sword model length in some cases (Child Link with Master Sword equip = Child Link with Kokiri Sword model, Master Sword length). The spin attack is a separate actor (0057: ovl_En_M_Thunder), so you might discover some things if you look into it

Gen 2 is to me the best generation. Beating the Elite Four and having an entire continent left to explore was an awesome twist. Also, according to some sources apparently the "Pokemon Timeline" was released the other day. Red/Green ≒ RS → Gold/Silver ≒ DPPt → BW → BW2 ≒ XY Nothing shocking except that Ruby/Sapphire take place at the same time as Gen 1. Maybe this will be important in the remake?

my guess is more will be shown at E3. It's a pretty underwhelming reveal once you think about it, since it looks to be just another remake.

There are no differences between the N64 U and J releases as far as N64 builds go.

Looks like the spike monsters from the Water Temple but with thicker spikes / 2d sprite. Edit: Or maybe like a Spiny Egg from Super Mario Bros

So last night I spent time documenting Link's variable, which appears to be used for spawning him. I (re)-discovered that a portion of the actor variable is used to set how the camera behaves when spawning. What I discovered was that the variables appear to be scene dependent, and that a number of these behaviors seemed to be unused. For example in v1.0 if you lock 1DAA4D to 00/01 and enter the ice cavern, the camera will face the exit rather than be behind Link.

I bought Etrian Odyssey 4 because of you. On my 3rd playthrough. The multi-language Gen 2? editor looks very interesting

Sorting actors into categories is on my to-do list actually, but it will be a separate page. A number of actors easily fall under multiple broad categories, so I'd need to duplicate actors to make it easier to find them. For example, with JSA's NPC and Puzzle categories, Ruto from Inside Jabu Jabu's Belly should fall under both since Ruto is both an NPC (can be talked to, part of the plot), and is used as a puzzle element (can press down switches, sets "global" level flags).