ENIGMA Development Environment

IsmAvatar, could these poll answers possibly be more loaded propositions?

That was the intention. I want to see what people's actual feelings are, not just a "Yes" or "No". That said, the votes are anonymous, and the results don't show until the end of voting*, so nobody's going to pick a fight with you or criticize you directly if you vote one way. So the gun's loaded, but pulling the trigger just fires it into a wall. At the end, we count which wall has the most bullet holes and make a decision.

* Admins can see the votes whenever, but we'll keep mum.

Probably all 7 YYG spies ..... I actually thought you were one of them   

But aren't guests not even signed-up ? HIDDEN you would not even see as guest as they are actual registered users with hidden login, right ?

I always thought guests were non registered forum browsers (a.k.a spies, or people almost interested )  I used to be guest too before registering

As far as I'm aware, you're correct, guests are non-registered. I don't think Hidden users even count towards those numbers.

As for YYG spies, ever since we started this forum I've wondered how many guests were YYG spies. It's now been years and there's not been any action, other than the occasional GMC mod showing up and thanking us for our work. At this point it's like if Madagascar and Easter Island decided to have an arms race -- nobody cares.

Is dropping LGM's GMK support even necessary? Couldn't we just drop ENIGMA's GMK support (which is pretty much dropped at this point anyways) and just have the plugin convert your game from GMK to EGM?

I'm seeing a bit of disagreement over what I said. I'd like to clarify.
I'm certainly not arguing against a CLI. As I said, not only did I write a CLI myself, but I did pretty much all of the work on making the API that opened the doors for a CLI in the first place.
My point was that it makes more sense for LateralGM to use ENIGMA as a library rather than an executable, and I outlined several reasons. The main reason is the interactive feedback that ENIGMA can give to LateralGM. That stuff *could* be done on a command line, sure, but we already tried that and discovered it was a really really bad idea - and the whole deal with files vs memory was really quite minor in that discovery. Library calls are just all around cleaner. You don't need a parser, and you don't need to keep updating that parser with more complexity whenever you change something. It also affords us the ability to pass callbacks to each other, meaning that ENIGMA not only interacts with LateralGM, but it opens up certain LGM abilities to ENIGMA (such as opening, populating, and closing informational windows like console logs, errors, and progress dialogs). Again, if you try to do that with files, you need some sort of clever dirty way of detecting when the file is done.

As far as GMS and EGM goes, I'm glad that file operations are getting fast enough, and I'm glad that these formats give us individual resource saving/loading. This certainly does open the door for a lot of new things with CLI and passing files, which I believe we can make even better use of through library calls.


@TheExDeus: While it's true that writing only the changes to the file could be faster than sending the whole file in memory, we need to remember a few things:
* In LGM, the file is already in memory. Sending that memory to ENIGMA does not require any effort, because it's shared memory. It's just a library function call to tell ENIGMA to actually read that memory.
* While having LGM save the file would be faster that way, you completely forgot that ENIGMA (cli) would now need to load the whole file. With library calls, the whole file is already in memory.
* The main reason for the slowdown in communicating the file to ENIGMA is because of a few limitations we had to deal with at the time which we continue to streamline. Mainly, we decided to rewrite the entire file into new slots of memory for passing to ENIGMA. That's completely unnecessary. If we just wrote the changes to memory and marked those as changes (so ENIGMA knew that those are the only parts that changed), that would be a better comparison to the individual resources written to file - and it would necessarily be faster because memory is always faster than files.

Is there anyway to get rid of the icons at the top of the screen? They can be MOVED, but can they be REMOVED?

Which icons?

By default, it will load whatever your System Default Image Editor is.
This is why it's loading different editors for you guys.
I programmed it that way, which is why Robert wasn't aware of it.
Thanks for documenting it, Benxamix2. Someone should probably add a wiki page for it if there isn't already one.

I'd just like to share a bit of history here. (Author's note. After writing this, I realized that a lot of it is already on the wiki page for CLI)
When Josh and I teamed up, we investigated a few ways to open communication between the two. Initially, I had a really hard time trying to figure out how to set up ENIGMA as a dll and actually send information to it because Java's linking support (JNI) was woefully inadequate (and I doubt it's improved) without the use of an additional library like JNA.
So we decided to make ENIGMA an exe, save the game as a file in our own (temporarily) proprietary format, then launch ENIGMA with that filename. The question then becomes how does LateralGM make sense of what ENIGMA wants to tell the user so that LateralGM can present it in a convenient format (such as highlighting problem lines, or pulling out errors from warnings). One possibility was to use files, which I think we tried briefly, but it was too slow and hard to manage, and it was difficult for ENIGMA to communicate when it was done writing to the file so LGM knew it was allowed to read it, so we gave that idea up and had LateralGM read the stdout and stderr from ENIGMA and parse it.
That was about as much fun as trying to read a message written in blood.

Then one day JNA got its act together and started hitting the gym. LGM was able to use it because it wasn't as fat as it used to be, and could be made even skinnier by me performing a little liposuction on it. This gave me an opportunity to experiment with talking with ENIGMA as a dll rather than an exe.

The functions that evolved from this are documented on the wiki and a specification was written up for it. Any IDE can use these to interface with ENIGMA. You could use these functions to create your own CLI for ENIGMA.

In fact, shortly after that, I wrote a ENIGMA CLI (Command Line Interface) and built it into The Plugin so that you could actually run the plugin without LateralGM, as a CLI, and simply pass it a file (which was one of the driving forces and use cases behind the EGM format) and some command line flags/arguments and have it compiled. I continued to periodically maintain the CLI throughout my active participation in the project. I can't speak for how it has fared since I left, but I would be willing to bet that the code is still in there and it can't be too hard to fix it up and get it working again if it broke.

the proper way to do it would be to save your project like you would in GMS, using folders, and having the IDE compile reading from disk......it would be far more efficient, smaller memory footprint, and more stable

Not quite. Disk operations are extremely expensive - they are slow, so there goes your "efficiency" argument. For older GM games (pre-GMX), games *had* to be loaded entirely into memory. Having ENIGMA as a DLL allowed us to share that memory -- compared to a file where both ENIGMA and LGM would keep separate copies of the game in memory. As for stability, read my history above. In addition, streams are buffered, and if any buffer gets too large before LGM got a chance to read it, the entire JVM would lock up and LGM would freeze. Additionally, parsing text from ENIGMA is hardly stable and rarely yields anything useful. Having specific memory structures that LGM and ENIGMA pass back and forth allows ENIGMA to not only give LGM more useful information (see above), but also affords us some really neat features, like Build Mode, where the compiler can actually edit the game (or allow the user to edit the game) and send that information back to LGM.

I partly agree with Darkstar2. It would have been fun turning LateralGM/ENIGMA into a staffed company, and you can be certain that it would have quickly started to outpace GM. But it would have been a very different product.

Unfortunately, I don't think it could have lived up to that level of scrutiny on the legal side. Being open sourced (and somewhat anonymous) gives us certain liberties in how similar to something else that we can design it without having to deal with lawyers being sent after us. Being a company, on the other hand, means that we have to really visually differentiate ourselves from our competitor to make it clear that we're not just trying to steal their money.

If I had the insight (and money) then that I have now, I could have pulled it off and designed the interface differently enough.


All that said, my vision was to provide this product free-of-cost and tinker-friendly. This vision continues to be the driving source of the project, and is not compatible with the closed-source model.

if there is a file relative to the .jar in the right position, then it overrides the default one that is inside the jar.

This should be what LateralGM already does. It's just not obvious because it's hard to tell:
* Which folders you can create
* Where to put them
* What they should be named
* What exactly goes inside them

So the challenge then is to just increase visibility of that somehow.