Playtester

Yeah put the skill ID you want the monster to react to as value. 1087,Orc Hero@MG_THUNDERSTORM,chase,21,20,10000,1500,5000,no,target,skillused,18,,,,,,, Like this means that Orc Hero will counter "Firewall" with the ranged skill "Thunder Storm".

It's mostly because scripts should be using the constants rather than using the internal numbers for positions. You can see how Lemongrass fixed the official refine NPC here: https://github.com/rathena/rathena/commit/7046cf8fc588d4c17047107a98f24547964e6e2e Or Atemo script fixes here: https://github.com/rathena/rathena/commit/05a1b61beded08b7759b59ef381b4ddbad791abf https://github.com/rathena/rathena/commit/7d6be7e21ea831130111de846b81700cfc6c6c1e And make sure you have the update on the global function for appropriate usage: https://github.com/rathena/rathena/commit/1a87f90aa9a9c8f40dec41517b6f2d749c73378e If you have custom scripts you have to adjust them accordingly.

The goal of rAthena is actually to make everything 100% official kRO, no customs. You won't even need approval to make something official. So if something is wrong about Atk/Matk, you can fix it. :-) I already applied some fixes on it anyway. Maybe it's correct now? And I don't care for renewal at all. From the very beginning when renewal came I said on eAthena that devs should work together to just make a 100% working episode 13.2 and forget about renewal until pre-re is 100% working and honestly if rAthena and Herc and other emulators were never created and all devs worked on making a 100% working episode 13.2 we might be done by now and could start renewal with a solid foundation. Still I didn't stay at eAthena and joined rAthena. Why? Because in the end supporting both is the correct way. Many of the fixes I do... all devs do... affect both pre-renewal and renewal. If you split that apart then you always have to do the fixes twice. That's just double the work with no benefit.

I can give you some general pointers. 1. If you want it to fail before cast you have to go to map/unit.c and find the function unit_skilluse_id2. That's basically everything that happens before cast. 2. Find a section that checks for if(sd) and switch through different skills. It's important that if(sd) is checked otherwise your server might crash. 3. You can figure out the number of spiritballs the caster has with sd->spiritball. 4. How to make a skill fail in this function you can see for example here: case BD_ENCORE: // Prevent using the dance skill if you no longer have the skill in your tree. if(!sd->skill_id_dance || pc_checkskill(sd,sd->skill_id_dance)<=0) { clif_skill_fail(sd,skill_id,USESKILL_FAIL_LEVEL,0); return 0; } If you don't want the "skill has failed" message on the client you can also just return 0. 5. If you want the skill to fail AFTER cast. You have to do this in skill.c instead (just search for CH_SOULCOLLECT).

src/party.c int party_exp_share(struct party_data* p, struct block_list* src, unsigned int base_exp, unsigned int job_exp, int zeny)

Yup, actively participating on github is a good start. If you can code you can even post solutions. This will collect you fame. If you want to help even further, apply as dev after having collecting some fame from fixes, if your past fixes were good you're likely to be accepted.

Depends on what your changes are. If they don't conflict with the changes done to rAthena, then you can just do: stash save -> pull -> stash pop. Done. Stash save basically saves your modifications into a separate file and removes them from the repository so you can update without any problems. Then pull gets the updates from rAthena. Then stash pop applies your modifications to the source again. Here it will also tell you when there are conflicts. If there are conflicts you need to resolve them yourself by taking a look at the code. So what I do in case of conflicts is... because I know my changes better than I know the changes from others, I keep a copy of my sources before the update and when there is a conflict I always just choose "Solve conflict using theirs" which removes my changes (but only those that are in conflict). Then I take a look at the modifications from me that got removed and think if I even still need them (could be that conflict is just there because rA fixed something I fixed beforehand, then I don't need my modification anymore). If I still need the modification I either just write it again into the new structure or open my old source file and the new version with a diff tool and move the lines I still need over from old to new.

1000 is the maximum.

Why would you copy over the db files though? You want third jobs?

I changed it because it's much easier to work with if there are only the official values in it (comparing changes) and you don't need to debate how it should increase. Previously it was a mess with every single row using a completely different formula and job exp requirements not matching base exp very well, not to mention that on higher levels it exceeded maximum and would just lead to an overflow. In the end it should be up to the server owners to decide what kind of exp increase system they want to use. In the sample in import-tmpl I simply used +2M base exp and +5M job exp per level above max. There's no perfect formula because Gravity just puts some values as they feel into it the table. http://irowiki.org/classic/Base_EXP_Chart Just look at the huge variance in percentual increase per level. You could go by the lowest increase per level which is 6.5%, but you need to be careful not to exceed 2.1 billion, because that could give you all kinds of trouble.

Most likely: Someone did cast Spiderweb on a cell that already had 20 other units on it. Not sure if you can do much about that unless you find out why there are so many units on one cell. WoE maybe? Allowing too much skill spaming?

In renewal.h you can edit the defines. If you uncomment PRERE then you have a fully pre-renewal server with pre-renewal mechanics. Then if you want renewal content added to pre-re you copy the NPCs and stuff over into the pre-re folders.

65535 is the maximum you can put.

Always could use the old files from eAthena RC5: https://rathena.org/board/topic/61283-old-old-version-ro/ Spawns in Aegis format you can get on ASB boards.

That "solution" doesn't seem to have anything to do with aspd, though? Edit: By the way, I just tested it in rAthena and it's working fine just as I told you in my last post. e.g. for Novice: // Novice 0, 20000,0 ,500 ,100 ,440 ,590 ,610 ,2000 ,2000 ,2000 ,540 ,2000 ,540 ,540 ,690 ,2000 ,2000 ,2000 ,2000 ,2000 ,2000 ,2000 ,2000 ,2000 ,2000 ,2000 ,2000 ,690 ,440 Then shield doesn't change ASPD anymore. :-)

Since I'm often asked for episode 4~9, I tried to create a mob_db with all the available info, unfortunately there isn't enough unmodified info left that can be used. I've attached a file that at least includes the old rune-midgard monster stats that were used from episode 3-10. MVP data is completely missing and drops might not be accurate. mob_db_7.txt

Not much into renewal, but the problem is probably in: status.c - status_base_amotion_pc if ( sd->status.shield ) amotion += ( 2000 - job_info[classidx].aspd_base[W_FIST] ) + ( job_info[classidx].aspd_base[MAX_WEAPON_TYPE] - 2000 ); In fact that code is super weird. If you don't want shields to influence your ASPD you have three choices: 1. Set shield delay to fist delay (so if fist delay = 400, shield delay also = 400) 2. Remove the code I quoted above completely and recompile. or 3. Don't use RENEWAL_ASPD define. It's not properly implemented yet anyway. Comment it in renewal.h and recompile.

Honestly not sure what you mean. Putting the value to 0 for shields is also much easier on rAthena than on Herc, because in Herc you'd need to edit them all to 0 where on rAthena format you can just set the whole shield column to 0. That the setting is not working is an issue completely unrelated to the file format.

You're mostly just missing the exp you need on max level now. rAthena requires that. On official server it's always 99'999'999 for base exp and 999'999'999 for job exp. I'll guide you through the first three error messages, hope you can resolve the others alone. First error: [error]: pc_readdb_job_exp: Number of columns 101 defined is too low for max level 99. Is this line: Which ends with... You're missing one number there, should be: Also, you are using the official values here, just delete the line! It automatically uses rAthena default from db then, which is already working (assuming you've updated to current version). Second error: [error]: pc_readdb_job_exp: Invalid maxlevel 255 specified. That's just because you put "255" but compiled with max level 250. Put 250 here as first number. Third error: [error]: pc_readdb_job_exp: Number of columns 12 defined is too low for max level 10. Missing max level requirement, should be: Again, you are using the official values, so you can just delete the line and use rAthena default.

Actually that needs some client editing, though I'm not sure how easy this can be done. Of course you could just send the "Bash" packet when using "Envenom" but then the character will also say "Bash !!" which might be confusing.

In the example data above, you only have the exp values for the first few levels, be aware that above was just an extract of the full line. The full list for exp requirements up to base level 1000 and job level 255 you can find in import-tmpl directly if you update your git. Or just see here: https://github.com/rathena/rathena/blob/master/db/import-tmpl/job_exp.txt As you can see that file has up to 1000 columns and ends with: "2143210000,2145210000,2147210000" (pre-renewal, base exp) You need that one (and the one for job exp) Only thing you need to do is take that line, uncomment it, put the max level you want and replace "x" by the list job IDs you want it to work for. When done place it into import. (Of course you can always just write your own exp requirements by using Excel or Open Office calc.)

It's super easy to change values in CSV format. Just open it with Open Office Calc, split the table so you always see the headlines and then just put the values you want. Takes me maybe a few seconds.

Hmmm it's kind of similar to the vellum weapons except they deal a fixed percentual damage amount and you want it to be a fixed number. You can look into its implementation and adjust it to your liking: battle.c void battle_vanish(struct map_session_data *sd, struct block_list *target, struct Damage *wd) Take a look into that function for some inspiration. If you don't use the bonus at all e.g. because you don't have vellum weapons in the first place, then it's easiest to just recode the function so it does absolute damage instead of percentual. If you need both, you'll have to implement a bonus that works similar to this one.

e.g. open the project in Visual Studio, then right click on the project and select something along the lines of "Recreate all". Not sure what you mean with reboot, but if you just mean close the server and start it again, it just won't change anything. It's still the same .exe file but you want a new one.

I'm against it. The Herc format is horrible, you can't load it into a spreadsheet program. =/ The rAthena format is much easier to customize for me.