Panallox

I love you.

I'm tempted to ask why there wouldn't be a cupake? We got a cupcake hater over here.

This is a small-scale operation so callbacks are the preferred method. Decided rewriting the system would be a better option and the core of it works for windows, just need to bring in the nix support and i can start testing. Alright, although I think once we have the initial plugin development framework working it'll be worth looking into creating event tables. This closed-source option might allow other developers to create more elaborate and protected source modifications, and it really wouldn't hurt to have the functionality supported (even if it never gets used.) Are you taking up the lead on this then? If so I'll focus efforts elsewhere

Pretty much, we want to avoid the mess of having callbacks everywhere. There would be two logical methods of implementing plug-ins which should both be supported: Default callbacks. Implemented in areas, like you mentioned, at-commands, script-commands which call default "events" or methods within a plug-in upon initialisation, usage and obviously shutdown/clean. An "event table" which stores string or other integer values as a sort of map, which the plug-in will load into memory upon the library being loaded to which the plug-in creator can then create calls to these methods by writing single lines of code within the source (IE: plugins_call_event("event_name", [parameters as va_arg?])) By providing an "event table", it means people could create closed-source plug-ins, but obviously one critical importance is allowing cross-platform compatibility which will need addressing in the plug-in system.

I'm sure this will be highly accepted. I think anyone who's played RO consistently has experienced the pain of moving a few dozen items to/from storage.

We got a SketchyPhoenix advocate over here! Anywho, the idea of a plugin framework sounds dandy. But, one of the reasons no-one uses the current plugin system is because there's no support right now for adding callback methods for areas of the source. If you wanted to add something to battle_calc_weapon_attack, how would you manage that via. a plugin right now? It can't be done, and to implement a plugin system would mean providing callback support through-out the whole source. Unless anyone has any better suggestions for implementing a plugin system? I'd be more than happy to discuss it and get some implemented

Just my two cents here, but I don't think adding all these various @ commands will help much at all. One of the main reasons we don't implement all these features is to reduce over-head file size, developer work and CPU run-time of the actual emulator. It'd be a novel idea to implement these custom commands, but in terms of relevance, or even importance, to the rAthena project it's simply not worth us looking into for the time being. Like you said, we are pretty busy trying to wrap up some of the bugs reported and we're also trying to reverse engineer the mechanics of renewal down to perfection, we just don't have time to be scouting the source modifications section attempting to find worth-while edits that could be committed to the SVN The edge we have right now is that we're continuously fixing the reported bugs, continuously revamping areas of the source to greatly improve efficiency, and that we're working as hard as we can to try and perfect the renewal mechanics and classes for official implementation. Besides, I think it takes no to little effort to implement a custom @ command using a download.

0x0635

Lol, so much discussion over a desktop and no-one else has uploaded their own! Yeah it's Windows, using the Elune Windows theme, Rainmeter @ Enigma, and some other stuff

First draft of the design, it's likely that while being converted into the HTML format the structure will probably change a little. Expect some jQuery and some animations in there though, give it that little extra fizz.

Simple is simple, take a screenshot of your desktop and post up a picture for others to cream over or discuss how messy everything is!

1526

One of the major pitfalls of other forks of eAthena is that they tend to dive straight into developing new content. The belief, apparently, is that if you don't develop new content immediately then people will lose interest in the forked emulator. This is a lot of crock. One of the major concerns right now is to re-work a lot of the eAthena code to improve our code-base, and to fix up the plentiful bugs that still exist within the source. For example, once my coursework period is over I will be committing the status database update (which converts source-specific status settings to a modifiable database format.) This is the kind of change that eAthena has been waiting to see for a few years now, but was never completed. If anything, one of the milestones should be 'fix that crazy eAthena crap up', or even 'step up the source game', but since fixing bugs isn't really considered a milestone, we'll just slowly integrate new content while we build around the existing codes and try to improve the functionality of the emulator

The chances are that an extra column with a list of affected skills associated with the status effect might be the simplest method, until perhaps it gets re-written at a later date. An example of some entries below: //================================================== // status database //-------------------------------------------------- // <status>,<icon>,<recalculate>,<flags>,{<cancels>},{<required>} //-------------------------------------------------- // recalculate: // eg. SCB_STR|SCB_INT // flags: // 0x01 : buff skill // 0x02 : debuff skill // 0x04 : cannot be dispelled // 0x08 : cannot be lost when character dies // 0x10 : does not override the previous instance // 0x20 : does not affect boss monsters // cancels: // eg. { SC_INCREASEAGI, SC_ADRENALINE } //-------------------------------------------------- // note: this file can use values from const.txt //-------------------------------------------------- SC_STONE,SI_BLANK,SCB_DEF_ELE|SCB_DEF|SCB_MDEF,0x20,{},{} SC_FREEZE,SI_BLANK,SCB_DEF_ELE|SCB_DEF|SCB_MDEF,0x20,{},{} SC_STUN,SI_BLANK,SCB_NONE,0x30,{},{} SC_SLEEP,SI_BLANK,SCB_NONE,0x30,{},{} SC_POISON,SI_BLANK,SCB_DEF2|SCB_REGEN,0x30,{},{} SC_CURSE,SI_BLANK,SCB_LUK|SCB_BATK|SCB_WATK|SCB_SPEED,0x30,{},{}

Hey guys, thought I'd post an update. I've re-written the source to use the status database, works just fine, just need any suggestions on where to store skill status entries. In the source it was originally assigned in set_sc() however I'm looking to move from statically designating the statuses in the source. For those who don't quite understand, how/where should the definitions be to define skill -> status infliction. There's no point adding a new database for storing these 2 values alone, it's possible to add a new column though in status_db.txt to retain skill IDs (IE: { <skill1>,<skill2> }. Open for suggestions, then the first commit will be ready

Well, I suppose first you can define the extensions simply in the import configuration files as Brian said. It will still process the file since it's reading the NPC as a textual file. But secondly, if there is a restriction in the source somewhere that composites .txt files then I imagine it would take little to no effort to add an additional extension. I don't see this actually being in the source though, so as far as I'm concerned I don't even see why/how this would be done other than renaming all extensions in the folders .ext (new extension) which seems moderately redundant. Although if someone wants to create a patch for this then by all means, create one and throw it into the script releases forum

Merry Christmas from the UK guys. Have a good one

Agreed, adding an inter-server packet to handle this would clean things up significantly. We could also consider expanding the search results to include more than just country of origin. Maybe include the city, region etc. which could be useful when trying to track down characters which have caused offense (see if they play in the same area, may possibly be the same person?)

This looks like there's a ton of Emperiums being spawned on top of each other.

I don't believe there ever will be a fix. The login window functionality (most of it) was removed when they introduced login through their website. As such, a lot of the features are now disabled, resulting in closure when incorrect password is entered or when the player clicks 'Quit' in the character select window.

I like the idea of having the require column. Although the reason we're not going to implement a 'script' column is because it's not accurate enough to generate the values we'd need (like the source does), and it'd also be slow (since every status would run a script on the user, this would be painfully time consuming). The database for the time being will server as a medium which will allow administrators, and developers, to maintain and edit the statuses as necessary I've added the required column into my list of to-do for it. Thanks Edit I have the conceptual database currently working. Note the following test entry: SC_STONE,0,SCB_VIT|SCB_DEF,0x02,{ SC_BLESSING, SC_CURSE },{ SC_FREEZE } Produced the output: status=0, icon=0, flag=0x0002, recalculate=0x00004020, cancels=30,5, requires=1

This is the discussion topic for the implementation and maintenance of a 'status database'. Information The concept behind this change would be to remove the entirely hard-coded current 'status table' system, and move the flags into a database file. This database file would be editable and customisable by any server owner, and would allow much more flexible implementations of things. Example Currently the source stores status related information in tables in status.c: static sc_type SkillStatusChangeTable[MAX_SKILL]; // skill -> status static int StatusIconChangeTable[sC_MAX]; // status -> icon unsigned long StatusChangeFlagTable[sC_MAX]; // status -> flags static int StatusSkillChangeTable[sC_MAX]; // status -> skill The first step in reforming this system would be to allow a status database (ie, status_db.txt) to define the characteristics of the statuses. This would mean the status icon displayed and the status change flag (which determines which statuses should be recalculated once it starts). However these are not the only areas left to be defined. The source dictates which statuses can: Be retained when the Sage skill Dispel is used Be retained when a character logs out Be retained when a character dies Override or cancel previous statuses Override the previous status active on the user To tackle these hard-coded solutions, it would then be plausible to implement a 'flag' column (for defining features such as 'buff' status, 'debuff' status, 'un-dispellable') and have an additional column to list statuses which are cancelled when the status is activated. Of course some areas of the status system will be kept in the source, mainly the actual bonuses (such as in the status_calc_* functions) and status specific checks (some statuses cannot be activated when another is active etc.) Proposition The idea would be to have a database in the format: <status id>,<status icon>,<recalculate flag>,<status flags>,{ <override status 1>, <override status 2> ... } The purpose of this topic is to collect additional ideas for this implementation, and thoughts on using a database like this.

On some servers, it's possible to reduce after-cast delay enough to the point where it's practically 0. There are some skills which actually don't have a cool-down period but are maintained entirely by amotion. For instance, AC_DOUBLE (Double Strafe) has no cool-down period but relies on ASPD (subsequently amotion) to perform the skill fast enough. By editing the .act files to remove the sprite delay when casting, it becomes possible for the player to spam the skill endlessly at a stupid speed. I suppose the idea of this is to store the amotion values for each particular sprite (at a particular level of ASPD) to prevent this hack being usable. Edit After writing up a quick ACT parser to read the delay frames from ACT files, I have come to the conclusion that practically every job .act file has a 'delay' rate for attacking, skill attack 1 and skill attack 2 of '4.0' which is the standard default. What this means is that we just need to try and replicate the algorithm used by Gravity for calculating how long an animation plays for using amotion. If the algorithm in the source is the official formula then we should be able to manipulate that to add an amotion delay when using skills. To download the parser I used when determining the values: http://www.epoque.ws/parser.zip Just paste a list of <sprite id>_³².act files into the same directory that you run the script.

Nice to see you again, welcome to rAthena Usako

The XML style isn't fully supported by C++ clients though. I know that javadocs; are supported, usually in either the format: /** * some line of description here outlining the process. * @param something a description of something * @return bool whether or not it is true! */ Or the same but: /** * some line of description here outlining the process. * param something a description of something * return bool whether or not it is true! */ I think having XML all over the place might look a little crowded? Just a thought