jaBote

Well then, for general how to use the patchers, you can see the Wiki link I posted before.

0, 0 isn't a valid argument for makeitem, you could want to try this other script: - script randmobdrops -1,{OnNPCKillEvent: // Triggered on the player getmapxy(.@map$,.@x,.@y,0); switch(killedrid){ case 1002: setarray .@rewards[0],969,969; //Add your rewards as Item IDs here. They must be valid. break; // case other_mob_id: // setarray .@rewards[0], item_id1, item_id2, (...); // break; } if (!getarraysize(.@rewards)) end; // For mobs without rewards freeloop(1); // The do-while loop can repeat quite a lot of times for (set .@i, 0; .@i < getarraysize(.@rewards); set .@i, .@i + 1){ do { // No way of getting the actual map size, so will try to find a suitable cell with this brute-force algorithm set .@x, rand(1, 512); // Hardcoded max map width set .@y, rand(1, 512); // Hardcoded max map height } while ( !checkcell(.@map$,.@x,.@y,cell_chkpass) ) // Repeat till the cell is passable //Now we have everything we need: the item ID as .@rewards[.@i], the map, x and y coordinates. Dropping the item... makeitem .@rewards[.@i], 1, .@map$, .@x, .@y; } end;} This, basically, hunts down a random cell and places the item there, matter what map you're in. Could be a bit resource_hungry since the 0,0 or the "Random" properties aren't defined in that, so I had to make my very own version of it. I haven't tested it so it may not work. You may not see the rewards unless you make looots of them or you work in a tiny map, though (the smaller the map is, the most tries and thus resource consumption the script will take for finding a suitable cell since the place is random).

It depends on what you want. Keep in mind that if you ask this here and in rAthena, you'll get here replies that say "Hercules is better" and in rAthena forums you'll be told that "rAthena is better". Correct reply is "Hercules is better in some ways, rAthena is better in some other ways". We don't get any commission or whatever based on users, (unlike rAthena we don't even place adverts on our pages), but it's an administrator preference. Here in Hercules we have the fastest and most optimized Ragnarok Online emulator to the moment and there's no possible argument to this: you can run the map server on 70 MB RAM, while rAthena consumes around 200 MB on an idle state. Anyways, this varies on the amount of maps and NPCs you load on your server, and in the amount of users you have. It's also a fact that Hercules consumes much less processing time than rAthena, but I'm not aware of how much. This also means Hercules boots faster than rAthena and has some caching system for even faster boot at the cost of some disk space. Note that these measures also vary depending on the OS you're using Hercules has some features that rAthena doesn't, and vice versa. For example we have an anti WPE security system (depends on client version) and some unique features (some of them were also merged in rAthena). The same happens on rAthena side, but I'm not well informed on that. Emulator stability is comparable, but since in Hercules we introduce and make more features it's quite obvious we are a bit riskier on that and may crash a bit more. Anyways, our bug fixing is way faster than rAthena. We're also comparable in emulator support, too, but I believe we've more answered topics in relation to our total amount that rAthena. The biggest flaw I can see out there is on the scripting and db development side, since rAthena is more active than us on that side (in fact, we seriously lack on them). Anyways, you can generally import all of them here with very little to no effort, most cases it's just a copy and paste issue and they'll work. We're also lifting some IMPORTANT scripting limitations at the moment and have no information of rAthena doing that at the moment. We've also support for the last 3rd job skills while rAthena doesn't (with good formulas but still not perfect), but neither of us have Rebellion yet. And we've also have a plugin system that allow you to make new features without the need of creating conflicts in the source code when updating. Anyways I still don't know why third party devs like eAmod still don't want to support us because it's pretty damn easy to do that with the plugin system which was specifically designed for them. I prefer to think they're lazy bums and only want to sell, because in eAmod case they tell you they support Hercules but then when you buy it they tell you it's still in merging process (it's been like 3 months merging, seriously?). Anyways, it's not that I personally like that much people getting rich at the cost of our free emulator. In short, if you want my opinion: Performance: Hercules Stability: If you mind it over all other things, use rAthena because it's slightly more stable but not much. Else it doesn't quite matter. Support: Hercules for bug fixing, doesn't matter for forum support. Development of new features: Hercules Development of scripts: rAthena (but you can just copy them over here most of the cases). Third party support: Still rAthena.

doc/script_commands.txt So you can just do this: sc_end SC_ALL; And you're done.

There are some patchers out there, like Neoncube, Triad Patcher, Jikari Patcher, Thor patcher, KPatcher, etcetera. If you want to use an already made patcher, you could go get some insight to the Patchers category in our Wiki. If you wish to make your own parcher from scratch, you'll need to know more about the grf file structure and so own, which I myself don't know, so good luck if that's your case.

Would it disappear by issuing an @refresh?

It's quite simple yet intuitive: Just go to that map, and place yourself on the place you want to put your NPC, then use /where (it's a command client that tells you the map and the x,y positions you are in). You'll get the map and the x, y coordinate positions on that map. Then you just put those numbers on the NPC coordinates.

Wasn't it on db/pre-re or re/skill_db.txt (sample: renewal one)? parameter #7 is splash area and AL_PNEUMA has 2. Maybe if you change it to 1 it'll work?

Or using the db/re or pre-re/map_zone_db.conf file (example: renewal one). There's a zone called GVG2, which imports all restrictions of GVG and you can add extra restrictions such as the cards you want to disable. Just add them in the same fashion disabled items are added on other zones.

Maybe I'd move the text up a bit and add a bit of padding so that it stays inside the signature. And... find a place where the text isn't over the render?

You could use a script for that, that gives the Proof of Donation ingame to whoever fulfills some conditions or even to anyone if you want: check doc/script_commands.txt for a full guide on that and the doc/sample folder for some samples on some scripts. That amount of information may be overwhelming for a first contact, so maybe you'll prefer to read this basic scripting guide first. You could also add it as a mob drop, either editing official mobs by editing any of the drop columns in db/pre-re or re/mob_db.txt or making your custom ones if you want. There are more ways of getting the item ingame, such as using @item, inserting it directly into the database and so on.

Love it. By the way I'm setting this one as featured at the moment, hope managers and admins don't complain.

I think it's PhantomRO1.exe?

I don't know if there are the same ASPD formulas in both iRO and kRO, but all RO emulators of today try to emulate kRO, not iRO.

Oh? It seems documentation is missing information on this. Let me quickly fill you up on the matter: // These all are the same:set @i, @i + 1;@i = @i + 1;@i += 1;@i++; // <-- It's just a unitary increment, just increments the variable in 1 and has no other uses// These others are also the same:set @i, @i - 1;@i = @i - 1;@i -= 1;@i--; // <-- It's just a unitary decrement, just decrements the variable in 1 and has no other uses By no other users I mean you can't use strange things like this: @var++2 or something like that. It just works with ++ or -- and can't do anything else than just incrementing or decrementing the variable by 1.

I guess battelfield one just has its name wrong.

LoL it's true, sorry for not realizing that! But the user will be notified anyways. Maybe if you don't want it to be notified you can perform a minor src edit to @autoloot so that if some parameter is given (for example notifyoff) the message of the autoloot change isn't sent to the client.

I've seen a recent HPM update which seems to fix most current HPM issues. Make sure to get latest revision and check if that works.

The button is below the image, I myself had to scroll down to see it.

I'd keep each database separately, to be honest. What I'd do is making a generalized registration form which asks every necessary thing for all the servers (and maybe select which games they want to play?), then launch the needed queries to each accounting tables in their respective database. This way it'll reduce multiple registration problems.

It's already been made/discussed on another topic, I believe in Source Requests (I can't link it now since it's a mess on mobile UI). Main problem of it is that you can't lift the 23 char name limit and those titles count towards that restriction, so it may cause unexpected emulator behavior.

First of all: What's the problem you detected on it?

Using FluxCP? I believe you could do that with some FluxCP edits that makes the check on account vars the account has, so that it only checks the #CASHPOINTS and the #KAFRAPOINTS vars ingame. But you should do that with the account offline since it's quite exploitable... P.S.: I don't know how to modify FluxCP so I can tell you what to do, but not how to do it. Sorry.

If it's on official servers, it should be enabled by default in my opinion...

Yommy's is a plugin and doesn't require any source edit and once compiled can activated/deactivated with just a conf change and a server restart, but has no web counterpart. This one's just a source edit that needs compilation both for adding and removing it, but has a web counterpart. In case of Yommy's you just would need to make the web part yourself.