Playtester

If you want 100% pre-renewal then don't comment that line. Instead uncommented PRERE in the same file. //quick option to disable all renewal option, used by ./configure //#define PREREChange to: //quick option to disable all renewal option, used by ./configure #define PRERE If you just comment RENEWAL then you will still have all the other renewal systems enabled like RENEWAL_EXP and RENEWAL_ASPD (but maybe you want that?).

Pre-Re: https://raw.githubusercontent.com/rathena/rathena/master/db/pre-re/skill_unit_db.txt Re: https://raw.githubusercontent.com/rathena/rathena/master/db/re/skill_unit_db.txt Unit ID is second and third column.

Not really sure what you are requesting, if you want pre-renewal completely then do what Emistry posted. The "left-to-right cardfix" thingy isn't a renewal-specific thingy as far as I know. It's in a config option... And if the only thing you want to change is how defense works against piercing attacks then just check the function: battle_calc_defense_reductionEspecially the last part of the function where "piercing" is applied. But just using the pre-renewal piercing formula for renewal is a very bad idea, because that would result in huge damage.

It's a renewal update. In renewal you can use it with swords and spears, in pre-renewal only with spears.

Did it work before or did it never work? I only know that if you are using Windows Vista, then patchers won't work, you need to manually patch.

There's no hack to use @ commands even though players don't have the permission to use them. So the only risk is that you give the command to the players in the first place or someone hacks you database and changes his admission level (but in that case you're doomed anyway, so better put a good database password). Within scripts you need to very careful. Most important rule: Always first substract zeny / ingredients BEFORE giving reward.

Well you need to do two things: 1. Make the required skill start SC_COMBO. This can be doen by adding the skill to skill_combo: void skill_combo(struct block_list* src,struct block_list *dsrc, struct block_list *bl, uint16 skill_id, uint16 skill_lv, int tick){This one is pretty self-explanatory. In section "Start new combo", add the required skill and give it a duration. void skill_combo(struct block_list* src,struct block_list *dsrc, struct block_list *bl, uint16 skill_id, uint16 skill_lv, int tick){ case AL_INCAGI: if (pc_checkskill(sd, MYCUSTOM_SKILL) > 0) duration=1; break;That means during AL_INCAGI effect you can do a combo. You can also set a fixed duration like 2000, that means you can do the combo until 2 seconds after the cast of AL_INCAGI.2. Now when using your new skill, add the code as explained above (see part I quoted). It would look like this: case MYCUSTOM_SKILL: if(!(sc && sc->data[SC_COMBO] && sc->data[SC_COMBO]->val1 == AL_INCAGI)) return false; break;That way you check if the combo was triggered by AL_INCAGI. If it's not the case you return false = "skill not possible".If you don't like the negation you can also do it the other way around: case MYCUSTOM_SKILL: if(sc && sc->data[SC_COMBO] && sc->data[SC_COMBO]->val1 == AL_INCAGI) break; return false;

You don't actually need to edit anything. It will automatically read from the "pre-re" folder if you disable renewal. By the way, if you want full pre-renewal you don't even need to comment all the renewal defines, you can just uncomment PRERE here: (uncomment second line) I did only that and it worked automatically and read all the data from the pre-re folder so I'm pretty sure there are no further changes needed.

Well, you have to work with status changes. Basically you do: if(sc && sc->data[SC_MYSTATUSCHANGE]) skillcode;Check skill.c, you can look at Monk combos to see examples: case MO_CHAINCOMBO: if(!sc) return false; if(sc->data[SC_BLADESTOP]) break; if(sc->data[SC_COMBO] && sc->data[SC_COMBO]->val1 == MO_TRIPLEATTACK) break; return false; case MO_COMBOFINISH: if(!(sc && sc->data[SC_COMBO] && sc->data[SC_COMBO]->val1 == MO_CHAINCOMBO)) return false; break; case CH_TIGERFIST: if(!(sc && sc->data[SC_COMBO] && sc->data[SC_COMBO]->val1 == MO_COMBOFINISH)) return false; break; case CH_CHAINCRUSH: if(!(sc && sc->data[SC_COMBO])) return false; if(sc->data[SC_COMBO]->val1 != MO_COMBOFINISH && sc->data[SC_COMBO]->val1 != CH_TIGERFIST) return false; break; case MO_EXTREMITYFIST: // if(sc && sc->data[SC_EXTREMITYFIST]) //To disable Asura during the 5 min skill block uncomment this... // return false; if( sc && (sc->data[SC_BLADESTOP] || sc->data[SC_CURSEDCIRCLE_ATKER]) ) break; if( sc && sc->data[SC_COMBO] ) { switch(sc->data[SC_COMBO]->val1) { case MO_COMBOFINISH: case CH_TIGERFIST: case CH_CHAINCRUSH: break; default: return false; } }in function "skill_check_condition_castbegin".If you just want the increase agi status change to be a requirement to use another skill you can just check for that status change, very easy. But if you only want to allow the other skill if you used increase agi yourself, then you need to make increase agi give the SC_COMBO status change to yourself and set "val1" to AL_INCAGI.

Needs more info: 1. Did you update something when it stopped working? If yes, what did you update? 2. Renewal / Pre-Renewal, make sure the file exists properly in the re/pre-re folder depending on setting. 3. When you start the server, make search for errors / warnings. If it couldn't read the monster skill because of bad format, then there should be an error or at least a warning. 4. How did you detect that a monster doesn't use any skill? With which monster did you test? What are the entries of that monster in the mob_skill_db?

The only choice you have is whether you want to compile the server Renewal or Pre-Renewal. If you use Pre-Renewal, it will automatically work like in official episode 13.2 regarding mechanics and will use the episode 13.2 files (in the pre-re folders). I haven't done that myself before, but I assume you can do that by using the following parameter when preparing your compile: ./configure --enable-prere If you want to go further into the past, you will have to manually revert scripts / database files to older versions. I would keep the code as in, because it contains many bugfixes that still apply even to episode 8. You will want those. If you want to revert to older database files or spawns, you could simply check out an older revision, but of course it's hard to find one that's fully based on official info, if you want something specific, you could also ask me again, I'll see if I can find it.

Well what you could do is: 1. Download eAthena RC5: http://rathena.org/board/topic/61283-old-old-version-ro/ 2. Get the item_db from it. 3. Then get the item_db from current rAthena. 4. Delete all rows except for cards that appear in both versions. 5. Open both with spreadsheet program. 6. Delete all columns except item ID and script (to avoid difference just from column changes). 7. Save both files. 8. Use a comparison tool like SVN Diff to compare both files. Now you can see what has changed in the script since 2004. :-)

The coded table above was the renewal table. You're quoted table was the pre-renewal table. But same story for both. Just find the lines that end with "//Ghost" and then you can define how much damage ghost element should take. If you just care for Ghostring Card, then you just need to adjust the level 1 attribute table. Otherwises you need to update all levels. If you want neutral damage to deal 80% damage to ghost elemental targets then you need to put an 80 on the first column in the ghost row.

I think he's talking about non-elemental damage from monsters that can't be reduced with elemental armor at all, not neutral damage. Unfortunately, there is no easy way to add a bonus for that. Maybe the setting in battle.conf helps: If you set this to for example "13" then monsters should no longer be doing non-elemental damage but rather neutral damage and the normal rules for neutral damage reduction applies. But that's -30% for renewal and -75% for pre-renewal by default, so you'll have to change the elemental table to 80% as explained above.

//SkillID,HPCost,MaxHPTrigger,SPCost,HPRateCost,SPRateCost,ZenyCost,RequiredWeapons,RequiredAmmoTypes,RequiredAmmoAmount,RequiredState,SpiritSphereCost,RequiredItemID1,RequiredItemAmount1,RequiredItemID2,RequiredItemAmount2,RequiredItemID3,RequiredItemAmount3,RequiredItemID4,RequiredItemAmount4,RequiredItemID5,RequiredItemAmount5,RequiredItemID6,RequiredItemAmount6,RequiredItemID7,RequiredItemAmount7,RequiredItemID8,RequiredItemAmount8,RequiredItemID9,RequiredItemAmount9,RequiredItemID10,RequiredItemAmount10 136,0,0,16:18:20:22:24:26:28:30:32:34,0,0,0,16,0,0,none,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 //AS_SONICBLOW#ƒ\ƒjƒbƒNƒuƒ?# It says weapon type 16 is required. 1252,Katar,Katar,4,41000,,1200,148,,1,1,0x00001000,7,2,34,3,33,1,16,{ bonus bDex,1; },{},{} Which is Katar.

Keep in mind that on official servers, the drop rate "1" is actually 2/10001 = 0.02%. If you don't "simulate" this bug, your drop rates will only be half of those on official servers. The drop rate also can't be reduced below 0.01%.

Why not just remove them from the spawn files?

The behavior in rAthena is actually pretty different from the official behavior. On official servers there is nothing like a walk delay at all, but monsters are still fairly easy to stop because if you hit them, they will be put back on the closest cell. Walking speed is an important factor for hitlocking on officials, while in rAthena it doesn't matter much at all and rather depends on the damage motion duration.

Yes, I was actually working on that project for a while, but the problem I mentioned above still remains: There are three different ways on how to do the conversion which all have good reasons why they are close-to-official and it's hard to decide for one. Just take Scaraba Hole, on the one hand all pre-renewal monsters above level 99 have HUGE attack at least 8000 and for renewal scaraba hole monster actually do a lot of damage, but giving them 10000+ damage makes it indeed a lot harder than in renewal. Not to mention that there is later a nightmare mode, how high do you want to put the damage there? 40000+? Kinda pointless, since players can't even level above level 99 (unless the private server raises the max level). So in the end it might makes more sense to give them ~4000 attack, that reflects the difficulty better and then you still have room to make nightmare mode harder. Or maybe use an average between both versions? Not very easy to decide. And even trivial things like halving VIT is not so clear. It seems important so that AD is not overpowered, but the Biochemists on your server will totally complain about it, if you mess with that stat. So admins might still opt to leave it in just to not risk making their players angry. All these things will vary strongly on server decisions and what the players want and also custom server modifications (if they have max level 255 they might want those monster be a lot stronger). It's also possible to write a full converter via statistical evaluation. It just needs to check the differences between renewal and pre-renewal for monsters actually existing in pre-renewal and then learn by calculating average differences how much the stats are different on average for that race, size, element level and level range and then just apply those average differences on the new monster. But there are quite some monsters that got significantly changed that will make such a converter very unclean, for example the level and power and desert wolf is really high renewal, much higher than in pre-renewal, but that doesn't mean that brute fire monsters should be generally a lot weaker and lower level in pre-renewal. But maybe I'll do a release with my preferred version eventually.

Later episodes never existed in pre-renewal. It is possible to do a direct Renewal -> Pre-Renewal conversion for some stats, but not for all. So you'd need to manually adjust those numbers. When wondering how to do that, you could for example do a statistical evaluation on the differences and then apply it or you could do it so that the stats are adjusted depending on how the different mechanics works (due to assumptio and hard def being strongly nerfed in renewal, you need to increase the attack power a lot in the conversion, and you could increase it so that the final damage with perfect armor and buffs stays the same). Another alternative is to understand how the original game designer of RO was thinking by looking at all his work and then just put the stats with a copy of his mindset. Depending on the method you will get completely different results however, so I'm not sure yet which path to follow. I tried to contact the server admins of the high population private servers and work with them together on it, but they kinda ignored my e-mails, so I assume they probably want to keep their results for their own servers only. My currently proposed solution would be (warning: the renewal stats are still wrong in rAthena for anything after bifrost): >For monsters with level 96-160 in renewal< Level - reduce by 30 (130 -> 100) HP - same DEF/MDEF - recalculated according to official formula (I wrote a converter for this) VIT - half of renewal VIT (60 -> 30) ATK - 5x of renewal ATK (700 -> 3500) BaseEXP - 3x (+ 5% bonus*), should not apply to MVPs JobEXP - 2.67x (+ 5% bonus*), should not apply to MVPs >For monsters with level 20-95< Level - same HP - 3x of renewal HP (5000 -> 15000), should not apply to MVPs DEF/MDEF - recalculated according to official formula (I wrote a converter for this) VIT - half of renewal VIT (30 -> 15) ATK - 3x of renewal ATK (500 -> 1500), should not apply to MVPs BaseExp - 3x (+ 5% bonus*), should not apply to MVPs JobExp - 1.74x (+ 5% bonus*), should not apply to MVPs Explanations: Level: Well in pre-renewal the max level for monster is basically 120. So for high level monsters it makes sense that they should have a lower level or else they will have too high HIT/FLEE as well as status resistances. Why I wouldn't reduce the level for lower level regions in renewal has a simple reason - players will spend most of their time above level 80 so adding a real low level region isn't really very interesting. HP: For high level monsters the HP is pretty similar in pre-renewal and renewal at the same level. For lower level monster the HP was reduced in renewal. 3x is just an estimated value, probably could get a more accurate one. If we look at the Brasilis differences, we can notice that x3 gets quite close, though. I wouldn't mess with MVP HP at all, though. Most MVPs are quite similar in their stats if you compare renewal and pre-renewal. DEF/MDEF: There is a fixed formula for this so not much to discuss here. Y'know that (4000+DEF/4000+10*DEF) thingy. VIT: It was around double in renewal since attacks that deals more damage on higher VIT have been nerfed strongly. So if you revert pre-renewal you have to half it again. ATK: In higher level regions, players can reduce damage in pre-renewal a lot stronger than in renewal, so the ATK should be multiplied with 5 to get the same final result on the damage. BaseEXP: It's a bit tricky because you need to apply the "more exp if you kill higher level monsters" system directly to the exp in pre-renewal. Basically if you have a level 101 monster and a level 103 monster, you would want the level 103 monster to give 10% additional bonus exp. The multiplier isn't actually 3x, it's just there to give you some estimate. It is better to make this vary on the monster level the map is based on. For example you have a map with a 101 and 103 level mob and a map with a 121 and 123 level mob. I'd say multiplier for the first map is 2.5x and for the second is 3x. But the level 103 mob should be 10% more than 2.5x which is 2.75x and the level 123 should be 10% more than 3x which is 3.3x. Also if you change the HP, the exp should scale accordingly. JobEXP: Same as base exp except that there is an official fixed multiplier for job exp based on the level which is fairly simple: For level 1-19 and level 96-160 the multiplier is 0.89. For level 20-95 the multiplier is 0.58. (If you check renewal job exp of monsters you will see a big jump in job exp from level 19 to 20 and level 95 to 96.) If you don't want to mess so much with lower level monster stats, there is also an "easy type" version you could use, since especially around level 50, renewal and pre-renewal monsters are almost identical: >Easy type conversion for monsters between level 50 and 95< Level - reduce by 30 (80 -> 50) HP - same DEF/MDEF - recalculated according to official formula (I wrote a converter for this) VIT - half of renewal VIT (30 -> 15) ATK - same BaseExp - 1x (+ 5% bonus*), should not apply to MVPs JobExp - 0.58x (+ 5% bonus*), should not apply to MVPs This way you can just leave HP and ATK alone and only apply minor conversions. Exp will also almost stay the same except for the 5% bonus and the job exp multiplier.

(UPDATED 2022-05-16) Unlike popular believe, Brasilis actually existed in pre-renewal, but only on bRO and jRO. Since it never existed on kRO, it is undefined in what rAthena consider "official stats". As of today I pushed the pre-renewal Brasilis monsters stats (jRO version) to rAthena master. Originally we left the guessed values as they were, but as we now have the YAML format that allows overwriting only selected stats of a monster rather than having to copy over the whole line, it's better to have as many official values as possible already in the base file. Now the only thing you need to do to get the bRO version of pre-renewal is to overwrite the ATK values. I've attached mob_db_bra_atk.yml which includes these changes. If you have no custom changes to your monsters, then you can just name it "mob_db.yml" and overwrite the file in \db\import\. Otherwise just copy the monster lines into the "Body" section of your file. I originally released the monster stats already in 2013, but the jRO values were guessed based on Doddler's comment that they seem to be about "3x" as high. In the meantime jRO actually released their customized values so we know the real ATK stats now. I also fixed the ATK in my original release from 2013, but keep in mind that the mob_db.txt format changed. This monster lines in the file will only work until rAthena from March 2016. After that you will need to fix the "mode" of the monsters (see here: https://github.com/rathena/rathena/commit/55e4df14c2141f291a985c391408a045ec1b25c4) or just use latest rAthena which uses YAML format. My old file also includes the spawns, they should still be working, but I did not test it (alternatively you can just use the renewal spawn files for bra_fild and bra_dun). bRO and jRO have slightly different versions, here are the differences: - the bRO version is the original version, but features really low monster attack, jRO considered this as too easy / exploitable and decided to strongly increase the ATK of the monsters (around 3x as much) - bRO's field map mainly has Headless Mule's and Curupira spawning, first floor is mainly Piranha and second floor is mainly Iara - jRO removed Headless Mule from the field map completely and added more Toucan and Jaguar spawns instead - jRO added Thara Frog and Headless Mule to the first dungeon floor - jRO removed all weaker monsters except Hydra on the second dungeon floor and added Headless Mule instead Issues that are not 100% official because a leak is missing: - monster modes in pre-renewal are unknown (both bRO and jRO), jRO reported that Iara was actually aggressive, however since we have no leaks on the monster modes, I simply used the renewal ones - the spawn types of jRO are 100% official, but the amounts are estimated Everything else should be 100% accurate. bra_all.txt mob_db_bra_atk.yml

It summons yoyo. ;-) But yeah, look at what frenzmu06 quoted. It's the "SUMMONSLAVE" skill and val1 to val5 can contain the different monster IDs that should be summoned.

What do you want to edit? If you just want to edit their stats, why not do it in the monster database directly?

This was fixed in r17222. http://trac.rathena.org/changeset/17222/rathena

I don't think the script above would work. The if check only goes through when the equipment is re-checked. The correct way to solve it would be to use "autobonus". Like for Violet Fear: autobonus "{ bonus bIgnoreDefRace,RC_NonBoss; }",50,5000; So basically I'd do: 4399,Thanatos_Card,Memory of Thanatos Card,6,20,,10,,,,,,,,2,,,,,{ autobonus "{ bonus bDefRatioAtkRace,RC_Boss; bonus bDefRatioAtkRace,RC_NonBoss; }",50,5000; bonus bSPDrainValue,-1; bonus bDef,-30; bonus bFlee,-30; },{},{}In this case you need to set a chance (50) and a duration (5000). I think chance is 50 = 5% and duration is in milliseconds (5000 = 5 seconds).