SceneNavi - A simple Ocarina of Time level editor

[mzxrules]

The shift IS the calculation, and your solution isn't exactly a clean one. Sanity has nothing to do with it, it's a simple matter of how the data is displayed

Explain one scenario where the user would prefer to edit the masked out value directly, rather than the proper bit field value.

 

you're nitpicking something that's not exactly an easy thing to have a good blanket solution for, how exactly do you expect him to handle something like that when it's determined by the actor definition?

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.

[Airikita]

I would rather be able to edit the binary as an option myself... I'm nerdy/geeky enough to know what to do. There are different actors that use different masks, and frankly I think I'd rather have binary mask editing as an optional feature.

 

I'm sure xDan will think of something for the other part.

[xdaniel]

Airikita: Because the filename table maps one-to-one to the DMA table, I have to use the latter to determine filenames, so if you've not modified that, you won't get the proper name displayed for your file. Also, any particular reason why you're still using Beta 2? That's extremely out of date... I really shouldn't even take bug reports for builds this old (even though this particular behavior hasn't changed since)

 

mzxrules: Is automatically detecting the shift count reliable under all circumstances (i.e. any potential mask value, etc)? If so, I could do it this way, instead of adding a MaskShift attribute or somesuch. Btw, you've seen my previous post, ex. about the Usage attribute? I'll get to more feedback to your, uh, feedback about the system later.

[john_smith_account]

The shift IS the calculation, and your solution isn't exactly a clean one. Sanity has nothing to do with it, it's a simple matter of how the data is displayed, you're nitpicking something that's not exactly an easy thing to have a good blanket solution for, how exactly do you expect him to handle something like that when

I agree, but I'm referring to the texture errors present in the final release of Sharp Ocarina.

 

I demostarted the problem and solution, but no ever enacted it.

 

 

I would rather be able to edit the binary as an option myself... I'm nerdy/geeky enough to know what to do. There are different actors that use different masks, and frankly I think I'd rather have binary mask editing as an optional feature.

 

I'm sure xDan will think of something for the other part.

 

I also concure.  Even if you do ignore my posts.

 

 

Airikita: Because the filename table maps one-to-one to the DMA table, I have to use the latter to determine filenames, so if you've not modified that, you won't get the proper name displayed for your file. Also, any particular reason why you're still using Beta 2? That's extremely out of date... I really shouldn't even take bug reports for builds this old (even though this particular behavior hasn't changed since)

 

mzxrules: Is automatically detecting the shift count reliable under all circumstances (i.e. any potential mask value, etc)? If so, I could do it this way, instead of adding a MaskShift attribute or somesuch. Btw, you've seen my previous post, ex. about the Usage attribute? I'll get to more feedback to your, uh, feedback about the system later.

 

That is no excuse, I still have a working hardware compatible copy of the Debug ROM that proves if you're patient enough the error(s) can be repaired automaticly.

[Airikita]

Airikita: Because the filename table maps one-to-one to the DMA table, I have to use the latter to determine filenames, so if you've not modified that, you won't get the proper name displayed for your file. Also, any particular reason why you're still using Beta 2? That's extremely out of date... I really shouldn't even take bug reports for builds this old (even though this particular behavior hasn't changed since)

 

mzxrules: Is automatically detecting the shift count reliable under all circumstances (i.e. any potential mask value, etc)? If so, I could do it this way, instead of adding a MaskShift attribute or somesuch. Btw, you've seen my previous post, ex. about the Usage attribute? I'll get to more feedback to your, uh, feedback about the system later.

I figured as much.... even so, the original besitu file wasn't changed... so, uh... ???

 

 

I also concure.  Even if you do ignore my posts.

Uh? I just usually don't have a response to everything... anyways, whatever the solution to this bug will be appreciated as long as it works. Mzxrules made the situation clearer to me. The mask is still staying at 1111 1100 without changing to 0011 1111 to shift the bits in order to display the proper hex value.

 

Still, an option for advanced binary editing would solve some of these problems. Could be something you can check off, like "Advanced Editing".

[Antidote]

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.

Then post your solution, just gesticulating and finger pointing does nothing, provide a working example for your solution. Even if it's just a code snippet.

You can't just assume that you have a concrete solution.

[!Tommy]

Dan, I seem to have a problem opening anything in SceneNavi now. I updated to the latest beta 8 and even attempting to open a clean, unedited debug ROM produced an error. It says,

 

 

Any solutions or ideas on this?

[Antidote]

Delete your actor definitions and replace them with the ones in the archive, if that doesn't work, re-download and try again.

If not, there may be a legitimate bug in the ActorDefinition parser.

[!Tommy]

Thanks, Antidote! I just redownloaded the program and put it in a brand new folder and now it works like a charm.

[Antidote]

You're welcome, glad it worked out for you.

[Antidote]

Got an exception when attempting to pick a collision triangle From what i can tell it's in Mono, but there may be something fishy in your picking code as well

X11 Error encountered: 
  Error: BadAlloc (insufficient resources for operation)
  Request:     53 (0)
  Resource ID: 0x8C002FC
  Serial:      11364
  Hwnd:        Hwnd, Mapped:True ClientWindow:0x8C002FC, WholeWindow:0x8C002FB, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x8C002EC, WholeWindow:0x8C002EB, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x8C002EA, WholeWindow:0x8C002E9, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x8C0001D, WholeWindow:0x8C0001C, Zombie=False, Parent:[Hwnd, Mapped:True ClientWindow:0x8C00016, WholeWindow:0x8C00015, Zombie=False, Parent:[<null>]]]]]
  Control:     System.Windows.Forms.Button, Text: &Jump to Polygon Type   at System.Environment.get_StackTrace()
   at System.Windows.Forms.XplatUIX11.HandleError(IntPtr display, XErrorEvent ByRef error_event)
   at System.Drawing.GDIPlus.GdipCreateFromXDrawable_linux(IntPtr , IntPtr , IntPtr ByRef )
   at System.Drawing.Graphics.FromXDrawable(IntPtr drawable, IntPtr display)
   at System.Drawing.Graphics.FromHwnd(IntPtr hwnd)
   at System.Windows.Forms.XplatUIX11.GetOffscreenGraphics(System.Object offscreen_drawable)
   at System.Windows.Forms.XplatUI.GetOffscreenGraphics(System.Object offscreen_drawable)
   at System.Windows.Forms.Control+DoubleBuffer.Start(System.Windows.Forms.PaintEventArgs pe)
   at System.Windows.Forms.Control.WmPaint(Message ByRef m)
   at System.Windows.Forms.Control.WndProc(Message ByRef m)
   at System.Windows.Forms.ButtonBase.WndProc(Message ByRef m)
   at System.Windows.Forms.Button.WndProc(Message ByRef m)
   at System.Windows.Forms.Control+ControlWindowTarget.OnMessage(Message ByRef m)
   at System.Windows.Forms.Control+ControlNativeWindow.WndProc(Message ByRef m)
   at System.Windows.Forms.NativeWindow.WndProc(IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam)
   at System.Windows.Forms.XplatUIX11.DispatchMessage(MSG ByRef msg)
   at System.Windows.Forms.XplatUI.DispatchMessage(MSG ByRef msg)
   at System.Windows.Forms.Application.RunLoop(Boolean Modal, System.Windows.Forms.ApplicationContext context)
   at System.Windows.Forms.Application.Run(System.Windows.Forms.ApplicationContext context)
   at System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm)
   at SceneNavi.Program.Main()
 
X11 Error encountered: 
  Error: BadDrawable (invalid Pixmap or Window parameter)
  Request:     14 (0)
  Resource ID: 0x8C00316
  Serial:      11365
  Hwnd:        <null>
  Control:     <null>   at System.Environment.get_StackTrace()
   at System.Windows.Forms.XplatUIX11.HandleError(IntPtr display, XErrorEvent ByRef error_event)
   at System.Drawing.GDIPlus.GdipCreateFromXDrawable_linux(IntPtr , IntPtr , IntPtr ByRef )
   at System.Drawing.Graphics.FromXDrawable(IntPtr drawable, IntPtr display)
   at System.Drawing.Graphics.FromHwnd(IntPtr hwnd)
   at System.Windows.Forms.XplatUIX11.GetOffscreenGraphics(System.Object offscreen_drawable)
   at System.Windows.Forms.XplatUI.GetOffscreenGraphics(System.Object offscreen_drawable)
   at System.Windows.Forms.Control+DoubleBuffer.Start(System.Windows.Forms.PaintEventArgs pe)
   at System.Windows.Forms.Control.WmPaint(Message ByRef m)
   at System.Windows.Forms.Control.WndProc(Message ByRef m)
   at System.Windows.Forms.ButtonBase.WndProc(Message ByRef m)
   at System.Windows.Forms.Button.WndProc(Message ByRef m)
   at System.Windows.Forms.Control+ControlWindowTarget.OnMessage(Message ByRef m)
   at System.Windows.Forms.Control+ControlNativeWindow.WndProc(Message ByRef m)
   at System.Windows.Forms.NativeWindow.WndProc(IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam)
   at System.Windows.Forms.XplatUIX11.DispatchMessage(MSG ByRef msg)
   at System.Windows.Forms.XplatUI.DispatchMessage(MSG ByRef msg)
   at System.Windows.Forms.Application.RunLoop(Boolean Modal, System.Windows.Forms.ApplicationContext context)
   at System.Windows.Forms.Application.Run(System.Windows.Forms.ApplicationContext context)
   at System.Windows.Forms.Application.Run(System.Windows.Forms.Form mainForm)
   at SceneNavi.Program.Main()
 
System.Exception: Generic Error [GDI+ status: GenericError]
  at System.Drawing.GDIPlus.CheckStatus (Status status) [0x00000] in <filename unknown>:0 
  at System.Drawing.Graphics.FillRectangle (System.Drawing.Brush brush, Int32 x, Int32 y, Int32 width, Int32 height) [0x00000] in <filename unknown>:0 
  at System.Drawing.Graphics.FillRectangle (System.Drawing.Brush brush, Rectangle rect) [0x00000] in <filename unknown>:0 
  at (wrapper remoting-invoke-with-check) System.Drawing.Graphics:FillRectangle (System.Drawing.Brush,System.Drawing.Rectangle)
  at System.Windows.Forms.Control.PaintControlBackground (System.Windows.Forms.PaintEventArgs pevent) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.Control.OnPaintBackground (System.Windows.Forms.PaintEventArgs pevent) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.ButtonBase.OnPaintBackgroundInternal (System.Windows.Forms.PaintEventArgs e) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.Control.WmPaint (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.Control.WndProc (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.ButtonBase.WndProc (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.Button.WndProc (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.Control+ControlWindowTarget.OnMessage (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.Control+ControlNativeWindow.WndProc (System.Windows.Forms.Message& m) [0x00000] in <filename unknown>:0 
  at System.Windows.Forms.NativeWindow.WndProc (IntPtr hWnd, Msg msg, IntPtr wParam, IntPtr lParam) [0x00000] in <filename unknown>:0 

[mzxrules]

mzxrules: Is automatically detecting the shift count reliable under all circumstances (i.e. any potential mask value, etc)? If so, I could do it this way, instead of adding a MaskShift attribute or somesuch. Btw, you've seen my previous post, ex. about the Usage attribute? I'll get to more feedback to your, uh, feedback about the system later.

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

[xdaniel]

Oh man, so many posts...

 

I agree, but I'm referring to the texture errors present in the final release of Sharp Ocarina.

 

I demostarted the problem and solution, but no ever enacted it.

[...] 

That is no excuse, I still have a working hardware compatible copy of the Debug ROM that proves if you're patient enough the error(s) can be repaired automaticly.

I might be misremembering here, but you don't mean that header setting or whatever it was you said was responsible for the errors, right...? Because that wasn't it. Mind pointing me to your solution again, now that I actually am working on a converter again?

 

I figured as much.... even so, the original besitu file wasn't changed... so, uh... ???

The location of your Besitu file(s) changed. SceneNavi reads in the DMA table, the filename table, then, when it's reading the scene table, for each entry there it tries to find an entry in the DMA table with the same scene start address, and if it finds one, it uses the filename from that as the scene name. The scene table entry for your Besitu points to a different address than the original Besitu entry in the DMA table, so there's no matching DMA table entry anymore, so it can't fetch a filename from there.

 

Got an exception when attempting to pick a collision triangle From what i can tell it's in Mono, but there may be something fishy in your picking code as well

My picking code kinda sucks, so there's definitely the chance for bugs to be in there. I'll look at my code again, double-check if it's sane, then try to hunt around for potentially related Mono bugs...

 

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).

 

[...]

Hmm, might be an idea to do both, calculate the shift count using your function by default, but allow an optional attribute in the definition to override it? Just to be safe, I guess.

 

Uh, hope I didn't forget anyone/anything I wanted to comment on right now...

[petrie911]

I'm not sure about the general idea behind editing of masked values, but looking at the screenshot mzx posted, I see two things wrong.

--That switch flag, as well as any other switch flag entry box, should have a value from 00 to 3F. No exceptions.

--Does that timer box support decimal entry? If not, it needs to be changed so it does.

 

Anyways, some things I noticed while using the editor.

 

General things

--Undo feature on object movement. How hard is to implement?

--How do I select vertices? It's very important to know the level of floors for proper positioning.

 

Individual Scene editing things
--When editing doors, allow manual input of room number. Otherwise it doesn't work well with individual scene editing.
--If there's only 1 object set in the room, load it by default. I can't think of a reason not to do this.
--The dialog box for opening rooms and scenes should filter by file type. That is, the box asking for scenes should only show *.zscene and the box asking for rooms should only ask for *.zmap.

[Antidote]

Depending on how SceneNavi is structured, it shouldn't be too difficult to implement an undo system. All an undo system is, is basically a bread crumb system. You store a previous state, then when you need it you simply put it back. However if the program isn't structured properly it can be a huge headache.

[Jason777]

Pushing and popping of a stack would be good to use for an undo system.

[Antidote]

Using a queue is usually the preferred method, but a stack works fine as well.

[mzxrules]

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>

[Antidote]

I'm guessing an off by one, but C# has foreach.

[xdaniel]

Why doesn't SceneNavi display the last "item" in a combo box?

I assume that's actually for actor 0x0169 and not 0x015F (considering the type attribute), but regardless, that definition is working fine for me in Beta 8 and Beta 9 WIP:

 

[Antidote]

Once SceneNavi is out of beta, you should make a transifex project for localization.

It's free for open source projects, I have one for Sakura Suite.

[mzxrules]

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

[Antidote]

Is that seam visible in game? Or is just an odd rendering glitch in SN?

[xdaniel]

Anyways, some things I noticed while using the editor.

 

General things

--Undo feature on object movement. How hard is to implement?

--How do I select vertices? It's very important to know the level of floors for proper positioning.

 

Individual Scene editing things

--When editing doors, allow manual input of room number. Otherwise it doesn't work well with individual scene editing.

--If there's only 1 object set in the room, load it by default. I can't think of a reason not to do this.

--The dialog box for opening rooms and scenes should filter by file type. That is, the box asking for scenes should only show *.zscene and the box asking for rooms should only ask for *.zmap.

 

General:

• I'm not sure if SceneNavi's structure would allow for undo/redo functionality. I'll need to take a closer look at this.
• First your select a triangle in "static object mode", then you can click on one of its vertices. However, that currently only allows changing its color and doesn't ex. show the vertex's coordinate, which is what you'd need, I assume. I hadn't thought about that this might be needed before, so I'll have to implement that for the next version.

Individual scenes:

• Yeah, I didn't think of individual scenes when adding the room drop-down a while ago. Will need to look into this...
• Will do that for individual file mode, makes sense there, yeah.
• .zscene and .zmap I'm a bit torn about. One on hand, they're the de facto standard, on the other, .zmap should be .zroom for accuracy's sake and some extractors don't adhere to this convention (i.e. OZMAV2 doesn't assign extensions). What's everyone's opinion on this?

---

As for localization, I've dabbled in that before but haven't really worked in that direction seriously. Will need to look into that more, as well as Transifex, etc.

 

As for that seam in the Spirit Temple boss screenshot, it's visible in-game too, just like a few in other places (ex. Deku Tree):

 

 

---

In other news, Nini-based configuration storage will be in Beta 9. It's still using XML files for storage, now stored at (on ex. Windows 7) "C:\Users\<username>\AppData\Roaming\SceneNavi\". Well, technically "[Environment.SpecialFolder.ApplicationData]\[system.Windows.Forms.Application.ProductName]\" and thus not hard-coded, so as long as Mono has those implemented properly, the configuration path stuff should work fine. And as long as Nini itself works right in Mono, configuration storage in general should finally work right under Linux.

 

Example:

 

C:\Users\Daniel\AppData\Roaming\SceneNavi\Main.xml:

<Nini>
  <Section Name="Main">
    <Key Name="RenderRoomActors" Value="True" />
    <Key Name="RenderSpawnPoints" Value="True" />
    <Key Name="LastToolMode" Value="MoveableObjs" />
    <Key Name="CombinerType" Value="GLSLCombiner" />
    <Key Name="LastROM" Value="D:\ROMs\N64\mqdbg_ORG - Kopie.z64" />
    <Key Name="OGLVSync" Value="False" />
    <Key Name="RenderCollision" Value="False" />
    <Key Name="LastSceneFile" Value="E:\Dokumente und Einstellungen\Daniel\Eigene Dateien\Programming\OZMAV2\extr\Ocarina of Time Master Quest (E) [Debug Version]\ydan_scene" />
    <Key Name="LastRoomFile" Value="E:\Dokumente und Einstellungen\Daniel\Eigene Dateien\Programming\OZMAV2\extr\Ocarina of Time Master Quest (E) [Debug Version]\ydan_room_0" />
  </Section>
</Nini>

 

[Antidote]

That should work wonderfully, how much effort did it take to move it to Nini?

And that seam is kinda hard to miss, Nintendo must not of thought it was a big deal but it's pretty obvious.

 

I think .zroom makes the most sense.