ENIGMA Development Environment

I haven't worked on the project in a long time, but we discussed all this stuff back in the day, so I thought I'd give my two cents on what we determined:

1) Windows phone compilation support - I can then make games for my phone, lol.

This is feasible. We've worked on iOS and android support. Windows phone would be the next step, but I think just getting iOS and android working again would be a higher priority, since they are easier.

2) Program compatibility with Windows phone - I want to work on my projects portably (Not desperate for this.)

This is unlikely. Even though LateralGM is written in Java, so technically it could work on any platform, it is targeted as a desktop application, with full mouse and keyboard support required. There are drag gestures and key-mouse combos and special key (like ctrl) frequently depended on throughout the application. If you want to develop on the go, get a laptop.

3) Multi-user online editing - I want to get my dev team working on this project, but it kinda makes it difficult that we have to pass the file around   
    over skype. (Again, I can just about cope without this)

This is planned. As Onpon said, the solution is to use a SCM (version control), such as Git. The issue that GM faces is that their file format is binary, which does not version/diff well; it works best with textual files. Fortunately, here at ENIGMA Corp, we've been researching and investigating textual technologies, and have come up with a few solutions. First and foremest, we have the EGM format (currently alpha). This format is designed to store every resource in its own textual file, called an E-Yaml file, with any data that is necessarily binary (such as images) stored separately. However, EGM is designed to get compressed, which just converts all the data back into binary again, but we have designed an uncompressed version so that you can use version control. Additionally, there was a project call LgmScm, which was a plugin for LateralGM the would port your code into an SCM-friendly format and add basic SCM integration (independent of whichever SCM system you chose). I don't recall whatever happened to it, but I'm sure it will get looked at again once EGM is more stable.

4) Improvement to Game Maker project compatability - Seriously, there are too many functions that I can't use on Enigma that I used to frequently
    use on Game Maker (Eg: execute_file) (I am aware I can implement Lua into Enigma somehow to solve this, but I'm too lazy to read the   
    instructions all the way through)

So, the big hurdle here is that execute_file requires something able to parse and interpret said file and inject that code into the game. This is an issue because unlike GameMaker, ENIGMA is compiled, not interpreted. We convert your internal game code into C++ code and then send it off to the C++ compiler (gcc), once and done. This requires a full suite of tools installed on the developer's machine - mainly gcc. We can't expect players to have gcc, because they're not developers, and gcc is huge, so we can't just ship it with the game.
Fortunately, here at ENIGMA Corp, we've been researching and investigating interprative technologies, and have come up with a few solutions. First and foremost, I think we have some sort of fancy Javascript engine that Josh wrote that can apparently read and interpret GM code, since it's mostly Javascript friendly, and can then pass that back to the game for integration. Josh can probably tell you more, or there might be a doc for it or something somewhere, or someone else might know more.

5) Fixed GEX support, or atleast implement it. (I see the feature is "there", but it doesn't function. Are you going to implement it, or not, lol.)

The issue with GEX is that it's often used for packaging a DLL with your game. DLLs are windows only. They are not cross-platform. Linux uses .SO files, and mac has I think a DYLIB. None of these formats are compatible (and for good reasons, since they often directly access things in the OS). We can workaround this a little bit by packaging a version for each in your GEX (so it will have all 3 - a dll, a so, and a dylib), which is more or less the plan. It'll still restrict the oparating systems that can play your game, or at least that can use the GEX extensions (so you may not be able to play your game at all on most mobile devices if it has a GEX), but it's better than no DLL support at all. It's also quite possible that we'll create our own GEX-like format, since GEX is property of GM, and if we had our own we could do more with it.

Anyways, thanks for the suggestions. They are great reminders to continue working on these side things that are often outside the scope of the main codebase.

If we have to, we could re-invent the algorithm based on how we see it. It won't be the most elegant thing, but if it gets the job done, we only need to run it when the alpha channel is actually used.

The message should read something more like:
"Are you sure you want to delete all instances in this room? This operation cannot be undone."

Instance is the official term and a well-defined concept in LateralGM; it even has its own wiki page: http://enigma-dev.org/docs/Wiki/Instance

"in this room" is an important qualifier, to not confuse the user as to what scope of instances will be deleted - will it delete all instances in the entire project or just the instances in this room - we must clarify.

"All data will be lost" is a horrible sentence to use here. It conveys nothing more than the first sentence, and does not imply that the operation can't be undone. It is also scary - ALL data?! Throughout the entire project?! Say what you mean, and be clear about it. "This operation cannot be undone."

Punctuation is a little important as well. We should avoid contractions like "can't" (prefer "cannot" or "can not"), and remember to terminate sentences with a period.

Also, remember to send the string through Messages.getString so that it gets translated.

As pointed out, we should also be translating "<no objects>", although that may be a challenge to translate since "objects" should be independently translated.



Edit: I have committed this change. Also, it appears that "<no objects>" already has a translation key; not sure why French didn't translate it.

1 would it be possible to simply do a version check before using the functions? We used to do this for some of the more advanced swing features and it worked great. This way you can maintain java6 support without incurring a big dependency, and display a warning of reduced functionality to encourage people to either update or download a jar.
2 if it can't be done directly in lgm, maybe a plugin could pull it off.
3 why are we dropping gmk support? The reader and writer work great and it's the latest version gm people can use without switching to studio. And what about gm6?

Notice h is before offset and shift and not after w?

The properties are alphabetized. c h o s w x y

ENIGMA's compiler does not presently support any formats natively, including EGM. LGM has all the resource readers/writers, so from the get-go, we just let LGM do that work for us. However, formatting the data into C-friendly structures is apparently an insurmountable task for the JVM. Possibly due to the fact that Java has the opposite endianness.

It hasn't always been this way. We've dabbled with a few options, eventually having LGM export the data to a file, and calling ENIGMA as an EXE - simply because I couldn't figure out how to get dlls to work in Java (using our own format, EGF, I think, so CLI still wasn't a viable option C-side only). It wasn't until I finally broke down and agreed on a JNA dependency that we were able to do what seemed more natural. Unfortunately, as Josh pointed out, transferring data this way is still a struggle on the JVM.
Sorry for skimming - I might be repeating what you already said, but what you might consider doing is some kind of hybrid where ENIGMA has a native EGM format, and ENIGMA itself will load any unloaded resources from file - while the loaded resources will be passed over through JNA->C-structures. This could further be optimized by only keeping track of which resources are changed, so LGM doesn't have to populate structures for unchanged resources. While we're doing this, as Josh suggested, we might even consider not bothering passing the more binary resources, and rather keep them in the EGM - especially if ENIGMA is just going to turn around and write them to a file anyways - it's better if we save the overhead of JNA->C-structures for binary data (which are, measurably and unarguably, the biggest cycle offender) and just write it to the file ourselves.

I mainly want to retort IsmAvatar in that I do not agree with full blown unmonitored contributions

Not sure what unmonitored contributions I allowed when I was active on the project. Or did you mean another word other than "retort"?
Actually I feel I followed the extreme opposite of that, which I now think is precisely why LGM stagnated in both developers and development -- because every commit had to be reviewed by myself.

Yes, that's what I was thinking as well. Similar to plugin dependency, plugins can identify other plugins to take higher or lower priority over. A pretty elegant solution whenever we get to that point in development.