Ben

Resolution issue is fixed, thanks to some genius-level thinking from Revi. It turns out there was a slight change in the way 10.15 handles lower resolution apps and this needed to be specified explicitly in the info.plist file: NSHighResolutionCapable = NO Pending more testing, we provisionally have a working 64-bit client compatible with the upcoming version of macOS

I have heard back from Sir_Odie, his help pinpointing the issue proved invaluable. It turns out there was a small issue in the new SDL_main.m file required by the upgraded version of the SDL.framework (1.2) I used for 64-bit compilation. Now we have it working fine under 10.14, I have upgraded one of my machines to 10.15 (Catalina) for testing and I'm seeing a strange graphical bug which is not present on 10.14. Have you ever come across that before? The EL log isn't giving me any clues as to what might be the issue, displaying only the same information as both the current Odie and 64-bit builds do on a 10.14 machine.

I have just re-downloaded the latest Sir_Odie build to double-double check, and it does indeed work as expected. Weird. Could we perhaps have the client automatically copy the included servers.lst to the user configuration folder, the same way it builds the rest of the files in there if it can't find them? If we can't figure out why my build no longer utilises the internal servers.lst file, that would save an additional step for Mac users installing the client. I'll try and reach out to Sir_Odie and see whether he does indeed use some trick to make his build behave differently. Although I am using the same Xcode project, it could just be down to the newer Xcode version I am using (he builds his client on an older machine). Edit: Just built the source as it was on the 17th of April (before the change you mentioned) to double-double-triple check, still seeing the strange different behaviour.

Things work a little differently on macOS, unfortunately. Nothing is really installed anywhere as almost everything (besides the user data) is self-contained within the EternalLands.app in /Applications. You can't really start the game from the datadir because the datadir and executable must be in a prescribed place within the .app - there isn't much flexibility. Thank you for taking a look at this, Bluap, I really appreciate it. Enjoy the rest of the weekend.

The #data_dir not failing over is causing some other launch problems too, if not manually changed. Odie client behaviour (launches): [14:26:19, /Users/linke/Desktop/el-devel/elc/macosx/../io/elpathwrapper.c:664] Warning: Didn't find your data_dir, using the current directory instead. Please correct this in your el.ini . Given data_dir was: "c:\Program Files\Eternal Lands\/". Using "/Applications/EternalLands.app/Contents/Resources/data". New client behaviour (crashes): [14:28:09, /Users/ben/Desktop/Eternal-Lands-master/io/elpathwrapper.c:664] Warning: Didn't find your data_dir, using the current directory instead. Please correct this in your el.ini . Given data_dir was: "c:\Program Files\Eternal Lands\/". Using "/". [14:28:09, /Users/ben/Desktop/Eternal-Lands-master/init.c:736] Error: Fatal error while loading data files. Either set the data_dir correctly or run from the data directory. I'm guessing this wouldn't be a problem for new installs (it could be added to the el.ini in the included data files, right?), but it would cause problems for people upgrading.

I understand why it is behaving differently now That would be a great help, without such a change Mac users would have to manually copy servers.lst over to ~/Library/Application Support/Eternal Lands/.

Interesting, I must be doing something different to cause it to ignore the servers.lst contained within the .app. The Odie client reads servers.lst from within itself: EternalLands.app/Contents/Resources/data/servers.lst (tested and confirmed). My client seems to ignore this file, even with an identical set of data files

Success! I have it running, though there's a bit of weirdness with files needing to be in places they didn't need to be previously. To get it to work I had to manually place servers.lst in ~/Library/Application Support/Eternal Lands/ and edit #data_dir in the el.ini under ~/Library/Application Support/Eternal Lands/main.

Getting closer: [10:43:55, /Users/ben/Desktop/Eternal-Lands-master/engine/logging.cpp:310] Log started at: Sun Sep 8 10:43:55 2019 BST [10:43:55, /Users/ben/Desktop/Eternal-Lands-master/engine/logging.cpp:313] version: 1.9.5 [10:43:55, /Users/ben/Desktop/Eternal-Lands-master/servers.c:118] Error: Fatal error: servers.lst file missing! Unsure what is causing the servers.lst fatal error, it is definitely present.

Thank you for the tip, Elbowrond. I’m glad everything is running smoothly for you

Looks like we've got this solved, the config had adopted incorrect display settings leading to a OpenGL error on launch: Error: Couldn't set GL mode: Failed to find display resolution: 1680x1050x32 Solution was to modify el.ini (located in ~/Library/Application Support/Eternal Lands/main/) to manually disable #full_screen and reduce #video_mode to a more reasonable resolution. #video_mode= 6 #full_screen= 0

Cody, I have dropped you an email.

Not to worry! Could you please try to start the game once again (using the method I gave above) and then pastebin the contents of the following file: ~/Library/Application Support/Eternal Lands/log/main_<random>.log The file will have a small number of random characters, but there should only be one starting "main_".

Nothing unexpected there (I have the same output on both of my machines, at least). When you attempt to launch the game directly (either via the method above or by clicking the EternalLands app within launchpad) do you happen to have any "EternalLands quit unexpectedly" messages pop up? If so, could you post or pastebin the accompanying problem report?

Cody, are you familiar with the terminal? If so, could you please enter the following two commands and post/pastebin the output: cd /Applications/EternalLands.app/Contents/MacOS/ ./EternalLands Edit: I should probably specify that the first command will change your active directory to the one containing the game executable, and the second one will execute it directly.

Cody, is the error you get when attempting to launch the game directly (EternalLands.app) the same as the error you get when attempting to launch via the server chooser app? If not, could you perhaps post/pastebin it for us? The errors you've posted so far all reference the server chooser app

I have also been seeing similar behaviour in recent months, across multiple Macs running various macOS versions. As Diealot has noted, the best solution (for now) for anybody else experiencing this issue appears to be a restart or trying the server chooser app. Here's a paste to the problem report for anybody interested.

Not a pr0 fighter, but I really do like this idea. A chunk of XP after a kill would be incredibly motivating, particularly for the more casual players.

Has anybody had any trouble with this?

Has working eyes, correct item_info, correct app icon, no framework issues. Thumbs up from me

Yes. No issues to report so far, beyond those already noted.

Same problem here. It appears to be looking for the frameworks in /Library/Frameworks (rather than within the app, where they actually are). Out of curiosity I duplicated the frameworks from within the app and added them to /Library/Frameworks, which results in a different crash.

I'm using Xcode, the usual method for the macOS client.

I'm seeing identical errors while trying to compile for macOS: Undefined symbols for architecture i386: "CalCoreMesh::setFilename(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from: _CalLoader_ELLoadCoreMesh in cal3d_io_wrapper.o _CalCoreModel_ELLoadCoreMesh in cal3d_io_wrapper.o "CalCoreMaterial::setFilename(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from: _CalLoader_ELLoadCoreMaterial in cal3d_io_wrapper.o _CalCoreModel_ELLoadCoreMaterial in cal3d_io_wrapper.o "CalCoreAnimation::setFilename(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from: _CalLoader_ELLoadCoreAnimation in cal3d_io_wrapper.o CalAnimationCache::loadAnimation(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, float) in cal3d_io_wrapper.o ld: symbol(s) not found for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation)

Great - glad I could point you in the right direction