Jump to content

Support & Releases


  1. General Server Support

    If you have a question that does not fit specifically in the other support sub-forums sections, feel free to ask here.

  2. Database

    This section is for database related support, releases, and requests only.

  3. Scripting

    This section is for script related support, releases, and requests only.

  4. Source

    This section is for source related support, releases, and requests only.

  5. Plugin

    This section is for plugin related support, releases, and requests only.

  6. Client-Side

    This section is for client related support, releases, and requests only.

  7. Graphic Enhancements

    This section is for graphic enhancement related support, releases, and requests only.

  8. Other Support & Releases

    This section is dedicated for support regarding Linux, Windows, or release of website resources (i.e. Control Panels) and Server Managers / Editors.

  • Featured Topics

  • Latest Commits

  • Topics

  • Posts

    • Hello, I think you have uploaded the wrong file here it is a card collector.txt, not endless tower.   On a side note, doing this change in setunitdata:   case UDT_DMOTION: //setunitdata_check_bounds(4, 0, USHRT_MAX); <---comment out then add setunitdata_check_min(4, 0); break;   is not increasing the limit. You just disabled the safety check and is letting the compiler set whatever value it wants (there is a logic to what is setting but this is a bit level and I don't know 100% how to expain/whether it is consistent on all compilers).   These variables are not big enough to support values higher than ~65000 (USHRT_MAX). It doesn't error out because the code is doing a cast, and it will simply ignore part of the value and go ahead with whatever the casting resolves to. (Which will be between 0 and ~65000).   From an online compiler, 96,000 will actually become 30,464 and 120,000 will actually be 54,464.   Try doing a getunitdata after you set it and you will see the real value.   To go over 65k at least the variables needs to be changed from short to int, I am not sure if this would be enough or this would cause issues in other parts, but unless this is done, you can't set a value higher than 65k (and that's why you see this error in vanilla herc)
    • I've never done it and this answer may not be totally accurate...   But I think the following is what you need to keep in mind: 1. NEMO probably won't be able to patch it, you will have to do by hand 2. The hardest part is not using the client, but usually each official server uses a different combination of packets. For example, if packet A was added in kRO in 2015, and packet B in 2016. For another server it may be the case that packet B was added in 2020 and packet A never came. Thus, relying in PACKETVER config will most of the time not work.   So you will certainly need knowledge on how to customize packets read/sent by herc -- specailly clif.c and related packet structures (and their counterparts in char/login server)   PEEK or BPE (Links to their topics below) may help you find the list of packets currently defined for the client. I did not test BPE for that, but I do remember PEEK being able to extract packet length table -- which would include the packet ID too.   For packet structures (if any of them changed for any reason -- should not be the case, usually only versions change) that will be harder. If you need a different structure, I think you have 2 options: 1. Reverse engineer the client and find where it sends the packet you need with some reverse engineering tool (IDA, Ghidra, etc) 2. Capture the packet and find the data by trial and error and guessing -- A good amount of guessing is needed here, and you may get some thing wrong   I am not sure if I can give much more info than that. But I guess it is better than nothing If you are really going this route, do know that it is some quite advanced stuff with barely any public info          
    • Step back into the golden era of Ragnarok Online with our meticulously recreated server based on the original eAthena from 2006, featuring Episode 11.3. We have painstakingly restored authentic content, including original monster spawns, mechanics, skill trees, skill functionality, maps, NPCs, and more. Using an original 2006 client, we offer a genuine retro experience without modern additions like battle mode or a mailing system. If you remember, you have just 12 pieces of F keys and Your only way to have a ''battle mode'' will be in Alt+M mode   To enhance the fun, we've set our rates to 100/100/50. Whether you're here to help us hunt down bugs or simply want to relive the classic 2006 atmosphere with friends, we invite you to join us on this nostalgic journey. If you're interested in participating, please reach out to me on Discord at Haganen#0204. I'll be personally selecting trustworthy individuals to ensure the integrity of our community. Given the vulnerabilities of the old server and client, this project is exclusive and not publicly accessible. It's a haven for true old-timers looking to reconnect with the magic of 2006 Ragnarok Online. Join us, and let's bring back the adventure and camaraderie of the past!
    • Update I also offer now original soundtrack for your server OldschoolRO - HR   OldschoolRO - MR  
    • Hi all,I need to know how to find the client packet for other official server not from kRO...   All I know the client that Hercules support from kRO   Can someone teach me how to find the packet for existing roextreme client?
  • Download Statistics

    • Files
    • Comments
    • Reviews

  • Create New...

Important Information

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