Jump to content
Eternal Lands Official Forums

freeone3000

Members
  • Content count

    2413
  • Joined

  • Last visited

About freeone3000

  • Rank
    Black Panther
  • Birthday 03/12/1992

Contact Methods

  • MSN
    freeone3000@gmail.com

Profile Information

  • Gender
    Male
  1. Android client

    I'm also interested in the source. I've previously ported the ElChat2 client to android ( at https://bitbucket.or...0/elchatandroid ). When I saw this project, I was immediately interested, and wanted to help out if possible.
  2. Latest Android client (14/10/2013)

    Looks like this was the wrong forum, and there's also a dedicated thread over in Programming. Sorry for the mis-post. Good work, though. Runs great here on my SIII.
  3. ELChat2

    No. And... I have no clue. Can android run native code loaded by a user? Is android a posix system? Are the boost libraries available for it? Does standard output point to a useful place? Does it have an ncurses library? Does it have a BSD networking stack accessible by applications? If all of the above are yes, then sure, it *can* be done. I don't have an android phone, nor a suitable cross-complier, nor any of the knowledge needed to do that, but if someone *can*, I'm open to the idea. A few things in the client could be shuffled to the library, but even if the above *isn't* true, the idea is that one can replace the PDCurses GUI with any other C++ class that extends the proper class, so it'd be possible to port it to any posix system with bsd networking.
  4. ELChat2

    I suggest not applying today's patches, or anything after commit 105 (ffa1178bc8d1). (In retrospect, it might have been better to push to another local repo, or get a bz2 of the files, but "hg push" is *still* the first thing that comes to mind. Didn't even branch...) The rest were a temporary measure, because my development computer managed to fry its PSU and can't run longer than a few minutes at a time. I'll try to get a Windows dev environment set up, but... not looking good for the rest of the week. I apologize for leaving the repository in an unstable state. Hazor: The breakage was between commit 108 and 110? That was an attempt to make it speed up printing of #look and similar, and to remove the garbage printed before the first repaint. (I was able to reproduce! And all it took was to be sitting at an actual vterm instead of a tty emulator.) EDIT: Figured out why. I'm getting the first n lines out of the buffer, instead of the last n lines (and possibly drawing in reverse). This was a change to allow scrollback, but won't be able to revive my computer for another week. I apologize for the delay - it's been affecting other things, too. EDIT2: Managed to get a "working" C++ development environment on my laptop. Fixed a few cross-platform bugs and tidied up the Win32 build process. (Yes, only x86 at the moment, until someone decides to build a x64 pdcurses.dll.) So it now works there, and I fixed the scrollback bug, and potentially the crashing bug. Anyway, source is back into a stable branch, and everything should work A-OK again. Sorry for the mess there.
  5. ELChat2

    I worry about this - A lot of stuff I do isn't perfect, or even well-designed, C++ code. (And surely isn't C.) Anyway, this issue is fixed. And this is done as you've said, but I still plan on putting the timer in eventually.
  6. ELChat2

    It indeed appears to be shaky: It did not write to my ~/.elc/main/chat_log.txt as you requested in-game that I test. Indeed it shouldn't. It'll write to the config specified in servers.lst, in a manner such that getenv("HOME")+"/"+config_dir+"/"+"chat_log.txt" is the filename. If you're running on the main server (which you probably shouldn't be, unless someone knows better), it'll be "main" by default. If you're on the test server (which you should be), it'll be test, such that the full path will result in ~/.elc/test/chat_log.txt .
  7. ELChat2

    I did a merge of the repository branches such that all branches are closed except "default". "default" will henceforth be the branch with the most stable source tree (ie, it'll always compile). Script should probably be updated such that it draws them from "default" instead of "guified_library". (Also got the chat logging feature done in full, but I think the directory handling's a little shaky. Other features are on the way.)
  8. ELChat2

    If you compiled without boost::asio, I'm honestly not sure how it could work - ELNetworkLib exclusively uses asio for network communications. The circular reference is why, originally, this was not 'default' - ELNetworkLib has a dependency on ELChat2, *somewhere*. Grepping through the source, it doesn't appear it's there, so I'm now considering merging the branch back into the default. It's probably only there because of how the executable is linked. As for the others, I'll add them to the issues tracker, and get on them when I have time. (I may need to find another developer who knows the stuff, due to my time constraints.)
  9. ELChat2

    Yes, please. The issue tracker on the code hosting repository should be open, and I'll get notified of reports both there and here.
  10. ELChat2

    Okay. I've posted a possible fix for it - change the gray to 700/1000 from its previous value, and added some new handling for terminals which don't support redefining colors creating new colors. (Grey isn't a standard color.) Those whose terminals support fewer than 6 color-pairs, and those whose terminals don't do colors at all, now get a nasty exception. I plan to introduce a monochrome mode sometime in the futures for these clients, but everyone else should be fine. (Those who can't redefine colors create new colors get a standard white-on-black, so it'd be hard to tell off-channel from on-channel.) EDIT: If you updated in the time between I first posted and when I edited, you'll need to pull again - apparently can_change_color() doesn't do what I thought it did, and I now check the return value of init_color properly. (Not the other ones, but there success is less critical and more determined.)
  11. ELChat2

    You seem to be linking against a version of boost_system other than the one I need (1.42). I'll update the dependencies file to reference version numbers for the libs I need, and look into making CMake check versions for its depends. (Currently, it just asserts you *have* boost_system, not whether it's the correct version or not.)
  12. ELChat2

    Huh. I'm amazed someone found this of use, after all this time. It seems you're working on the "default" branch. This branch has fallen out of use, and probably only worked in MSVC++ anyway. I'm willing to update it, but if you're willing to deal with a (slightly) larger binary and an (n|pd)curses depend (when compiling, not linking - `ldd` confirms no runtime depend), you should run switch over to the hg "guified_library" branch. (The plan was to branch off these nasty changes which require *gui callbacks* in the network lib to be gone, but I never got around to it. The project's been sitting dormant for some time.) The branch switch detailed above can be done by hg up -C guified_library . Note that the newer version uses CMake. To avoid problems, create a new directory as a sibling to the repository directory, cd to that, and run cmake ../elchat2 . (This is also the closest thing to a doc detailing this - the project's been sitting dormant for some time, and honestly, no one has asked for it but you). I did have to push a change fixing the CMake file such that the network lib is built dynamically, instead of statically, so you'll need to pull that. In summary: Pull for the latest fix, use the "guified_library" branch unless you have a reason not to, and use CMake to make the build file, and it should compile. As for your other two issues, I've made a note of them, and I'll get to them whenever I can. Following the repository'll allow you to get it sooner than I post a new build (which may be never, depending on demand). EDIT: Outstanding PM issue fixed. Color issue not fixed, as [username @ ch]: shouldn't even be *in* a color (and it's showing up white here - I have the other colors, so...)
  13. Anitmated npc storys

    The second already exists, under the name of "Joker". The prizes were reduced due to joker-hunting being too profitable. As per the first, I doubt I'd want to go to an NPC unless I had to, despite any sort of animation that could be present.
  14. ELChat2

    ELChat2? Why the "2"? elchat, originally developed by Wytter, was a chat-only implementation of the Eternal Lands protocol, favored by those on slow computers or with outdated graphics cards. However, it has since become difficult to maintain due to changes in the protocol and the platforms involved. My Project As a replacement for elchat, I have developed ELChat2, an unofficial chat-only client. It currently reads system-wide el.ini for options, supplemented with its local el.ini, parses the local server.lst for configuration and connection options, and fully supports the EL Protocol bindings. (Most actions are unsupported, and only a limited set of client-side commands are implemented) It uses an entirely new implementation of the EL Protocol, asio (Which fixes the intermittent issues elchat had with SDL_Net). Code Code is http://bitbucket.org/freeone3000/elchat2/overview/ (Mercurial repository) Packaged builds are http://bitbucket.org/freeone3000/elchat2/downloads/ Tech Details: The client sends five types of packets: LOG_IN, HEART_BEAT, PING_RESPONSE, SEND_PM, and RAW_TEXT. There is no support for any more commands to be sent through the user interface. It is clearly flagged as an illegal, as it sends neither SEND_OPENING_SCREEN or SEND_VERSION. This is intentional, as long as it is not an officially-allowed client. As the server defaults to "test" instead of "main", playing with it on the test server should be fine. Due to the feature restrictions (chat-only, curses-based ui) it uses much fewer system resources than el.exe. EL.exe here uses about 110MB RAM in console. ELChat2.exe uses about 1.5MB. In addition, ELChat2.exe uses nearly no processing power and immeasurably small amounts of graphical resources. Proposal to Users I submit this for public user testing. Compiled binaries for linux and win32 will be available within the week. Please, mention ALL issues on this thread, so that they can be fixed as soon as possible. I am also taking (reasonable) feature requests. Proposal to Admins Once this client has proven its user-friendliness, stability, and usefulness to your satisfaction, I humbly ask that you consider a method to confirm this as a legal, secondary client. The lower system requirements and wider range of platforms (all POSIX + Win32) will allow more to connect, chat, and enjoy than otherwise could.
  15. Depletable resources and multiplaying

    I'm for the idea. Ignoring the multiplay elements, which have been discussed at length elsewhere, depletable harvestables would be a welcome change to the game. While some care must be taken in order to properly rebalance the price floors and ceilings (NPC buy/sell rates need to be changed), it would make it difficult if not impossible to simply grind one task repeatedly. This makes a wider variety of goods produced, rather than a very small window, thereby increasing prices. However, grind price would also be increased - levelling in non-fighting skills will be more expensive, and since there will likely be a goods price increase across the board, a smaller increase in fighting skill training. While the levelling in non-fighting skills *should* be balanced out by the increase of goods, it might not be and the price floors/ceilings may need to be adjusted (after a few months seeing how it works out). This would also force some players to go to riskier areas for resources, who would then charge a higher price. The price does not rise, scarcity increases, which causes the price to rise anyway. It's no longer an infinite resource or a price-floored resource, now market forces come into play for raw resources as well. Some issues with skills would be upper-level manufacturing's dependence on iron and crafting's dependence on gold and silver. Unless these resources have a higher spawn than normal, these skills would be more difficult to train. Unless proper care is taken to provide sufficient resources for the entire player base, it may be difficult to train a character that does not fight at all - possible, and perhaps even preferred under this system. (pp could be assigned on two chars for two tasks, and since the exp curve is exponential, gain would be achieved) The lack of harvesting events would be an end to a minor annoyance, the increased harvesting experience per hour would hopefully more or less offset the limited resources for most. However, the harvesting delay is of questionable merit - simply waiting a minute after login will likely do nothing. It is possible to simply run a client constantly to check the harvestable's status, or even better, just harvest with an alt placed directly at the harvestable, and trade it over to the main. Or, ya know, wait a minute or two and then preform any sort of 'trickery' one so desires. It will, at most, be a minor annoyance with allowed multiplay. Certain areas of harvest limits would be of use, for instance, IP, but beyond that great care must be taken not to overplace these areas. The vast majority of the game should contain limited resources for this shift to be most effective. I would go for all harvestables replenishing at the same rate, for the simple sake of being easier to understand. The game is complex enough in base skills as it is - we already have a dwarf fortress.
×