mzxrules

Woops. I guess it was an off by 10 error.

Why doesn't SceneNavi display the last "item" in a combo box? <Definition Number="0x015F"> <Item Index="0" ValueType="System.UInt16" DisplayStyle="Hexadecimal" Usage="ActorNumber" Description="Actor Type" ControlType="System.Windows.Forms.TextBox" /> <Item Index="2" ValueType="System.Int16" Usage="PositionX" Description="Position (X)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="4" ValueType="System.Int16" Usage="PositionY" Description="Position (Y)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="6" ValueType="System.Int16" Usage="PositionZ" Description="Position (Z)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="8" ValueType="System.Int16" DisplayStyle="Hexadecimal" Usage="RotationX" Description="Rotation (X)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="10" ValueType="System.Int16" DisplayStyle="Hexadecimal" Usage="RotationY" Description="Rotation (Y)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="12" ValueType="System.Int16" DisplayStyle="Hexadecimal" Usage="RotationZ" Description="Rotation (Z)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="14" ValueType="System.UInt16" Description="Type" ControlType="System.Windows.Forms.ComboBox" Mask="0x0001"> <Option Value="0x0000" Description="Brick Pillar" /> <Option Value="0x0001" Description="Brick Throne" /> </Item> </Definition>

Pretty much. As long as the mask is read in as an unsigned type you won't run into any issues. The way my program reads the actor def, is it reads in a value off the rom at whatever offset the def specifies, stores it in a UInt16, applies the mask (also a UInt16). private int GetShift(UInt16 mask) { int shift; //a mask of 0 isn't valid, but could be set in the xml file by mistake. if (mask == 0) return 0; //Check the right bit //If the right bit is 0 shift the mask over one and increment the shift count //If the right bit is 1, the right side of the mask is found, we know how much to shift by for (shift = 0; (mask & 1) == 0; mask >> 1) { shift++; } return shift; } The function could be tweaked to also calculate the range of the input value if you'd like to display that as well The only weird situation that should never happen is one where you need a mask with a break in it, but you'd have to do something special anyway to get it to display correctly. Ex. 0xCE = 11001110

Explain one scenario where the user would prefer to edit the masked out value directly, rather than the proper bit field value. I'm "nitpicking" because there's no reason for the editor to display the data this way in any scenario, and no reason to add an extra attribute that makes it harder to modify the XML file by hand. Also, it IS easy to handle this, my program does this already for printing out actor info. The mask attribute has to always have a value for the program to even be able to read data off the rom, since you perform a bitwise AND with it to capture the value for editing.

There is no "calculating the mask". Its set via the Mask attribute in the actor definition format. I'm saying you can use the Mask attribute (rather than add yet another attribute to the format for this specific purpose) to figure out how to right-shift the value read off the rom/left-shift when writing back to it so that you're editing the actual bit field that the devs would have been editing. I don't know why any sane person would want it any other way.

In order to edit the value, you have to figure out the underlying mask, then left-shift your intended value. For example, say there was an actor that displayed a number between 0 and 16, but the bit field to display this number was in an odd position like this one 0XXXX000 That would mask to 0x78. In order to display values 0-9 you'll have to input 0 = 0x00 1 = 0x08 2 = 0x10 3 = 0x18 4 = 0x20 5 = 0x28 6 = 0x30 7 = 0x38 8 = 0x40 9 = 0x48 If you drop the DisplayStyle attribute (which lets you edit the value as a decimal value), then values 0, 8, 16, ... , 72 would represent 0-9... not very intuitive. Instead, what can be done is you can read in the value with the mask, then shift the value right based on the position of the least significant digit of the mask, then display for editing.

Another thing, I don't like how masking captures the value for editing either (note the switch flag on the bottom).

You can find zdec packaged with Utility of Time. From my experience with creating Dungeon Rush, zdec causes some minor graphical bugs and graphic exceptions, but these disappeared when I recompressed the rom.

My editor is "done". It's a little hacky, but it's good enough to build up the xml file. I'll be working on filling it up now, and updating with any issues I encounter. The worst quirk so far is that I can't set the Usage attribute to my own values, or have an empty value set without SceneNavi throwing an exception. Seems odd considering the attribute is optional.

Since Dan hasn't responded to my comments, I will. Still want this. It is much easier to import automatically when defining things explicitly, so I don't want this anymore. I've thought up one other one (a "Text" value), but it'd be a little ambitious. With some npcs (Navi Infospot) it's possible to display a certain text dialog. Rather than store all the dialog combos in English, we'd simply store the textbank id number then retrieve the value programmatically? Actually, it's more likely that you would be able to just store a single index and generate all possible options based on the mask value. Two more things. One, when the definitions are filled out more, I want the actor names to be put in the same xml file. Two, the actor def editor is getting closer to being done. Need to create some sort of gui to easily add in the data that will fill the combobox options.

I feel like the devs would have worked with tools that measured things in meters... whatever the hell a meter is suppose to be in virtual space

Read up more on XML with C# and found out some interesting things (most of which being xsd.exe which can be used to generate classes from an XML file), and took another stab at creating an editor for the actor definitions xml file.

Did you even try to call Nintendo for help? Might be able to get back the games at least. Also you probably shouldn't have been trying to transfer games the last few days because of the whole Nintendo Id/Pokemon Bank thing in retrospect.

I have a full list of descriptions for every cutscene "stage" because of Ocarinabot's wrong warp calculator but not for normal gameplay "stages". However I believe only Hyrule Field, Kokiri Forest, and Lon Lon Ranch have normal gameplay stages that are dependent on game events rather than the standard day/night.

It looks so terrible. Not hyped at all.

meh. too early to see if this is really going to happen like they say it is.

Since this thread has been ruined, imma fix r up

[23:12] <@petrie911> http://imgur.com/WREfhA2 [23:13] <@petrie911> this is what every OoT level editor does wrong [23:19] <%mzxrules> so in that image [23:19] <%mzxrules> you tried rotating around the y axis, but the box rotated around the Z axis? [23:20] <%mzxrules> or was nintendo drunk when they coded actor rotations [23:27] <@petrie911> nah, what happens is [23:27] <@petrie911> scene navi rotates about the object's y-axis [23:27] <@petrie911> the game rotates about the y-coordinate axis [23:28] <@petrie911> all the rotations are about the coordinate axes [23:28] <@petrie911> in the game [23:42] <%mzxrules> is it that the x rotation is applied, then y, then z? [23:46] <@petrie911> yes [23:47] <@petrie911> it's worth remembering that rotations in three dimensions don't commute [23:47] <@petrie911> so there has to be an order to apply them in

This game is legit my favorite game right now. Beaten it, 1 boss fight away from beating Hero Mode, have been racing people on SpeedRunsLive.

Just got it today. Caught my first shiny at about an hour in game time (Caterpie, now a shiny Butterfree). So far the most terrible thing about it is moving your character around. I'm finding it difficult to interact with NPCS and the like, and the Rollerskates are fucking terrible for navigating hedge mazes. The weird thing is that on foot you move in "blocks" like you would in the older games, but on skates don't snap to these "blocks", almost as if skates came about much later in development.

[img=http://i.telegraph.co.uk/multimedia/archive/01828/wonder_1828455i.jpg]lets you display an image. Also, you can press the image button on the post editor.

Simple. This is the first Scene_Word outputted. *** Scene_Word = { code=24, data1=00, data2=2000068 } ***Code 24 is 0x18 in hexadecimal, which is the alternate header command. data2 holds an offset to a table of offsets to the other headers within the scene file. This matches the first few bytes in the scene file for Hyrule Field (18000000 20000068) [ZU]sceneset age =[0] [ZU]sceneset time =[FFF3] [ZU]sceneset counter=[7]This part is used to determine which alternate header to use. This calculation only occurs if the 0x18 code is encountered. sceneset age is simply the age code for link (0 for adult, 1 for child). sceneset time is not the game time, but what I think is referred to as the stage number. Because it's not 0, the sceneset counter is/was set to 7 (4 + the sceneset time's rightmost digit). sceneset counter determines which header to load. If the counter = 0, it uses the main header, else it uses the header referenced in the alternate header list at index counter-1. *** Scene_Word = { code=21, data1=0a, data2=131e } *** *** Scene_Word = { code=4, data1=01, data2=2011dd0 } *** *** Scene_Word = { code=25, data1=00, data2=0000 } *** *** Scene_Word = { code=3, data1=00, data2=2008464 } ***This is where the game starts loading data from the header it chose (offset 11D60 into the scene header file). Later on, you can see where it loads the map. http://cloudmodding.com/zelda/ Here's where it's documented. I've added a little extra to explain what maps to what. 0x800F7350 [Tble] #Scene Item Restriction Table Each scene entry is 1 word long. Table Entry Format IDXXYYZZ ID = Scene ID XX = Restriction Flags 0x01, 0x02, 0x03 Bottles 0x04, 0x08, 0x0C Unused? (a_button) 0x10, 0x20, 0x30 B Button 0x40, 0x80, 0xC0 Unused? (h_gage) YY = Restriction Flags 0x01, 0x02, 0x03 Warp Songs (c_warp) 0x04, 0x08, 0x0C Ocarina 0x10, 0x20, 0x30 Hookshot & Longshot 0x40, 0x80, 0xC0 Trade Items (c_warasibe) ZZ = Restriction Flags 0x01, 0x02, 0x03 Global (c_another, basically all other c items) 0x04, 0x08, 0x0C Din's Fire & Nayru's Love (m_magic) 0x10, 0x20, 0x30 Farore's Wind (m_wind) 0x40, 0x80, 0xC0 Sun's Song

That first link is clearly a debug printout of the game being booted... you can see some interesting things like when the game checks to see if the sram is valid *** Scene_Word = { code=24, data1=00, data2=2000068 } *** Scene_Word is the structure used in the http://wiki.spinout182.com/w/Maps_and_Scenes headers. This shows that everything between data1 and data2 is never used parameter->button_status = 0,0,10 h_gage=0, b_button=0, a_button=0, c_bottle=0 c_warasibe=0, c_hook=0, c_ocarina=0, c_warp=0 c_sunmoon=0, m_wind=1, m_magic=0, another=0 Is the button/item restrictions stuff that Cloudmax documented. Atm I don't know what h_gage is for

I'd chalk it up to Personally I see it as being more that Ocarina of Time is just a really big and complex game.