Akinari

Renewal magic attack was implemented for players last November. See: http://rathena.org/board/tracker/issue-5689-renewal-matk-and-mdef-formula-issue/ And: r16981 As malufett had stated the remaining portion that is incorrect is mob calculations. See: bugreport:5103 This post serves as a reminder that monster magic attack still needs to be completed as I had totally forgotten about that important detail. Thanks Rage.

The old repository will update automatically. If you want to stay up to date with latest revisions, switch your SVN repo. cd /path/to/trunk/ svn switch --relocate https://rathena.svn.sourceforge.net/svnroot/rathena/trunk http://svn.code.sf.net/p/rathena/svn/trunk Run a repo checkout before relocating. Tools like RapidSVN and Tortoise have these features built-in to relocate.

There are some VCC errors in this current revision as well as a few GCC warnings. Will get these fixed ASAP and update this post when finished. Edit: Fixed in r17403.

I did that. Thanks for putting so much effort into this and finally getting it released!

This was fixed in r17356.

The same way you put the SQL in the first time. Just use whatever front-end, if you have one, like phpMyAdmin to run the SQL queries. It looks like all you're missing is the bound items column in the storage and inventory tables. upgrade_svn17351.sql

What revision did you update from? Have you checked for any SQL updates in sql-files/upgrades?

Well I'm pretty sure there multiple things wrong with this script, although your warning and debug messages are showing because you're using a sleep within a while loop. It should look more like: Start: set .event,2; set .e_x,rand(1,35); set .e_y,rand(1,35); set .e_t,5; callsub WarpShow,.e_x,.e_y; while(1) { sleep 1000; if(.e_t-- < 0) break; else callsub ShowEffect; } callsub WarpNoSafe,.e_x,.e_y; sleep 1000; return;

Updated diff to latest revision. Fixed compile errors under pre-re settings. Fixed compile errors when pre-re and renewal_edp are configured together. Fixed warnings under pre-renewal settings as well.

Implemented in r17386.

I agree with this. I would also think not only does this make it extremely easy to make a item/point shop, but also decrease processing time as you wouldn't need to go through script engine like you have to now. +1 from me.

Instance System Rewrite!! r17386 contains a complete instance system rewrite! In a nutshell this new instance system allows us to create instances in a much easier fashion as opposed to the 5+ steps it took before. With the introduction of an instance database, creating an instance within a script is as simple as a single command, as well as entering it. Everything in instance creation is now handled automatically, making scripting instances a breeze compared to before. Features: Separation of instances from maps and scriptsThis allows us to create a system that is independent of the main functions (killmonster, monster, warp) using a new command instance_mapname(); Now whenever specifying a map for an instance, we no longer need specific commands to have these src4instance checks. Everything related to instancing is also done on an as needed basis, which means there won't be extra processing on each script run to figure out whether you're in an instance or not. Loading an instance automatically runs OnInstanceInitBefore it was an extra task taking generally 20-50 extra lines of unnecessary code. Now, when specifying your instance to create, this is no longer an issue. Instance database files hold the instances to be madeWith a new database file that contains all the instances, we no longer have to manually add each instance map and attach it to the scripts. This is another way we've made a system that works for the scripters, not making the scripters work for the system. We've also added a useful @reload instancedb command to reload the instancedb in runtime. Instances persist through @reloadscriptOne of the major reasons for this rewrite was to offer us the ability to use reloadscript and keep our instances in-tact. Now, when a reloadscript occurs, we reset all players to start of the instance and reset their timer. Instance persistence can be expanded upon later allowing us to store these into the SQL and even recreate them on server reboots! Script commands rewrittenWith the new system, we've removed a set of commands. These include: instance_attachmap instance_attach instance_set_timeout instance_init instance_detachmap has_instance Create instance of any mapIn the old system, we could only create instances of maps which were named to be instances because others would crash the client. Now you can create an instance of any map you'd like. Usage: To create an instance, first add it into the new database, then you can create it using instance_create and enter the instance with instance enter: 10,Instance Prontera,7200,prontera,150,150,prontera if (instance_create("Instance Prontera") < 0) // Check for a failure in creating instance instance_enter("Instance Prontera"); To make a monster in an instance, simply use the instance_mapname function. areamonster instance_mapname("prontera"),155,150,160,155,"Prontera Octopus",2192,3; You can refer to the rewritten instance scripts for more examples. Documentation for the new commands is below. Special Thanks: Euphy for suggesting this rewrite be done, doing hours of testing, and rewriting the scripts for the new system. It would have never been done without him. Auriga the Japanese emulator for giving me a place to start as well as much of the code in the new system. It certainly made this task much easier. Lemongrass for helping me out along the way and providing some code improvements in the final stages. Lighta for help in fixing bugs. The Future: Expect expansions upon this project such as instance storing in SQL and possibly additional instance types such as guild instancing. Please remember to post bug reports in the proper area and if you have any questions or need help converting a script, don't hesitate to ask. Commit 1 Commit 2

Yes. I just posted a new diff. Also fixed a bunch of linux warnings that weren't there before the configuration update. Thanks for testing!

Before continuing I'm aware this post probably doesn't belong here, but I'm assuming this will get the most views and will also get our development of this huge modification on a roll. Essentially the only portion that needs major testing is the Pre-Renewal. Renewal attack has been tested for the last month by the writers of this mod and on their servers. Please report your findings back to us so this isn't put on hold any longer. Credits: Baalberith - Broke apart all of the battle.c functions and started the mod Helvetica - Fixed many bugs within the initial stages of mod Without wasting anymore time, here's a diff updated to our latest SVN. Edit: I've been told to release some more information on what to test. Like above, we mostly just want to make sure we didn't break pre-renewal, but I'm bringing this to the public for any extra testing. I'm aware the things most wanted in renewal are EDP and Acid Demonstration working correctly, so if you use renewal in your server, you're free to use this before we actually release. We ask that users of pre-renewal see if there are any differences in the attack when this is implemented. Edit2: New diff posted. Fixes a bunch of linux warnings and windows error. renewalattack.diff

Sounds good to me. You have my vote.

In r17361: Added configuration option to disable Guild/Party bound retrieval/removal system in core.h Added support for Character Bound items

Yes Cydh. I apologize for the misunderstandings. I was just going off the inter_athena.conf naming of it.

This was partially implemented in r17326. It can still be expanded so I will be leaving this open for further discussion. Personally, I want a versatile way to unload mapflags, maybe something like @unloadflag pvp (removes PvP mapflag from all maps).

Implemented in r17353. Thanks Hercules and thanks M45T3R for suggesting.

Implemented in r17353. Thanks Brynner!

Will place as implemented. Topic: http://rathena.org/board/topic/83324-r17351-accountguildparty-item-bound-system/

It's been completed as of r17352. I wasn't sure if I should rewrite it as permissions rather than bounds.

It would be very simple to add that into the system. It's too bad I hadn't thought about a completely different way of looking at this when I started. I was thinking it would be much more versatile to do item permissions rather than hard coded bound types. Example: 0 - All Permissions 1 - Cannot Drop 2 - Cannot Sell 4 - Cannot Guild Store 8 - Cannot Account Store 16 - Cannot Trade 32 - Cannot Vend 64 - Cannot Mail 128 - Cannot Auction A system like that. Ours is still very usable, just thought of this after I finished adding the current system. Back to the original character bound question, it can be done with a few simple checks and additions to the scripts/atcommands. We already have a custom system so I don't see why adding to it would be a bad thing.

Updated first post with countbound, getitembound, and getitembound2 as part of the item bound system in r17351.

Item Bound System r17351 adds in a new feature which allows characters to have specific items bounded to their account, guild, or party. Suggestion topic: http://rathena.org/board/topic/70372-item-account-bound-proposal/ Features: Items can be bounded 3 different ways. New script commands 'getitembound' and 'getitembound2' creates bounded items. New script command 'countbound' counts number of bounded items, also placing them automatically into an array. New at commands @itembound and @itembound2 used to create bounded items on the fly. Account bound items can be stored in account storage and in cart. Guild bound items can be stored in guild storage and traded to other guild members.When a character leaves or is expelled from the guild, these bounded items are automatically returned to guild storage. Party bound items cannot be stored but only traded to other party members. These are temporary and will be deleted on party deletion or when leaving the party. Credits to Xantara for the initial diff and Lighta for helping with the guild bound system. Please report all issues/bugs in the proper bug report section. Don't forget to update your SQL tables with upgrade_svn17351.sql!