The MDI definition is accurate... Apparently it stands for Multiple document interface, but really it's just a window house, kinda like how an IDE is just a fancy text editor (because "Integrated Development Environment" is just linguistic masturbation).

As for data storage, it certainly could go in the logic tier, I was just concerned because the functionality tends to get rather large, and can be conceptually separate. In fact, even the graphic demonstrating the register system shows it somewhat separated:
http://en.wikipedia.org/wiki/File:Overview_of_a_three-tier_application_vectorVersion.svg

But you say logic tier, and then you describe the presentation tier o.O
Either way, whatever works, I just want it separate from the backend data, and figured it's usually large enough to keep it separate from anything else. I can kinda envision it as an alternative presentation tier implementation, although the logic tier would be mostly unused for that.

Updated with better terminology. Replaced "System" with "Loader", as per its defined job. Replaced "Object" with "Component", Java's name for widgets. Added "Node" component, e.g. nodes in a tree, for more proper use when referring to tree nodes.

I like the idea so far. My biggest concern is that it's difficult to visualize/maintain a 3-tier architecture. I feel very strongly that the 3-tier should be made an integral part of the spec.

For instance, the top-most tier of our Mesh resource would be the MDI window for editing it. The lowest tier would be the data backend of the mesh, and would not contain any special functionality aside from basic necessities for the format. The middle tier would contain all the functionality, like, say, rendering it. Perhaps a separate middle tier would provide the reading/writing of the data.

I like the ideas put forward here, and I can see we're very much on a similar page as far as formats go. I'd like to point out that we also don't have to restrict ourselves to the existing formats. Considering the flaws of the common formats, it might be a good idea to create a new format which would be easier to parse while still keeping the text fairly user-friendly for a text editor. Especially now that we have experience on what we *want* to parse (as opposed to what we *should* parse) so that we can design a parser that isn't just totally hacked together.

As for extensions in EDL, it's a noble idea, but it could be problematic when we consider that LGM itself doesn't recognize EDL - that's entirely ENIGMA-side. One of the handy things about LGM is that you can clip it from ENIGMA, put it by itself, and still run it, making it a compiler-less IDE (without Syntax Checking).

I agree with the zip directory idea.
I also think textual resource information is a good idea especially earning it the "ogf" extension.

I'm concerned:
1) About using eYaml for the textual resource information. This is basically just a growing distaste for Yaml. I was hesitant about it at first, but went with it because it was basically the best format I could find for the job (which isn't saying much). Now that I've seen it get hacked to bits in the eYaml spec and the parsers that parse it in such a hacked up way that I wonder how it even sticks together... I can't help but look at eYaml with the same kind of feeling I get when I look at a clunker car that was assembled with odds and ends in my garage. Fortunately at this point in the project eYaml is a module that serves as a translation between the yaml file and the areas that use it. It could very easily be replaced and probably even interchanged with a XML module or any other module.

2) Binary support? Text is all well and grand, but some projects get massive, even after being zipped, and having everything in a text format... Just tell me what your plans are for binary support, and I'll be happy.

Not to mention, different behaviors each run if they aren't in perfect parallel sync.

I'm also in favor of . especially for consistency. It's also the way Java does it.

After looking it over, it appears that the textfield does not allow you to type the space character, and attempting to add a space to the tree node will cause the space to be removed once editing has finished. This behavior is appropriate. However the behavior of clearing the name entirely because [a loaded game contained a resource with a space] is completely inappropriate and should be fixed as soon as I get a chance.

PatternSyntaxException will be corrected in the next revision. Thanks for the report.
Resource names should allow spaces in LGM, so the behavior you describe is not desired. I'll investigate.
Problems during game run are Josh's area. It may be a depth-related issue - e.g. it is being drawn, but something else is drawn overtop of it so you can't see it.

The (incompetent) tracker may be more appropriate for this

At this time, Josh has put fonts on the backburner - they are not directly supported, but I believe you can instead use the _from_sprite function(s) and it will show up.

Please run from the terminal and see if it outputs any kind of errors or strange output.

Also, when you say the object is not visible, *where* is the object not visible? In the LGM resource tree? In the LGM room editor? In the game when running?

In Java, normally if you want to allow something somewhere, you have it inherit from an interface which defines any methods needed for that somewhere, rather than provide an is_ method. For instance, a component which may be added to a room can inherit from the org.lateralgm.ui.swing.visuals.Visual interface, which provides a paint(Graphics g) method (Java's standard render() method).

I don't see a reason to disable motion_set while keeping move_towards_point. It seems to me that if you want to disable one, you'll want to disable the other as well (e.g. bulk removal of motion-related functions). That said, if you still wanted to disable motion_set but keep move_towards_point, you might be able to set motion_set to be private access, so that it's not visible to outside files (this might just be Java rubbing off on me)... but there's not much use in that, because the function is still there, it's just not visible anymore - in which case you might as well just keep the function and not use it. Point is, move_towards_point needs motion_set one way or the other, whether it's in a function called motion_set, or unrolled. The benefit of using motion_set is that it eliminates duplicate code.

I don't understand what you're asking. If you don't want to use a variable, don't use the variable...

As I said in the other thread, I do like the idea, and was expecting it to come sooner or later. This is especially helpful for LGM, as it's very bundled currently, making it hard to modify/extend, so this is a welcome change. I'm not a fan of luis's proposal, but it kinda gives us an idea of where to start.

We could provide official extensions which will maintain the ENIGMA license so that users don't have to worry about "boohoo, all the good stuff forces me to go open source."

This seems already pretty much compatible with LGM's existing plugin system for the most part, which is another part of my concern with Luis's suggestion - it's not revolutionary enough to change the internals of LGM yet, which is what I'd really like to do. I'm sure as it evolves that will become more readily available.

Also, luis should consider joining the IRC from time to time.