I know that Robert, actually memory usage is not an issue but the error shows VM errors, out of memory, not found, etc.
I will post more examples when I get them.
I have not worked in ENIGMA for a while as I was busy lately.

Robert, what are you talking about ? I have posted many times logs since I joined here, many times we discussed the stability issues of LGM and showed you reports, and you said the problem is with enigma.jar (the plugin) and not the IDE itself, these problems start to happen eventually - the longer I work in LGM, eventually pressing anything and an error pops up relating to Java, VM, memory, etc.
And yes even with the settings file tweak setting memory to max.

Some are so easy to reproduce, just frequently save your project, eventually it will error out and the entire MFing project gets corrupted., including backups.

I'd be glad to post those logs, but that won't change anything

Yeah I was already aware of it and had plans to fix it, but I was thinking about adding surface_set_viewport function Harri. But then again I still don't know if we want to add application_surface or not.

Wouldn't that cause a performance hit ?

No not necessarily - I'm thinking some software in general that are very buggy and poorly tested.

As to YYG let's give them credit when due, they made some very positive changes lately.
Version 1.4 is not officially released, and lots of interesting changes with the IDE that any LGM user would have wet dreams about
but with every positive change comes the negatives i'm afraid so yeah, work in progress.....But we should not talk, as ENIGMA is a WIP too lol!

@Darkstar2
Thank you for that very thorough post! That list of Enigma specific functions was what I really wanted. You can disable extensions?! Holy cow that's awesome! Besides size, does disabling extensions have any positve effect on game speed? It's probably negligible if any...

Those are very good questions you ask that should be put in a FAQ.   Yes the enable/disabling features is a great thing about ENIGMA, instead of compiling the entire set with your EXE you only compile the features you will use.  No physics, no particles, no video, disable their extension and these won't be included in your final exe.......so yeah, smaller file sizes for sure.
About performance, since these modules are used on demand when needed, when enabled, they just are included in the compile.....Should not affect your game's performance, and any hit would be minimal you'd probably not notice it at all if any.  Again might depend on the complexity of game, but on tests I've done did not see any noticeable difference.

Python is bad not because of its speed, it's bad because of its syntax. <Runs away now before nukes drop>

What nukes? I'm sending the PGJ (Procuraduria General de Justicia - A branch of the mexican police famous for getting you to confess the murder of Pancho Villa if they so choose) 

YIKES! Brace yourselves.

From my point of view every version of windows is a beta version (Well okey vista was an alpha version but still . . . ) 

Partially correct.  Vista was pre-alpha
the rest, beta and its users as guinea pigs.
I guess one could say the same about other software too.....

edsquare, you tried a beta OS on a physical disk? D:

Didn't we all do stupid things like that on our computers? Or were you born a software engineer from your mum's womb ?

Yeah I'm actually going to dare try this MF out later this evening......I have a fresh spanking brand new SATA3 drive I will test this on, but this is an early stage, things can change to the RTM, so I'm not expecting flawless not even close lol

The world does not evolve around C++

Blasphemy!

Sadly, until they develop a true compiler for Python, Harri is right, the world does evolve and revolve around C++ 

It might evolve around C++ but most people you ask probably never heard of C++... and probably think it is a vitamin supplement LOL!

The world does not evolve around C++

Blasphemy!

Correct, I fixed my post ! lol!

What I actually meant was that he should not be discouraged because he is not as skilled in C++ to contribute to code, he has the skills to get there eventually......There are many skilled people in the field who don't know C++......

BTW, I fixed my post, the entire universe and world and experiment simulation we call life, was actually coded in C++ So I was mistaken

Unless GOOGLE is secretly working on a game making engine of its own, I think this should be fixed - they should get a sample of the EXE and white list it.

Mind you the problem is not ENIGMA, but the heuristics and the self extracting.....some EXEs might have attributes of a virus or malware and be picked up by heuristics as malware. Some similar characteristics might be picked up and generate false positives.

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

I disagree here, unless you still have an old PATA drive working at 20-30MB/s now people use SATA2/3 with blazzing speeds, even SSD.  The advantage of disk to disk
compiling is efficiency - for smaller games, the tradeoff is minimal, but for massive/larger games, the tradeoff is worth it.  For developers wanting to make massive games, would be more efficient that way.
In any case GMS now does it that way, leaves minimal MEMORY footprint, keeps your IDE fast and more stable........Try to work with massive projects and see how slow the IDE gets, this goes the same for GMS......though they made some very good improvements there in terms of dynamic asset managements.....was about damn time

I am aware that RAM speed exceeds that of disk by far but in this case the tradeoff has its pros.

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'm sorry but LGM is very annoying to work with and highly unstable.  I often have to close and re-open due to segfaults, VM memory errors, etc......My system is powerful, up to date, heaps of RAM, and yes I tweaked the settings file to the maximum xmx allowed for java.......same deal.
Working with massive projects with LGM is a turn off, sadly........GMS's IDE improvements set it miles apart - never thought I'd say this.

My solution to this soon will be my written from scratch C++ dynamic asset handling engine + some changes.......but barely have time now !

[/quote]

Thanks but I can't really compare to your genius. I still can't contribute to ENIGMA effectively because of my limited C++ knowledge.

The world does not evolve around C++, even though the entire universe was coded in C++, you still are willing and persistent and learn quickly, so you got very good attributes and skills you might not even know of....that's a good asset to go forward.  One thing you should polish a bit is debugging - learning how to find bugs, testing for them, testing different possibilities to generate bugs, etc.....and if you can master that you are on a way .......... then you can actually debug lonewolf's stuff too

At this point in time, I am honestly afraid to download, I think I'll wait I have too much important stuff going on.

Since when are you afraid of anything ? You handle ENIGMA quite well LOL are you afraid of Windows 10

Great, I will play along, I'll set up a test partition and give this a try this weekend and report back