Char_id, account_id

[Anubis-K]

Hello,

 

        digging in the forum I did not find the answer to my question (or I was really blind), so I ask here.

Is there any special reason why the char_id starts at 150000 and the account id at 200000?

It is defined in the src somewhere and sql like that... the question is:  why?

 

Regards

 

Edit: I'm not sure anymore if it should be in "Support" or "SRC Discussion". It is not really a support questions, but in my mind matches better a discussion where I could learn something from.

Edited August 19, 2014 by Anubis-K

[Aleos]

It's a limit range just like all the other things on the server: Items, Mobs, NPC, etc. These I assume would be the default values AEGIS starts off with.

[Anubis-K]

This is an theory I have from before:

 

Time ago the NPC had the ids below 1000 (sprite, I'm talking about sprite in the mobs case), and the monsters start at 1000 (ID). So, in that case make sense in my mind: mob will never have an ID that overlaps the npc sprite ID. Therefore, both can live in peace in the lua file that regulates the sprites. Otherwise one npc will sprite id=1001 will be a scorpion (example).

That makes sense when I think about the new NPC_id (view) >10000: that gives enough space for some thousands of mobs before the NPC id start again.

Until this point my theory was: ID mob, should not overlap NPC sprite ID (stupid theory, but matches with the info I got from the lua files)

 

Just few days ago I thought about the char_id and account_ID. I think is because for something similar: char_id should not overlap mob_id or npc_prite_id or account_id.

Again: stupid theory without other sustain than the already explained, just because of the sprites.

 

By extension (Mathematical Induction), I tough the same apply to the account_ID. But, in the mmo.h I have found one non-further-explanatory line that refutes my theory, the number there present is an upper limit.

//Limits to avoid ID collision with other game objects
#define START_ACCOUNT_NUM 2000000
#define END_ACCOUNT_NUM 100000000
#define START_CHAR_NUM 150000

Now my question is: Does anyone have an idea if I'm thinking in the right direction about char_id, npc_wiev_id and mob_sprite_id?

 

NOTE: Further from this line you can skip, here come one idea and a doubt that should be posted may be in support, but still I do not ask for support, but for discussion so I guess it is not again the rules of the forum... I hope... :

 

 

I have found this in the forum: http://rathena.org/board/topic/95094-npc-bg-supplier-badges-to-cashpoints-converter/?hl=consumables#entry258367

The idea is to make it compatible with rAthena. good idea? bad idea? at the moment I think it is a bad one (read at the bottom).

 

They use a char_id to simulate the Alchemist (potion maker in general), of some consumables, that id can be used as an char_id that the players never will get (in theory below 150000) for example: 149999 or something big... very big 7777777777777777 (check integer type), and then read it from where the item is signed: 

set .@BG_CHARID, 165100; // character named "Battleground" 

Combined with:

getitem2 .@item_id,(.@amt*.@sets),1,0,0, 254, 0, .@BG_CHARID & 0xFFFF, .@BG_CHARID >> 0x10;

So far I have used on my eathena home server and works (with some tweaks and recoding). I Have implemented to read it from a Battleflag as a char id. If a character with the char_id=165100 is created the item gets the name of the character as it is suppose to do.

 

 

Now my question is: do you have an idea if it is a safe method?

 

Just thinking about how it is implemented. I would have a very interesting bugs and several security issues regarding the special signed items.

 

 

Regards, and thanks for reading this long testament.

[Aleos]

From what I get, all Brian did was take the char ID of a character he made. All you would need to do is just replicate this method. I have done it to create an automated Auction Script that is done by the server. I just made a character named "Auction" and then from there scripted the auction system to run off of that character's ID. You won't have collission because that character already exists.

[Anubis-K]

That is part of the point, if I use an existing character I will have no problems from the point of view of char_id overlap or something like that. That is what you say and I do agree, it will work perfectly.

 

Now, what I want to use a battle configuration (battle.conf or char.conf, something like that. i.e. configurable) to give the char_id of an unexisting character and then check if for the name in "map_reqnickdb()". That also should not generate any problem if and just if I use a char_id in the range that will not be reached when creating characters.

There is where my first question came from, the reason of the starting char_id (that is "clear" now and I know the range "I can use")

 

Now, thinking about bg consumables, the bugs: This system open some issues when combined with consumables:

 

- If Battleground not closed while woe and (&&) you have bonus Food+much (str+10,int+10, etc) they can go to BG and use them then go out to woe with some extra bonuses. (If allowed in batroom, it is even worse)

 

- They will be able to create potions (AM_PARMACY,AM_TWILIGHTx) using those items (white potions->condense white potion) by using those "cheaper" items (got from BG), because the src just check the item_id.

 

- Bug: If they use it out of the mapflag where are allowed (bg_consume, in the example case): I guess they will get the product but the ingredient will not be erased.

 

As I said: I want to make a patch for that cool feature, but I do not want to introduce bugs or issues.

 

Edit:

Now the question is: If in every case I do the patch (eAthena and rAthena) and I warn in the respective topic about the bugs and issues, would it be more a bug introduction than a help? (I'm thinkng of the case of BG consumables)

 

 

Regards

Edited August 21, 2014 by Anubis-K

[Cydh]

Even char_id, account_id, & npc_id is overlapped, it doesn't matter, because they used for different matters.

 

Well besides minimum char_id value that we believe is as AEGIS style, however, don't ever make it less than 256, as we can see, in some case, item that impossible to have slots (forged, named, egg) NEEDS card[0] for CARD0_ src/map/itemdb.h#L28-L30

 

So, afaik, don't ever make the minimum ID less than 256, for now.

 

and btw, so we can judge that script has wrong behavior then, to check if the items is BG items (but it's not official issue here)

[Anubis-K]

I have sen in the SRC that the char_id, account_id, & npc_id can overlap, but they should not happend in the case of npc_id & mob_id (as far as I understood generates sprite view problems). In general that was something I was thinking on.

 

Any way, that is very interesting, I never thought about the CARD0_X could matter in that case. Simply did not cross my mind, and it is the kind of answer I was looking for. Thankyou so much. (btw: I never used char_id under the default).

 

I consider my question answered: please close if needed.

 

The following is just a comment.

 

Now:

About the bg items. I know it is a non official issue, in fact it is not an issue yet (or at all), because it is not an available patch (rAthena compatible, in fact that one is not compatible with eAthena unless gets modified). Meaning: there will not be topics like: "my players are making potions with BG items".

The point is, I realize that it could create some issues, but the feature itself is very cool.

Therefore, I'm not sure if I should make a patch for rA o eA at all; or if I do it, I should warn the possible abusses until I have a solution or someone else think about one.

[GmOcean]

Char_id and acct_id shouldn't matter what it's set to as Cydh said, aside from the card0-4 issue. Probably the main reason being that, those numbers are for db entries only. Where as an npc_id and mob_id need to be something viewable by the client and therefore cannot overlap with each other. That is why acct_id and Char_id can have the same numbers.

It's similar as to why you can have multiple pvp/gvg/BG ranking ladders.

You should even be able to have Guild_id and party_ids overlap with char&acct as well. Since they all hold no true value to the client but only to our sql dbs to help us be organized.