SceneNavi - A simple Ocarina of Time level editor

[xdaniel]

Back! Unclean! UNCLEAN! You damned amalgamation of Sayaka's general Ucode interpreter and Nanami's various component classes! You need some intense cleaning up before progressing beyond this point!

 

...wait, what the hell am I talking about? If anything, it's the child of an interesting yuri relationship, it should be freaking cute if the mothers are any indication... *cough*

 

 

But in all seriousness, I do need to clean the code for this up, split the main class apart, make texturing optional for those who don't want or need it, etc... Also showing off custom map support again!

[xdaniel]

Yeah, last post an hour ago, but... this is something else... so...

 

The game has a huge amount of tables, right? And at least some of them contain more than just a bunch of addresses, like the exit table, or, well, "exit list" as it's called on the wiki?

 

 

Now, I will not support editing things like the DMA, actor and object tables, which are, as mentioned, just addresses - not to mention the DMA table doesn't like being edited anyway. Also, this is all preliminary, it doesn't save yet, the interface is far from being finished, etc. Also also, tables planned to be editable are the exit table and part of the scene table (namely the area name texture offsets, and whatever the last 4 bytes are, the "camera effects" being one of them).

 

Any other tables (that fit the criteria) that you'd like to see editable from within the program?

 

[spinout]

z64tables support? I posted in the topic a quick way to check for the hack.

[wareya]

Beaut

[xdaniel]

spinout: What exact ROM is the z64tables bps patch for? Keep getting errors with my Debug ROMs, and just trying rom_update.py apparently trashes the ROM, regardless of CRC fixing (Invalid Access Violation on startup in Nemu, permanent loop in PJ64).

 

That aside, the table editing interface is taking shape; exit and scene tables are in:

 

 

 

Note the "Configuration #" column, that's what's called "camera effects" on the wiki. It's more than just camera stuff, tho, it's... "scene-specific settings" (can't think of a better term ATM) that determine RAM segment contents - semi-dynamic textures like Kakariko's windows, IIRC the lava in Dodongo's Cavern, probably even (and this is speculation!) the camera stuff itself, meaning the matrix that modifies the world view to be wobbly or shaking plus the DL commands to load it; the SetEnvColor command used for mixing Texel0 and 1 in the grass' combiner mode, too. (change Kakariko's 0x02 to the Deku Tree's 0x13 - good-bye multitexturing!)

 

I seem to remember posting about this before, but I can't remember where or when that was...

[Three_Pendants]

Wow. You turned this from a small little jack-of-all-trades into a planned Masterful piece of work in such a short time! Keep up the fantastic work!

[xdaniel]

SceneNavi v1.0 Beta 1: http://magicstone.de/dzd/random/SceneNavi-v10-beta1.rar

 

Changelog since v0.9 WIP:

• Improved Ucode interpreter and renderer (texturing, color combiner)
• Room objects and special scene objects editing
• Now scans for and reads more data tables (actor, object and exit tables)
• Data table editing (exit and scene tables, within limits)
• Improved address translation support (now works for scene, room and object names)
• More XML actor definitions and address translations
• Preliminary mouse-based actor editing (so far only selecting actors via right-click)

Todo, with no particular order or priority:

• Add z64tables support, once I get the hack working on my end
• Implement/improve mouse-based actor selection and movement
• Probably add waypoint, exit, entrance and collilsion type editing
• More and more address translations, but can't do the actor definitions alone

EDIT:

 

 

 

 

No saving for that particular feature yet. Also made some tiny improvements to the renderer; fixed some slight blending bugs (ex. grotto exit light beams) and added Texgen support for pseudo-reflective surfaces (ex. Sacred Forest Meadow weird grotto's walls, Treasure Chest Contest gold bars on shelf)

 

EDIT 2:

 

 

 

 

Optional, can be toggled from the menu.

Edited June 20, 2013 by xdaniel

[xdaniel]

So, tiny GUI question: Which order do you think would be the most "natural" for the tabs on the right?

 

As you can see from the screenshots, it's currently "Scenes" -> "Room Actors" -> "Spawn Points" -> "Transitions" -> "Objects" -> "Waypoints", which is pretty much the order in which those features were added to the program. I was wondering what everyone thinks might work better, as I kinda feel the order is a bit odd in some cases... like how Room Actors come in between the scene selection and scene-specific things like spawns. Also, where should additional things like editing exits and entrances go? Or a page for certain general things, like the BGM and skybox settings, that don't need a page for themselves?

 

[Three_Pendants]

Hmm, maybe you should add a menu called "Scene Dealings" for the more tertiary scene stuff like music, the skybox, fog, etc And I think that maybe it should then go Actors, Objects, Span Points, Waypoints. Just my thoughts on the matter.

[wareya]

that would be Metadata

[xdaniel]

Changes since Beta 1 so far:

[*]Some renderer bugfixes and improvements; blending error fixed, Texgen support added

[*]Added path waypoint support; waypoints can be edited and saved, their rendering, and them being linked by lines, can toggled from the menu

[*]Changed the tab order & added a (so far empty) metadata tab according to your suggestions

[*]Fixed - or rather worked around - a bug with multi-header scenes; caused room actor changes to not be saved, unless they were done from the last scene header

[*]New actor definition for the Kakariko carpenters

And because of that multi-header scene bugfix, I should probably post a new build in a bit...

 

 

 

[Three_Pendants]

Wow, I like this variable table choice! But at the same time is it possible to have a normal variable table as well? After all I think that there might be some variables to actors that are not completely recorded yet.

[xdaniel]

That's why I'll only add actor definitions for actors whose parameters are fully known, and it's why I can't do them all myself. But anything that does have detailed settings like that should be 100% documented... or 99%, and one of the options will be labeled as "unknown", like that one unknown bit in the switch's variable.

[Mallos31]

This is looking really awesome! I figured since you're trying to get the graphics on the edge of perfect, I should tell you the room where you get the iron boots is KINDA SCREWED THE HECK UP. The walls are all duplicated like 3 times and some of them are missing. Only from the inside though. That game is crazy.  

[xdaniel]

There being three layers of walls are correct, but they aren't rendering correctly. Still need to figure out how they work...

 

 

[xdaniel]

SceneNavi v1.0 Beta 2: http://magicstone.de/dzd/random/SceneNavi-v10-beta2.rar

 

Changes since Beta 1:

[*]Some renderer bugfixes and improvements; blending error fixed, Texgen support added [*]Added path waypoint support; waypoints can be edited and saved, their rendering, and them being linked by lines, can toggled from the menu [*]Changed the tab order according to your suggestions (new Scene Metadata tab is still empty and hidden) [*]Fixed - or rather worked around - a bug with multi-header scenes; caused room actor changes to not be saved, unless they were done from the last scene header [*]New actor definition for the Kakariko carpenters [*]Texturing and combiner emulation can now be toggled from the menu

Main reason for the build's release is fixing the multi-header scene bug mentioned above.

 

[Three_Pendants]

Looks like that nasty Scene Header bug from the previous version was fixed. I came across it as well, but was certain that you would fix it by the time of the next release. Everything's looking good. But I still must stress the possibility of adding definitions for all actors since all but... .5% are known to us now and it makes working a little bit difficult when most everything reads "Generic Actor", but looking at your .xml you handled it in such a way that every entry has to be unique, so it may not be as easy as a copy-paste job.

[Arcaith]

The unique route is far more solid though, as it gives more flexibility for entries, including perhaps custom ones later down the track.

[!Tommy]

Why is it when I go to open my mod in progress, I get an error saying Source array was not long enough. Check srcIndex and length, and the array's lower bounds. What does this mean and how can I fix it?

[xdaniel]

!Tommy: There should be a "Details" button in the error message's window; could you post the full exception text from there? Otherwise I'd have no idea where to even start looking.

 

Also, as for actor names... added XMLGameDataGenericZLActorNames.xml.

<?xml version="1.0" encoding="utf-8" ?><Table KeyType="System.UInt16" ValueType="System.String">  <Element Key="0x0000">Link / Spawn point</Element>  <Element Key="0x0002">Stalfos</Element>  <Element Key="0x0004">Shops</Element>  <Element Key="0x0007">Disintegrating Blue Flame</Element>  <Element Key="0x0008">Flame</Element>  <Element Key="0x0009">Wooden Door</Element>  <Element Key="0x000A">Treasure Chest</Element>  <Element Key="0x000B">Great Fairy</Element>  <Element Key="0x000C">Proximity Activated Firewall</Element>  <Element Key="0x000D">Poe</Element>  <Element Key="0x000E">Octorok</Element>  <Element Key="0x000F">Webbing</Element>  ...

[Three_Pendants]

Excellent. And you can supercede those with your unique entries down the line XDaniel? I wouldn't want you to have to sacrifice individuality for easier referencing and representation.

[wareya]

It would make sense just to have the unique ones override the generic ones.

[xdaniel]

I just ended up replacing the description property in the actor definitions with this file, everything else still comes from the definitions. That kinda compromised my idea of having everything that's actor-related and important for the user in one file, but it's alright. I guess it is nicer on the user this way, instead of having many "generic actors" that are actually all different.

 

[!Tommy]

@Dan: There is no details button on this error for some reason. This is what it looks like when the error comes up.

 

 

It does seem to open up a clean ROM perfectly so I'm not quite sure what the problem is here.

[xdaniel]

I changed the error handling around a bit, so you'll be able to actually get the details of an exception from the next version onward. It'll still be a bit until then tho, as I want to add a few more features beforehand; at least the Scene Metadata tab with BGM, skybox, etc. options.