ENIGMA R4

[Brett]

Thanks for the reply, I'll check back about a week and see progress. Once I get it, I'm planning on adding to the function list (coding functions in c++)


Cheers
~~Brett

[RetroX]

Speaking of packages, I've decided to make a compromise.  I've modified unipkg to work with compiling for multiple architectures and multiple package formats, including pacman, debian, and slackware (it was there, so, I made it work properly).  If anyone has the sanity to work on an RPM package, go ahead, but I won't for now.

Right now, I just have to run build-enigma and it compiles all of the packages for me at the latest revisions.  If Josh or someone on the ENIGMA team could upload them to sourceforge (under files, not on the SVN) once I finish building them, that would be nice.

[Rusky]

@retep: That worked.
@Josh: Thanks, will do.

Edit: the build system has issues on Windows. The error is "sh: C:\Program: No such file or directory." I'm looking into it, but I don't know enough about the system.

[Josh @ Dreamland]

Oh, er, well. Never mind then. Someone was having problems where the DLL was right there but LGM couldn't find it unless the JRE was pointed right to it via command line.

[IsmAvatar]

I've committed a working and tested updater, but I wouldn't use it, partly because update doesn't work (due to a bug I'm trying to fix, but first time checkout works and checks out the latest revision), but mainly because it sleeps until the update and make is done, which takes long enough that the user would probably think that LGM froze.
I've also committed the latest LGM, which replaces the infamous "ZOMG ERROR JNA ISN'T A PLUGIN, LGM IS GONNA ASPLODE" with "Info: jna.jar is not an LGM plugin: null: No plugin entry point (LGM-Plugin)" along with a minor bugfix.

Stay tuned for more progress.

[IsmAvatar]

r346 fixed the update part of the updater. Also r348 now displays the Make output in a GUI frame and to stdout. Be aware that checkout/update may take a moment, and during that time you will still have no indication of progress, but look at the console, and if you don't see errors, you can assume it's moving along. It shouldn't take too long. `Make` is the longest part, but it shows in a window, so you know it's working.

I'd like to make some other GUI improvements, and possibly thread the whole thing so you can use LGM while the plugin is loading.

[Josh @ Dreamland]

Make is the longest part *on your connection.

[IsmAvatar]

And CPU. Point taken.

[RetroX]

Suggestion for the linux version: compileEGMF should be placed in /usr/lib and LGM should search there.  If it's not there, it searches in /lib, and if it's not there, it searches in the working directory.  Windows should place the plugin in the same directory by default but should search in system32 if it's not there.

Additionally, there should be an option to link to ENIGMA's runtime libraries as SOs/DLLs as opposed to including them with the program (inclusion should be default).  And these SOs/DLLs can be packaged and redistributed and put in system32/runEGMF.dll or /usr/lib/librunEGMF.so.

[IsmAvatar]

Might I inquire as to why you think these actions should be taken? The reasoning isn't exactly obvious to some of us, namely myself.

[RetroX]

1. To make it so that LGM will work by just running java -jar (LGM) rather than having to create a bash script to go to its directory.
2. Runtime libraries make the binary file size smaller.

[Josh @ Dreamland]

God damn it, that is the stupidest fucking excuse in the book, and it's officially pissed me off, because now we have the most flaringly beautiful fallacy of accident I have ever seen.
1. Using a runtime library makes binaries smaller, WHEN MORE THAN ONE BINARY DEPENDS ON THE LIBRARY AND SO THE USER CAN BE GUARANTEED THAT IT IS ALREADY INSTALLED. I have to include a megabyte-large AL installer with ENIGMA, and if I don't do something about it, users will have to include that same installer with their games. Why? Because no one has fucking AL installed! As the sole proprietor of libcompileEGMf.so, it doesn't matter WHERE THE FUCK WE PUT IT, IT'S STILL A MEGABYTE OF DLL. Maybe if fuck-anybody had any reason to install OpenAL on Microsoft, I could happily leave AL's DLLs dynamic. But as it stands, no. one. does.

2. Putting a DLL in a system folder that would, ideally, be updated by LGM moderately frequently, is not a good idea. Sure, you can set its permissions to allow LGM to replace it, but then 20 different things have to be modified in LGM to make sure /usr/lib is what this particular operating system supports: so far, Mac has been riding Linux's coattails to functioning at the bare minimum. I'm not exactly sure what trying to write into the correct system folder would do.

[RetroX]

It was an idea, not a required obligation.  It doesn't mean that it should be done in the near future or even at all.

My idea is that simply, ENIGMA shouldn't all be stuffed into one folder.  Some parts should be stuffed into /home/user or C:\Users\user and others should be put in the right places in the system.  But then again, and system32/lib is probably a bad idea.

[RetroX]

LINUX PACKAGES ARE FINISHED

They are listed in this file.  I've automated the building of ENIGMA so that I just have to run a bash script to upload the new packages.

NOTE: Old packages are not kept, and if you end up having a failed download, it's probably because the file was deleted automatically on a package update; in this case, check the package list again.  I'm only going to be updating these on major updates, and I'll give you about an hour's notice before I do so, for those with really slow connections or limited bandwidth.

For people that don't know which package to download, i386, i486, i586, and i686 are 32-bit, and x86_64 and amd64 are 64-bit.  The Ubuntu packages have the .deb extension, the Arch Linux packages have the .pkg.tar.xz extension, and the slackware packages have the .lzm extension.

[freezway]

im getting 404's now... i can dl the pkg list.. but not the .deb