[Edit:]

Alright, great thanks for the feedback some other things to consider:

I like the solution I mentioned above regarding tabs when tabs are used for normal indent and vertical tabs are used to create the columnar alignment, this makes it work with python.


In that picture it would mean "string s" whitespace would be replaced with a single preceding vertical tab, and all of the other lines would continue to be normal tabs.

Regarding Sublime, I haven't switched to it yet, but there is an elastic tabstops plugin for it:
https://github.com/SublimeText/ElasticTabstops

I also got this FF extension which stops making the tab key change focus so it works nicely with pastie.org, even though pastebin.com already had tab input support (depends on the website and how keen the developers are, stack overflow is a pain to format code)
https://addons.mozilla.org/en-us/firefox/addon/tabinta/

Whether you use spaces or not though tab is still used for the indent so you can select multiple lines, code editing in browsers sucks either way you go imo.

Anyway I've personally gone 180 degrees back the other way I think to just tabs because I feel all of the advantages outweigh the benefits when properly configured and because of my above discoveries and that tabs separate model from view.

Anyway, not to be rude Harri, but to be honest, I don't want to do our own styleguide. Whether anybody likes Google's or not I don't really care, it's very popular and I feel just as comfortable working with it. So my vote goes towards us adopting the Google styleguide to make things easier for new contributors and because it is already widely adopted and has a number of extensions for many editors, plus it's what Josh and I already have configured on our computers and you do partially as well.

I'll wait and see what he says, if we get his seal of approval I'm checking out ENIGMA's latest branch and running over the whole code base with a formatter. Maybe though since you don't mind the elastic tabstops idea we could be a revolutionary project in using this coding convention and make it more popular, let's see what Josh has to say and egofree or anybody else feel free to weigh in too.

Edit: Also I love your idea about the code headers, definitely agree with you there. I also get kind of sleepy reading code with doxygen as well, this is why I like a class hierarchy view.

Well, I'll be a monkey's uncle, you're right.
https://github.com/IsmAvatar/LateralGM/blob/master/.checkstyle

I wonder if it defaults when you open the editor or if it needs configured in Eclipse first like I had to do with the Google styleguide I needed for my other library. If it is the case of the former then that leads me to point out that I don't particularly like this style and I don't think Josh or anyone but IsmAvatar does, but I believe this has been mentioned before. In practice I would rather just keep it what it is then try to change it. However I do feel ENIGMA and LateralGM would benefit further if they used the same styleguide.

Regarding ENIGMA, since Josh works at Google, and the compiler has always been written with that style, I feel as though that's the one we should go with, at least for ENIGMA. The reason being is that Google has the styleguide well defined and you can even download an XML schema file for it to plug into Eclipse or other editors.

Still looking to see what everyone else thinks as I wouldn't want to make contribution difficult for everyone, I think this would actually make it easier and it's bugging me to the point I may check out the latest ENIGMA and clean it up if we can all decide. I am looking basically to get everyone's approval to enforce it since it seems egofree is comfortable with it, I am comfortable with it, and so is Josh. Using style formatters is not difficult but my only wish is that Josh would have sat me down and made me think about it before letting me contribute instead of just letting me ignore it. Anyway, most projects adhere to a styleguide at least to some degree, but ENIGMA straight up has nothing to the point the code is a complete mess, at the very least we need to define the indentation style.

This was always a huge problem when I began contributing to ENIGMA. Having to format and reformat code constantly. Recently I've taken the practice of using standard style guides for my projects and sticking to them.

I feel ENIGMA and LateralGM have suffered tremendously from the lack of an enforced styleguide. This post is not about tabs vs spaces but about using consistent formatting in both projects.

My personal preference would be the use of a mixture of space and tab indentations which I am conflicted on but have expressed in a 64Digits post:
http://www.64digits.com/users/index.php?userid=RobertBColton&cmd=comments&id=504378

I've been configuring my code editors to allow me to use a consistent coding style for multiple projects. I was simply reviewing some of ENIGMA's source code and stumbled upon the inconsistencies in formatting, caused by myself and a lot of others. You can see in the following screenshot some of the problems, some lines are indented using tabs and others with 2 or 4 spaces.



This makes it considerably difficult for contributors, including each and everyone one of us, whether we prefer tabs or spaces. The reason is simple and that is the lack of consistency. I would be able to work with either depending on what everyone else would prefer to use. But I think the quality of our code base could be seriously improved through the ratification of a standard coding style for the project with input from everyone. Please let me know what you think.

I've got the solution to your temporary problems ego. Also I'm going to follow up with a private message to you to let you know what else I've been working on.

I can be less dirty, but I don't think it needs a billion features. Just make it load and compile egm. Compilation is done trough makefile flags anyway. The only thing CLI actually does is it parses EDL and then adds resources to the compiled exe.

Not so much about it being dirty as it is about making it long lasting, etc. Josh's library has something to do with parsing command line flags, you should ask him about it.

It doesn't matter that much how it is saved inside egm as we can create the resource tree from a description file of some sort.

No I hate that, Josh doesn't like it either. The directory structure is already there. From a design perspective it should definitely be imposed by the IDE or the model's "view" as in MVC. A lot of IDE's also automatically sort your tree in alphabetical order and don't even give you an option.

And the bugs that threw exceptions are now gone. I only have LGM freezes and crashes without any kind of exception or error message.

I know I agree, I'm just saying that dialog was one of the greatest things that ever happened to LGM, it's one of my favorites actually. Probably my most proud accomplishment and the greatest thing about using Java as we almost 99% of the time know exactly what's causing an error, except the rare JNA cases where it gets mixed with native code.

Well, the 'official' version of LateralGM available now on Github uses 'your' version of Joshedit, with pull requests not accepted by Josh. So it's not only about constants. Try to get LateralGM and Joshedit from Github and you will see it not will compile.

Taken care of, I've uploaded my last fork of LGM. I had this local on my disk and it's the last version I worked and I haven't touched it for a year. I uploaded it to ENIGMA's dropbox account. I tested it in Eclipse just now and it builds fine with JoshEdit, no need to check anything out, just import to your workspace. However I likely patched around shit waiting for Josh to merge my PR's which is something else I want to get to next.
https://www.dropbox.com/s/gefgz1p286uw6e5/lateralgmlastcheckout.zip?dl=0

Edit: I have no idea where to put this, but please continue to maintain the list of links for LGM's old revisions. These are good when people need to downgrade Studio projects or import corrupted GMK's etc.
http://enigma-dev.org/docs/Wiki/LateralGM:_Revisions

9 Months ago, i told you about the problems with Joshedit and you told me that you were too busy to fix it. That didn't prevent you to start DockFX. Of course, everybody has his own life, and Enigma is a free and open-source project, so nobody has to work on this project, but at least if you had time to do DockFX, you could have take time to fix your problems before leaving it, even if you were not motivated anymore by this project. To leave modifications in a open-source project with compile errors is not professional and don't show respect for other developers. If you really didn't have time to finish your work (i doubt it as you started DockFX), at least you could have reverted your changes in LateralGM. You left the problems with Joshedit but also reading of egm files broken ! At the same time to finish on a positive note about you, you made also an outstanding work on this project and an excellent support on this forum, and i thanked you several times about this.

You're probably right, that's why I'm not pointing any fingers. But also at the same time what am I supposed to do when Josh is working and doesn't have time to clean it up and merge it or explain what he's looking for to me? Nothing so I just get the "fuck it anyway" attitude. So I blame all of us. I <3 you guys, but I totally don't want to work on LateralGM.

Also i worked hard last year to add multi-selection, and in the in end, they were never available to anyone, except on github. So i worked for nothing.

I don't think this is true I could have swore in the post where I was updating LGM's status last including the resource searching functionality that I had released a version with this included. I am pretty certain that is the case, if not, fuck, whatever, blame me I guess.

We could of done that, but as I lost interest in GM years ago I didn't do it myself. I have moved on from GM8.1 or any kind of GM at least 3 years ago when I started adding totally new stuff to ENIGMA. And I do it constantly now too. You can still remove all the non-GM stuff easily though as nothing there should be very integral to ENIGMA engine.

In the end nobody seems to be interested by LateralGM anymore. That's too bad, because except of the instability problem in the plugin, i feel LateralGM is not bad at all.

These two are related, I agree with both of you. A little less Harri, because it's not so much that the other changes aren't good. It's just that I've seen a lot of people recommending LGM when Studio fails to import projects. GM8.1 and lower was like the best thing we ever had, Studio was crap, and that's why we never supported a lot of it including the ds accessors like mymap[?5] and mylist[%3] which are just downright absurd for any programming language.

I'm just saying, hey guys, there's quite a bit of people that could use LGM for a while into the future. I think it may not be too late to split LateralGM in two with a version for only 8.1 and lower, but I don't recommend you try to follow through on this.

Another thing to look at might be really the CLI way. It might actually be easier to have that up and running the fixing a plugin that uses JNA. But anything is better than just watching LGM burn every time you open it.

I'll prod Josh tonight about it if he's around.

[NOTHING MORE]

I used ENIGMA on Linux recently and it worked. I ran it on Tegra K1 which is actually an ARM, but supports GL3, so I didn't have to change anything. I will try running it more on Linux. I tried testing Linux on Virtual Machine, but then I have GPU problems as the virtual GPU driver doesn't support GL properly.

Yeah I don't agree with Josh on this at all, Linux is like the only place ENIGMA does actually work the way it's intended. Though I can not comment on any recent versions because I haven't tested at all.

1) Make CLI work so LGM wouldn't work trough a plugin thus creating instability.

Josh had no objections to a CLI just that it be built properly which the one I set up probably isn't, it was very quick and dirty. I asked him some time ago about one and he mentioned his GFlags library which I think he has up on GitHub, you'd have to ask him.

2) Finish EGM so it is future proof in a way that additions wouldn't break it.

I like the EGM format I just don't like how sprites are confined to the sprites folder in practice instead of theory. I think the IDE should impose that constraint not the file format. Regardless EGM is a great format and the meta-data uses a format that's a lot less verbose than XML. So I like the format, despite some of its implementation being a little buggy, one of the issues I did address a long time ago was the file handles left open in LGM which made it impossible to move or delete an EGM while LGM was running. Also some of the plugin side YAML parser is missing features that the ENIGMA side EYAML parser has, despite the latter being a subset of the former.

Also I don't want to hear any complaining about LGM's exception dialog, you should be glad I made it so ubiquitous, not that you are I am just saying to all of you in general. It led to me fixing a number of trivial bugs that would have otherwise gone completely unnoticed from versions before I even touched it.

3) Make parser more robust by reducing GM compatibility features.

What are we talking about here, getting rid of globalvar or what? I'd say we should add an option. But after talking with Harri I still feel like the best idea would be to do GM8.1 compatibility to 100% and then fork ENIGMA with anything else we do. I look at it like this, we have the code base, everything we need for 8.1 compatibility is there. Throw out any of the other frivolous shit we've added and any new functions and feature freeze it as an 8.1 and lower augmentation and NOTHING MORE. It's probably too late to do this now, we should have done this a long time ago. If I had the power or the time to do it though that's exactly what I'd do but it's still probably a huge task in and of itself.

Yeah, it is meant an ironic reference to the fact that Josh isn't actually interested in it.

You guys have lost me with this, I don't get it. JoshEdit is likely named after JEdit which was also Swing and provided syntax highlighting, he likely put his name there to distinguish his project.

Robert, I don't see how that is Ego's problem. If JoshEdit doesn't work because it was left in unfinished state, then it's a problem there.

Yes that was incorrect, I did not mean it the way you interpreted it, I meant that is where the source of the problem is. This is not his fault even remotely.

Edit: After further review I believe I originally meant that it should be building but I couldn't recall the specific details of whether I had made additional changes. Thus why I said "I was going to say that is your problem" instead of saying "That is your problem", you see the difference?

Anyway I would fix this but right now I'm starting another full-time semester plus these other projects I am working on like DockFX is too much to do. To think about working on LateralGM right now with all the outstanding issues just makes me want to cry. I don't even have the time to be here, I have to finish finding my books online or purchasing them and get started reading.

I'm getting so tired of this half-ass "add a broken feature and forget it" kind of work ethic.

That was where I last left off, I don't recall leaving anything else in such an unusable state beside constants, which also occurred around the same time I started to become unmotivated.

Here's what happened:
* Josh insisted I set up LateralGM to pull JoshEdit directly.
* I did that and moved several of the changes I made into separate pull requests. I didn't know how to use a styleguide then and Josh was busy with work and couldn't take the time to sit down and do it the way he wanted it.
* I gave up on Josh's intent to pull JoshEdit directly upon checking out LateralGM and continued to make additional changes LateralGM side. However they were only a few lines, it really shouldn't be that difficult to get the latest JoshEdit working with the PR's applied.
* I gave up on LateralGM for a while chosing instead to focus on my studies. Made an improved release of JEIE and then decided to focus on nothing but my studies.

It's been two years since I've been able to do a git pull and compile a game on Linux. That's why all our other Linux users either maintained their own forks (as DarkAceZ did, and he was 14 fucking years old at the time), or left (as most others did).

Nope, you just did that game for 64digits in 2014 and iirc you applied a patch somewhere I thought.

Also I've just been kind of mellowing out and hoping ENIGMA's problems will just go away. Personally I wish we would have done GM8.1 compatibility as best as could be done and left it at that and not touched the source any further because I think we were getting really good and stable for a while. And then forked ENIGMA and LateralGM for any Studio functionality, that's what I wish we would have done but at this point I refuse to remove any GMK or GM6 support from LateralGM. I'd rather fork the IDE and stick with a GM: Studio compatible version only but then GMX doesn't even have a version number so what's the point. I don't even have any interest in developing an IDE for that program.

Just thinking about the troubles LateralGM had maintaining translations. There's a startup project that basically works like git for translations where authors can create translations for a project.

As an example this is the one for the ControlsFX project:
https://www.transifex.com/controlsfx/controlsfx/


This could be a good idea for the future as it can attract more professional translation services and there are paid versions too.
https://www.transifex.com/product/

Yes Harri listen to Rusky, the debugging symbols/huffman codes are not my doing, it's Java's doing.

I was going to say that is your problem because the JoshEdit that LateralGM checks out is a fresh copy from his main repo but I added print support.
https://github.com/JoshDreamland/JoshEdit/pull/14

There may have been other modifications that I made and did not commit though I really can't remember. He likely does not want to merge my pull requests because of the huge commit history and I wasn't very good at formatting Java files back then with a style guide, but LateralGM doesn't actually use one so he's probably just to busy or doesn't care. I am looking to port JoshEdit to JavaFX.

It looks like a pretty straight 1 to 1 correspondence with the ENIGMA/GameMaker version. I am really interested in JS now too and I'd like to share my prototypes with you too egofree but now's not the time. Also your game loads pretty fast too, not bad at all!

Harri, where are you getting this information? There is no concept of debugging symbols in Java. What you are likely referring to is the symbols that are in the native JDK implementation for your platform. You do not build Java programs with or without debugging symbols. It is all byte code and thus always has debugging symbols (sort of, but really a different concept). The only control you have over jars is whether to include the directory structure (since a jar is really a ZIP), what files to export, and whether to export the source code files along with the byte code (the byte code is in *.class files) generated from these sources. Obviously there's no need to include the source code generally speaking and it just increases the file size as does including the directory structure in the jar. When you build a Java program you convert it to byte code which is like cross-platform assembly kind of and it is fed into the JVM (Java Virtual Machine) that sits on top of the hardware. In .NET this is called the CLR or Common Language Runtime, .NET will actually take the generated byte code the first time you run the managed program and convert it to machine language (assembly) and store that for each subsequent execution. In Java this is somewhat analogous to JIT or Just In Time compile which converts the byte code to assembly "just in time". Anyway this is how Java solves the ABI compatibility problems, though I don't know about .NET because .NET programs make extensive use of versioned dll's.

Not to sound condescending or anything Harri I just want you to understand why that sort of doesn't really make any sense to suggest building LateralGM with debugging symbols, it has the debugging symbols, and that's how it can tell you the Java file and line number where an error occurred and the same is true for C#. That said what you suggest is likely true, someone should probably take the time to sit down and actually organize that part of the plugin if it's being obstinate about a missing compiler. I spent a lot of time putting the exception dialogs into LateralGM properly to avoid race conditions and infinite popup loops like you see in GM: Studio which you can thank me for later.

@ShadowMan, my favorite always has been and always will be when I first learned you could get to Yoshi in SM64. Always one of those rumors when I was a kid but when I actually found out it was true unlike all the other rumors.... yeah.

Good read, but I agree with stroustup. Most of the "issues with C++" are either made up or just stems from not actually using C++. Like I work with a guy who doesn't like C++, because using STL relies you on "others people bugs", while himself writes everything in C with pointers and can hardly make code that doesn't explode. When I finally showed him how even a ranged for loop creates more optimized code than he could even write, he finally started looking more kindly on it.

Yeah, I pretty much agree as well. The only C++ arguments I've really heard are that it's difficult (totally not but a lot to learn though). I also disagree with your coworker because I encourage the use of the STL because it's written by very smart computer scientists who account for things that you may not consider and also does logarithmic growth (averages out the complexity of a resize etc etc). That's one of the benefits of using code by someone else and also that you are guaranteed for it to work specific ways across compilers and platforms. However I do kind of see his point too because I really hate waiting on JavaFX bug reports to get filed (I've filed about 20 on this new framework) and I know none of them will get fixed until JDK 9 which is a whole year from now. I was actually considering joining the OpenJDK project because I already have fixes available for the bugs I've discovered.

I will do it when I get something stable. I'm playing with compiler too now so I can pack the newest one with 64bit's, but I have problems with LGM. Like it crashes when I have a different compiler in PATH. How can that even be? It works if the /bin I point to is the one coming with the installer now, but when I point to /bin from Dragons release it just crashes on startup. I don't even compile anything with it as the .dll already exists. This kind of weird LGM stuff is something I have to deal with, but as I don't code in Java it's hard for me to debug. Maybe you can at least give we LGM and plugin with symbols? Because now it trows like 5 SIGSEV's on startup when debugging with GDB, but it has no backtrace as there aren't any symbols I guess. Lookee here: http://enigma-dev.org/forums/index.php?topic=2561.new#new
edit: It looks like I tries to call something to do with the compiler on startup whether it is needed or not, because a third compiler I tried adding in PATH made LGM trow something about incompatible .dll even though IT WAS NOT even recompiled. This is a strange behavior indeed. The thing about LGM compiling the .dll actually has never worked for me in Windows. I have always needed to do it manually trough shell. So maybe either a setting to disable this? It would make startup faster as well.

That would be ideal so the same compiler is used for both versions. I can't really say much about the random crashes that's actually all in JNA (we do not use JNI, JNI is older) if you are getting SIGSEGV. LateralGM will never throw a SIGSEGV by itself because it uses no other native code. Also in Java there is no concept of debugging symbols, the code is JIT'd to byte code which is fed to a virtual machine. Complete stack traces with the file name and line number exist for exceptions because of this. So in a way a Java application always has debugging symbols (though not really because it's a different concept). So any segmentation fault is either through invoking native code with JNA or a bug in the JVM.

I will probably try creating both 32bit and 64bit installers. The difference only being the .jar's and .dll's. Both will come with 64bit compiler (which itself is 32bit exe) and both 32bit and 64bit "Additional's" so you can compile both from any installation of ENIGMA.

That is ideal because then users can just install that compiler as well to offer a lighter weight ZIP. Not that the size matters since you are offering to upload but the download size may matter to them which is also something to consider.

That is great and hopefully this is how Windows10 will allow you to work. I have already mentioned that Package Manager is the only thing I really miss about Linux.

Yeah I was the one that originally posted it on the forums. As far as I know it is a fork of OneGet but I don't know if it's actually Microsoft developers working on it. As far as I am aware you are also unable to use it with anything but power shell. Also I feel that Windows 10 is better than 8 but 7 still trumps it for a desktop OS despite all of its fancy features that I do actually like. Some of the features I like is the package manager, return of glass/Aero theme and start button, the package manager thingy, and some others. The things I don't like are forced updates which are causing tons of problems for people including endless reboot cycles. I also do not like Apps like the Xbox one which I heard opens automatically when you start playing a game and tries to record it without you even asking it to by default. Just a bunch of annoying settings like that is why I turned around and decided not to upgrade. Not to mention the privacy of the thing, the whole OS is clearly a giant NSA playground. Call me crazy sure, I don't care if the NSA is watching me or stealing passwords or working with Microshaft to make back doors, but OMG they are so annoying about the way they do it lol.

This isn't as big of a problem you put it to be. First, Windows 10 finally has a built-in package manager, so looking forward to that. Second, there really isn't that big of an issue of providing mingw in an installer together with "Additional". I think the current method works quite good.

I've seen it already and I don't think I care, it will take some time for it to take effect either way. I really would just rather use Linux which solved all of these problems a long time ago. I don't switch to Linux full time because I really do need things like Word which does happen to be more reliable than Google Doc's or Open/Libre Office. While I may be exaggerating the problems they are very real and I think you are undervaluing them. There are a large number of complaints about C++ but most of them Bjarne Stroustrup dismisses except for a standardized ABI. I don't mind coding in C++ at all and I did make a number of substantial improvements to ENIGMA's engine including starting that model class (though I've learned much more C++ since then) but this really turns me off from trying to build cross-platform applications or applications to be distributed in the language.
http://www.stroustrup.com/slashdot_interview.html

The compatibility with C at the system interface level has encouraged people to use C-style strings, arrays, and structs, where they would have been better off with some higher-level abstractions presented as classes or templates. Instead of leaving the low-level facilities at the system level and within the implementations of classes, people have let the low-level constructs - and pointers to them - permeate their designs. Type errors, wild pointers, array bounds errors, and memory leaks are the obvious results. Lots of macros and casts often adds to the obscurity of the code. It saddens me to see some of the unnecessary messes people get themselves into.

This is why I still really honestly like Java besides its amazing new MVC GUI API called JavaFX (which I am building some of my prototypes in). Java is still amazing in that you can generally build quick cross-platform applications, build them once, and deploy anywhere. This idiom only gets broken when you try to mix it with native code like ENIGMA which really sucks, it is the lowest common denominator, and gives you the benefits of neither Java nor C++. Regardless I agree with Mr. Stroustrup 100% on everything he's said there.

I'm willing to do that. I think you even posted some tutorial or something how you did it, so if you could link it then I will start doing it. Internet isn't a problem where I live and 100mb's is really not an issue speed wise. Only need to find a good place to host - I think hosting on Dropbox isn't the best way. Maybe we have a way to host on ENIGMA's website? I don't know how much space we have though, Josh should know.

The topic is pinned in "General ENIGMA" and I would appreciate it if someone else would build the ZIP occasionally. Josh could obviously give you FTP access to the server but I've just realized that we could just upload these to GitHub directly if Josh enables it on the repository. He does it this way for Calico (click "Releases"). I think we should upload the ENIGMA binary releases directly to GitHub since that is a standard/more common approach.
https://github.com/enigma-dev/Calico-Icon
http://enigma-dev.org/forums/index.php?topic=1399.0

I can compile ENIGMA (the plugin) on 64bit, but of course the LGM stuff needs to be changed too in that case.

That would be great as well because then users would at least be able to download a 32bit and 64bit version of ENIGMA and they wouldn't have to specifically install a 32 JDK/Java. You would have to recompile all of ENIGMA's plugins though and I also think you need to replace the jna.jar with the 64bit version. I hit too many errors and incompatibilities between MinGW64 and 32 and finally just gave up on packing it. It's sitting on my desktop and was the last thing I was trying to accomplish before I stopped contributing for this period of time. Largely because of my poor internet, if someone else were to begin packing the zip or just taking care of it instead of me by some standard/methodical approach as I did before it would make it easier for me to contribute to ENIGMA again in the future. I am actually mainly still interested in LateralGM's development so if I could maintain improvements and bugfixes to that and delegate the ENIGMA matters to someone else (regarding packaging LGM and everything) it would be a lot of work off my plate and free me up for more contributions to LGM.

In my honest opinion I still like ENIGMA on Linux because it just uses the package manager, you install the necessary components one time and then ENIGMA just works. You can easily replace the lateralgm.jar and the entire ENIGMA framework just as it is expected.

Yeah, finish the CLI would be a good start. I think the only big thing missing there is rasterization of fonts? All the other things are either done or should be easy.

Yes that is one thing that it needs but it is debatable whether the ENIGMA engine should provide such functionality as well, perhaps through a plugin because GM does have functions to add fonts at runtime that we never implemented and I believe Studio added TTF font support or w/e.

@BPzeBanshee

Yes calm down TKG, you're being eccentric. You know some of the prototypes I've been working on and one of them is about to be released open source in a few days. It is a library that is a necessary component to bigger things I am developing and are ENIGMA related.

Yeah Windows is a large part of ENIGMA's problems. The OS has no package manager like any sane Linux distribution and every Linux distro comes with a C++ compiler generally. On Linux ENIGMA just utilizes the package manager to install OpenGL and other libraries but on Windows we have to ship the whole freaking MinGW compiler, plus all of its binaries that ENIGMA does not even use, plus all of the libraries ENIGMA uses but MinGW does not. That much really is a Windows problem and also a C++ problem because C++ has no standard ABI. This means you generally can't build C++ programs with one compiler and then link C++ code from another compiler. Such as writing Visual C++ dll's that are linked from a MinGW compiler. This means when you write a class in C++ the vtable or virtual table which holds all the pointers to the classes methods can be layed out in memory differently between each compiler, because C++ does not standardize how the implementation should work. The C++ standard only defines what the implementation of any standard function does not how it does it. This can even lead to problems linking C++ binaries to other C++ binaries that were produced with different versions of the same compiler.

https://en.wikipedia.org/wiki/Virtual_method_table
https://en.wikipedia.org/wiki/DLL_Hell
https://en.wikipedia.org/wiki/Application_binary_interface

This is also why I do not update the ENIGMA zip anymore because it's 100mb's and takes me an hour to upload which is a complete waste of time. We were going to make the server do this automatically but nobody has the time or interest to set that up.

Anyway I agree with BPzeBanshee, I really have no idea what this discussion or argument is about but I totally do not care. However I agree with him in that nobody wants to use ENIGMA because of how big a pain in the ass it is. This is especially true because of what I just mentioned above. These largely result from our use of JNA to communicate LateralGM's plugin with ENIGMA's C++ compiler interface. Related to the problems I specified above is the reason why a 64bit Java installation will not work when LateralGM is coupled with ENIGMA. I would also like to point out that because of the way Eclipse works it also does not work between different architectures of Java, so 32 bit Eclipse only works on 32 bit Java. But ENIGMA does not even have a 64 bit version on Windows because of the OS's above mentioned problems and the complete rubbish that is MinGW64 on Windows. It's a total nightmare to go and build this thing and that's why nobody wants to do it.

That aside if you take LateralGM and use it by itself without the ENIGMA plugin you rarely have problems but it is about as slow as GM8.1 with loading projects because both it and GM8.1 use managed languages (Delphi.NET and Java). This is also what a command line interface would solve because LateralGM and the Java Runtime would not have to link to ENIGMA at all and would not have to give a crap what architecture or compiler it was built for it would just pass command line arguments to it and be done. It's not even that these problems can't be worked around without a CLI it's just that nobody has the time or interest to do them and it's a lot of work to really do it correctly.

This is why I continued to package LateralGM separately from ENIGMA and why I feel it should continue to be done that way. LateralGM works great on its own and it's a wonderful and very stable program by itself with a lot of applications including recovering projects in niche cases that old and new GM versions can't handle.