Undefined behavior then because even this old post from 2010: http://stackoverflow.com/questions/2723280/why-is-my-program-creating-empty-lck-files tells me that handlers need to be closed. But I see a nicer method to close all log handlers at exit, without code duplication (ie. calling log.close() before every exit call) - addShutdownHook ! In App.java main(): Code: Runtime.getRuntime().addShutdownHook(new Thread() { public void run() { log("Shutting down log handlers..."); Logger logger = Logger.getLogger("org.co8.jtfe"); for(Handler h : logger.getHandlers()) { h.close(); } } } ); This will close all log handlers before app exit EDIT: I will need too recreate project using IntelliJ IDEA, NetBeans sucks
@ Tapek: Thanks for the update! @ Ted: Just ensuring that the thing works as it did before with the changes made - so, as long as it doesn't crash anywhere where it used not to, we're fine. I don't think these changes should introduce any unwanted behavior though, they're very straightforward and only strengthen the code base. So, it's mostly just a "safety measure", as in "better safe than sorry". - Agetian
UPDATE 08/21/14: Updated TFE-X to v4.6a. Fixed a bug with TFE-X not closing the logger handles upon exit which caused undefined behavior that resulted in creation of multiple log/log lock files on some systems [patch by tapek]. I tested this build on my systems (JRE 7 / Linux and JRE 7 / Win 7) and it appears to work fine. The change is not drastic so it shouldn't cause any unwanted side effects and should only be beneficial on all systems (on systems where things worked perfectly before they'll just keep working perfectly; on systems where things went awry in ways similar to what tapek described things should now work perfectly well). Thanks to tapek for this valuable contribution. - Agetian
UPDATE 09/22/14: Updated TFE-X to v4.7. Implemented a way to preserve the contents of Extraplanar Chest after switching modules back and forth. Also, bumped up the requirements of the Windows TFE-X executable to Java 7 (1.7.0). We haven't supported or recommended using Java 6 for quite a while already anyway (because our modules are big enough to cause unpacking issues when used with JRE 6). - Agetian
I am having some troubles just trying to install the front end. I feel a little silly as I would consider myself nowhere near as tech savvy as some of those posting on this forum, but I am a ToEE lover nonetheless, and would love to be able to install this modpack. I tried to follow the FAQ, and once I installed java, I tried to open the installation file but it is not associated with java and it doesn't seem to have a file type. Hopefully I am not making too dumb of a mistake here, but any help would be greatly appreciated! Thanks.
By installation file, do you mean the executable file you downloaded? (It should be called 'Circle of Eight Modpack 8.1.0 Standard/New Content.exe.') That's not a Java file, just an executable that installs the mod. If you set your system to display file types, you should be able to see if there's an error with the extension - the .'exe' part. If there is and it's not called '...whatever.exe,' it won't be associated with any function and won't run itself when you double click it. If that's the case, just rename it and then try again. If you're saying the installation utility runs and installs fine but TFE-X (the front end) won't launch, we'll need more info. That is a Java app specifically.
I did try renaming it as an exe, but the file type is just listed as "0_NEW_CONTENT_EDITION_SETUP[1] File (.0_New_Content_Edition_Setup[1])"
Delete the period and the text after it, and then add in .exe to the end of the filename. That should solve things. http://windows.microsoft.com/en-us/windows/show-hide-file-name-extensions
i got the GOG version working on osx (mavericks). it took me like an hour because i had no idea what had to be done, so i'll leave it here in case other folks run into it. after installing the game you want to dump the patch into the wineskin. if i command+down on the application i get a wineskin menu (to run the application you can double-click on it). i have no idea if this is a standard wineskin thing or it's because i already had wine installed on my system. if it doesn't work for you you can install wine i guess (really easy with homebrew). anyway from there you can use "install software" to dump the patch contents into "/Applications/Temple\ of\ the\ Elemental\ Evil.app/Contents/Resources/drive_c/GOG\ Games/Temple\ of\ Elemental\ Evil" (or wherever you put it). the .sh script was doing funny things so i didn't use it. i ran the jar file directly from the terminal: $ cd /Applications/Temple\ of\ the\ Elemental\ Evil.app/Contents/Resources/drive_c/GOG\ Games/Temple\ of\ Elemental\ Evil $ java -jar TFE-X.jar at some point it gave me the CEN header error, even though my java installation was up to date. apparently oracle's version doesn't overwrite the system-wide installation (check with java -version on the terminal), you can follow this if it happens to you: http://stackoverflow.com/questions/...al-is-still-using-version-6/14875241#14875241 (or just use the application with the full path rather than just "java", you only have to run it once.) seems to work
I'm not sure if this is the right place for this, but it's the closest I've found. Please point me to the right place if not. First, thanks for making TFE-X work on Linux, as it saves me the hassle of trying to get it to work under Wine (which I never could do with the old .NET version). I do have a few issues with it, though: 1) I noticed that save games are archived and restored when changing the activated mod, but the modification date is lost. The game uses and displays the date, so here's a quick & dirty patch against the 4.7 source provided above: Code: diff -ru src/src/main/java/org/co8/jtfe/util/ZipIO.java tfe/src/src/main/java/org/co8/jtfe/util/ZipIO.java --- src/src/main/java/org/co8/jtfe/util/ZipIO.java 2014-08-19 06:57:14.000000000 -0500 +++ src/src/main/java/org/co8/jtfe/util/ZipIO.java 2015-07-03 20:53:23.771083384 -0500 @@ -97,6 +97,7 @@ // to the directory being zipped, so chop off the rest of the path String zipFilePath = file.getPath().replace('\\', '/'); ZipEntry zipEntry = new ZipEntry(zipFilePath); + zipEntry.setTime(file.lastModified()); zos.setLevel(0); zos.putNextEntry(zipEntry); @@ -194,6 +195,9 @@ } } in.close(); + File inf = new File(zipEntryName); + if (inf.exists()) + inf.setLastModified(zipEntry.getTime()); } logToWindow(logger, format("Installation: %s is done.\n", zipFileName)); 2) Is there a reason that 1366x768 (a very common laptop and cheap TV/monitor resolution) isn't directly supported? Seems to work fine to me. 3) Is there a reason that the entire map directory isn't recursively cleared? Is it because java doesn't have a native recursive delete function? It's easy enough to implement, I guess, if that's the case (http://stackoverflow.com/questions/779519/delete-files-recursively-in-java). I ask mainly because I want to know if it's safe to do that instead of invoking the front-end every time (I might be more inclined to do that if the front end took a command-line parameter to skip the GUI and just start the game; I suppose I could add that to my own copy if I felt like it)
As the new Frontend needs Java instead of .net I had to install Java again which I hadnĀ“t used the last years. Now my browser warns me that the "JAVA deployment toolkit 7.0..." is having security issues. Could I deinstall that somehow separately and still have JAVA to get the Co8 Frontend to run?