Did a crapton of work today managing metadata and basically external memory storage.
Basically, this should free up a path to make a freespace manager (when I get tired my puns get really bad).
But seriously, the idea is, then we can keep a list of freespace in the hub metadata, and allow the various editormodules to mark areas as free, or for the user to manually mark it.
[2/13/15, 11:34:30 AM] Crazy Colorz: Idea for metadata or something:
[2/13/15, 11:34:43 AM] Crazy Colorz: I’ll have an on-focus event for the windows to reread from metadata… I’ll also make quickWriting a thing
[2/13/15, 11:35:00 AM] Crazy Colorz: That values write speed over space.
[2/13/15, 11:35:16 AM] Crazy Colorz: I.e. basically, just repoint the main table, see if it fits in the existing space, and if not, just append to the end with no cleanup.
In fact, I have never used the freespace management function of FEA,because I think the most reliable tool for rom management is a hex editor and a note. After all ,work such as to copy, move, delete or repoint data manually is not too hard.
As for the weird concurrent/or async read/write issues, I recommend always keep your hex editor like UE opening your rom during any work, for it can inform you reload the rom whenever the rom is moified by any program so you can always notice any changes to your rom in that way.
Good luck to everyone working on it~
It’s not so much the hex editor or tools like EA that’s an issue; it’s more of FEditor or Nightmare which have to keep the rom loaded in their RAM.
Doesn’t help that FEditor’s free space management is a GUI nightmare.
Speaking of Nightmare since the integration is in progress I was thinking about perhaps a few ways to improve it further.
So maybe like, a default nightmare mode, and from a menu you can change to edit nightmare mode, that edits the lib directory.
Oh god fucking PLEASE make this a thing. Well, to be honest, you could just put all your modules in one folder and the text files that are a part of the modules would be grouped together but man that folder would be a clusterfuck.
I like the modules subdivided into folders, but the library is a much needed improvement.
Question: Are we content with breaking backwards compatibility for the FEES2k15PDE modules?
One additional idea would be that we could add hover-over help descriptions to the entry labels, that’d be just placed into the formatting like so:
Character Name
'Corresponds to an index in the text array. Used in the stat screen and various menus.'
0
2
NEHU
NULL
Kind of like the R-button descriptions
Yeah, they’d be a big part of Nightmare but I think it could be extended to the rest of the interface as well perhaps.
http://i.imgur.com/YEQN291.png
Something like this, to use FEditor’s portrait interface, where it’d call that name in the text box from the library and you could edit names in the program itself. And then perhaps the text editor could recognize portrait.txt values in its load face code parameters, so that you could write [OpenMidLeft][LoadFace][Eliwood Sad] instead of [0x003].
Metadata.
I guess I’ll make a hub function for setData(id, w/e)
Edit: Or just have like
PortraitDefinitionsMetadata.meta
So we could have the nightmare modules instead reference the lists in metadata and assign a hexadecimal count to it? The idea is that it’d become a universal labeling system, with different metadata called (I suppose what currently are .txt files in the nightmare packages would be metaized).
EDIT: Random thought any way to add a spellcheck function to the text editor? It could even use the metadata to recognize character names and terms used by the game for an ignore list of things to flag so that it actually only catches spelling errors.
If you use a system similar to EA’s and how it can assign multiple names to the same hex byte (Like 0x01 can be not only Lyn Lord, but also Lyn Character, Iron Sword, etc) then it would basically always substitute that hex value for that name. That’s what you mean, right Arch?
Basically, yeah. But like in nightmare, it’d know which list to use in order to create dropdown lists and text inputs in the interface. Like if EA’s disassembly knew that the first parameter in the UNIT code was the unitID, it could disassemble according to those definitions and spit out UNIT Lyn_t LynLord etc etc.
The metadata would be utilized throughout the various other editors too, is what I’d envision.
Portrait
'Corresponds to a value in the portrait array. Displayed in the stat screen.'
6
2
NDHU
PortraitList.meta
That same metadata would be referenced in that Portrait Editor mockup above, and in the specific portrait value parameter of the [LoadFace] code. We wouldn’t want conflicting labels to cause problems, so they’re kept within specific contexts.
Probably a stupid question, but what’s the difference between FEditor Suite and NM3? Isn’t all of this what NM3 was supposed to be? I mean, it actually sounds better than NM3 but maybe that’s me.
expanding on something someone else mentioned, how about the ability to rename all the txt files for nightmare through feed2015pde? so that instead of having to open up the text and change “0x01 Eliwood” into “0x01 Henrick” you can just do it through feditor–might save a bit of time for everyone
Basically, you know the pointer feature that Hex added in Nightmare 2? Think taking that and running with it, so that instead of just having a linear list of ‘components’, you describe an entire tree/graph of stuff, using a more sophisticated language. Also, it rips out the data and gives you nicely formatted JSON dumps that highlight the structure of the ROM data, which you can then edit and burn back in, in a freespace-aware way. Then you can make diffs of the changes to the JSON files, and zip them up with a script, and that’s your “patch”.
That’s the dream for NM3, anyway. It’s more or less shelved now while I see what we can accomplish with the current plans for tools.
That’s basically what I’m suggesting. It’d be neat (I dunno how wizardry works though), if dropdown lists could have button next to the list arrow with a pencil icon, click it and the dropdown field becomes a text input (and the pencil becomes a check mark to save the edit and revert to dropdown list). Integrate the metadata lists into the other editors too with the same setup (in the portrait editor, for example, you could use the dropdown functionality to find the portraits by name instead of by the array ID input).
the specifics of the implementation aren’t really important
things like GUI mockups and requested feature lists are honestly far more useful, as a dev.
I’d like to point out that is somewhat wrong. For example, assume you want to edit a character’s name. Imagine you had to choose between pressing a button that says “Edit name”, typing in the name, and pressing Enter, vs an implementation of “Edit name”, followed by an “Are you sure?” yes/no prompt, then you type in the name, then it asks “Are you sure you want to edit the name?”. Which would you prefer, the first or second?
In that case, it adds two extra steps of annoyance. Making sure it’s as streamlined as possible is a fairly important step. Unless you just meant it’s not important to focus on implementation just yet and save it for the future?
he means “tell us what you want, don’t worry about how hard it is to implement”