The fewer dependencies, the better imho.

Right. A few requests do need to have the line drawn. I think a good approach for these dependency-hogging features is the plugin concept. Natively, they are not a part of LateralGM, but if the user opts to include them somehow, the functionality becomes available. This also brings in the idea of some sort of package (e.g. possibly through TGMG's package manager) which allows the user convenient ways to determine whether it will be a minimal install or which extensions will be available for use. These are all features, since the core sound-playing functionalities are already there, so not being able to play additional sound types (such as OGG, MP3) is a feature request, not a bug.
A bug, on the other hand, would be if a button is available for some ability (like RTF stuff) but does nothing (either because we have not implemented it yet or because it would require a library dependency or heavy code for a small feature). In those cases, use your discretion to determine whether the button should be implemented or whether the button should be removed - keeping in mind whether GM supports it or not and whether that would be a big deal or not.

I am not able to really decide how best to abstract this and was hoping for help from you or Josh because I didn't know whether to make generic completion classes or if each marker should implement its own or what to do.

I think Josh handled the syntaxes. He would probably have the most valuable input. If he can't help you, my suggestion is to just go with whichever seems most logical. A refactor of some of the internals of that system is always an option here, since that particular system was kind of hacked together as a replacement for JEdit, and I found that I frequently had to adjust it to meet my requirements where JEdit had better support for it before.


When you have architectural questions, like these, each architectural person has their own preferred avenues of contact. Since I'm not able to actively monitor the forums, irc, wiki, or tickets (due to a mismatch of my available time and the quantity of information on them), I'm going to say the best way to contact me with architectural questions is to email me (although you're free to reference whatever wiki, forum post, ticket, etc you need to in your email). I usually respond very quickly to emails. I think that's why some tickets may go ignored by me while others get an instant response is because some of them get forwarded to my inbox.

Do not mistake my language for emotion or a rant. It is a thoroughly thought out manifesto for my LateralGM and the direction I hope to see it go. The warning within my post is not an attack on you, Robert, and the fact that you feel the need to defend yourself from it - by retributing and attacking my character - makes me wonder if perhaps you are aware of more of your own shortcomings on these topics than I am. I'm also curious what kind of propaganda I'm advocating for here, since it's not like I have a competing product that I'm trying to steal your users over to.

That said, I do forgive you if you felt the language was directed - because it was, just not at you. It was directed at the developers of a number of other projects (like G-Java) that have failed for those reasons. I do not question your commitment to the quality of LateralGM. The warning to you in my post is not "you have caused these problems with LateralGM", but rather, "While you have not yet caused these problems, you are also not acutely aware of them, so here I lay them out so that you can better understand and avoid them." That is to say, while before I may have been the lead to help steer what needs to be addressed, and help refocus efforts when they drifted a little bit - I simply do not have the time to babysit LateralGM's direction anymore, so I've laid out this manifesto in hopes that it makes that direction more clear.

The open bugs concern may be an exception to this, but it may also have been due to a misunderstanding in process. I'll address this in a moment.


I'll now respond to some of your comments:

This is exactly why I have decided to leave it where it is with the GMK format, and move on to the new GMX format for RadialGM and leave GMK in the dust

This was an edge case, and I believe you handled this admirably. Again, you continue to demonstrate your commitment to quality, and your ability to devote such great thought to the file format is one of the main reasons I can endorse you. And now you can see that it's a higher priority so if you do see it drifting from this, you know when to correct for this and fix the format.

As over simplified as that may be, you just can't fix all of the bugs either, that is an unrealistic goal

I agree, and I mentioned this in the post as well.

a few of the bugs are the fault of the JDK itself.

Aware. When it comes to those, address them how you like, but try hard to hack around them. You might find a few places where I document my hacks around the JDK's shortcomings or bugs. Usually what I do is make sure the JDK has an open ticket for it, find a/the workaround (usually in the ticket), and use it (with a link to the ticket so the workaround can be removed whenever the Java gets around to fixing it). One thing I've learned in the workplace is that, when you get a ticket that you'd rather just leave behind, the best approach is to just buckle down and give it a go (that is, try to fix it anyways). Once you know that you've put an effort into it, if you can't fix it, that's fine, say so in the ticket and either close it (if it's not a big enough deal) or leave it in hopes someone else can pick it up. Of course, for those, remember you can always ask me for help, as I have a lot of valuable "architectural" insights into the more complex tickets.

Every release for the past two months has been solid bug fixes

This is just a difference of opinion on what's a bug and what's a feature. Not a big deal - glad you know that bugs are a priority. (For example, I often consider support for newer versions of GM as a "feature" until the version has been around for a while, and then it might become a "bug" - completely subjective... there might be a better process for that - heck, maybe even you know of it - so I'm not judging)

so fix your bugs or else I will do so

(The open bugs concern) The misunderstanding here was probably because a lot of the open tickets are difficult things that I don't really trust others to fix reliably, since I designed it, so pretty much I'm the only one who knows how the system works/should work. As I don't have time to work on them, it was hoped that I'd find a free weekend (or, more realistically, a free week) to get to them, but that never happened, so those tickets sat stale forever. Sorry if I take those tickets out on you, I understand your hesitation to take them on when they obviously have my name on them. However, with you in charge now, they are your tickets now, to do as you want with them. Don't be afraid to do a crappy job with them - you can fix bugs as they come up. I just have 2 small suggestions/requests:
1) You can/should consult with me about the best way to approach them if the ticket doesn't make it crystal clear. I obviously don't document exactly my plans for things when I make a ticket for them since I usually figure I'm the only one who will work on it, so the ticket can sometimes be a less-than-descript reminder.
2) As you close off the tickets, especially if you feel your solution isn't a rock-solid facsimile of what I had envisioned, be so kind as to document it somewhere where those things can be grouped together (e.g. the wiki) so that I might be able to look it over when I get a chance. If nothing else, just have one page where you link to each of the tickets.

The second point is really what the whole "review before I pull your code" was for - mostly just for me to get a chance to look at how you addressed certain things that concerned me. What I've learned is that doing that, while ensuring you have a rock-solid product, will also slow development to a crawl. Realistically, we can tolerate a few bugs here or there when they spring up, and that's why we have a ticket system to report those bugs and developers to fix them. This can also create smaller/easier bugs for less experienced developers to take on and get a foot into LateralGM.

As of today, I'm officially endorsing Robert B Colton as the maintainer of LateralGM. My hope is that this will allow speedier development availability to the public due to less administrative overhead from having to go through me.

I'm aware this is a controversial move, but I have made it clear that I am unable to continue maintaining LateralGM due to a lack of time and a refocus of priorities. As a result, with me being the sole maintainer of LGM, it has stagnated and has been unable to compete with the products that it is intended to compete with, while Robert's fork has advanced a whole slew of new features with the future in mind.

Personally, I'm not a fan of Robert's software development methodology, and he has a lot to learn, but his commitment to the product is ineffable and, with me no longer available, I see no other way.



That said, my methodology and intentions with the product are explained in a few places, but I will restate them here in hopes that maybe Robert will listen and lead LateralGM to a solid future and not turn it into vaporware or such.

* First and foremost, LateralGM was created as a tool for dealing with the Game Maker file format. A vast majority of the users of LateralGM look to it as a way to open their GM files, especially their corrupted files. As such, this is the core of our product and it is never to stop functioning. Likewise, if LGM corrupts files, this is a critical failure.

* Secondly and finally, LateralGM has succeeded by learning from the mistakes of other products. This was the driving force behind LateralGM becoming a full-fledged IDE and not just a file-format tool - to deal with the shortcomings of Game Maker.

The reason it succeeded was because I saw where other products failed - such as G-Java and G-Creator. In my opinion, the reason they failed was because they focused on features and not core functionality. They had some fantastic and admirable features that looked very futuristic and fancy, some of which would be awesome to add to LateralGM, but without a solid foundation/core, it was just feature vaporware. As such, LateralGM learned 2 things. First, develop a solid core, and make sure it never breaks. Second, Features are second-class citizens, releases are first:

So declare the set of features you would like to see in a release, and then be ready to declare feature freeze - a time in development when you will introduce no new features into a release and will instead focus on fixing ALL the known bugs before that release. This is extremely difficult, because features are fun and leftover bugs are a pain, but it's also extremely necessary. Leaving bugs behind is what GameMaker does, not LateralGM. That said, some bugs aren't worth fixing, but they are rare.

A release is not "I've made a bunch of features guys, here, have a release so you can check them out." - that's what a prototype is for, and that's what Feature Freeze beta is for. You've made a bunch of neat features, congratulations, now fix all the leftover bugs and THEN you can declare a release.


Are there improvements to this method? Sure. But we don't have the manpower for it. From being in the workplace, I've learned a few things about software development methodologies and releases that more manpower affords you. We can't just truck through releases like they do - we need to buckle down and focus on what we said would be in the current release, or else officially bump it with good reason and update your roadmap.


I miss working on LateralGM and working with you guys. It was a lot of fun. I wish I still had the time to work on it. Maybe some day I will find some time - believe me, I've been thinking hard on ways to factor it in. If and when that happens, I can't say if I'll continue development in my own fork from the old code (where I left off) or if I pick up Robert's code and try to deal with our differences. But one thing's for sure - at this point in time, there's only 1 thing about LateralGM that I care about and that concerns me, and that's the list of open bugs. Those bugs need to be fixed, and if they're not and we keep releasing features, we are headed down the same path as G-Creator.

The IDE was a separate project from enigma. By doing this you can fairly easily swap out either the ide or the compiler. So if someone wants to take up the hilt of writing a very new and different ide and can actually make it work (the big if) then enigma could just as easily use that. LateralGM as a project saw where other projects (g-java, g-creator) failed by obsessing over features and novelty and neglecting core functionality, and decided to take a different approach: use a design that works, and focus on core functionality and compatibility first. In doing so, we successfully became the first actually usable ide for enigma. Once we are confident in lateralgm's capabilities, then we can start adding really cool features and really breaking away from the familiar old gm design.

I hope that answers your question :-)

The entire LateralGM front-end is based on Swing, meaning that you would have replace all of that.
Note, LateralGM does have MVC, so you'd only be replacing the Presentation-tier, but still, for an IDE, that's a significant portion of the project.
When LGM was still young (back when "mobile" meant flip-phone), I did flirt with the idea of a web-app version of LGM, but put the idea on the back-burner because it meant some research into how to handle the files - and getting LGM working at all was a main priority, which meant a lot of Swing work one way or the other.

Like polygone said, indexes should probably have started at 1 and used 0 for 'noone' when GM was designed.
The reason why -4 is used for noone is because 0 corresponds to object0 (or whatever it has been renamed to - or the oldest object after using ID Defragging). -1 corresponds to self, I believe, and so on.

As our administration advances in life, persons like myself and Josh gain more finanial power, meaning we have more capability to actually start a lawsuit if we wanted to. When we were earlier in this project and were licensing it, we were much too young and powerless for that to be a real concern. That said, while we "can" be trusted not to sue, it should not be a matter of trust - basically everything josh just said.

So I agree that a license exception is absolutely necessary to ensure that our game developers can closed source their games (even if we may not feel it is completely necessary, it is still common practice and we would like to cater to those persons still) without having to worry about us potentially suing them.

That the exception must only apply to an "official" ENIGMA has never been something I feel is necessary. I see nothing wrong with a $49.99 AMGINE springing up, since its code would have to be GPL, meaning that we (or anyone) could easily copy their changes or fork their product and distribute it for free (once we get our hands on a copy, that is).

That said, while I do not feel the "official" route is necessary, I still don't object to it. I understand Josh feels it is necessary, and as this product is Josh's brain-child, I'm cool with signing off on an exception with that condition.

But that's also why I'm not jumping at the opportunity to write up the legalese, even though I am pretty well known for a good understanding of legalese. Without a concrete desire to add such a restriction, I don't understand the restriction well enough to have any ideas how to write it.

Your 2-modes idea was kind of what we were planning with the Batch Tiles tab. It was just difficult to get the two interfaces (objects and tiles) to look similar enough to implement it for both of them, so I only started on it for Tiles, and I'm not sure how it would be done for Objects.

That said, the room frame is very modular. If someone wants to completely redesign only the widget interface, they can do that without needing to touch the actual room editor (the area with the grid and the actual instances and tiles and such) - so there would be no need to replace the whole thing with a new one, since, unless the person doing that (here Robert) has some sort of secret plan that they haven't told us of, he's just going to end up with something very similar to what already exists - assuming it works at all.
I'd like to see some buttons to do the common bulk tasks, if possible.

Now, what you've described is a bit of a different direction than I was planning. I'm trying to avoid fancy mouse movements at first, since they're hard to program, hard to document, unintuitive, and not very modular - they get hard-coded into the Room Editor, which just complicates that code even more.

I wrote the article, and was never able to get it to work completely, but to answer your question:

So copy MacOSX/Android - where? I copy it to trunk/ENIGMAsystem/SHELL/Makefiles/Linux, but it is probably is wrong

That is correct. You will have a Linux/Android and a Linux/AndroidSym.

Looks good. This information should go on the wiki, under something like ENIGMA:Developing

It's called Bus Factor.

[JOSH-EDIT:]

Can we try to keep this on topic? If you want to discuss aa smoothing, do so in another topic.

JOSH-EDIT: Split the topic. Posts about AA are now in THIS topic.

Also, if you've already made some code, but haven't committed it yet, but are ready to, you can still checkout the branch. So the first two steps can be done out of order.
So for example, I'm going to start moving mouse_x and mouse_y. I'm not sure how much work is involved, but it seems fairly simple. So I'm on master, I start work, and then the end of the day rolls around and I realize that I'm going to have to commit broken code. That's ok, just

Code Select Expand

git checkout -b moving_mouse and then

Code Select Expand

git commit -m "moving mouse. Shit done broke."

If, however, you already committed to master (but haven't pushed hopefully), not a big deal, just a couple more steps. Create your branch. At this point, both master and the branch will have the commit. We don't want master to have the commit yet, so we're going to roll him back. If you have any uncommitted changes, please make sure to commit or shelve them first, as they will be lost.

Code Select Expand

git checkout master
git reset --hard HEAD^
git checkout moving_mouse
Add more carets after HEAD according to how many commits you made (e.g. 2 commits = HEAD^^). Alternatively, you can just name the commit before yours in place of HEAD^.

Binaries don't go on a repository. Repositories do diffs for version control. A diff doesn't make sense on a binary, so every time you put in a new binary (e.g. jar), it adds another mb of diff to the repository (assuming the binary is 1 mb), so whenever someone tries to checkout or otherwise work with the repository, they have to download the entire history, which includes every single version of every single binary that ever existed in the repository.

Our packaging system uses simple urls (and a hash). This means that it doesn't matter where you put the binary, as long as you link it and provide an updated hash. We've just been using dropbox since it's been the most convenient option for us. I think Josh has indicated that he wants to see the server itself build and deliver the binaries, and I think this is a good idea as well, it's just that it is a bit of an undertakin since building LateralGM and the Plugin is not a very automatible task.

Also, our packaging system partitions everything into individual binaries, so you don't need to upload everything at once. If you build LGM, you only upload LGM, and update the url (if necessary) and hash.

Sounds good to me. Just beware before you throw EnigmaBot up on the github, as I know for a fact that he stores his credentials in either a plaintext file or hardcoded, which gets "distributed" right along with him. This information would naturally need to be censored. Otherwise, I'd like to see him AND thundercleese (thevalog) up on version control so that we can begin merging them. Again, censoring where appropriate with thundercleese.