Seraph Sephiroth

How is that a minus? The mob HP bars will have different colors. I'd say that it is only a pro for support classes to be able to view a mob's HP in addition to the party members HP.

Alright, I am currently diving into everything related to that function. I do have a little question though, I read on the eAthena board that the client specifically handles the way the player HP/SP bar (I mean the one beneath the player) gets filled in. Now I am not so sure where to look for a solution to my problem. You see, what I am attempting to achieve is get that display to function correctly when I set my maximum HP to a value higher then 21.000.000/22.000.000 (not exactly sure where the limit lies). Can this be done through editing source code in rAthena? Or is this problem solvable only through some type of client hack?

I would like to inquire the method the client uses to handle increment in player HP bar percentage status. Or anything that is related to that process for that matter. I've been searching my head off all day, and just did not manage to find anything useful on that topic.. It would be nice if someone could give me a little heads up.

I don't see how you can use a function that is not embedded within a script. Your goal is to reset stat points, no?

What script are you trying to use exactly? I tested resetnpc.txt myself just now, and it works like a charm. My server limit is set higher then yours as well.

I think so, yes. If you search for the script that is activated upon "overweight" status, you should be able to insert that same string into an equipment script slot. Although, I could be wrong about that since I haven't tried it out personally. If it works, be sure to edit the script so natural healing doesn't get affected.

You need to alter all of these files; battle.c map.h client.conf exp.txt to successfully change your server's maximum allowed character level.

*knock knock* Hello? Is there no one that knows why the integer is not functioning correctly when set to anything higher then UINT16_MAX?

I am talking about the variable "status_point". This is used to store points used in upgrading your character stats (str,agi,dex,vit,luk). I was able to find an influencing factor in clif.c on this. When you go to the line "WBUFW(buf,2)=min(sd->status.status_point, INT16_MAX);" you can affect the method status_point is stored to the server, however.. No matter what I try to replace it with, it either stores the value as "-1" or in the range of "-28000 / -29000" with a test character leveled to 1000. Unless I use a smaller integer to store the value, such as UINT8_MAX I believe it will then obey neatly and store a maximum value of "255". It appears as if I am simply not permitted somehow to store a value exceeding UINT16_MAX, anything higher then that will just act as if the integer is not unsigned. My SQL database stores the correct value, but it won't load back up. What does send the stat_point value back to what it really should be for a character, is gain/lose one or more base levels. That made me ponder on a possible fix through a script that would automatically de-level and re-level any character that logs on, to "fix" this value with a workaround. But ofcourse I'd much rather have this issue fixed the normal and clean way.

I did find that earlier on and tried to alter the code, but that didn't do anything at all. My current code in mmo.h is the following: struct mmo_charstatus { int char_id; int account_id; int partner_id; int father; int mother; int child; unsigned int base_exp,job_exp; int zeny; short class_; unsigned int status_point,skill_point; int hp,max_hp,sp,max_sp; unsigned int option; short manner; unsigned char karma; short hair,hair_color,clothes_color; int party_id,guild_id,pet_id,hom_id,mer_id,ele_id; int fame; I am not certain how to read the "short class_;" part, does this indicate a group altogether? Or is this an individual object? If the latter is true, my current code seems to assign an unsigned int to the status_point property yet it is not being read by my server. My SQL database had the value set to unsigned int as well, by default. I have tried to change my current code to this: struct mmo_charstatus { int char_id; int account_id; int partner_id; int father; int mother; int child; unsigned int status_point; unsigned int base_exp,job_exp; int zeny; short class_; unsigned int skill_point; int hp,max_hp,sp,max_sp; unsigned int option; short manner; unsigned char karma; short hair,hair_color,clothes_color; int party_id,guild_id,pet_id,hom_id,mer_id,ele_id; int fame; And ofcourse, recompiled. But that didn't seem to do anything either. What's also pretty odd, is that HP and SP values are also stored in that same list but I am able to push those values very high up. I have no issues concerning integers with my current max HP setting (75.000.000), although I did have to alter the assigned integer for that as well, it does obey my custom setting there.

I've been digging throughout the source for hours, searching the internet for possible hints on how to solve it but all to no avail. The points get reset to a measily 32767 as soon as a character logs out, and that just won't do. Is this problem related to packets? Or has the source been changed after all, to disallow a higher value being stored? All I do know for sure, is that this problem was not always there and I have used an older revision myself that had no issues with this whatsoever. Perhaps I am not looking close enough, but I have the sincere feeling looking further in the code won't do me any good either. I've tried looking up terms using text finders, I've looked at every file that included "status_point", "status point", "ushrt", "unsigned short" and several other variations, tried several adjustments, recompiled, realized it did nothing, and set it all back to the previous values to recompile again. I am using rAthena Revision 16243. If anyone can give me a solution on this revision, or commend a higher revision where this problem does not occur please share your knowledge. It will be greatly appreciated.

To my knowledge there is no way to set a skill cast time parameter for a select group such as 3rd Job skills only. It may be possible though by editing the source code, but that won't be worth the efford to begin with if you ask me. Just stick with doing it manually, and you could always re-arrange the layout of the correspondending file. This would allow you to macro manage your settings.

It is probably not the solution, but perhaps that particular client doesn't support character deletion relay even though it should? Have you tried it with higher clients?

Try changing your "langtype" in clientinfo to "0".

Try neglecting your data folder when it comes to clientinfo.xml It will not read from there, unless you use some special bat file (I've read). Just use the clientinfo inside your custom GRF file, I had the same issue and that solution fixed it for me.

Hmm, that's new information to me. I'll try it out immediately. --- Alright I tested the newly diffed client, and it does appear to work normally when using "RagexeRE.exe" as executable name. Thanks for sharing that, very handy indeed.

Using hackshield is very prone to give trouble loggin into the game. Most of the time it will not even start up properly and just "hang" there, pretending it's starting up when it just plain isn't. Even if it starts up it will take up so much time, it's just not fun anymore to play RO like that. It's worse then loading up an MSX tape to play a game on that system.

Can anyone confirm wheter this is normal client behavior or not? I am in the dark on that one. Judas bible doesn't have anything on that either. --- Fixed it on my own.

This is only partially true. It will read a certain portion, but it will also ignore a portion. You will not be able to connect using the clientinfo from the data folder, yet custom item information MUST be read from the data folder (at least in my experience it does).

Hello there people! I have a rather strange issue, but I'm not sure wheter it's supposed to be the way it is or not. Anyway, I succesfully added a custom card for my server yesterday but that appeared to be more of a struggle then it should be really, it took me the whole day to figure that one out. You see, what is happenening is the following: I diffed my client not to read the data folder, which it does to some extend (when turned on, I cannot connect to my server for instance so it doesn't read my clientinfo from the data folder). Yet, what it appears to be doing.. Is read the information required for custom item implementation from the data folder, and not from any GRF file I build with this information inserted. This means I am dependant upon the data folder no matter what when I wish to insert customs. And diffing the client to "don't read data first" has no effect on it whatsoever. I tried disabling my data folder by renaming it for instance, but that only results in missing information and customs turning into unknown items, or spriteless items that crash the server. Does anyone know if/how this can be resolved to a state where I can abandon my data folder altogether? So, to summarize quickly: - Sprites, etc are read from GRF - Edited text documents to support them are read from data folder, despite client diff.

You should probably get yourself a properly functioning work environment before attempting to play around with stuff like rAthena servers.

The code given here to answer Brynner's question did not work for me. I use revision 16243, and after some toying around with the code I found that the following code did in fact work for me: if( pc_isdead(sd) ) { clif_displaymessage(fd, "You cannot use this command when dead."); return -1; }

Good day board, I started a topic yesterday on an issue I ran into concerning MATK values that are stored "incorrectly" when my intelligence value is set too high. That topic can be found here: board/tracker/issue-6053-matk-reset-issue/ I kindly received some information from Core Developer "Wildcard", and was instructed to ask further assistence in the correct place. So here I am, asking for some pointers on where I would be able to find and possibly edit the method MATK is stored, so it would allow higher values then "65535". Supposedly it is a very unpleasant task to alter this, but I am willing to take on tedious unpleasant tasks. All I need, is to know how. :} Thanks in advance for any help I might get!

I don't know what the Karma system is factually for, but I can image they would use it for functions such as NPC behavior towards playing characters. This could result in varying chat options to choose from, denying services (save, teleport), possibly bribing related functions, and in case of shops: overprice/underprice purchases and sold items. It could be applied to certain battle/luck factors as well, perhaps something along the lines of hightening/lowering the overal chance of certain skills to be used succesfully, or allowing a slight possibility of no gemstone being used whereas normally it would require a gemstone to use a given skill.

Thanks a bunch, it's really appreciated! I never figured it could be found there >:-P