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.

It's hard to tell if there's any consensus in this topic, so I've started a poll. The poll will only be active for 2 weeks, so please vote while you can.

You can continue to discuss and change your opinions/votes until the poll has concluded, and then the admins will decide if the checkbox stays or goes based on the results.



Admin note: checkbox can be removed from Admin > Configuration > Features and Options > General > Allow non-admin users to hide their online status

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?

If everything in Enigma is open source, does that mean the output executables are easily decompiled?

To go a bit further on this, your game executables are Compiled C++. They are not any easier to decompile than any other C++ program (which is pretty darn hard). Let's compare this to GM, which simply attaches your game data to the end of the interpreter data. Decompiling then is ridiculously easy in GM.

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.

Additional note after a very brief chat with Josh:
* Please hide the ["Resources","Search Results",etc] tabs when not searching.

a preliminary minor release of a major build

I believe we call that a release candidate

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?

Eclipse is quite stable, can be sluggish due to its bulkiness but is generally fast enough for typical use, and uses a bit of ram due to its bulkiness, but it's not going to elope with your RAM. If you're that concerned about speed/ram consumption, use a text editor.

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.

My one main complaint with Netbeans has always been that it gives very obscure errors. For some reason Eclipse seems to make the errors a lot easier to read.
My one main complaint with Eclipse is that it is bloated, which can make it a turn-off for people who don't plan to use it frequently, because there's tons of features that you'll never use. That said, surprisingly, I'm pretty sure I've used every single on of the buttons/features in eclipse at some point.

I agree that Eclipse is the way to go. Netbeans has the advantage of a WYSIWYG, but I have a strong opposition to WYSIWYGs because they bloat your code and force their style. They are useful only for proof-of-concept layouts and learning some possible ways to do layouts. Also, I'm sure there's some plugin for an eclipse WYSIWYG at this point.

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.

We never had a good format definition for rooms that an external editor could use and hook into. Scripts are easy - export the code to a file, and launch the editor. Sprites are similarly fairly easy - just export the sprite to some sort of compatible image format, such as apng, and launch the editor. The difficulty for rooms is that they have dependent data. Objects populate the rooms, and objects are represented by sprites. What about backgrounds and tiles - will the room editor support those, and if so, we now have dependencies on backgrounds too. To export all the dependent information - sprites, backgrounds, objects, and rooms - at this point you're exporting most of the meat and bones of the game file - might as well just export the whole file in some sort of easy format and pass it to the room editor. EGM comes to mind.

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.

Project Lead of LGM here (in case you didn't know me).
A universal level format is a neat idea, and implementing the json version should be pretty easy.
My main concern is what exactly that buys us. Does anybody else use this format? If not, what purpose do we have for adding additional code to LateralGM to support a format that benefits nothing and nobody else is using?
We already have EGM, which mandates that all non-binary resources (such as rooms) be in a text-friendly format (currently I believe Josh is doing work in rewriting that, as we didn't actually honor that mandate before, and improvements - to keep the story short), so it certainly doesn't buy us that - it just adds one more format we now have to support.

That said, if you have a working room editor that uses the format, this format would buy us access to an external alternative room editor for LGM. I can see value in that, and we should be able to find some way to accommodate your format and editor.

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.