Jump to content

Haru

Administrators
  • Content Count

    382
  • Joined

  • Days Won

    38

Posts posted by Haru


  1. Would it be possible have the capability to load multiple .po files for a same language? The purpouse of this is to be able to add individual translations to individual scripts instead of modify main language.po file (wich is cool as it is).

    This is something I started working on a while ago (but I had to suspend it in order to take care of some other urgent issues).

     

    The reason why I wanted to split it is another: the current .po file is very large, and it crashes (or is rejected by) various .po editors (both online and offline). My idea was to generate, instead, one .po for each .txt file in the scripts folder (and load them when loading each .txt). This would also have a positive side-effect of only loading the strings that are actually needed (and potentially warn you if a .po is missing).

    Preliminary work to support this was started in the split-huld branch in my fork of the repository (commit 908d531f. So far only the generation is handled, the loading part is not yet implemented.

    If there's interest for that, I'll resume working on it.


  2. I don't know how exactly works Huld, but I can think in another idea that maybe could help in this kind of cases. What about put a second translation in the same script, something like this:

     

     

    #: npc/cities/prontera.txt
    # mes "Welcome to Prontera.";
    msgctxt "Guard#pront::prtguard"
    msgid "Welcome to Prontera."
    msgstr "Bienvenido a Prontera.":"Bienvenida a Prontera."
    
    So, this wouldn't need to edit the original script and when Huld detect there is a second string, let him knows the first one stands for male players and the second one stands for female players. It would be even more easier, since it doesn't involve any sprint command.

     

    Another idea that I have is maybe create another command than msgstr, one that let huld know that the translated string has a different translation according to the gender of the player.

     

     

    But by doing that we'd lose the only reason why we decided to use the .pot/.po file format: compatibility with a large number of translation software we can currently use (i.e. poedit) and websites (i.e. crowdin, transifex.

     

    We have to stick to the syntax allowed by the gettext .po file format:

     

    https://www.gnu.org/software/gettext/manual/html_node/PO-Files.html


  3. So you could do 

     

     

    if (Sex)
      mes("Bienvenido a Prontera");
    else
      mes("Bienvenida a Prontera");
    

     

     

    This wouldn't work with the current translation system though (it's a known limitation I don't have a workaround available for)

     

    Given a piece of code like this:

    if (Sex == SEX_MALE)
      mes("Welcome to Prontera");
    else
      mes("Welcome to Prontera");
    
    the HULD generator would detect that those strings are the same, and would just produce one entry in the .pot file, making it impossible to translate them differently.

     

    Normally, .pot files use the context field to differentiate between multiple entries that might have the same value, but we (ab)use that field to contain the NPC name instead. It's a choice that was done in order to be able to automatically generate reasonably meaningful translation templates without having to edit every script to manually add context to them.


  4. I agree with you that libconfig is quite bad, but that's what we're stuck with for the time being. If it was up to me, I'd convert everything to yaml, but I was too late to the party, and Hercules had already started using libconfig for some files.

     

    The old .txt format had a lot of (parsing and future extensibility) problems, and it was overdue for an update.

     

    I disagree with your point about the sql_connection. The most common case is to have everything in one database, and now you can do that by just editing one file. The format allows for more advanced cases using different databases of course, and it's not much harder to achieve than it used to be (or possibly easier, since the format is standardized, and it makes easier to find things, just do a folder-wide search for sql_connection and you'll find all the files that support separate configurations. You'd previously have to search for sql, db_ and possibly other words.

     

    About the separate folders, it might be personal preference, but it feels better organized this way. If you're using any decent/modern text editor, you'd normally open the whole config folder with it, and the files to edit are just one click or keypress away, tidily organized in a nice folder tree (Vim/GVim/MacVim (screenshot), Atom (screenshot), Kate, TextMate, Sublime Text, Coda and possibly many more allow you to do that. If you're stuck with the old notepad++ and it still forces you to open all files separately, maybe it's time to start looking around for alternatives)

    On a side note, the files in the import folder are still all in one place.

     

    Could the file format and structure be done better? Probably. Are we still in time to do improve it? Of course. Got specific suggestions? Post them in the bugtracker. Complaining that something sucks is pointless, just say how you'd improve it.


  5. Doxygen is a developer-only dependency. We use it (check the 'hooks' target in the top directory Makefile) only to re-generate the HPM Hooking definitions and the HPMDataCheck definitions. That operation is only needed when you edit something in the interfaces (and it's generally not needed to do manually if you push code to the repository or make a pull request, because the build-bot will take care of re-generating those after each push to the master branch)

    It's not needed at all in order to run Hercules or to load HPM plugins (even if they use the HPM Hooking)

     

    About vim plugins and configurations, this is a good start: https://github.com/HerculesWS/StaffPlugins/tree/master/Haru/vimsyntaxgen

    it's a HPM plugin that will let you generate syntax definitions, filetype detectors, etc for Hercules scripts.

    It also includes a syntax definition for Syntastic, in case you want to use the Hercules built-in script checker to test the syntax of your scripts every time you save the file. Note that this last part needs the syntastic vim plugin available at https://github.com/scrooloose/syntastic and some configuration (you'll need to tell it where your compiled Hercules is located:

    " from my .vimrc
    let g:syntastic_herc_compiler = '/usr/local/Hercules/script-checker'
    
    Other noteworthy plugins that I use:

     

    - airline - https://github.com/bling/vim-airline (a better status bar)

    - commentary - https://github.com/tpope/vim-commentary.git (comment in/out code quickly with 'gc')

    - DirDiff - https://github.com/grota/DirDiff.vim.git (diff directories)

    - easy-align - https://github.com/junegunn/vim-easy-align.git (auto-align definition blocks, such as enum definitions)

    - fugitive - https://github.com/tpope/vim-fugitive.git (git commands from inside vim)

    - gitgutter - https://github.com/airblade/vim-gitgutter.git (show markers for added/removed/edited lines if a file is in a git repository)

    - repeat - https://github.com/tpope/vim-repeat.git (extends the '.' repeat feature with support for more commands)

    - signature - https://github.com/kshenoy/vim-signature.git (show visual hints for 'm' markers)

    - unite - https://github.com/Shougo/unite.vim (a framework to search/show/select various kinds of things - advanced stuff, check their page for examples of use)

    - YouCompleteMe - https://valloric.github.io/YouCompleteMe (very good autocompleter that actually works, even with Hercules)


  6. We don't really have any archive of actual Ragnarok database data (it's quite unfortunate, yep). Since many Hercules developers have/had access/owned a private server at some point in our life, we have some private samples we can use for tests. I generally use a clean database though.

     

    As for packet replays, it depends on what you're working on. I either gather it myself from official servers, if it's something I can access, or ask others if they can record something... There are also some packet structure/length tables available, and most stuff we implement comes from those (followed by test s with the actual client, where possible) - you can find some packet information here http://herc.ws/wiki/Packets (and if you google for some of those IDs, you can likely find more)

     

    You can find various more or less useful tools around the Downloads area (http://herc.ws/board/files/) and the Support&Releases area (http://herc.ws/board/forum/13-support-releases/), but there isn't very much tailored to source development. My main friends are vim and the dozen of general purpose vim plugins I use, along with a gcc-compatible compiler and the almighty Z-shell. For in-game testing, I tend to either download a pre-hexed client if I'm testing a specific version that I haven't made on my own, or download a clean one and hex it with NEMO. That goes on a case by case basis

     

    Probably not the kind of answer you expected, but I guess this is it at least for me


  7. In order to specify the " character, please prefix it with a backspace (\").

     

    This is from the libconfig documentation at http://www.hyperrealm.com/libconfig/libconfig_manual.html#String-Values :

    String values consist of arbitrary text delimited by double quotes. Literal double quotes can be escaped by preceding them with a backslash: ‘\"’. The escape sequences ‘\\’, ‘\f’, ‘\n’, ‘\r’, and ‘\t’ are also recognized, and have the usual meaning.

     

    In addition, the ‘\x’ escape sequence is supported; this sequence must be followed by exactly two hexadecimal digits, which represent an 8-bit ASCII value. For example, ‘\xFF’ represents the character with ASCII code 0xFF.

     

    No other escape sequences are currently supported.

     

    Adjacent strings are automatically concatenated, as in C/C++ source code. This is useful for formatting very long strings as sequences of shorter strings. For example, the following constructs are equivalent:

     

    "The quick brown fox jumped over the lazy dog."

    "The quick brown fox"

    " jumped over the lazy dog."

    "The quick" /* comment */ " brown fox " // another comment

    "jumped over the lazy dog."


  8. The reason why no one works on this "feature" is that, while being an official feature, it has nothing to do with the game. Its sole purpose is to monetize (which certainly isn't what players are looking for). If a private server owner wants to monetize (from a game they don't even own the rights for), they can invest some time, and develop a VIP system (and why not, make a pull request, we'd likely merge it, as long as it wouldn't impair the Hercules performance for those who want a vanilla Ragnarok experience).

     

    Hercules development is progressing (see the number of branches that are being worked on -- it's not only the feature that make it into master), but no one, including Ind, would want to spend their free time on something whose sole purpose is to make leechers earn money more easily. And I believe Ind was especially bitter about that aspect of the community, when he left.


  9. Rationale:

    This changeset offers improvements to the HPMHooking, making it capable to detect, at compile time, an error in the type of a hook function, as well as allowing pre-hooks to be more powerful when it comes to pointer-type arguments.

     

    Contents:

    The HPMHooking macros addHookPre() and addHookPost() have been slightly edited, and they can now detect if the type of the passed function is the correct type for the hooked function. In order to do so, the HPMHookingGen script produces one more header (HPMHooking.Defs.inc) that lists the hook function types.

    This means that, if a plugin hooks into a function through HPMHooking, and the core function changes, the plugin will show a compile-time warning instead of silently compiling (and crashing at runtime or causing undesired effects).

    The post-hook function types have been simplified, dropping all the extra indirection levels that were added originally.

    The pre-hook function types have been changed, increasing the indirection level for pointers (now all variable types require an extra '*' in pre-hooks). This makes it possible to override const pointers from pre-hooks.

     

    Impact:

    Scripts that use the HPMHooking will need some small syntax changes.

     

    Details:

    All plugins that want to use the HPMHooking will need to #include "plugins/HPMHooking.h" (it's recommended to include it just above HPMDataCheck.h)

    #include "plugins/HPMHooking.h"   // Included by plugins that use the HPMHooking
    #include "common/HPMDataCheck.h"  // Included by all plugins
    
    Then the addHookPre() and addHookPost() calls need to be updated to the new syntax, separating interface name and function name:
    /* Before */
    HPExport void plugin_init (void)
    {
        addHookPre("pc->dropitem", my_pc_dropitem_pre);
        addHookPost("pc->dropitem", my_pc_dropitem_post);
    }
     
    /* Now */
    HPExport void plugin_init (void)
    {
        addHookPre(pc, dropitem, my_pc_dropitem_pre);
        addHookPost(pc, dropitem, my_pc_dropitem_post);
    }
    
    Pre-hook functions will need an additional indirection level in their pointer-type arguments:
    /* Hooked function: */
    int (*dropitem) (struct map_session_data *sd, int n, int amount);
     
    /* Pre-hook (before) */
    int my_pc_dropitem_pre(struct map_session_data *sd, int *n, int *amount) // Only adds '*' to the non-pointers
     
    /* Pre-hook (after) */
    int my_pc_dropitem_pre(struct map_session_data **sd, int *n, int *amount) // Adds '*' to everything
    
    Note: arguments of type va_list do not require an additional indirection level. 'va_list ap' remains 'va_list ap' and does not become 'va_list *ap'

     

    Post-hook functions will no longer need any additional indirection level in their arguments:

    /* Hooked function: */
    int (*dropitem) (struct map_session_data *sd, int n, int amount);
     
    /* Post-hook (before) */
    int my_pc_dropitem_post(int retVal, struct map_session_data *sd, int *n, int *amount) // Adds '*' to the non-pointers
     
    /* Post-hook (after) */
    int my_pc_dropitem_post(int retVal, struct map_session_data *sd, int n, int amount) // No longer adds any '*'
    
    Merge Date:

    Sun, 1 May 2016 20:22:03 +0300

     

    Related Pull Requests:

    - #1253 - https://github.com/HerculesWS/Hercules/pull/1253 - HPMHooking improvements [Haru]

     

    Related Commits:

    1ec9328 - https://github.com/HerculesWS/Hercules/commit/1ec9328 - Sun, 28 Feb 2016 02:12:48 +0100 Moved HPMHooking-related definitions to plugins/HPMHooking.h [Haru]

    5db7c79 - https://github.com/HerculesWS/Hercules/commit/5db7c79 - Sun, 28 Feb 2016 02:17:21 +0100 Added type-checking for the addHookPre() and addHookPost() macros [Haru]

    4e49441 - https://github.com/HerculesWS/Hercules/commit/4e49441 - Sun, 28 Feb 2016 02:20:40 +0100 HPM Hooks Update [Haru]

    2788afc - https://github.com/HerculesWS/Hercules/commit/2788afc - Sun, 28 Feb 2016 02:40:15 +0100 Replaced memset with braced initializers in the HPMHooking hook handlers [Haru]

    fa2f2f4 - https://github.com/HerculesWS/Hercules/commit/fa2f2f4 - Sun, 28 Feb 2016 02:41:01 +0100 HPM Hooks Update [Haru]

    8aacecc - https://github.com/HerculesWS/Hercules/commit/8aacecc - Fri, 15 Apr 2016 19:37:54 +0200 Removed extra indirection level in HPMHooking post-hooks [Haru]

    7eb4ae4 - https://github.com/HerculesWS/Hercules/commit/7eb4ae4 - Sun, 17 Apr 2016 00:38:37 +0200 HPM Hooks Update [Haru]

    89e0550 - https://github.com/HerculesWS/Hercules/commit/89e0550 - Sun, 28 Feb 2016 02:48:47 +0100 Added one level of indirection to all variables in pre-hook functions [Haru]

    e9c98a1 - https://github.com/HerculesWS/Hercules/commit/e9c98a1 - Sun, 28 Feb 2016 02:50:40 +0100 HPM Hooks Update [Haru]

    95b4e32 - https://github.com/HerculesWS/Hercules/commit/95b4e32 - Sun, 1 May 2016 20:22:03 +0300 Merge pull request #1253 from HerculesWS/hpmhooking [Andrei Karas]


  10. Rationale:

    This is according to our Supported Platforms policy.

     

    For an overview of supported OSes and compilers, please see the wiki page https://github.com/HerculesWS/Hercules/wiki/Supported-Platforms

     

    Contents:

    VS2015 is our primary target compiler on Windows, and this merge removes all the warnings that were present when compiling with that version of Visual Studio.

    VS2010 isn't one of our supported platforms (and hasn't been for a while), so maintaining its solution inside the repository adds unnecessary work to the dev team.

     

    Impact:

    While it's currently still possible to build on VS2010 (download the files `Hercules-10.sln` and `vcproj-10/*` from an older snapshot of the repository such as https://github.com/HerculesWS/Hercules/tree/bbcb040 and put them in your Hercules directory), we offer no support for any build issues causd by future commits, nor we'll update the project/solution files.

     

    Merge Date:

    Sun, 24 Apr 2016 13:13:19 +0200

     

    Related Pull Requests:

    - #1264 - https://github.com/HerculesWS/Hercules/pull/1264 - V2015 improved compatibility and dropped VS2010 solution [Haru]

     

    Related Commits:

     

    - a92fa36 - https://github.com/HerculesWS/Hercules/commit/a92fa36 - Sun, 17 Apr 2016 13:37:08 +0200 Updated README file [Haru]

    - e69e8c5 - https://github.com/HerculesWS/Hercules/commit/e69e8c5 - Sun, 17 Apr 2016 13:43:30 +0200 Removed VS2010 project [Haru]

    - 3af03d2 - https://github.com/HerculesWS/Hercules/commit/3af03d2 - Tue, 19 Apr 2016 11:32:04 +0200 Improved parsing of the server name/port in the irc bot configuration [Haru]

    - 2b1dce1 - https://github.com/HerculesWS/Hercules/commit/2b1dce1 - Tue, 19 Apr 2016 15:26:36 +0200 Changed map_session_data::chatID to int (and renamed to chat_id) [Haru]

    - dc23fd3 - https://github.com/HerculesWS/Hercules/commit/dc23fd3 - Tue, 19 Apr 2016 16:31:57 +0200 Corrected the type for several variables through the code [Haru]

    - e4feddf - https://github.com/HerculesWS/Hercules/commit/e4feddf - Wed, 20 Apr 2016 15:40:19 +0200 Corrected the type of the 'length' argument of various broadcast-related functions [Haru]

    - d7ffa6a - https://github.com/HerculesWS/Hercules/commit/d7ffa6a - Wed, 20 Apr 2016 17:06:18 +0200 Removed the 'len' argument from clif_disp_onlyself() and clif->disp_message() [Haru]

    - 4788c81 - https://github.com/HerculesWS/Hercules/commit/4788c81 - Thu, 21 Apr 2016 20:38:18 +0200 Removed the 'len' argument from various message-related functions [Haru]

    - f5b88f9 - https://github.com/HerculesWS/Hercules/commit/f5b88f9 - Wed, 20 Apr 2016 17:23:03 +0200 Corrected the type of the 'length' argument of other message-related functions [Haru]

    - 9e58db4 - https://github.com/HerculesWS/Hercules/commit/9e58db4 - Wed, 20 Apr 2016 17:24:37 +0200 Added some files specific to VS2015 (Update 2) to gitignore [Haru]

    - 9fdb456 - https://github.com/HerculesWS/Hercules/commit/9fdb456 - Thu, 21 Apr 2016 20:57:56 +0200 HPM Hooks Update [Haru]

    - 31e27a1 - https://github.com/HerculesWS/Hercules/commit/31e27a1 - Sun, 24 Apr 2016 13:13:19 +0200 Merge pull request #1264 from HerculesWS/vs2015 [ibrahem Hossam]


  11. Opinions like these are what drove the project to the situation it is in right now. Through the years we have accumulated a level of technical debt that I'm not confident we'll ever be able to fill.

    If we keep implementing new features the way we did until now, the project will turn into a big ball of mud (or rather, it already is). Architectural changes are very needed.

     

    Now, the change the broke compatibility with your patches, isn't this one (the change in order to implement the private headers is almost irrelevant in terms of changed lines of code). What you should blame is, instead, the redesign of the client interface in the login server.

     

     

    In my optinion, both changes were necessary in order for the project to go forward. I'll point out some of the reasons why I want changes like these:

     

    - The private interfaces: the change may seem pointless if the only reason is compile time (in fact, they aren't pointless - even if server owners don't recompile it often, we developers do -- and by shortening the compilation time, you increase the amount of tests we're likely to do on a patch before submitting it, or reduce the time we take to fully implement and test something). There are, though, other more important reasons. By making some methods private, we're ensuring that they aren't called by other modules, reducing the chance that new features will be implemented in a half-assed way like it happened in the past (resulting in a cleaner and more manageable codebase overall).

    Once again, keep in mind that the changes to the lclif.c file that were necessary in order to implement this were almost zero (just some lclif->xxxx or lclif_xxxx replaced by lclif->p->xxx), so this is very unlikely to break any of your patches.

     

    - The clif changes: This is important for at least three different reasons.

    Firstly, right now we're mixing login logic with packet sending logic, and that's just plain wrong (login code should be independent from the client, and clif code should be client-specific, just like it's important to separate logic from presentation in any well designed application).

    Secondly, implementing new packets, or editing old ones has become much easier and less prone to very subtle errors (think of 'WFIFOW(fd, 13 + 7 * i + 4) = foo;' versus 'packet->item[7].nameid = foo;').

    Finally, it addressed some long standing issues that made it very hard for HPM plugins to hook into packet handling. Writing a plugin that performs additional actions on a specific packet (or that completely overrides the handling of a packet) is much easier now.

     

    I already merged these changes into my own (private) codebase, where I have very large changes to the login interface, and the merge wasn't as painful as you describe it (you should consider doing it commit by commit rather than all at once - that's what I did when I merged it, and that's the reason why I refused to merge this as one mega-commit).

    On a side note, have you considered implementing your changes as a HPM plugin? If not, we'd like to hear the reasons, so that we can improve the HPM so that it's flexible enough for most use cases.


  12. There is usually little to no reason to install an outdated version (unless your hardware isn't supported by the latest). This means that you should go for Debian 8 or CentOS 7. CentOS 6.x is a bad choice, because it comes with a version of gcc that we don't offer support for (it may work or may break at times), and you should upgrade it on your own.


  13. Both distributions are perfectly usable. The main differences is that CentOS carries very outdated software (or stable, as they call it). I personally find debian easier to use and manage, and more compatible with third party software (especially with modern software).


  14. I'd like to add a note here: Object oriented has nothing to do with C or C++. You can write object-oriented code in C, just like you can write non-object-oriented code in C++.

     

    There are several reasons not to use C++, including the terrible choices that were made by the language designers, when they tried to engineer solutions for non-problems, or the fact that the majority of C++ developers only know about 20% of the language (too bad, the 20% they know, is a different 20% for each of them).

     

    If Hercules was written in C++, I wouldn't even have considered joining the project (it's more than enough having to cope with that absurd language during my day job).

     

    For some interesting (even if a bit outdated perhaps) reads:

    Linus Torvalds - http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

    Yossi Kreinin - http://yosefk.com/c++fqa/

     

     

    Now, back to the main question - why Hercules isn't written using an object-oriented paradigm. That's a question that the original developers might be able to answer, but I'm not. I'm only able to guess, they wrote it the way they knew to.

    Some parts of Hercules are object-oriented though. See the DBMap (common/db.c, common/db.h) for an example.


  15. There seems to be something very wrong with your Visual Studio setup. In the log it mentions running "Microsoft ® 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86". That doesn't belong to VS2012, but is much, much older. cl version 12 was shipped with Visual Studio 6 (18 years ago).

    I suggest uninstalling visual studio, finding and deleting any leftovers from very old versions, and reinstalling it.

     

    Edit: some reference from other people who had the same problem on MSDN:

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/e98908c0-002c-4d74-a0d6-e5cb2eb732d2/cannot-compile-defualt-console-application-on-fresh-installs-of-vs2012-or-vs2010?forum=vcgeneral

    https://social.msdn.microsoft.com/Forums/vstudio/en-US/829bf89b-8693-409e-9907-d5debef42a9f/link-fatal-error-lnk1181-cannot-open-input-file-obj?forum=vcgeneral

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.