I totally understand and agree with having some files external to LateralGM in order to override LGM's default behavior in a user-friendly way. I could never figure out a good way to do that. One possible way is to provide the files (or even LateralGM) as a zip *alternative* to users who want that, but it might not be able to place the right files in the right places, since some files may belong in a different directory (and also limitations that I'll detail in the next paragraph).
Whatever the case, I do believe the single-file has value to many users, which is why I strongly continue to try to preserve it. First, it affords us the ability to easily store LateralGM on certain mediums without adding write permissions requirements to that medium (for example, a CD). Second, it's super convenient for users to download 1 file and run it. Even easier is moving it around - one file to move, without needing to worry about if it has any other file dependencies or if the registry is expecting it to be located in one location.

I've done a lot of work on trying to get LateralGM to honor external files in logical locations. For reference, please read the wiki page on LateralGM's WorkDir:
www.enigma-dev.org/docs/Wiki/LateralGM:Workdir
A little work still needs to be done in some spots, but most importantly, we need some way to increase the visibility of these locations.
A few solutions that I've seen other programs do that I like:
* Attempt to create those directories. An installer will often handle this, but I want to avoid requiring an installer. LGM could try to create those directories, probably with the user's permission, and if it's even possible.
* Give in-program easy links/access to those directories. Commonly a button or link will open the user's file browser pointed to the directory. You'd just need a good spot to put this button (or these buttons)

Whatever the solution, we should try to keep it as platform-independant as possible. If it doesn't work on one platform, that's fine, skip it and continue - and let LGM still continue to try and work on that platform.

The code in ENIGMA is currently licensed under the GPL3+. This is code contributed by many talented programmers, each individually having their code licensed (or relicensed) to the GPL3+. Relicensing an entire product is not a trivial matter, and even less trivial due to its current license. Relicensing ENIGMA (or LateralGM) would require *every single code contributor* to agree to have their contributions relicensed to the new license. It cannot be done democratically (with a vote). If any single developer does not agree, their code is stuck to the old license, meaning you either have to give up or scrap *all* of their code. Which could potentially leave the product broken, so you'd have to have someone rewrite those code sections from scratch using the new license (or compatible), and it can't be identical to the old code.

I completely agree with everything you've written above. The only thing I would add is: We're talking about relicensing ENIGMA's engine code, the code that would be redistributed in executable form with a compiled game. LateralGM and the parser/compiler would and should remain GPL licensed. I don't think anyone is arguing otherwise.

Was just providing LGM as an example of another GPL project in which relicensing would be difficult. I know you guys never mentioned it, but I did recently get a private message from someone asking if I'd be interested in relicensing LGM. Also, for the record, even though LGM and ENIGMA are separate projects, they do interact together and are used together. In order for this interaction to occur, they require either compatible licenses or licenses that permit this interaction. I don't recall exactly how far this goes, but it could be worth looking into to ensure that you don't have to abandon LGM as the interface just because you chose a more permissive license!

For example, I am a well-known contributor to some of the modules in ENIGMA. You'll see my name appear at the top of some files. I for one intentionally wrote my code with the GPL3+ license (with option for a special exception for the games). I do NOT consent to having my code relicensed to the BSD or MIT licenses. I do not want a permissive license, as I do not want to see a proprietary competitor to ENIGMA stealing ENIGMA's code and not sharing their own improvements (which I think Josh mentioned).

I see the MPL v2 as a fair compromise between the GPL v3 and a permissive license like the BSD or MIT license. The MPL is still a copyleft license like the GPL, but it allows for linking non-MPL code to MPL code. It's just as viral as the GPL except where linking is concerned. It was designed with the purpose of being a bridge between copyleft licensed code all other types of licensed/proprietary code.

However, it's not my intention to get into another long-running debate over licenses. I can understand why most people wouldn't want to comb through so many pages of discussion to arrive at a license choice. I've got an idea that should simplify the discussion, but I'll need everyone's help to implement it. I'll post more about it soon.

If you guys decide to go with MPL2, I'll consider it.

That's all from me for now. Proceed :-)

I haven't heard anything about that, but Josh and I did some pretty thorough testing of the vulnerability to verify if we were vulnerable before and after an update, and we were able to verify that we were not vulnerable afterwards by any of our battery of tests - while bash was exhibiting symptoms prior to the upgrade. Perhaps we got both patches, or they patched the patch. Whatever the case, we pass the best battery of tests we could find.

If you haven't heard the news, another security vulnerability probably worse than Heartbleed has been discovered in Bash.
With it, an attacker can craft a very simple http response and have your server run arbitrary code.

As soon as we heard the news, we immediately tested it and updated bash to the latest patched version, just to be sure.

We do not believe our server was vulnerable to these types of attacks, as our apache does not seem to interact with Bash in that way. Our bash was indeed vulnerable, but again, nothing seemed to use it, so no harm there.

Other sites may still be vulnerable. An attack could publish database information, files, and other requests from users. This means that an attacker could gain access to passwords, credit card information, and public keys, even if the server isn't storing them - just from the fact that they are sent over the net to the server at some point.

Standard security precautions are recommended. Change your passwords regularly. Be careful where you enter your credit card information, and frequently monitor your account transactions and statements.

I haven't read through this entire thread, so forgive me if this has already been mentioned.

The code in ENIGMA is currently licensed under the GPL3+. This is code contributed by many talented programmers, each individually having their code licensed (or relicensed) to the GPL3+. Relicensing an entire product is not a trivial matter, and even less trivial due to its current license. Relicensing ENIGMA (or LateralGM) would require *every single code contributor* to agree to have their contributions relicensed to the new license. It cannot be done democratically (with a vote). If any single developer does not agree, their code is stuck to the old license, meaning you either have to give up or scrap *all* of their code. Which could potentially leave the product broken, so you'd have to have someone rewrite those code sections from scratch using the new license (or compatible), and it can't be identical to the old code.

For example, I am a well-known contributor to some of the modules in ENIGMA. You'll see my name appear at the top of some files. I for one intentionally wrote my code with the GPL3+ license (with option for a special exception for the games). I do NOT consent to having my code relicensed to the BSD or MIT licenses. I do not want a permissive license, as I do not want to see a proprietary competitor to ENIGMA stealing ENIGMA's code and not sharing their own improvements (which I think Josh mentioned).

Our wiki has a good deal of information to help you with developing LGM. For starters, getting the code set up for dev initially is documented here:
http://enigma-dev.org/docs/Wiki/LateralGM:Developing

Understanding the layout of the code is the next task, documented here:
http://enigma-dev.org/docs/Wiki/LateralGM:Packages

All of the file-handling code is contained within /org/lateralgm/file/
All of the frame code for e.g. the frame shon for editing a Room or an Object is contained within /org/lateralgm/subfarmes/
All of our custom components, like custom widgets like the ResourceMenu and IntegerField, are in /org/lateralgm/components/


While LGM was designed to be cross-platform, and mobile devices technically support it (since it is Java), I never considered it worthwhile to do, due to the extreme limitations of mobile platforms (such as the lack of a normal keyboard or two-button mouse) which make IDEs on them less-than-trivial. So while you're welcome to do it, and I'm certainly not going to stop you, I'd just discourage it because it seems silly. Instead, you might try shifting your efforts towards getting games to compile for mobile devices (enigma-side).

Looks great. I've always wanted to make the object code more easily accessible. My first thought was to replace the action list and DND panel with a code editor, but it'd be tight. My next thought was to consolidate the event selector into some sort of combo box or something in the toolbar of the code editor, and make the Object Properties be minimizable somehow. Being able to quickly navigate to an object's event from the tree sounds appealing.

Two things:
* What does "Filter Tree" mean?
* Regex.

Awesome work! Definitely looking forward to these features. This should make the interface a lot cleaner and bring it up to date with most other IDEs, making it look that much more professional. When I had designed the settings frame, the first priority was to just get it working and working well - function over fashion - and that task was achieved. It's nice to see the more-than-capable hands of Robert and Co. bringing their creative visions to even this easily-neglected interface.

My only request/reminder is that if you do take out the enigma plugin, and just have a vanilla LateralGM, that none of those enigma-specific settings show up and the interface still looks clean and usable. Although I'm sure that you already thought of that and I'd be curious to see the system you set up to achieve it, since the swing layouts I designed always seemed to end up being set in stone and unable to be modified easily with plugins.

Yes, Josh. LGM doesn't quite fully honor the spirit of EGM yet. There's an experimental textual format for rooms, but nobody's working on it currently, so to avoid scope creeping that into a simple "let's add a checkbox", egofree just added the setting into the rooms binary format.

Of course, to complicate the matter, the room binary format isn't even versioned, so this was inevitable. As ego said, I said I'd deal with any issues that arise, but it looks like ego beat me to the punch.

* Deleting and shifting all instances/tiles are bulk operations and are not performed frequently, and the operations should ideally be global (independent of the tab).
* The Toolbar is for convenient access to frequently used things.

Therefore, the toolbar is not the best place for these two actions. I agree with Robert, it is rather unintuitive to have to switch to the Tiles tab for a toolbar button to delete all tiles.

Move the buttons. Either into their respective tabs, or into an Actions menu.


Also, I'm seeing that the Objects tab is starting to get cluttered. We should think of some ways to improve and declutter it.


Oh, and one more thing: NPE if you click on the Instance List with no instances present.

If these properties are in GM:Studio, it would be reasonable to hard-code them directly in LGM, rather than appending them to the property list.
If they are not, and are intended to only be in ENIGMA, then your solution seems sufficient. Hopefully everything is in place to make this possible.

I volunteer to deal with anybody who needs a converter.

DirectPlay had a few things going for it:
* The ability to sniff games over a LAN.
* Global storage of variables
These are things that I was never able to figure out in Berkeley, and especially LAN sniffing is extremely useful. Minecraft has this ability (even on linux), and it's used a LOT.

Frankly, I don't care if you port mplay as-is or not. DirectPlay is dead - decaying, and touching it is likely to give you and all your players the bubonic plague. I also don't care if you re-imagine multiplayer and build some fancy new multiplayer library. But one thing is for sure, DirectPlay gave us some really fancy features that made it usable and make ours unusable. At the very least, we need to offer some usability features, and I really want to see LAN play.

That was probably an oversight on my part. LGM always creates a backup of the game (gb1) before saving overtop of the original file. This was only intended for GM files and was not intended or thought out for egm files. You'll just have to deal with it for now. I can think of a few workarounds, but deciding on a proper way to handle backups would require some architecture and refactoring.
Perhaps for the time being, we could only create a gb1 file if the extension was gm*. It'd be a hack, but very easy to undo for the refactor.

The file is created by FileChooser.pushBackups().

I don't see how it would cause problems, though.

I was able to assist him via email.