JiKeidan

As for the "gibberish" text... if you can do a chat dump (/savechat FILENAME will save the chat as a file in your RO directory)... then officially copy and paste that nonsense ascii-talk and do a similar scan... if you're on a hunky junky windoze box =P then paste it up here and i'll run it through my handy ole grepper... might try (if using windows) to throw it in a #^F query (windows key + f) lol and AFTERWARDS i want YOU to help me out with some of MY issues =P

not entirely sure... what os you running? Well on my debian box, i ran /\ ~/rAthena/trunk/ find ./ -type f -exec grep -i emails '{}' \; -print Which gave me the following output: 510: You have %d new emails (%d unread) 1151: Please enter 2 emails (usage: @email <actual@email> <new@email>). ./conf/msg_conf/.svn/text-base/map_msg.conf.svn-base 510: You have %d new emails (%d unread) 1151: Please enter 2 emails (usage: @email <actual@email> <new@email>). ./conf/msg_conf/map_msg.conf clif_displaymessage(fd, msg_txt(1151)); // Please enter 2 emails (usage: @email <actual@email> <new@email>). ./src/map/atcommand.c clif_displaymessage(fd, msg_txt(1151)); // Please enter 2 emails (usage: @email <actual@email> <new@email>). ./src/map/.svn/text-base/atcommand.c.svn-base So you may try looking in any of those files... as those are the only files that contain the word "emails" =P to clean that up a bit... ./conf/msg_conf/.svn/text-base/map_msg.conf.svn-base ./conf/msg_conf/.svn/text-base/map_msg.conf.svn-base ./conf/msg_conf/map_msg.conf ./conf/msg_conf/map_msg.conf ./src/map/atcommand.c ./src/map/atcommand.c ./src/map/.svn/text-base/atcommand.c.svn-base ./src/map/.svn/text-base/atcommand.c.svn-base but the above output shows which files have which output containing "emails"

i *think* those are handled in the ./athena/conf/motd.txt at least the "eathena svn version" message

So, I have been working for the last few days pretty diligently, trying to get a working server and client up for Ragnarok... this is a question, however... so bear with me as I want to make my understanding of how these things work, clear... to assist you (kind soul) in helping me ^.^ I am beginning to see how things function... 2012 Clients and later use Alexandria's v3 Data package... Data package in these later clients REQUIRE grf file to be made of said package... <2012 Clients use respective versions, but I've only been willing to go back as far as 2011-03... which uses Alexandria's Data pack v2. Shin's Differ works magick on the clients, hexing them to your specifically desired functionality... a few things being required (specifcally skipping packet header obfuscation and not reading data files first), everything else seems to be fairly dynamic in choice. Lua versions have to match your client.. .if you are trying to use Lua versions in Alexandria's v3. data package, with <2012 clients, then you are to be bombarded with plenty of lua death messages, threatening your sanity (nor can u use <=v2. with >=2012 clients) The obvious importance of keeping your dates and packages consistant is not in question, however... in either of 2 scenarios (whichever will work)... Running v3 with 2012-04-10aRagexeRE client: Even using Earthlingz's obfuscation dll, there is no way to "skip packet header obfuscation" in diff... so squaring everything else away... 0x970 byte will disco the user EVERY time, after character selection. Running v2 with ohhh... go with 2012-03-15aRagexeRE client (since it is by far the most predictable and stable i've worked with, OF the 2011 series): Great! We can skip packet header obfuscation, but now when I am finally able to get into the server and dance around a bit... my celebrating is cut short as I am frozen solid, and if i send too many chat messages (none of which are appearing in my main chat), the server disco's me anyway... If I use any other client, I either get tiny window syndrom (window is barely big enough to make out any of the serial number in the bottom-corner of the screen) or the client refuses to load... as in, thinks for a couple seconds about it, and then goes back into it's folder and stays away from memory =P To conclude... how in the world were any of you able to get your ragnarok clients working with any version? Not for lack of trying, but I'm failing around every turn. If anyone out there is able to ask the right questions and help me realign the way I think about this entire operation, I would be very appreciative. I think this is going to require actual conversation though. Thanks in advance.

I was actually having the same problem, but specifically with character selection, being transferred to the map server, regarding byte 0x970. Naturally having r17185 the 2012-04-10aRagExeRE.exe is included in the packet_db under version 30... and yet even in the packet db, that particular byte is not mentioned. Why then, is the client attempting to send a byte, that is not recognized in it's version?... I have a hard time understanding what specifically the role of the .exe is compared to the data files, lua, system, etc... where are these bytes coming from?... i'm using alexandria's Data bundle v3... The typical work-around seems to be to diff with packet header obfuscation... which would be nice if (even using earthlingz's rebuilt dll) it was an option... otherwise I think i'd have a working client by now. -------------------------------------------- as for the more immediate concerns on this topic, what mootie was saying is in each of your .conf files (./athena/trunk/conf/char_athena.conf ./athena/trunk/conf/login_athena.conf and ./athena/trunk/conf/map_athena.conf) you have to specify which interface to bind your serverS to. // is used in a variety of programming languages in order to designate a COMMENT line. By using //login_ip: 127.0.0.1 you are telling the server to connect to the login_athena server ON A COMMENTED line... remove the (//) and specify the device you wish to have the server bind to (127.0.0.1 will only work internally on ur computer... otherwise if you're behind a router use 192.168.x.x or w/e your LAN connected network card is attatched to

Solved That may be, I whiped the database, ran 'svn up' on the trunk... and did as explained above... perhaps it all just came together smoothly =P... if you don't mind... will this upgrade sql work with the other problem i've been having?: http://rathena.org/board/topic/79839-unknown-byte-0x970-20120410ragexre-rathena-17179-kro-20121001/

Unfortunately after whiping my rAthena server folder entirely, and re-installing via SVN (r17185) I configure, compile and run after changing all listening servers to my LAN ip (debian OS, so they have to listen on that device or the router won't forward properly, here nor there)... I now have this issue: [SQL]: DB error - Unknown column 'pincode' in 'field list' [Debug]: at account_sql.c:528 - SELECT `account_id`,`userid`,`user_pass`,`sex`,`email`,`group_id`,`state`,`unban_time`,`expiration_time`,`logincount`,`lastlogin`,`last_ip`,`birthdate`,`character_slots`,`pincode`, `pincode_change` FROM `login` WHERE `account_id` = 1 [Notice]: Unknown account (account: ***, received pass: ***, ip: 192.168.1.20) [Notice]: Connection of the char-server 'Moonlight_RO' REFUSED. [Error]: Can not connect to login-server. which makes perfect sense considering that all cridentials are being queried from sql in 1 string... and when 'pincode' as a column is not found... it throws out the entire statement, thus comparing user *** and pass *** to NULL and NULL (or w/e default value those variables hold) Question is, why is it looking for this pincode column at all? If I go in and fix login.c to not ask for the pincode column, will there be other side effects? Is that even the proper solution? ***EDIT: I resolved my own issue.... Running debian 6.0.6 (might be relevent) I had been using the shell command: cat main.sql | mysql -u root -p ragnarok to populate my database, for whatever reason... it doesn't work well... when instead i used: mysql -u root -p ragnarok < main.sql it seemed to apply that rule... i don't know if there's much of a difference honestly... could have caught the svn update at a bad time... =\ it's working now though... anyone with a similar issue, check your main.sql and search for 'pincode' ... if it's there, then it should work.

Which revision are you using?

yah, nevermind