SceneNavi - A simple Ocarina of Time level editor

[xdaniel]

(was: "Interest check - simple room/scene actor editor"; original post in spoiler...)

 

Current version: SceneNavi v1.0 Beta 9b (use update function in Beta 4 or later)

 

 

Any potential bigger projects of mine will take quite a while to materialize, so here's an idea I've been toying around with yesterday and today:

 

Is there any interest in a very simple (or barebones you could say) room/scene actor editor? Meaning, it would only work on uncompressed OoT ROMs (not Yaz0-compressed, not Majora), it should work with custom maps unlike ex. SayakaGL, it would only rudimentally render rooms (untextured, etc), it would only allow modification of room and scene actors, and maybe loaded objects, and, the most important aspect, to simplify usage it would use the XML actor definition stuff I've been working on for Sorata, thus it would abstract away and break down actor variables and flags for which a XML definition exists.

 

Here's a (*cough*) badly (*cough*) paint-shop-pro'ed example of how I'm imagining it:

 

 

This is far simpler to do than, say, Sorata itself, so the basic program could be a reality in a few days (ex. got lots of code I can reuse). However, it'll still be work I could spend on something else, so this'll only make sense to write if there's enough interest in it.

 

It would mean no more fiddling around with bits in variables or rotations that really signify flags, etc., at least for the actors supported - treasure chests and switches among them already! -, more actor definitions can be added by anyone with just a tiny bit of programming knowledge - nothing major, I'd reckon if you know what an UInt16 or a ComboBox are, you can do it, don't even need to recompile the program; I suppose I could also write a tutorial for that? -, and for every other actor, the program could still fall back onto the usual type/position/rotation/variable data.

 

So, anyone interested?

 

Edited September 21, 2014 by xdaniel

[Three_Pendants]

Yes, indeed Xdaniel. This lack of scene editing has made that essential part of modding more of a burden than a blessing with the older tools having, then losing, that functionality.

 

Though if I may ask one more thing. Could this also have a group changer? This paired with Sayaka would make it a quintessential, all in one, easy modding tool.

[Mellow]

I am very interested in this. It would be a lot of help for everyone, beginners and experienced alike.

[spinout]

If well coded you could just keep throwing in little features, but the idea of starting out with something barebones is a very good idea.

[haddockd]

*eyes xDan*

 

Are you doing what I think youre doing?

[Spire]

Holy mackerel. I'm on board mang.

[xdaniel]

*eyes xDan*

 

Are you doing what I think youre doing?

 

Erm... if it's that I'm thinking about starting something new when I should be working on "something else", you're right? I'm thinking about and working on the other thing, too, so don't worry

 

Also, thanks for the feedback so far, I guess I'll go ahead with this then. I'll see about posting some non-shopped screenshots over the weekend, and the program itself hopefully soon after.

 

EDIT: Not a mockup, but -very early- WIP:

 

 

[haddockd]

Actually I was referring to the ability of the reuse of something like this to other things.

[xdaniel]

Actually I was referring to the ability of the reuse of something like this to other things.

 

Ahh, yeah, this will be reusable for sure.

 

EDIT:

 

 

EDIT 2:

 

Documenting the definitions: http://magicstone.de/dzd/random/xmlactor/

Edited May 26, 2013 by xdaniel

[xdaniel]

WIP build: http://magicstone.de/dzd/random/SceneNavi-v09-wip.rar
 
And as it says in the program...
 
Remember: Bug reports and feedback in general are welcome and encouraged!

 

[giadrosich]

First impressions from me: It doesn't LAG. I have so much lag in Sayaka, this is beautiful. I'll have to dig into a bit further to really give better feedback and/or report bugs, but I'm extremely happy about the no-lag situation. Listing the actors and being able to switch around the contents of a chest easily without looking at an actor list, I love it.

[Three_Pendants]

Works excellently as far as I can tell. The scene transitions and spawn points look great.

 

The tool gives off a very smooth reliable vibe already.

[petrie911]

Would it be possible to have it work with individual room files rather than the whole ROM? I find it preferable to work with those.

 

Also, I don't suppose you could implement collision type editing, could you? It'd be quite useful.

[xdaniel]

Would it be possible to have it work with individual room files rather than the whole ROM? I find it preferable to work with those.Also, I don't suppose you could implement collision type editing, could you? It'd be quite useful.

 

It'll be a bit of work, but I think I can add support for individual files. Not sure about collision types right away, I'll need to look into them again; been a while since messing with them for SO. Don't think they'll be too difficult to implement, tho.

 

[Airikita]

Yes, if you make it work for individual rooms, that would be better. I like the feel of it being close to UoT.

 

Also, is it possible you can get textures to work? Sometimes I find the details of the textures showing help with where I place things for accuracy.

 

No pressure, and it's not like it's absolutely necessary, just a question.

[xdaniel]

I specifically did not want to support textures or anything fancy like that, to keep the program simple for both myself and the users... although by this point it might be more of a question of "when" rather than "if".

 

That said, additional features of any kind, like textures and anything related (combiner emulation, etc.) are not a priority and might come later, when the important features - namely actor editing and its XML definition system - are proven to work 100% correctly.

 

[Airikita]

I specifically did not want to support textures or anything fancy like that, to keep the program simple for both myself and the users... although by this point it might be more of a question of "when" rather than "if".

 

That said, additional features of any kind, like textures and anything related (combiner emulation, etc.) are not a priority and might come later, when the important features - namely actor editing and its XML definition system - are proven to work 100% correctly.

Well exactly, and I was just curious. I will keep this program on my list for later, I will need to know if it doesn't corrupt roms like UoT first though. All in good time.

[giadrosich]

Can you like...mesh together the ZLE2 collision/landscape editing and an interface like UoT? I would really like a program that does what Utility can do, but that program doesn't work on my computer. It crashes all the time. I think everyone who starts a mod wants to edit the landscape to be really awesome, but the only two tools I know for it is ZLE2 (which I'm trying to put together a tutorial series on), and UoT (which crashes and thus I can't put a tutorial out on).

 

If anyone knows other tools to edit the landscape, that would be appreciative.

[spinout]

ZLE 1 also edits landscapes. It's where collision_fixer.exe comes from.

 

xdaniel, some simple features missing from current editors is exit modification and entrance index modification (start pos : room # list)

[xdaniel]

I'm supposedly taking a damn break from hacking, yet what do I do?

 

I hate this game, I hate wanting to program, I hate myself! <.<

 

(Also: landscape and collision model editing is unlikely, better F3DEX2 simulation is more likely, collision type and exit and entrance editing is possible but not decided.)

 

(Oh, and no rapid progress. I'm doing this when I feel like it, instead of forcing myself to code.)

 

 

 

Edited June 8, 2013 by xdaniel

[Conker]

xdan, that's awesome. <3

[xdaniel]

The things in .NET I didn't even know about...

 

 

...the DataGridView is awesome.

[Three_Pendants]

That data_gridview to more easily find a specific group does seem like a really neat implementation! I have a quick question though, do you draw anywhere for the file names in the ROM or are they set up elsewhere? If so may I suggest that the player be able to swith between raw file names (as they can sometimes be misleading, see Torch32) and the actual in-game representation? I changed the wiki page of Complete Actor Listing to include Representations so there's no hassle of double checking for the modder.

[xdaniel]

If the program detects a filename table, it'll use the names from that for various things. There is, however, a system in place to "translate" pairs of start and end addresses in the ROM, which overrides the internal filenames and is currently used for the scene listing, and "dictionaries" for the scene files of OoT NTSC v1.0 and the Debug ROM are included - see ReleaseXMLGameDataNZLEFAddressTranslations.xml in the WIP build from before. That can easily be extended to cover anything else where exact start and end addresses are known, like ex. objects... which I just did.

 

This...

<Entry StartAddress="0x011C1000" EndAddress="0x011CF800" Description="Stalfos"></Entry><Entry StartAddress="0x01206000" EndAddress="0x012099C0" Description="Deku Baba"></Entry>

...becomes this...

 

 

Actors on the other hand... Well, they are already covered by the actor definition system - the thing that generates the simplified user interface around an actor's properties, check out ex. switches and treasure chests in the WIP - but that means that each actor requires a definition file, from which its human-readable name is read. I mean, I could just make 400 copies of the generic number/position/rotation/variable definition, just with a different name in each, but... I'm not sure how I'd feel about this - I think that would defeat the purpose of the system.

[Three_Pendants]

Oh, that is rather nifty. I'll have to take a look at that for personalized use. Thanks for that bit of information XDaniel.