Great. I also thank Ism and Josh for this (and Gary and a2h).

On a related note: Is there a way I could get to wiki's sql? I don't want to modify anything, but I am trying to create a manual type of thing and what I do now is get the whole page and just cut out the article. It would be a lot faster, less bandwidth intensive and easier if I could get the article from the database at the first place. Maybe some read only account could be made (is there even such a thing)?

Consider using the wiki's bot API. It won't get you direct access to the mysql, but it will bypass the parser that generates the html for the page.
http://enigma-dev.org/docs/wiki/api.php?action=query&prop=revisions&rvprop=content&rvlimit=1&format=xml&titles=<<PageTitleGoesHere>>

Get a job :-p
I pay rent of > $200 a month, internet of $65/mo, electric of $50/mo. An extra $20 wouldn't hurt me.

I'd like to have the LGM mantis hosted closer to enigma-dev.org, and I'd be more than happy to share with ENIGMA. Mantis makes this easy. Due to the low quantity of bugs on the mantis at this point, I would not object to starting over from scratch.

However, I think before we go hosting another app on our host, we should get our webhost issues straightened out, even if that means moving to a dedicated server.

I'm fine with keeping them separate. I think I'll start a template for easily linking to the mantis.
Just be aware that I usually try to address Mantis bugs first unless they're really trivial things that I agree with.

I suppose GM-incompatible features can be classified in three categories:

You only listed two.

Missing msys-regex-1.dll? Sounds like something for Josh to look at/help you with. Sounds like an important dll that you're going to need that didn't get installed for some reason.

My response was before you mentioned a preference towards the wiki, so now I'm responding to that.

I think it could be made to work. All the detailed information about a bug could be filled in as it becomes available, meaning that you can either file a quick bug or a detailed bug. The big issue would be figuring out how to get a good overview of the bugs. I mean, it's going to be one of the following:
* Every bug listed on one page under categorical headers. This quickly becomes unmaintainable. Can't fill in significant details about the bug. Have to page down several times reading each bug to get to a specific one. Obviously this is not the way it would be done. Maybe just for quick backlog bugs for when there's not enough info to start a new bug page.
* Every bug has its own page. This is great, but then we have the issue of where the central database of these bugs is. How do I see what bugs there are? It would have to be one or more of the following:
** Bug Category. Lists all the bugs (or at least the ones that bothered to use the {{bug}} tag). Unfortunately, it only lists them as page names in alphabetical order. There is no indication of their status, etc.
** Bug Categories. Different category tags for different states of bugs. But usually I like to see all the bugs together, and be able to filter out, say, the closed bugs. If I'm looking for a specific bug, I probably won't remember what state it's in, except that it's not closed, because they're changing states all the time.
** Maintained List/Table. This isn't going to happen unless you write a bot to do it.

Basically, I want this: https://sourceforge.net/apps/mantisbt/lateralgm/view_all_bug_page.php
and this: https://sourceforge.net/apps/mantisbt/lateralgm/view.php?id=24

I use Mantis for the LGM tracker because of the features it affords me that Spray sorely lacks - plus Spray has pretty much stopped being developed. I like mantis because it's really descriptive about bugs, letting you know exactly what they affect, what state of fixingness they are in, if they relate to other bugs, and how crippling they are (or if they're a feature request). Unfortunately, this quantity of information also means that it takes a little bit of time to file a bug, so people who encounter a NullPointerException when clicking a button decide to do whatever they were doing through another route rather than fill out the bug form, or they tell me and then I forget. This is where the wiki/forums can came in handy, because it provides people a quick way to report bugs without having to fill out the form. I don't really consider it a non-consensus, just a second backlog of bugs that have yet to be reported on the mantis because people are too lazy to fill out the forms for them. Every now and then, I'll skim through the list, and if I find something important, I'll fill out a mantis bug for it.

LGM preferences:
* Mantis: Bug goes here.
* Wiki: Can be a good place to quickly post bugs when you can't be assed to fill out the form. Essentially a backlog of bugs that still need to be picked through and transcribed into an actual mantis bug.
* Forum: Great for collaboratively discussing ideas or problems. Find out if something is really a bug, and come up with ideas on how to implement something or how to fix a bug. NOT an actual bug report.
* IRC: Great for bouncing ideas or errors off me to see if it's just user stupidity or a bug. If you know it's a bug, don't put it here. We'll forget. Occasionally, it's really simple, or something relevant to what we're working on, so we'll be able to fix it real quick - but don't count on it. I forget. End of story.
* Spray (when you click the Tracker link at the top of ENIGMA pages): LGM doesn't use this because it is inferior. LGM bugs should be reported elsewhere.
* Email: Yeah, no.

Plugin Preferences:
Since I'm always working on the plugin, if you find a bug with it (which is hard to do, since it's such a stable and small module, but it does happen), the IRC is sufficient. If I can't get to it, it usually gets logged on the Wiki so I don't forget.

If ENIGMA can support it, LGM support won't be far behind.
At some point, though, before we start mass introducing these GM-incompatible features, we need some proposals on how to deal with when the user tries to press "Save As GMK" on a game full of EGM-specific features... This is not the topic to discuss that, though.

From what site? You shouldn't use the LGM from lateralgm.org unless you are planning to use it by itself (e.g. no compiler). ENIGMA has its own branded LGM. You should only obtain the ENIGMA LGM through standard ENIGMA installation procedures or through an SVN client (or svn command line).

It should still work despite the update. Actually, come to think of it, if it actually updated lgm16b4.jar it should have asked for a restart. Seeing as it doesn't appear to have, the update must have decided to skip it for whatever reason.

It looks like lgm16b4.jar has been modified. If it's not trampling your changes and updating it (which it should be - I'll have to run some tests and found out why), then in order to make it stop asking to update, either disable automatic updates, or revert lgm16b4.jar. If you have subversion installed and in your path, you can do this from the command line as follows:

Code Select Expand

cd C:\Users\Joshua\Desktop\ENIGMA-R4-r822-win
svn revert lgm16b4.jar

If it has been modified for an intentional reason, I would encourage you to find another way to get those changes externally, or else disable automatic updates.

The LGMLAF.jar error can be ignored. It's caused by some internal mechanics in ENIGMA.exe (l*.jar) and nobody has a good proposal for how to fix it. Not sure where your LGMLAF.jar came from or what purpose it serves, but to avoid that problem in the future, don't put anything that matches the filename l*.jar in the enigma/ directory. Rename it to something else, or move it somewhere else, or continue to ignore the error.

If ENIGMA isn't ready, it means ENIGMA isn't ready, so just wait longer. In this case, ENIGMA isn't going to be ready until a short while after you answer the "Install updates?" dialog, after which it rebuilds and then either fails (and reports the problem) or succeeds and is ready.

Constantly needing an update is an indication that your version became unsynchronized with our updates somehow, and the updater couldn't figure out how to update it. This is sometimes caused by conflicting changes -- e.g. you changed some file. The exact nature of the issue should be reported in the full scrollback of the terminal. Please paste/pastebin that and share it here. We do have plans to improve this process down the road, but for now, I'd like to know exactly where it's going wrong so I know of good ways to deal with those issues.

I don't see how that would even work. 1) You lose the reference to the ds_list, 2) You try to store a non-ds_list object in a ds_list variable, 3) That doesn't even touch the ds_list, let alone perform a replace on it.
You must be missing something. ds_lists[id][size] = val maybe.

It's been on the wiki since May 22nd: http://enigma-dev.org/docs/Wiki/Command_line_interface