Development Suggestions

[Peopleperson49]

It's funny, but if we really want to make rAthena stand out over the other many many versions of RO then we need to utilize peoples good work!!! Just go to the download and the source release areas and start adding those custom @ command releases to the source code! It won't break the 1:1 goal because people are not required to use them, however, it will give rAthena that edge over other versions. Every new script and @ command is one more thing we have and they don't. It will expand rAthena and get more people involved. There should never be a source release section with @ command releases for very long before being implimited. Some may need to be obmitted for obious reasons, but most are good to go as long as they work as promised, which means the will need some testing. I understand that developers are already busy with other stuff, but I hate when people ask for suggestions or help spreading the word about stuff, when there is more benificial stuff that can be done! I know that rAthena is already progressive in some area, and I believe that the work around ragnarok spreads super quickly on its own when things warrent. Why is it is that eAthena is slowed down significantly and are almost an epsiode behind, but it isn't worth people's time to convert to rAthena? Hopefully this doesn't offend anybody. Thanks.

Peopleperson49

[Panallox]

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.

[xazax]

We always consider to add the most used @ and script commands. For example we extended the autoloot r15489 and added string manipulation commands r15039. However we want to avoid all unnecessary bloat, because it can cause huge development overhaul.

[Earthlingz]

rAthena should stay close a what the official server scripts/commands need.

[Peopleperson49]

I don't disagree about the server being just fine that way it is. I was meerly just commenting that I have seen a lot of posts around here lately saying that we needed to spread the word about rAthena or contribute more. We need more people, etc... The only way to do that is to show that we have what it takes to stand out over the other versions out there! Right now were basically all the same. Don't get me wrong, the re and pre-re division is a very nice touch. At some point somebody had to decide to split it that way for some reason or another. The @ commands are the exact same way. How many time have you ever played a server as a GM and been like, I wish I could just give an item to everybody on this map. Or whatever it might be... The reality is that most people that run a server don't know everything they should to be running it. And it seems like source modification takes a back burner. Just look at all the people that run servers using pre-compiled versions. Thanks for the replys.

Peopleperson49

Edited March 19, 2012 by peopleperson49

[MarkZD]

I think it'd be cool to have these easy custom, but IMO people who want to make a server have to know at least the basics to change it the way they want or they're not a good administrator and is just a provider who is not capable to mantain a server and should not be doing it.

This is what makes the differential between just servers and real servers which have people to really assist it.

I'm not saying you should know how to solve all the problems(it'd be outstanding however, but it's not the goal because fortunately we have the developers and the community to greatly help us with it), but if you want a server, you have to be interesting in it, so you should learn all you can about customizing and etc tutorials that you can easily find out, then you're ok to have and mantain a server.

Edited March 19, 2012 by MarkZD

[sketchyphoenix]

Adding all of those source modifications just makes for more unnecessary upkeep.

Though I'm not above the idea that rAthena could use a good plugin framework for its most customized features.

[Arcenciel]

This discussion is similar to this topic

http://rathena.org/board/topic/54236-extra-item-bonuses-expansion-pack

[Peopleperson49]

I see what you mean about it being similar (but on different spectrums), and again that is just another good example! I'm not sure which of those script commands have been impliminted here, but that forum said that around 30 of there were already implimented on eAthena. Like it or not expanding the game is what it's all about. If it comes from copying the official or from the people that actually play here. Look at now compared to when the game came out and how much as been added and were doing just fine! The issue is more about having the time to impliment things now, then worrying about upkeeping them later! My point is that everybody trys so hard to make the perfect 1:1 with the official, that they often forget that it is the differences that set one server apart from the other! Take my server: I have made over 5000 custom items, 200+ NPC's, variable rates 10/10/5-20/20/10, so much customization, but I left the core concepts and play the same! Then you have the servers lake TalonRO or Ragnarok Frontier that are basically just cookie cutters of the files with a few add-ons. (I have played them both and I'm not knocking them). I put time in to balancing my stuff out, 99% of my custom items are one time usable items that once they are used up the unbalance problem is fixed automatically... Take DarkRO with there 5billion types of annoying wings (play that also and the wing part is just my oponion). Even the original EuphRO, before all the crap happened was basically a cookie cutter server, with enough over powered items to make Adam lots of money... If you don't give people room to expand every RO server will fade together and eventually people will get truely bored with it and quit. Then RO dies... I havn't been playing since 2003 for that to happen! Just go to ratemyserver.net and check out what is different about most of the servers there, basically the rates. Some might be PK, but again there are generally rules about killing others on the PK servers that is frowned upon breaking. Pretty much every server has the same features: warper, resetter, etc... The only difference besides rates is usually a couple custom quests, and the custom items they boast. I made sure that with my server that is NEVER an issue! I take every add-on, script command, @ command, or whatever and see how it would fit into my server! I can impliment those myself, but not everybody can even if it means more competition for servers like mine! We need more diverse severs out there to ensure that people don't quit RO completely to go play games like WOE which is constantly evolving! Those extra adds to you might seem like a waste of your time, but coming from a person who took the time to make over 5000 custom items, it's not trivial to me...

Peopleperson49

Another issue being that you mention 'making it worth people's time to switch from eAthena to rAthena by adding more features' makes it even more difficult for people to switch. I would venture to say that some of the reason why people haven't 'switched' yet is simply because rAthena has changed SO much that it's difficult to get their server working with it. REMODE, various source code changes, additions, subtractions, etc. is all stuff that people don't want to do right now with their server.

That and people can use whatever they wish, it doesn't really matter. So what if people are using <insert other emulator here>? We know we have an emulator that works, that is contantly being updated, and a kick ass dev team who busts their asses everyday to make sure that happens. We know what we're here for.

There is a difference about making a change such as adding script command or @ commands. Since they are an OPTIONAL feature there is not any issues switching! That is also why it doesn't violate the 1:1 goal. Unless eAthena has them and we don't, which I thank you for helping me proove my point that were at a disadvantage. I will tell you that I switched from eAthena to rAthena and all I really had to do was look over the pre-re vs the re. And that was just realizing what they were and which one I needed to update! If people don't know how to look through source code there not going to be able to do it on rAthena or anywhere else!

Peopleperson49

[sketchyphoenix]

If you don't give people room to expand every RO server will fade together and eventually people will get truely bored with it and quit. Then RO dies... I havn't been playing since 2003 for that to happen! Just go to ratemyserver.net and check out what is different about most of the servers there, basically the rates. Some might be PK, but again there are generally rules about killing others on the PK servers that is frowned upon breaking. Pretty much every server has the same features: warper, resetter, etc... The only difference besides rates is usually a couple custom quests, and the custom items they boast. I made sure that with my server that is NEVER an issue! I take every add-on, script command, @ command, or whatever and see how it would fit into my server! I can impliment those myself, but not everybody can even if it means more competition for servers like mine! We need more diverse severs out there to ensure that people don't quit RO completely to go play games like WOE which is constantly evolving! Those extra adds to you might seem like a waste of your time, but coming from a person who took the time to make over 5000 custom items, it's not trivial to me...

Peopleperson49

The burden of presentation is on the shoulders of the administrator that runs his/her server. While we do provide the base (the emulator, the vanilla ragnarok or as close to it as we can get ), it's not our responsibility to make other people's servers unique. We can certainly make the software easier to customize, but that's the server admin's responsibility to make fun and interesting custom content.

This is why I posted earlier that I am not above having a plugin framework for rAthena. It would allow users to distribute modifications much easier than what's in place now. It would be a lot easier to drop a few .dll/.so files in a folder and they just work as opposed to having to build a new binary for even the smallest changes and have to do all kinds of user support because somebody doesn't know what a compiler is, or they thought you just save the .c files and it just works automatically or they didn't add it correctly and now they have compile errors.

[jTynne]

Plugin framework? Yes, please.

A plugin framework make me holla honey booboo child.

[SkzBR]

Scripting and Commands should be in LUA format.

[Panallox]

Scripting and Commands should be in LUA format.

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

[SkzBR]

I think that it will be hard to make a plugin system because you'll need to extend to public clif functions, battle calculations, pc/mob/npc informations and plugin need to be able to edit and/or use it.

Anyone here played Counter-Strike correct? amxmodx was a great plugin system for me, you just need to register the plugin, custom variables and hooks into functions that you will modify.

[sketchyphoenix]

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.

Then we'll just make some. Starting with gm commands for now.

Then i looked in source

void plugins_init(void)

{

// Sugested functionality:

// add atcommands/script commands (Borf)

We're late.

[Peopleperson49]

A plugin would be nice! Yes I have already found them also. We need to expand them though to eventually include more than just @ commands.

Peopelperson49

[xazax]

I also do not like the idea of adding dozens of callbacks.

But a nice interface for most common modifications, like adding atcommands, script commands, (statuses, skills?), sounds less messy and maintainable.

But what is the advantage of such plugin system? Everybody is free to modify their code. Why would they create a plugin instead of just adjusting their source? Only advantage I can see, there is less delta against our codebase, easier merges, updates for the server owners.

I think, if we wants to improve the plugin system, first we should determine what kind of plugins do we want to see. I think plugins should not implement anything that is related to game mechanics. They should be tools, that helps debugging and administration and meant to be distributed although be an unoffical feature, for example a gui plugin.

[Peopleperson49]

I think that initially the modifications should be limited to additional @ commands and script commands through source modification. Adding @ commands and script commands is a fairly simple process for somebody who has some experience and it won't be over taxing on the actual developers that already overwork themselves most of the time! Those "simple" additions make a huge difference in the flexability and rAthena standing out. I know there is concern about server owners updating there server and plugins making it easier. But when a server owner updates them in the future there won't be an issue becuase the new updates contain them also. Just like when they added the trans classes. They started out as a mod which took a while to get fully implimented, now every owner already has them. If you took them away there would be alot of very mad owners! Adding those @ and script commands would become fully intergrated into future updates and the plugin wouldn't ever be necessary. There woundn't be any possibility of people installing them incorrectly (except the developers which have the most experience to do it correctly), also by having a professional do it, this prevents a lot of wasted time on posts for people asking for help! Whens the last time you saw a post asking for help to add the @go command to the server? They don't need to be an "option" for servers to install a plugin to allow there use. They would already be there and If they don't want them, then they don't have to use them! I don't allow normal users to use the @go command, but it is still available for use if I wanted to without any plugin. At one point in time even that command didn't exist. Now every server has it!

Peopleperson49

[Panallox]

I also do not like the idea of adding dozens of callbacks.

But a nice interface for most common modifications, like adding atcommands, script commands, (statuses, skills?), sounds less messy and maintainable.

But what is the advantage of such plugin system? Everybody is free to modify their code. Why would they create a plugin instead of just adjusting their source? Only advantage I can see, there is less delta against our codebase, easier merges, updates for the server owners.

I think, if we wants to improve the plugin system, first we should determine what kind of plugins do we want to see. I think plugins should not implement anything that is related to game mechanics. They should be tools, that helps debugging and administration and meant to be distributed although be an unoffical feature, for example a gui plugin.

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:

1. 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.
   
2. 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.

[Kenpachi]

Scripting and Commands should be in LUA format.

Why? What's wrong with our C-style syntax?

And which commands do you mean beside script commands?

I'm asking that explicitly because a second scripting language isn't something I would support (damn whis would be a mess) and replacing the old one is utterly out of the question (at least with me as responsible person).

@Plugin system:

I'd like to see something like this but it should be documented this time... (It's the first time I hear about such a thing is already implemented in eA)

[sketchyphoenix]

I also do not like the idea of adding dozens of callbacks.

But a nice interface for most common modifications, like adding atcommands, script commands, (statuses, skills?), sounds less messy and maintainable.

But what is the advantage of such plugin system? Everybody is free to modify their code. Why would they create a plugin instead of just adjusting their source? Only advantage I can see, there is less delta against our codebase, easier merges, updates for the server owners.

I think, if we wants to improve the plugin system, first we should determine what kind of plugins do we want to see. I think plugins should not implement anything that is related to game mechanics. They should be tools, that helps debugging and administration and meant to be distributed although be an unoffical feature, for example a gui plugin.

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:

1. 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.
   
2. 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.

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.

[Peopleperson49]

I didn't realize this topic was going to be so hot when I started it, lol. Anyways, I agree with SketchyPheonix to atleast get the stuff working using callbacks. However, for @ and script commands placing them in the actual source code seems like a better option. The current volume of @ and script commands don't rely on plugins and we should really keep things the same throughout. They need to be there at anytime when somebody wants to use one, without having to go install a plugin or do anything special to get them!

Peopleperson49

[Panallox]

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:

1. 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.
   
2. 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.

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

[Peopleperson49]

Functionally is always defined and applied differently. Some commands that one person thinks is useless might turn out to make the best script ever! Having that option available allows people to give a new idea a shot or test stuff without extra work. This again allows diversity to keep the game alive! Most people generally wont take the time to install stuff with no clear goal in mind.

Peopleperson49

[Lighta]

Actually even if I agree new interface are easy (either script commande or @command) they're some who could be revamp, extend etc.. wich imo will benefit dev team and user imo, but that you don't implent. Yes I'm thinking about checkweight update, or merging those getitem getitem2 stuff etc..

What really missing is like a pull request systeme.

Addin string manupulation is nice but I'm fearing we'll turn ea langage in a simplified C like.