ENIGMA Development Environment

At this point I'm going to have to pass this problem off to Josh and the other guys, because I'm out of ideas and they know a lot more about ENIGMA than I do. You might try joining the irc, especially while Josh is on, because you can get faster help that way.

Please update to r710.

If you are using the trunk (rather than stable/testing):
* Please also do not update to a later revision past r710 until stated otherwise.
* If you have accidentally updated past r710 (e.g. to latest revision), please revert to r710.

Freeing up a resource type I'd imagine would be similar to deleting an object which has many instances spread across many rooms. The result wouldn't be to delete a room - it would be to delete each instance of a reference to it. Although it wouldn't be a terribly efficient operation, I don't imagine deleting an entire resource type to be a common activity done while a game is already open. I appear to have mis-understood.

You do have a point that simply being able to quickly locate dependencies through some kind of context feature would essentially eliminate much of the need for the kind of organization that this would allow. On the other hand, though, this kind of organization could be useful in creating and isolating self-contained modules of game functionality. For instance, imagine a custom made textbox which you could just plug into any game. All the textbox resources (scripts, sprites, and objects) would be contained in one folder.

While we're designing the new EGM file format, there are quite a few new things that we can do that GM doesn't directly allow.

For starters, I'd like to ask your opinions on whether resources should be allowed in other folders where they're not designed to be. In essence, this would be leaving organization completely up to the user - you can clump a bunch of different resource types together in one group - like having a sprite in the same folder as an object.

This could be a nice organizational feature -- or it could be a total disaster. Also interesting, I don't think I've ever seen it suggested for GM.

As for how this effects the format - it would mean that each resource would need to identify its resource type. This would slightly increase filesize. It would also make it a little trickier to read it in - but not much.
Another interesting note - technically GM's file format allows this - there's just no IDEs that can do it.

Alternatively, we can keep it the way GM has it, and force resources to be segregated into their own folders.

Actually the stable and testing tags are both r710, which is the version that everyone (especially windows users) are encouraged to use until further notice.

As for the error message, please provide the full log from the terminal. What you have provided is only the last 7 lines.

Fair enough.

At some time between 2011-04-23@02:18 (when I last saw it working) and 2011-04-25@19:14 (when someone reported the problem), a fatal database corruption took the life of our wiki. We have submitted a ticket with our host to fix it, which may mean performing a rollback to an older backup. We'll let you know how it all goes, and hopefully we can have it back and running without too much work lost.

Thank you for bearing with us in the meantime.

Looks good and formal enough for the internal directory structure. I'd just need specifics for how to handle the leafs. I suppose we can deal with them one resource type at a time.

Figure out what you want to do with definitions, and how you plan on handling binary data in the game settings, such as the icon and the progress bar images. Once you do that, I'll get started on a prototype.