ENIGMA Development Environment

Is this the Mario example you are referring to: http://enigma-dev.org/edc/games.php?game=68 ? I will test it tomorrow and post what I got.

While simple GM projects can run without changes in ENIGMA most of them needs to be changed in one way or another. ENIGMA is basically dropping GM compatibility it never fully achieved and so in the future larger and larger divergence will happen in this regard.

In the current case I cannot be 100% sure what the problem is without the gmk itself. If you can post it here I will run it and see.

For a first website it ain't bad. I do like the routes and pictures. Did you really take them? I'm going to CERN this october so I will go near Montreux area and probably see that too. Looks like a beautiful place.

This significantly complicates the overall process of passing the resources by requiring them to be loaded into the IDE, written to the disk, then read back from the disk on the other end before being passed from the CLI to compileEGMf.

It doesn't complicate anything as the IDE must be able to save EGM anyway and the CLI needs to be able to load it. If you have these two features then this interface is as simple as:
functionThatSavesInEGM(randomlyGeneratedFileInTemp);
system(cliPath+" -egm "+randomlyGeneratedFileInTemp);Normally you would do some checks here but this is truly is as easy as that.
I do understand the positive side of using "compileEGMf", but "less complicated" is not one of them. It's the contrary. I also know the negative sides which are more. And I do support compileEGMf existing and a plugin existing, but only if they are stable. That is why I think we need to finish CLI and hook it up (maybe optionally) with LGM. So I can at least use ENIGMA while the plugin gets fixed. I feel having a stable CLI to be easier to achieve than having a stable plugin. Although technically the CLI still uses the compileEGMf so it might be just as unstable. But a lot easier to debug for sure. Many crashes in LGM happen even when nothing is clicked (just minimize and maximize the window a few times). At that point the only work LGM should be doing with the plugin should parsing headers - thus reducing the places we should be looking for a fix. I think the parser is the main error magnet here.

Rusky has pointed out to me that XML supports namespaces and some other features I see, so excuse me for being naive originally. I was not aware of this but I think it is still debatable about how verbose XML can be, and I clearly tend to agree that it is. However, XML apparently does have some good data processing and querying features (which I was already aware of), but why exactly does ENIGMA need them? YAML is clearly/technically/colloquially not a markup language and really good for just plain old data, which our rooms basically are. So I would like to know if you had some ideas for utilizing the XML processing/querying features or not, because that is something to consider before making a decision.

I do agree that XML is more verbose than some alternatives, that is for sure. But I don't really see an issue with that. It matters if the XML must be read by a user or the XML can make size a little larger which maybe was a big problem 15 years ago. But in our case the XML is only for the IDE and the CLI/plugin (which means the XML could look like "<093420uf09ihsudoifhirwouh97 au='sqqd1'></093420uf09ihsudoifhirwouh97>" if we wanted) and the size in the modern world is no longer a problem. For an XML file to even be 1MB in size it would have to consist of A LOT of information.

I don't know what you want me to say. LGM has taken all of the necessary precautions to make sure the errors are properly reported, and so has the plugin framework. Even a native IDE would require a plugin framework so that it's not limited to only ENIGMA, it's a simple separation of duty.

I didn't mean the error reporting is bad, I just meant that the excuses like "Plugin is crashing, not LGM" is futile here. When the plugin crashes, LGM crashes. The only thing I don't like about LGM's/plugins error handling is that there aren't that many checks done. Removing one .ey entry can trow a segfault. I think one of the main reasons for a markup language for settings is that you can check if the settings exist and use the default if they don't. Or at least report in a sane matter. But it seems EYAML wasn't made with this in mind, as I actually had to add a function to check if an entry exists myself recently "bool ey_data::exists(string n)"  (https://github.com/enigma-dev/enigma-dev/commit/fc5a90a4b8e64718927fb2765c5ee4572ee3ef80).

Are we still not able to debug these compile errors you're having with the plugin or what?

This is a problem, yes. I personally cannot get any backtraces in 90% of crashes.

For EGM I think the first step is to write a real specification. I will look in the http://enigma-dev.org/docs/Wiki/EGM and http://enigma-dev.org/docs/Wiki/EGM_format pages and see if I can make something better.

Yes it certainly does make it easier to get started, but ideally in a perfect world you still need compileEGMf to pass resources that have been opened but not saved in the IDE. This is the problem GM Studio's IDE has, it always forces you to save your changes before running, which 99% of the time nobody wants to do, Especially me, you make small changes just to test them.

That is really not a problem as you can just write to a temporary. Saving a project usually takes a second or two - just make it save to a temp directory and compile that. It is a lot easier to make saving and loading faster for CLI than to make interfaces between IDE and ENIGMA (as LGM shows).

I was going to do that, but clearly if that's all you want then there is GMX. XML is a bloated markup language and Josh already proposed an EYAML format to replace the binary room blobs. Anyway, I don't have time to do it, that's a substantial amount of work. The breaking change is fine though because I have backed up every old plugin and LateralGM version in multiple locations and they aren't hidden either, you can find them easily on the Wiki and I've linked it multiple times. So if you'd like to make the changes to the plugin, knock yourself out it needs done but nobody has time right now.

I don't see how that is a lot of work. In C++ I can do it in a day. The problem is that LGM is made in freaking Java. And we did have posts with Josh talking about rooms in a non-binary mode. In it I showed how XML is actually not bloated if used correctly. Yet has more features than EYAML proposed. But I honestly don't care in which format it is. Use a CSV or Excel if you have to, just don't make a version breaking incompatible binary blobs.

EGM is actually supposed to support this, it was never finished and I never had the interest in doing it. Also note the above comments regarding LGM still loading the entire project instead of just the resource you are currently editing.

Again, if you have EGM loading then this should be trivial. It should be even easier, as you must SKIP a step. Just don't open the .zip and instead read the folder structure.

Irrelevant

What you said irrelevant. Users don't even differentiate between LGM and ENIGMA even if you change the title bars. This site is called ENIGMA-DEV having a game development tool named ENIGMA. When you install it and run it (on windows you run ENIGMA.exe) you can make the logical assumption that the editor is also ENIGMA. And the errors you mentioned are Java exceptions - they are not the problem now. It is quite easy to create a Java exception by changing .ey files or by not having correct paths because LGM/plugin does 0 error checking, but if the plugin crashes then there is not exception. Just crashes like a regular SIGSEGV. Hell, in Win98 or even XP ENIGMA would probably trow BSOD's with the current stability.

So push the changes to GitHub.

I have. All my changes are in my branch. But there must be a million more. The whole .dll needs to be rewritten to get rid of the unsafe code.

I am doing this release to fix the JoshEdit problems so that egofree is able to build LGM again and people can continue to develop it.

Good to hear.

I read somewhere that one of the developers/contributors would like to see an IDE developed in Enigma; this implies to me that it would be possible, and if it's possible, I would love to get involved.

That was my idea and I think it is certainly possible. We already have about 95% of functionality required for something like that.

Robert, I see that you have basically remade LGM 5x over the past few years and it would have been awesome if you actually managed to finish one. I was the one rumoring that NGM is dead because the repo doesn't have any commits for the past 2 years. I guess you just keep it private (although that requires GitHub subscription).

CLI is the easiest way to make a custom IDE compile a game with ENIGMA. That is why I encourage finishing it, because then HitCoder and other people who want to make an IDE wouldn't have to waste time somehow interfacing with ENIGMA. They would just need to make a writer for EGM which is a trivial format.

And talking about EGM - There are still two things troubling me and I don't think either of them are complicated to finish:
1) Change room data into XML. Hell, eyaml if you have to. Just don't do binary. Copy-paste GMS even. EGM sadly doesn't have version information inside (which is also an idiotic "design decision") so EGM would break with this change. But I don't really care. Just add version info and if there is version info load XML and if there isn't load binary.
2) Make a format that is basically extracted EGM. Just like GMX this is required for version control. Right now I am making a GUI for one of my projects in ENIGMA and have it versioned with git. But it always show up as "binary" even if I do the gitattribute stuff "*.egm diff=zip". That apparently works with docx, but doesn't work for ENIGMA.

edit:

Don't take this the wrong way, but I actually do not agree with the complaints about LateralGM on Windows because of this. Sure LGM may not be designed well for a good plugin, but its problems almost always crop up when used with the ENIGMA plugin on Windows. LateralGM by itself rarely if ever (I've never seen it) segfault on its own all by itself, it's always the ENIGMA plugin crashing it. And this is not just because of LGM's poor plugin architecture it's the generally bad design of the ENIGMA plugin itself.

It doesn't really matter what crashes. When the user opens LGM and it segfaults then of course the only thing he can blame is LGM. That is why the bugs need to be fixed. I have noticed the crashes also happening in different frequencies on different PC's. On my laptop my plugin fixes made crashes almost non-existent (about 1 crash every 3 hours or so). On my home PC on the other hand I get about 4 crashes out of every 5 times I want to compile a project, thus rendering LGM useless.

Why cannot I delete posts?