Garr

Server-side it's not that hard to disable, but iirc that restriction is also applied on client-side, and you can't disable that without a help from knowing person that'd make a patch for you. Ask @@Neo, perhaps?

Yup, sleep2 returns a bool if the player is still attached. The problem is, in this case as there would be no player attached it'll return 0 and it won't even run the cycle.

That indeed would be a better idea if possible

I don't think sleep returns anything, so your while statement doesn't get anything to evaluate. Just change it to while(1) and place sleep in the end of cycle?

I think this would be a bit more useful *questinfo <Quest ID>, <Icon> {, <Map Mark Color>{, <Job Class>}};This is esentially a combination of checkquest and showevent. Use this onlyin an OnInit label. For the Quest ID, specify the quest ID that you wantchecked if it has been started yet.For Icon, use one of the following:No Icon : QTYPE_NONE! Quest Icon : QTYPE_QUEST? Quest Icon : QTYPE_QUEST2! Job Icon : QTYPE_JOB? Job Icon : QTYPE_JOB2! Event Icon : QTYPE_EVENT? Event Icon : QTYPE_EVENT2Warg : QTYPE_WARGWarg Face : QTYPE_WARG2 (Only for packetver >= 20120410)Map Mark Color, when used, creates a mark in the user's mini map on the position of the NPC,the available color values are:0 - No Marker1 - Yellow Marker2 - Green Marker3 - Purple MarkerWhen a user shows up on a map, each NPC is checked for questinfo that has been set.If questinfo is present, it will check if the quest has been started, if it has not, the bubble will appear.Optionally, you can also specify a Job Class if the quest bubble should only appear for a certain class.Exampleizlude,100,100,4 script Test 844,{ mes "[Test]"; mes "Hello World."; close; OnInit: questinfo 1001, QTYPE_QUEST, 0, Job_Novice; end;}

It's pretty simple if you look at it this way: Let's take this situation per example: x0000t00 Where x is player and t is target. Usually distance between two entities is calculated from one of them, in this case player stands on cell 0, target stands on cell 5. So distance will return 5. But we need to know amount of cells between for skill, in this case it'll be (5-1), or 4. Next, we get extra 100% damage per every 3 cells between, so we need to find out how many times 3 is included in the number we have above. Here "/" stands for integer division, pretty much "how many times something fits into our number fully". In this case we'll have (4/3) = 1. So there you have it, result of this operations in our case is 1. If there were 7 cells between players, result would be 2 and damage would increase by another 100%. Where did I get that flag is distance? By reviewing where the call came from. In this case it comes from skill.c: unsigned int dist = distance_bl(src, bl);skill->attack(BF_WEAPON, src, src, bl, skill_id, skill_lv, tick, dist);/* int skill_attack(int attack_type, struct block_list* src, struct block_list *dsrc, struct block_list *bl, uint16 skill_id, uint16 skill_lv, int64 tick, int flag) */battle->calc_attack(attack_type,src,bl,skill_id,skill_lv,flag&0xFFF);/* struct Damage battle_calc_attack(int attack_type,struct block_list *bl,struct block_list *target,uint16 skill_id,uint16 skill_lv,int count) */battle->calc_weapon_attack(bl,target,skill_id,skill_lv,count)/* struct Damage battle_calc_weapon_attack(struct block_list *src,struct block_list *target,uint16 skill_id,uint16 skill_lv,int wflag) */battle->calc_skillratio(BF_WEAPON, src, target, skill_id, skill_lv, skillratio, wflag)/* int battle_calc_skillratio(int attack_type, struct block_list *src, struct block_list *target, uint16 skill_id, uint16 skill_lv, int skillratio, int flag) */

I think you can edit this yourself if you want: void clif_parse_WalkToXY(int fd, struct map_session_data *sd){... if (sd->sc.opt1 && ( sd->sc.opt1 == OPT1_STONEWAIT || sd->sc.opt1 == OPT1_BURNING )) ; //You CAN walk on this OPT1 value. /* else if( sd->progressbar.npc_id ) clif->progressbar_abort(sd); */ else if (pc_cant_act(sd)) return;...} Just uncomment the line. Albeit if it could be made into a configurable option it would be best imo.

Well, you can change picture, but that's pretty much all you can change sadly.

Bunch edit as in you can now edit few items at once, for example if you'll highlight few items inside item_db and edit weight to 10, all highlighted items will change their weight to 10. SDE also has client description autocomplete depending on item_db1/2. Python script lets you make your own changes depending on your own conditions, but that requires some Python knowledge, check the topic I linked you to, Tokei wrote some example python scripts.

SDE + bunch edit/Python script?

Try "/font" command in chat

Iirc there was an issue fixed in src long time ago by Ind, it was connected to ":D" in character names which would crash clients on fetching info on character. Maybe this is also part of that bug?

Ooh, then set is not an option. Maybe something along these lines? - script checkpoints -1,{end;OnInit: bindatcmd "checkpkpoints",strnpcinfo(0) + "::OnCheckPoints",0,99; end;OnCheckPoints: if( .@atcmd_numparameters != 1 ) { dispbottom "Proper usage: @checkpkpoints <Player Name>"; end; } if( !(.@taid = getcharid(3,.@atcmd_parameters$)) ) { dispbottom "Requested player is not online or does not exist."; end; } .@said = getcharid(3); if( attachrid(.@taid) ) { .@points = #PK_Points; } else { dispbottom "Error occured while checking, please try again later. If this message persists contact GM."; end; } if( attachrid(.@said) ) { dispbottom "Player " + .@atcmd_parameters$ + " has " + .@points + " points."; } end;} Please note that I did not check it ingame, and only checked for syntax mistakes using haru's script checker. Also, I'm not really sure if bindatcmd takes every word as a separate parameter or it can take something in quotes as one parameter (and I'm too lazy to actually launch my test server/client and check it out), so this script might need a bit of fixing to work on players with spaces in names.

Why would you need that when you can just attachrid and get variable? Or if this bindcmd is just for checking points you can use @set.

Well, he did say "randomly set", not "randomly increase", thus I changed it accordingly

Well, not quite what you're thinking about, but you can summon effect from NPC using several different commands: skilleffect;npcskilleffect;specialeffect;specialeffect2;misceffect; You can read their descriptions inside doc/script_commands.txt and choose whichever you see most fitting. But be warned, those only summon effect for the predefined duration of the effect itself (only), so if you want a continuous animation you'd need to refresh the animation calling every now and then, and for that npc timer will come in handy

query_sql ("UPDATE `cash` SET `cash_point` = " + rand(100,1000) + " WHERE `account_id` = " + getcharid(3));

You can place any effects on map using Browedit, but you'd need to patch map files client-side for people to see.

At max points yes. And it'll be a flat growth per point, so every point will get you extra 1/20 (0.05%) chance to win. So, let's say, at 300 points you'll have (300*1/20) = 15% chance to win, or at 465 point you'll have (465*1/20) = 23.25% chance to win.

@@thor1009 Hmm, idea is good, but after few points it'll always will be close to 100% chance, as e^(-5) is already damn close to 0. Hell, even at e^(-3) it's damn close to 50, making the chance real close to 100%. @@Lord Ganja Hmm, I don't know, it depends on how people earn the points, in what amount, what's the current max on server, are you limiting the points and so on. If you're limiting them I'd say make it ~125% of max, that way you'll have a nice 80% win chance at max amount.

I'd do if( rand(x) < #CASHPOINTS) { // Yay! Winrar!!} Where x is some amount you want #CASHPOINTS to have 100% chance at. Here it takes random amount from 0 to (x-1), and closer $CASHPOINTS to x is higher is the chance scripts succeeds.

Both would do, I think. "i" stands for one integer as argument. "v" stands for variable, as my guess (you can input either integer or constant) "s" is text "?" is unknown, one argument "*" is unknown, unlimited arguments.

Well, I see few problems with checking if item is bound, since you'll need to check some specific item, as it is stored inside item itself. If you plan to delete it afterward you'll need to delete it by its index, and I believe there's no command to do that by default. And that there can be both bound and non-bound item inside player inventory does not make it easier. Albeit delitem prefers normal items over bound/carded ones, but don't take my word for it. For the flag checking you can use this command that was made for me by a friend long ago: /* [List of Restrictions] ITR_NONE 0 ITR_NODROP 1 ITR_NOTRADE 2 ITR_PARTNEROVERRIDE 4 ITR_NOSELLTONPC 8 ITR_NOCART 16 ITR_NOSTORAGE 32 ITR_NOGSTORAGE 64 ITR_NOMAIL 128 ITR_NOAUCTION 256 ITR_ALL 511 Usage in scripts: chk_restrictions(ItemID);*/BUILDIN(chk_restrictions) { struct item_data *item_info; int item_id, item_tradable; item_id = script_getnum(st,2); //Value sent by the script (Item ID) if(itemdb->exists(item_id)) item_info = itemdb->search(item_id); else { script_pushint(st,-1); //If the ID is invalid it stops here and returns -1 return true; } item_tradable = item_info->flag.trade_restriction; script_pushint(st, item_tradable); //Returns the sum of restrictions return true;} It returns combined value of restrictions on item, so if you want to check if it's tradeable, then chk_restrictions(item)&2 must be 0. Makes it easy to use inside ifs: if( chk_restrictions(item)&2 ) { // Item is non-tradeable, prevent script from advancing}

But there is an example of how clif->soundeffect is used O_o clif->soundeffect(<session data of who you send it to>, <source block list>, <name of file to play relative to datawav>, 0 <type, stands for play once, iirc other types except 0 do not work>) What exactly do you mean by "example" then? If you want to use it as skill sound with area you'll be better off using clif->soundeffectall btw.

Check soundeffect command in script.c