I don't have a way to commit

Fork...
I don't know why you don't listen to us.

When the editor is set to `system` (or null, which polls system if no internal editor exists), it asks the OS for the EDIT program associated with the resource. Modifying the EDIT program associations of your OS is well beyond the scope of LateralGM/ENIGMA, and being able to change it should be a function of your OS, along with other normal file associations.

Note that on Debian Linux, EDIT file associations is broken, which is 2-part: Java doesn't implement System.EDIT on Debian-based (bug), and Debian-based "edit" command (provided by mailcap) associations may be broken for text files (and possibly some other file types).

Alternatively, you can force LGM to use a program of your choosing by overriding the respective setting (see Wiki:Overriding settings). Obviously we do need a Settings pane to edit all these settings at some point, and it is planned. I'm just much too busy with other stuff, like fixing bugs.

As for the RAM, I've talked to Josh about it in the past, but I don't think we reached any kind of full resolution. Currently, you can't do it via command line. There's supposed to be some sort of file that you can edit to achieve the effect, but we have yet to find where to put said file.

That's what I like to see. I've documented all of this on a wiki page:
http://enigma-dev.org/docs/Wiki/Sprite_editor:Suggestions
I'll get around to it one of these days.

If you haven't taken a look recently, the Sprite Editor is already radically different from GM's.

Ok. I'll make sure to host an lgm.md5 next to lgm16b4.jar. Likewise, you should also find an enigma.md5. We could probably also combine the two, but I'm not a very fast shell scripter. Here's what I've got so far for producing a release:

Code (bash) Select Expand

$ cat release.sh
#!/bin/sh
cp ws-git/LateralGM/lgm16b4.jar Dropbox/Public/enigma-dep/lgm16b4.jar
#should probably make it so `release.sh e` does enigma.jar only.
cp enigma-dev/plugins/enigma.jar Dropbox/Public/enigma-dev/enigma.jar
cd Dropbox/Public/enigma-dep
md5sum lgm16b4.jar > lgm.md5
md5sum enigma.jar > enigma.md5

Edit: And here's one I made after I learned some basic SH scripting

Code (bash) Select Expand

#!/bin/sh
DB=~/Dropbox/Public/enigma-dep

rel_l()
{
  cp ws-git/LateralGM/lgm16b4.jar $DB/lgm16b4.jar
  cd $DB
  md5sum lgm16b4.jar > lgm.md5
  cd -
}
rel_e()
{
  cp enigma-dev/plugins/enigma.jar $DB/enigma.jar
  cd $DB
  md5sum enigma.jar > enigma.md5
  cd -
}

if [ "$#" -gt "0" ]; then
echo $1 | grep l > /dev/null 2>&1
if [ $? = 0 ]; then
  rel_l
fi
echo $1 | grep e > /dev/null 2>&1
if [ $? = 0 ]; then
  rel_e
fi
fi


Kind of annoying that md5sum also outputs the directory, otherwise I could probably simplify it a lot.

The Sprite editor could use for several improvements. I'd greatly appreciate if people drew up proposals for what they'd like to see the Sprite editor look like. Otherwise, I'm just sorta fumbling around occasionally adding a button or such.

(Note the Sprite editor is not the Image editor)

Hey Harri, we might be able to get more people on Windows to try and hack something together if we collaborate on what we've been able to get so far.

If you would, update this wiki page http://enigma-dev.org/docs/Wiki/Install:Git:Windows with what you've done so far. I populated it with the furthest I was able to get.

Your 7zip extracts to 600 MB...

We're pretty much all in agreement with regards to the jars. I'm not sure about wgetting them from the makefile though - it's not that simple. The jars update occasionally - maybe once every 5-10 revisions. This means that we might not want to fetch them every time the user invokes make, because that would add an additional download time that usually just results in the same jars. We obviously don't want to do it as a 1-time thing because sometimes the updates are critical. We'd probably want some sort of intermediary to determine if the jars should be updated. Fetch some small information that determines the latest version, and compares it to the user's current version.

If I wanted, I could recommit them. The issue is that I'm afraid he's right; some of those files just shouldn't be in the repository. We ought instead to include them with releases as needed. The issue is creating a release mechanism around git.

This is my stance as well. I think it sums up the problem pretty nicely.

Also, to clarify, Rusky didn't just delete the files. He deleted the history of the files. In essense, he made it so they never existed on the git repository. The reason is because, when you clone (svn "check out") a repository, you are fetching the entire history of the repository. You can delete a file, and that's all well and good, but a phantom of the file is still there, so that you can roll back to it. As a result, these phantoms make the repository larger, and when you're dealing with binaries, like jars, every time that file changes, the entire binary is re-added to the repository, since you can't just do a simple `diff` like on text files. As such, histories of binaries causes repositories to quickly bloat to a size somewhat similar to Josh.
Instead, binaries like LateralGM, which have their own histories, and don't need an additional binary history, are not included in binary form. Instead, they have their own source repository. As for how they are distributed to team members, that requires some decision - either they can be downloaded in binary form, or built from source - and this is really just a team decision: in what way can I best facilitate my team?
As for releases, we just build all the sources that we can, clump the binaries together, and distribute it. Not a big deal. The only question that remains then is how to distribute updates.

*shrug* We don't get paid enough.

Hey Josh, what do you think about increasing product price by, say, 10% to facilitate communication training, policies, and organization?

Harri, you can fork the repository and then submit pull requests when you're ready to share something.

I'd add you myself, but either I don't have that ability, or I can't find the button.

It's not that git can't store binaries so much as rusky didn't want us storing binaries because it makes the repository huge and slow. Anyways, as long as we have the problem identified we can begin to move on from it.

As for your parser, as with anything, just because it's there doesn't mean they will use it. They probably already have their own parsers. Yours needs to bring something to the table that theirs doesn't have. Like modularity. Bitches love modularity.

Also, not sure that ideka was saying we should use mercurial or just sharing a Svn-to-distributed ideology brain-unscrambling link.

DarkAceZ: like I said, `make` would probably fix it.

I believe the Parse fail only relates to fetching the main compiler to compile ENIGMA's dll. If the dll is already built (you can build it yourself by invoking `make` on the command line), then the parse fail doesn't matter, because it doesn't need to automatically invoke make, since we already manually invoked it.