Kenpachi

Hi. Quick, dirty and untested:admin_no_gems.diff diff --git a/src/map/pc.c b/src/map/pc.c index 179a4b78a..c77bfbc22 100644 --- a/src/map/pc.c +++ b/src/map/pc.c @@ -1359,6 +1359,10 @@ static bool pc_authok(struct map_session_data *sd, int login_id2, time_t expirat sd->sc_display = NULL; sd->sc_display_count = 0; + /// Characters with group level => 99 don't use gemstones. + if (sd->group->level >= 99) + sd->special_state.no_gemstone = 1; + // Request all registries (auth is considered completed whence they arrive) intif->request_registry(sd,7); return true; ~Kenpachi

Hi. In Checagem script: OnClock1055: set $Check, 1; end; Add a 3 second delay before setting the variable $Check to 1: OnClock1055: sleep 3000; set $Check, 1; end; ~Kenpachi

Hi. The are effect type to achieve this. From doc/effect_list.md: 420 | EF_BABYBODY | Eswoo (Small) (Visual Effect) 421 | EF_BABYBODY2 | Eswoo (Alt. Small) (Visual Effect) 422 | EF_GIANTBODY | Eswoo (Normal) (Visual Effect) 423 | EF_GIANTBODY2 | Eswoo (Alt. Normal) (Visual Effect) Atcommand @size uses 420 and 422 for example. ~Kenpachi

Hi. Please open an issue: https://github.com/HerculesWS/Hercules/issues/new/choose ~Kenpachi

Hi. Would be nice to see the script you're using to let us know how you store the IDs of chars that should have their save point changed. ~Kenpachi

Hi. Quick and dirty. Partially tested. ~Kenpachi patch.diff

Open script file in editor. Find the line which contains query_sql "DELETE FROM `viptable` ...... Set cursor to the end of that line (click behind the semicolon) Press Backspace. Save file. You'll notice that the semicolon wasn't removed, because you deleted the hidden character (whitespace) behind it. ~Kenpachi

You can do this in OnClock0000 by running a simple SQL query. If your variable is a character variable: query_sql("DELETE FROM `char_reg_num_db` WHERE `key` = 'your_var_name'"); If it's an account variable: query_sql("DELETE FROM `acc_reg_num_db` WHERE `key` = '#your_var_name'"); ~Kenpachhi

There is a hidden character behind the semicolon in that line. (Probably caused by text encoding mismatch.)

Hi. Alter your SQL table: ALTER TABLE `viptable` ADD COLUMN `insert_on` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP AFTER `email`; Or recreate it: DROP TABLE IF EXISTS `viptable`; CREATE TABLE `viptable` ( `vipacc_id` int(11) unsigned NOT NULL default '0', `vip_id` varchar(255) NOT NULL default '', `days` int(11) NOT NULL default '0', `email` varchar(39) NOT NULL default '', `insert_on` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`vipacc_id`), KEY `name` (`vip_id`) ) ENGINE=MyISAM; Change your function (note line 2): function script F_TicketAddVip { Query_SQL "DELETE FROM `viptable` WHERE `vipacc_id` = '"+GetCharID(3)+"' AND DATEDIFF(DATE_ADD(`insert_on`, INTERVAL `days` DAY), NOW()) < 0"; // remove expired VIP status before reapplying Query_SQL "SELECT `days` FROM `viptable` WHERE `vipacc_id` = '"+GetCharID(3)+"'", .@checkDays; if (.@checkDays > 0) { Set .@setDays, (.@checkDays + 30); Query_SQL "UPDATE `viptable` SET `days`='"+.@setDays+"' WHERE `vipacc_id`='"+GetCharID(3)+"'"; Query_SQL "SELECT `group_id` FROM `login` WHERE `account_id`='"+GetCharID(3)+"'", .@userLevel; If (.@userLevel < 1) Query_SQL "UPDATE `login` SET `group_id`='2' WHERE `account_id`='"+GetCharID(3)+"'"; } Else { Query_SQL "UPDATE `login` SET `group_id`='2' WHERE `account_id`='"+GetCharID(3)+"'"; Query_SQL "SELECT `userid` FROM `login` WHERE `account_id`='"+GetCharID(3)+"'", .@userID$; Query_SQL "SELECT `email` FROM `login` WHERE `account_id`='"+GetCharID(3)+"'", .@userEmail$; Query_SQL "INSERT INTO `viptable` (`vipacc_id`,`vip_id`,`days`,`email`) VALUES ('"+GetCharID(3)+"','"+.@userID$+"','30','"+.@accEmail$+"')"; } AtCommand "@reloadpcdb"; dispbottom "You received 30 days of VIP Account, congrats!"; specialeffect2 338; End; Return; } The info script could look like this: - script VIP_STATUS FAKE_NPC,{ OnPCLoginEvent: if (getgroupid() >= 2) { Query_SQL "SELECT DATE(DATE_ADD(`insert_on`, INTERVAL `days` DAY)), DATEDIFF(DATE_ADD(`insert_on`, INTERVAL `days` DAY), NOW()) FROM `viptable` WHERE `vipacc_id` = '"+GetCharID(3)+"'", .@expire_date$, .@days_left; dispbottom "========================"; dispbottom "Account Status : VIP"; dispbottom "Expire Date : " + .@expire_date$; dispbottom "Time left : " + .@days_left; dispbottom "========================"; end; } } ~Kenpachi

Sorry dude, but I wont write a complete patch for the item options system that works with your emulator version. it's not just updating the clif.c/.h but also packets, the socket, macros and everything else related to items. I spent more than an hour trying to add that diff to your emulator version, but didn't even came close to something compilable... Again, sorry. ~Kenpachi

Hi. I see no problems. It should start WoE each friday at 14:45 and end it at 16:45. I'd use agitstart; and agitend; instead of the @commands, but that's up to you. ~Kenpachi

Hi. Haven't tested it, but try ITEMLINK instaead of ITEM. (Source) It depends on the used client which one works. (Source) ~Kenpachi

Hi. The actual problem is that you've changed the the data type of a parameter which is passes to the clif_add_random_options method. Thus you have to change the data type when calling clif_add_random_options, too. Double click each warning in VS to jump to the line where the data type mismatch was detected. You'll notice, that the method call tries to pass something like WBUFP(buf, 19) or WFIFOP(fd,21+offset) which both wont return an ItemInfo struct which clif_add_random_options expects to be passed. Now that you've found the faulty spots, have a look at the corresponding code parts in Hercules and change your code accordingly. Hope this helps. ~Kenpachi

No Problem, dude. You really helped me. 😍 I think my question was answered completely now. Maybe you should consider to discuss Hercules' way of interppreting water cells with the dev team. (Refering to my last post.) *Marking your answer as solution.* ~Kenpachi

Thanks a lot. That's something to work with. 😊 But this actually means, that *Athenas interpretation of water cells is far from official behavior. According to your code snippet every cell can be a water cell regardless of its type, but *Athena only accept type 3 or alternatively type 0 (cast to 3) if the conditions are fulfilled: // FROM map.c - map_readgat(struct map_data *m) if( type == 0 && water_height != NO_WATER && height > water_height ) type = 3; // Cell is 0 (walkable) but under water level, set to 3 (walkable water) And additionally I'm wondering about the difference in the water level check condition. According to your code snippet AEGIS checks if cell height is less than water level, while everyone else checks if cell height is greater than water level. This really confuses me. 😲 ~Kenpachi

Okay, before reading your post I did some improvements to my code. At first I noticed that return 0 if no RSW file was found and then ignoring it was stupid, sind 0 is an assumable value. So I changed it to float.NaN which brought slightly different results: After this I thought about bad rounding of float values when comparing, so I changed the comparison to byte level and got really different results: So I'll stick to the byte level comparison, since this should be more accurate. Now that I've read your post I noticed, that AEGIS uses the 4th DWORD, which noone else does. Hercules uses the 1st DWORD: (Woops! Possible improvement detected. 😋) Let's compare those two: Okay, there's a huge difference. For a better overview only the AEGIS based results: Still not what one would expect, since type 3 should be water. Let's see what happens when checking for value is less than water level: Well, type 3 looks better now but overall it still looks bad. Let's include equality when comparing: Still... no perfection at all. 😥 My currently used algorithms: Any thoughts/suggestions? ~Kenpachi

Hi there. Long time no see. 😊 I'm currently working on a small server/client application just as a finger exercise for me. Therefor I'm using RO files and stumbled over the .gat cell types and their relation with the water level in .rsw files. According to *Athena and some other projects there should be just a few possible types: Additionally I found different ways to check if a cell is under water or not: So I did a little testing a wrote a tool to collect all combinations of cell types and water level checks in every map. This is the result: What? Now I really got confused. Even if only the *Athena way (IsUnderWaterUpperLeft) to check cell types is payed attention to, there is a significant difference to what one would expect: See? Maybe I'm using wrong algorithms, but they seem to be correct: So could anybody please tell me, how AEGIS handles this? Maybe Hercules can profit by this, too. 🙄 ~Kenpachi

Hi guys. ( Yes, I'm still alive. ) First of all: great idea, great work! This confused me, and so I checked the commit... Is it supposed to not include announce, mapannounce, areaaanounce, menu, dispbottom and probably some other string related commands? //EDIT: I put my hand up if you need a volunteer for a german translation. ~ Kenpachi

Well, backward campability should be a big point in a community project like this, but maybe that's just my opinion. And forcing people to completely rewrite their tools, isn't nice, too. Adding a field to an existing converter logic is much easier than rethinking the complete logic. I really don't know if the advatages of this update are bigger than the disadvantages. For me personally there are no advatages, so you maybe understand why I'm grumbling. Can't find a topic. Please send me a link via. PM. Currently I don't even have time to be actively developing Hercules, so I can't do this. That's the point. Think of the possibilities of SQL. You would be able to change data while server is running and this not just temporary. You could even create completely new data structures if required for a script. at runtime. (You can do this know, but not when dropping SQL.) Wouldn't whis be an advantage? "Hard to read".. Well, there are many many tools which make it easy to create SQL statements if you don't like typing them, that's not a valid reason in my opinion. Yeah, thanks for the clarification. I indeed misunderstood that one.

I suggested this many times. Noone wants it. And as long as there are just a few files available in SQL my tools will use the TXT version, simply because I don't want to implement a logic for SQL an another one for TXT. Well, now you have to search another item if the item you are editing inherits another item just to see the values. And perhaps this item inherits anotherone and you now have to search this now. Furthermore you don't see all the values with one view... I my opinion this new format is pretty confusing.

It isn't difficult but a load of work, which isn't necessary. I don't think there will be a converter which is compatible with my private projects. What actually concerns me most is: Did you think of all the tools in use? Every single tool which reads the item DB must be rewritten because of this update. Furthermore RegEx replacements are nearly impossible now, too. I wish this would have been discussed before implementing, but now it's too late. :S My suggestion to please everyone: Provide a converter which is capable of converting the new format into the old format.

I don't like it. 1. Now I always have to know the default values of the fields which aren't stated 2. My converter is useless now, which In just finished last weekend. -.-

The female sprite is missing the most important thing: Big breasts! Girls in dirndl always have to have big, pushed breasts!

A card is always set up to fit in only one type of equipments. If you want DG card to be useable in shoes, too, you have to add a new card which does the same as DG card but fits in shoes.