Everade
-
Posts
192 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Downloads
Jobs Available
Server Database
Third-Party Services
Top Guides
Store
Crowdfunding
Posts posted by Everade
-
-
Ich benutze bereits seit längerem den Thor Patcher (vorher KPatcher, welcher wirklich nicht zu empfehlen ist)
In letzter Zeit habe ich viele Bug Reports an den Coder vom Thor Patcher gesendet.
Er hat soweit alles ernst genommen und vieles davon gefixt.Somit kann ich den Thor Patcher wirklich nur empfehlen!
Ich hoffe einfach das andere Leute sich auch die Mühe geben ihm Bug Reports per mail zu senden. -
Well, according to the current char_athena.conf file and so on, it states:
// Set this to what your server's public IP address is.//char_ip: 127.0.0.1
So if you follow the instructions, i guess you shouldn't have any issues at all.
It's just that (as stated above) i've had issues in the past with the ip conf settings, which forced me to set the login ip address as well in the login_athena.conf for instance. (there were other weird issues as well, but bare with me, i don't have the best brain to save memories from what happened a week ago and this goes 10 years back)
So on my rA SVN rev. 13742 and older (back to eAthena) it worked with the local IP address setAnd when i updated to the latest revision (which was quite a big update)
global address ip was required and caused my initial issue stated at the very top.-
1
-
-
With my old revision, my map, char and login configurations were each set as local IP address.
For for instance:
map_athena.confmap_ip: 127.0.0.1char_athena.conf
char_ip: 127.0.0.1login_athena.conf
login_ip: 127.0.0.1Now on the latest rAthena revisions, i was forced to set each of these to the global ip instead.
So for example:map_athena.conf
map_ip: 93.65.178.54char_athena.conf
char_ip: 93.65.178.54login_athena.conf
login_ip: 93.65.178.54I don't know if my old configurations were always wrong in the past.
However it always worked before. (worked for over 10 years)I have to mention here that i've always had weird issues with the IP settings back in the past.
I remember about 8~10 years back i've had reported a similiar issue on eAthena. It only worked when i specified specific configs which were not even preset on the emulator itself.
Like now being forced to the public ip on login_athena.conf for example.
And now you're forced to set it to the public ip address, otherwise it won't work anymore.
(i know it even states it in the settings to set it to the public one, i can read just fine)It's just that it worked for 10 years straight and i did not expect that i would be forced to change anything related to the ip settings.
So from what i remember, that was the actual issue on this one.
-
No i never used any command unless the official ones
/str+ 200
To increase my stats.
This is a freshly created character, naturally leveled up.
No commands used what soever.
Something is just freaking messed up and i can't find out what it is.
That's why i'm here.Just look at the other stats as well.
I increased AGI by 1 which costs me 2 points.
Yet the script says it costs 3 points.(As mentioned above)
-
Script by Brian:
https://rathena.org/board/topic/70252-anti-cheat-stats/?p=183729I have tested myself during several hours through the entire Total Stat Point check script.
Over and over again, together with a buddy of mine we studied the whole code.
Even compared it to the source code from rAthena.We have no idea what's wrong, but for some reason the calculated stats are messed up as soon as you add some stats.
I have removed all unnecessary code, to fit my test server.
It's a renewal server, however we have this setting in renewal.h
//#define RENEWAL_STAT
commented!So with that we're using the classic stat system.
Which means the script should work on Classic Server setups onlyYet according to the npc calculation, the first stat point i use on STR for instance, will cost me (according to the npc) 3 stat points.
While in reality it costs only 2.
At 200 STR the npc tells me it costs me -1283
(max stats are 200 on my server)Next to that, it also tells me as a BABY class that i should have 6972.
Correct me if i'm wrong but... only trans classes should reach 6972 stats.
Non trans classes should be able to reach 6920 only right`?
Really looking forward to some support on this one.
We ran out of ideas...By the way:
On the screenshot, it says i'm missing 3617 stat points
But i'm only missing 52 if i reset my stats to 0 which equals to 6920 stat points in total.prontera,155,180,0 script Total_Stat_Points 910,{ function pc_need_status_point; // src/map/pc.c function pc_maxparameter; function read_statpoint_table; mes readparam(bStr)+" Str = ^0000FF" + pc_need_status_point(bStr, 1-readparam(bStr)) + "^000000 " +readparam(bInt)+" Int = ^0000FF" + pc_need_status_point(bInt, 1-readparam(bInt))+"^000000"; mes readparam(bAgi)+" Agi = ^0000FF" + pc_need_status_point(bAgi, 1-readparam(bAgi)) + "^000000 " +readparam(bDex)+" Dex = ^0000FF" + pc_need_status_point(bDex, 1-readparam(bDex))+"^000000"; mes readparam(bVit)+" Vit = ^0000FF" + pc_need_status_point(bVit, 1-readparam(bVit)) + "^000000 " +readparam(bLuk)+" Luk = ^0000FF" + pc_need_status_point(bLuk, 1-readparam(bLuk))+"^000000"; sleep2 1; mes "unused StatusPoint = ^0000FF" + StatusPoint + "^000000"; set [email protected]_have, read_statpoint_table(BaseLevel) + ( Class&EAJ_UPPERMASK ? 52 : 0 ); //==== statpointcount() ==================================================== set [email protected]_statpoint, pc_need_status_point(bStr, 1-readparam(bStr)) + pc_need_status_point(bAgi, 1-readparam(bAgi)) + pc_need_status_point(bVit, 1-readparam(bVit)) + pc_need_status_point(bInt, 1-readparam(bInt)) + pc_need_status_point(bDex, 1-readparam(bDex)) + pc_need_status_point(bLuk, 1-readparam(bLuk)) + StatusPoint; //========================================================================== mes " "; mes "Should Have = " + [email protected]_have + " stat pts"; mes "Actual Stat = ^0000FF" + [email protected]_statpoint + " stat pts^000000"; if ([email protected]_statpoint == [email protected]_have) { mes "^008000 Correct.^000000"; } else if ([email protected]_statpoint > [email protected]_have) { mes "^FF0000 You have "+([email protected]_statpoint - [email protected]_have)+" extra stat points!^000000"; // do other stuff like: // - @kick, ban, or @block // - notify GMs with @request // - notify the server with announce } else if ([email protected]_statpoint < [email protected]_have) { mes "^0000FF You are missing "+([email protected]_have - [email protected]_statpoint)+" stat points T_T^000000"; } close; function pc_need_status_point { set [email protected], getarg(0); set [email protected], getarg(1); if ([email protected] == 0) return 0; set [email protected], readparam([email protected]); if ([email protected] >= pc_maxparameter() && [email protected] > 0) return 0; // Official servers show '0' when max is reached set [email protected], [email protected] + [email protected]; if ([email protected] < 0) { // swap(low, high); set [email protected], [email protected]; set [email protected], [email protected]; set [email protected], [email protected]; } for ( ; [email protected] < [email protected]; set [email protected], [email protected] +1) { set [email protected], [email protected] + (( 1+ ([email protected] + 9) / 10 )); } return [email protected]; } function pc_maxparameter { return 200; } function read_statpoint_table { switch (getarg(0)) { case 1: return 48; case 2: return 51; case 3: return 54; case 4: return 57; case 5: return 60; case 6: return 64; case 7: return 68; case 8: return 72; case 9: return 76; case 10: return 80; case 11: return 85; case 12: return 90; case 13: return 95; case 14: return 100; case 15: return 105; case 16: return 111; case 17: return 117; case 18: return 123; case 19: return 129; case 20: return 135; case 21: return 142; case 22: return 149; case 23: return 156; case 24: return 163; case 25: return 170; case 26: return 178; case 27: return 186; case 28: return 194; case 29: return 202; case 30: return 210; case 31: return 219; case 32: return 228; case 33: return 237; case 34: return 246; case 35: return 255; case 36: return 265; case 37: return 275; case 38: return 285; case 39: return 295; case 40: return 305; case 41: return 316; case 42: return 327; case 43: return 338; case 44: return 349; case 45: return 360; case 46: return 372; case 47: return 384; case 48: return 396; case 49: return 408; case 50: return 420; case 51: return 433; case 52: return 446; case 53: return 459; case 54: return 472; case 55: return 485; case 56: return 499; case 57: return 513; case 58: return 527; case 59: return 541; case 60: return 555; case 61: return 570; case 62: return 585; case 63: return 600; case 64: return 615; case 65: return 630; case 66: return 646; case 67: return 662; case 68: return 678; case 69: return 694; case 70: return 710; case 71: return 727; case 72: return 744; case 73: return 761; case 74: return 778; case 75: return 795; case 76: return 813; case 77: return 831; case 78: return 849; case 79: return 867; case 80: return 885; case 81: return 904; case 82: return 923; case 83: return 942; case 84: return 961; case 85: return 980; case 86: return 1000; case 87: return 1020; case 88: return 1040; case 89: return 1060; case 90: return 1080; case 91: return 1101; case 92: return 1122; case 93: return 1143; case 94: return 1164; case 95: return 1185; case 96: return 1207; case 97: return 1229; case 98: return 1251; case 99: return 1273; case 100: return 1295; case 101: return 1318; case 102: return 1341; case 103: return 1364; case 104: return 1387; case 105: return 1410; case 106: return 1434; case 107: return 1458; case 108: return 1482; case 109: return 1506; case 110: return 1530; case 111: return 1555; case 112: return 1580; case 113: return 1605; case 114: return 1630; case 115: return 1655; case 116: return 1681; case 117: return 1707; case 118: return 1733; case 119: return 1759; case 120: return 1785; case 121: return 1812; case 122: return 1839; case 123: return 1866; case 124: return 1893; case 125: return 1920; case 126: return 1948; case 127: return 1976; case 128: return 2004; case 129: return 2032; case 130: return 2060; case 131: return 2089; case 132: return 2118; case 133: return 2147; case 134: return 2176; case 135: return 2205; case 136: return 2235; case 137: return 2265; case 138: return 2295; case 139: return 2325; case 140: return 2355; case 141: return 2386; case 142: return 2417; case 143: return 2448; case 144: return 2479; case 145: return 2510; case 146: return 2542; case 147: return 2574; case 148: return 2606; case 149: return 2638; case 150: return 2670; case 151: return 2703; case 152: return 2736; case 153: return 2769; case 154: return 2802; case 155: return 2835; case 156: return 2869; case 157: return 2903; case 158: return 2937; case 159: return 2971; case 160: return 3005; case 161: return 3040; case 162: return 3075; case 163: return 3110; case 164: return 3145; case 165: return 3180; case 166: return 3216; case 167: return 3252; case 168: return 3288; case 169: return 3324; case 170: return 3360; case 171: return 3397; case 172: return 3434; case 173: return 3471; case 174: return 3508; case 175: return 3545; case 176: return 3583; case 177: return 3621; case 178: return 3659; case 179: return 3697; case 180: return 3735; case 181: return 3774; case 182: return 3813; case 183: return 3852; case 184: return 3891; case 185: return 3930; case 186: return 3970; case 187: return 4010; case 188: return 4050; case 189: return 4090; case 190: return 4130; case 191: return 4171; case 192: return 4212; case 193: return 4253; case 194: return 4294; case 195: return 4335; case 196: return 4377; case 197: return 4419; case 198: return 4461; case 199: return 4503; case 200: return 4545; case 201: return 4588; case 202: return 4631; case 203: return 4674; case 204: return 4717; case 205: return 4760; case 206: return 4804; case 207: return 4848; case 208: return 4892; case 209: return 4936; case 210: return 4980; case 211: return 5025; case 212: return 5070; case 213: return 5115; case 214: return 5160; case 215: return 5205; case 216: return 5251; case 217: return 5297; case 218: return 5343; case 219: return 5389; case 220: return 5435; case 221: return 5482; case 222: return 5529; case 223: return 5576; case 224: return 5623; case 225: return 5670; case 226: return 5718; case 227: return 5766; case 228: return 5814; case 229: return 5862; case 230: return 5910; case 231: return 5959; case 232: return 6008; case 233: return 6057; case 234: return 6106; case 235: return 6155; case 236: return 6205; case 237: return 6255; case 238: return 6305; case 239: return 6355; case 240: return 6405; case 241: return 6456; case 242: return 6507; case 243: return 6558; case 244: return 6609; case 245: return 6660; case 246: return 6712; case 247: return 6764; case 248: return 6816; case 249: return 6868; case 250: return 6920; } return 0; // BaseLevel out of range } }
-
So it's supposed to be style.bmp and the client simply loads the wrong file name?
Because from what i've seen it's the stylist shops, and i've never seen the style.bmp to be used anywhere else.
-
1
-
-
totem.bmp is the icon used on all Styling Shops on the minimap.
I also wasn't able to find the picture, so i drew my own icon for it xD
Please post the totem.bmp here if you were able to find it.
-
I'm using 2015-09-16aRagexe
I personally never had this crash issue, the effect works just great.As i'm currently running a test server with beta testers, one of the testers actually experienced the same issue as you.
I have no idea why this happened, as i've offered the same files through a patcher for everyone.
-
Anyone?
-
Harmony Anti Cheat System also offered a splash screen.
But it's outdated (only available for older clients)
-
Bump
I'm using 2015-09-16aRagexe
-
All latest clients are now showing the following message if you go above their zeny limit while vending.
You entered more than 1 Billion Zeny ,
the price will be set to 1 Billion Zeny.With that the setting in item.conf:
vending_max_value: 1000000000
Does not take any effect anymore if you try to increase the limit.
Anyone an idea how to get rid of this message or simply how it's possible to increase it to 2Billion?
Is this hard-coded clientside or triggered by rAthena? -
I ran into the same issue as well while setting up my beta test server.
I tried to make it as easy as possible for the players, using thor patcher to simply patch the complete client.
While testing it myself, i tried to repack the whole data.grf on windows 10 using an older Thor Patcher version.
I got stuck with that infinite saving resource issue.
So i tried to split the data.grf into 10 smaller patches (150 up to 270MB)
It worked just fine for me, yet after releasing the open beta, i've recieved several reports that they get stuck on the saving ressources.
A few people retried it several times until it worked, others weren't able to get it fixed at all.
All i can say is:
Either split it up to really really small patches (i would say max 150MB).
Or let the players download it manually.I was talking with the developer of Thor Patcher about this, he actually made quite a few updates to the patcher within the past months.
He was able to fix another bug i've encountered in his latest release, so you could also try testing the latest one.
I haven't tested the saving resources issue as of yet, but it may be fixed already.
-
langtype 0 is korean, that way you won't be able to type special signs such as
öäü éàè and so on. Instead you will get either ? or korean signs while trying to type them.I would recommend langtype 1 which is america.
That should fix your issue
Please note that on langtype 1 however your guild tip "help" information window won't show any information anymore. If anyone knows how to solve that problem, please let me know.
+-----+------------------------+-------------------+ | int | enum SERVICETYPE | "servicetype" tag | +-----+------------------------+-------------------+ | 0 | SERVICETYPE_KOREA | korea | | 1 | SERVICETYPE_AMERICA | america | | 2 | SERVICETYPE_JAPAN | japan | | 3 | SERVICETYPE_CHINA | china | | 4 | SERVICETYPE_TAIWAN | taiwan | | 5 | SERVICETYPE_THAI | thai | | 6 | SERVICETYPE_INDONESIA | indonesia | | 7 | SERVICETYPE_PHILIPPINE | philippine | | 8 | SERVICETYPE_MALAYSIA | malaysia | | 9 | SERVICETYPE_SINGAPORE | singapore | | 10 | SERVICETYPE_GERMANY | germany | | 11 | SERVICETYPE_INDIA | india | | 12 | SERVICETYPE_BRAZIL | brazil | | 13 | SERVICETYPE_AUSTRALIA | australia | | 14 | SERVICETYPE_RUSSIA | russia | | 15 | SERVICETYPE_VIETNAM | vietnam | | 17 | SERVICETYPE_CHILE | chile | | 18 | SERVICETYPE_FRANCE | france | | 19 | SERVICETYPE_UAE | uae | +-----+------------------------+-------------------+
-
I've had an old script which worked some years ago, which used:
if (petstat(PET_CLASS) != 3065) { mes [email protected]$; mes "Where is my love?"; close; } if (petstat(PET_CLASS) == 3065) { set [email protected]$,"[Lady Solace]"; mes [email protected]$; mes "Oh Lady Solace!"; mes "My wonder,"; mes "My delightfulness!"; next;However petstat is deprecated, so i tried to update the script to the new one i've found in the script doc file:A_BringLadySolace: if (getpetinfo(PETINFO_CLASS) != 3065) { mes [email protected]$; mes "Where is my love?"; close; } if (getpetinfo(PETINFO_CLASS) == 3065) { set [email protected]$,"[Lady Solace]"; mes [email protected]$; mes "Oh Lady Solace!"; mes "My wonder,"; mes "My delightfulness!"; next;But it does not work anymore.The npc always ends with the "Where is my love?" part.Even if i have the pet with the pet_db id 3065 currently in use.Am i doing anything wrong, or is this script command broken?I simply want to check if i have the pet with the db id 3065 currently HATCHED -
Problem solved.
Thanks Dastgir, you were a big help.
It was a silly issue related to my configurations.
For some reason the same configs worked on my old rAthena revision using a 2012 client.Can be closed
-
[Info]: connect_check: Connection from **.*.***.*** allowed. [Status]: Request for connection of testaccount (ip: **.*.***.***) version=53 [Notice]: Authentication accepted (account: testaccount, id: 2000013, ip: **.*.*.***) [Status]: Connection of the account 'testaccount' accepted. [Info]: Closed connection from '**.*.***.***'.
I've updated to a new client, however my issue is the following:
As soon as i've successfully connected to the Login Server as shown above.
The Login Server immediately closes my connection again, as shown above. (unless that's normal?)
On my client, it looks like i'm connected.
But when i select the server to connect to the char server, the char server never recieves any packet.
And the Client simply times out.
I've tried 3 different clients out of 3 different years, all of them officialy supported.
Could someone please tell me what's wrong?
I'm out of ideas.
Maybe it's just a small mistake, who knows.
-----------------------------
Current client i'm testing:
2015-09-16aRagexe
rAthena rev: 15556 (27 January 2016)
packet_db.txt:
packet_db_ver: 53packet_keys_use: 0x17F83A19,0x116944F4,0x1CC541E9mmo.h:
#define PACKETVER 20151029
Clientinfo:<version>53</version>------------------------------ -
- Nicht benötigte Dateien löschen (das wird schwierig welche zu finden)
- Falls die GRF alt ist, kann es sein das sie stark fragmentiert istEs gibt Patching Systeme die in der Lage sind nach einer gewissen Grösse an Fragmentierung diese zu defragmentieren
Ansonsten einfach:
- GRF komplett entpacken und wieder neu packen (Guides dazu findest du genug, GRF Editor ist dafür sehr gut)
- GRF in mehrere kleinere GRF Dateien aufsplitten (Gesamtgrösse bleibt gleich, aber du hast dann zB mehrere .GRF dateien die nur noch 500MB Gross sind oder nocht kleiner) und dann einfach in der DATA.ini angeben damit der client die alle liest.
Schlussendlich gehts nicht kleiner, GRF ist bereits stark komprimiert. -
-
A newly created char starts in the novice grounds, not prontera.
So no, it's not the problem.
But thanks for the information on a new prontera, that's new for me ^^ -
Yeah, I'm sorry to say but I would have been glad to help you get your stuff working, and after that awful reply, I'd rather not deal with you personally.
Good luck finding help from somebody else. It's no surprise you find none.
Thank you
The Client Support topic isn't that out dated. Truthfully speaking the 2014 client was missing (I just added it in). Client development has become very slow after the clients were packed with Themida.
If you've done all those steps, provide the errors you are hitting that way people can provide more accurate answers.
From what i remember that topic included 2012-04-10aRagexeRE as the latest client.
Whatever...
I've provided the error already.
There's none.
It's a simple client crash without any error at all, right after loading the map server.
-
I guess there's no response on your char server?
Please check the following configs.
Because i just had the same problem.rAthena/conf/char_athena.conf
// Character Server IP // The IP address which clients will use to connect. // Set this to what your server's public IP address is. char_ip: public ip here!<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
rAthena/conf/map_athena.conf
// Map Server IP // The IP address which clients will use to connect. // Set this to what your server's public IP address is. map_ip: public ip here!<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
-
Yes, I believe you're the only one feeling this way. I don't know why you decided to go for 2014-02-05b after being told 2014 wasn't very thoroughly tested and we recommended you use a 2013 client.
Your previous post before that one had no details, so nobody was able to help you, and you just exploded into a huge rant, making people feel even less inclined to bother.
Yes 2013 is recommended.
I've tested (right before my huge rant) 2013-08-07aRagexe
Yet exact the same issue.
But thanks to everyone who tried to help.
It's really not personal, it's just driving me crazy
2014-02-05b isn't even supported by rAthena. You need to stick with 2014-10-16 or 2014-10-22.
As for your rejections, yes, it could be that you didn't have your IP setup correctly in your config. I ran into that issue as well while testing the newer clients and saw no one out there had posted anything about it since not many people ran into it. The problem was because I was using imported values that I just copied over while testing, but later fixed the issue when I started everything clean and saw what I was doing wrong.
Make sure your data.grf is fully up to date as well since you're using a newer client. Grab the updated LUAs. Diff your client using NEMO as it is pretty much the most stable and up-to-date patcher out there. By default the server should have packet obfuscation on. Follow the steps in the link before for making sure your packet obfuscation is setup correctly. And, that's it. You should be good to go.
I've realised that 2014-02-05b isn't even supported. But only after checking all files on my own. (the missing packet version with all those question marks etc... Yet hercules has a complete packet db in their source already)
According to the rAthena forums it looked as the most promising and up to date client.
I've first tried 2014-10-22 because you stated in the news that it's now officialy supported. Yet that client crashes right away so i tried the next one.
That's what i'm trying to say.
It's hard to find out with what you're good to go.
The topic "official supported clients list" is SUPER outdated.
My data.grf is fully up to date.
I've tested 6 different FullClient setups. (also not fully up to date)
with and without rdata.grf
With old luas
latest luasluas released on client release date
diffed using NEMO
tested through all diffs if one may be broken
Tested WITH and WITHOUT packet obfuscation. (client diff incuding source code)I've wasted 2 weeks already.
as always
-
Ok found the issue.
For some reason it seems to work different than my old version.
There was an issue with the char_ip setting.It works on my live server though.... at least i've found it.
After another few hours of testing and debugging i've found out that the packet_db from rAthena is completly messed up.
I had to manualy fix some things for the client 2014-02-05b
The packet keys were totally, also one packet, while it seems to contain a few more packets which probably shouldn't be there, i don't know.So after fixing my packet_db on my own, i was able to get up to the map server without any rejection of a "wrong packet" error.
Yet the client crashes right away.
[WIP] Native Ragnarok Client
in Abandoned Projects
Posted · Edited by Everade
Looks already pretty polished. Respect!
The best thing that could happen to this project would be, if it goes open source ones you're ready for it.
I'm sure there's more than 1 person willing to extend this project to it's full potential, which would also give us the possibility to implement renewal features as well.
And real-time shadows sounds like a more than awesome feature
Which could be extended with light effects coming from fire effects for instance (otherwise some maps might look weird with the missing color variety on the floor)