dMZX Forums: Ability to Alter the Order of Boards -> Archived Requests -> Tracker

Fairly self-explanatory, this has been suggested several times in the past.

The favored approach seems to be to separate the internal order of the boards from the display order of the boards. This would require a world format change, but would allow boards to be reordered without having to scan through the boards and reassign passages.

It does not necessarily require a format change if you use an external file which contains settings used in the editor (such as display list reordering, settings of new boards, and those kind of stuff).

Updating status to: Confirmed
Updating severity to: 1 - Low
Updating version to: GIT


Changing the world format isn't such a big deal any more -- I changed it recently to fix some silly field limitations, and we just have to maintain downver.exe to allow people to go back if the new version doesn't pan out.

OTOH, it might not be necessary here. I think updating the entire world's references on board re-order is probably the way to go, even if it means this feature takes a little longer to implement.

I'll approve this one.

--ajs.

Updating version to: 2.84b

zzo may be on the mark here. Storing this in the world format would require a format change (not necessarily a bad thing and accounted for in the EBML spec, but would push it off until 2.85), there's already plans for an editor metadata EBML file for other similar things, and refactoring board references will ruin anything like "put c?? stairs pXX", which while could be fixed by manually scanning every line of robotic, would really suck trying to detect in DBC -- not to mention (please never do this) setting BOARD_ID to one of these types and intending it to be used. Do we want to introduce an editor EBML before a total format switch?

(Re-wrote this after some investigation)

Looks like the best fit would be libebml2 because that's written in C and has a C API. There's an example of a parser https://matroska.svn...test/ebmltree.c

I think this is a good choice for a world format which tools might want to be interoperable with (and downver, and checkres, etc..) but the editor settings might be less compelling. There's no doubt that using EBML for a couple of editor features will initially consume more of your time vs just fwriting some buffers, but it could be a nice warm-up to doing the world file.

--ajs.

This post has been edited by ajs: 05 June 2012 - 04:16 PM

Updating version to: 2.84c

Fizz

Well, after having looked at how Import World behaves and considering how unlikely it is that Robotic has exact-ID board references, I think I'll go with what ajs suggested. The things I brought up have probably never happened in the history of MZX, or at least recently enough that they'd screw anyone up. There are other things much more suited to the editor file.

Updating version to: 2.84d

Probably not going to get to this in the timeframe I want 2.84c out in. Oh well!!!

Updating status to: Implemented
Updating version to: 2.84c
Issue fixed in: GIT

jk lol

GIT 0b01429

Moving to: Archived Requests