Maki

jTynne kRO still has penalties for the level difference for drops so far as I'm aware, however, iRO did away with that, as it prevented high level players from getting cards and such at the normal rate from lower level monsters.

GodLesZ Damn i forgott about iRO and kRO differences. Weill, we should wait for some feedback from kRO testers. I dont know, only searching on google =/

Ind So the Orc chart is outdated or just on iRO it is different? (e.g. kRO uses the orc chart values)? I'm a bit sleepy sorry if you made it clear

GodLesZ This seems to be up2date: Experience changes @ iRO wiki (Note that MvPs wont be affected) As for the Drops, i'll quote Doddler Also iRO confirmed it: Drop System

Ind Hum we gotta figure which one is correct, I've followed this chart I found on doddler wiki where -3 would give 105% boost, and "<- 10" 40% btw I didn't know drop rates were affected by this too, I wrote just for exp

GodLesZ Followed by r39 - source of this? if( diff >= -10 && diff <= -3 ) boost = 100 + (( -diff * 5 ) - 15 ); As seen by RODE-R Testing current implementation: But Doddler says, on a difference of 3, the mob should give +5%, not on >= 4. Also, we have "diff <= -10 == 40%", but doddler says <= -16. Who is wrong?

GodLesZ I've implemented such a thing on my test server about 3 years ago. It was, like many other test modifications, oriented on the IRC chat system. The player was able to create chats using something like @createchat <name>{<password>{<max_users>}} and joined chats using @joinchat #<name>{<password>} After successfully joined tha chat, he was able to talk to it like PM'ing a player: [#<name>][message]. There was also some chat commands like @chatcolor, to switch between white, darkgreen, lighreen and brown or @searchchat <id|name> to search all vending players, listen to the joined chat, for this item. Color changing ie.e was only accessible by the chat moderator, which was also a GM and the user created the chat. The Moderator was also able to kick, mute or even ban player from the chat. Some global chats like #main, #market and #region replaced the whole @main thing. Btw, the #region chat worked like WoW's region channel - only players in a specified region (i.e. all prontera fields = prontera region) was able to read and write with each other. If you want i could search for my old repository and try to implement it.

Squishy This has been a mainstream mod for a while and so most big private servers have some form of it... yea I think that it'd be good to revamp the @main command.

jTynne This is one of the most requested things I've personally experienced over the past five years running servers, and it's typically always in high demand. Perhaps providing such a feature in the SVN here will opt people using the RR emulator? Tell me your thoughts!

Ind Good point, I've started: r64 We're not doing the same thing as them, should you take some time to see what's been done so far (timeline) you'll realize that.

Ind I agree and understand your points. I believe, however, that before multi-core, documentation and clean up the truly essential is a smooth, feature-full emu that makes people look at us and be willing to move in, although very important parts, at my point of view, they'd not be as catchy as a updated emu would -- I'm in no way denying these features but rather pointing out my belief that getting up to date should be our main goal. Whats your opinion on this? Thank you for your time.

GodLesZ Totally agree for all of this. Of course, multi core is worth a trying, but we should focus first on general clean up first. IMO we should support Packets for the last 2 working years. These would be Packets starting on 2009. If we finished all packets from 2011 and reached 2012, we should remove anything up to 2010. This should be enough for some "old school" servers and would also reduce issues about realy old clients. And of course cleans up the code from unnecessary switches. Also +1 for a well documented source. But the first step would be a in-code documentation, known as comments. Including the removal of the stupid japanese comments and that. We should define something like a roadmap and milestones for these steps.

Error404 I kinda like this part, if you think about it, eA has a lot of old-client-packets support (perhaps this is not the topic to mention this..) that should just be removed, I don't see any reason to have a lot of old stuff (2009--) in there. A big thing that needs to be done is to remove such things and move on, it sucks that people are still using XRay. On another note, a proper SRC documentation should be done, mind you but eA has a poor/none doc at all. If you approve the removal thing, i'll start removing old stuff that are just there and make the SRC too crowded. --- Another thing I wanted to say is, multi-core support is a must. I can look into that too. Anyways, thats all I wanted to say. I do agree on bringing the whole updated emu, instead of just giving the same switch thing all over again. If they want old stuff, they can have eA for a change or 3ceam for that matter.

Ind no problem at all, I personally enjoy reading colleagues' opinion. Yes I agree their previous experience is very poor, we should, however, be able to get rid of this switch at some point, but at this stage it is a must. I'd like to add that, I think you might have misunderstood this switch, because there wouldn't be as many as you appear to say -- they are used at few places, of course we still do not cover 100% of RE features such as the casting system but I'd say we'd get about to 30~50 around. Notice what I've done here: http://trac.ro-resou...et/changeset/44 these 2 "constants" saved 5 #if nesting, do you think it is worth to use this kind of constant pattern? Whats your opinion about it? Thank you for your time.

GodLesZ You are right, of course this will be a highly request thing. At least if eAthena drops full his support and updates hardly, this will be next high frequenced repo. So actually we had to ask the users. Should it be possible to switch between full-renewal & pre-renewal or not? Problem here is that the current renewal users inspired from 3Ceam and other projects do not even know a "real renewal" gameplay, because many things are missing. And as a consequence of the wrong imprerssion they say "i dont like renewal!". So actually we couldnt count there vote +1 for the switch, because they have some wrong impressions. Its like the SQL/TXT switch in eAthena, maybe even bigger in the future. Ragnarok will be developt more and more in the way of renewal, so our switch would be bigger and bigger, the code more confused, the debugging harder and the needed time to developt heavly increased. I dont think there will be new features for non-renewal in the future, so there isent any need for an "up2date" software to switch most of the updates & features of. This is not meant any harm :X

Maki Agreed, if down the line a huge majority of RO users decide to stop using pre-renewal functions then we could discuss the removal of the switch. But for now a lot of people use non-RE mechanics (hence why eA is dominant compared to ReAM or 3Ceam imo). We should be the most feature-rich as well as being the most updated and stable branch!

Ind I agree with you and I'm not a fan of that path either, but the popularity of such switches is too great to be left behind, it's a feature many users look forward to. In my opinion for this project to succeed we should make a few concessions in order to give the server admins what they're looking for. What do you think?

GodLesZ I'm a real fan from preprocessor directives, miss them realy often while coding games & stuff in C#.. But i think it would be overpowered to split every renewal/non-renewal code in such a directive. I thought this should be the most up2date & offical branch, so where isent any reason to provide a non-renewal option. Also, without a directive for this the code would be more cleaner and requires less debugging. I'm a friend of user discusioin, of course, but not for 20% of server code. Thats my point of view

Ind Using hard-coded #defs to enable/disable features in order to save performance at runtime Initially we'll be running with minimum on this, currently there is a single setting there, 'RRMODE' to define which formulas to compile, saving a great load of performance compared to using a runtime check such as battle_config stuff. Whats your opinion in using this pattern for newer settings used in busy functions? and possibly in moving older settings that are run in busy functions (busy such as damage / move block / walk / etc )

GodLesZ IMO this is a community question, not only developer. People will keep asking "wtf why doing this f*ckin dmg? Never seen this on retail server", because they are playing on iRO or any other iRO based server. On a developer pov, iRO is the better choice because of her wiki, changelog, level rate, ect. Could be done via simple NPC scripts and a new script command to open the shop window of a specific player. But dont sounds that hard

JakeRed I think in the same way, a mix between iRO mechanics and kRO would benefit the most this project. Getting mainly information from iRO and the rest of the unknown data would be gathered from kRO. Since from the past 1 and half years i'm doing test over kRO and at the same time over iRO just comparing how does work each skill that i'm allowed to use and every mechanic before to make an update to a few stuff at the SVN.

Ind indeed there are quite a few areas that 'frees' the target without reaching unit_stop_attack, we'd need to create a 'release' function to manage the counter

GodLesZ Glad to here If you are in the mood, feel free to start the implementation. I had to write a damn software documantation until end of work, so I'm a bit busy for now :S We should add a bug tracker issue for this and ask others for battle tests. I'm not sure if every attack stop points to unit_stop_attack(), so we should test this with different scenarios (simple attack, target dead, dead by status, dead by skills, dead by @command, ect).

Ind great suggestions, a real-time counter would work much better indeed, also liked your performance directive idea

GodLesZ These could be done on many places in eAthena (more memory vs less CPU). Of course, I'm pretty forward to this, but the interval shouldnt bee more than 3 sec to prevent incorrect results in a hudge battle. We could also provide a new directive "MORE_MEM_LESS_CPU" and surround optimisations like this. And, we could add an uchar to each mob instance, increment on unit_attack() and decrement on unit_stop_attack(). This will cost again more memory, but less cpu because no iteration through all mobs on the map would be needed.