Search the Community
Showing results for tags 'client'.
Found 4 results
I've been working on a new way to build the windows client which is now ready to test. I'm using a tool-chain called MSYS2/MINGW which allows use of the latest compiler and up to date libraries on Windows 10. This all means that the resulting executable should run better on Windows 10. I have also automated the build process and so can provide more regular test clients for Windows like I already do for Linux. The previous builds I have provided were built using a very old tool-chain on Windows XP; which was not good. Please give this new build a try and please give me some feedback. But, BACKUP your current el.exe and all the .dll files before installing the new package as these files will be over-written by the package. Also as always, ensure your important game files like your quest log etc are backed up; good practice even if you do not try this new client. The packages only contains the el.exe and the required .dll files, the game data is not included. There is a 32-bit package and a 64-bit package for Windows 10, extract the zip archive for your version of Windows into the game data directory where the existing el.exe and .dll file (which you have backed up) were located.
Since I like to catch up on email, websites, etc. while harvesting, and generally like to have audible warnings for numerous events if I'm in game but Away From But Near To Keyboard, or get distracted by doing jigsaw, I have a great number of client alerts defined, up to 26 sounds, now. However, I can't seem to get _all_ of them to work, only about the first 15, so my question is: is there a numerical limit to how many sounds can be defined, or do i have to look for some other obscure error I have made?
Hi, all. I'm relatively new to the game. I'm an experienced software developer (though I haven't worked with C or C++ in years). I've spoken with radu about my idea, and he suggested I post in here to get some feedback and discussion about it. Among several other improvements I want to try to make to the client code, I want to try to improve the mouse clicking user experience. Specifically, it seems that clicking (and the results of clicking) in the main world view window operates on an "exact pixel" basis. For example, you must click on one of the pixels of a flower to begin harvesting it (based on the current camera angle). At wide zoom amounts, this can mean very few pixels to click on. Trying to initiate combat with things like bunnies and brownies is significantly more challenging (frustrating?) than attacking large creatures like deer. What I'm thinking is to just expand the code to consider an n by n square of pixels (or perhaps circle) around the mouse cursor, instead of just one single pixel at the mouse cursor. Then have the cursor operate just as it is now (including both hover and click functionalities), except the thing hovered over, or the thing clicked is the one that is closest to the mouse cursor within this pixel area. When there is more than one small hotspot near the cursor, the UX will still remain as tricky to use as it is now, but if you are trying to chase a bunny down, and there's nothing else in the vicinity, this change should make it much easier to do so. Any thoughts on this approach, or tips on where to start? I've only briefly browsed the code, but I've found such things as thing_under_cursor. I'm also thinking that this should be a toggleable setting, as it is likely to require a little more CPU power.