Hard-Coded Configurations

[Maki]

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 )

[Maki]

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

[Maki]

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?

[Maki]

Maki

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?

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!

[Maki]

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]

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.

[Maki]

Error404

.....

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

[Maki]

GodLesZ

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.

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.

[Maki]

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.

[Maki]

Ind

Including the removal of the stupid japanese comments and that.

Good point, I've started: r64

Anything you do, if its not properly cleaned up/optimized, its not worth it. If we just do the same thing as 3CeAM devs or ReAM, that just took eA and added bunch of code in there without even looking at ways to optimize it, then we'll have a much hard work later.

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.

[GodLesZ]

I would love to see some suggestions about current features like txt support.

Its hard to come on the same base for things like removing old packet version and that.

But things like txt support should be discussed i think.

[sketchyphoenix]

txt should be replaced with sqlite. less work all around especially for new features that are using sql

[Mercurial]

txt should be replaced with sqlite. less work all around especially for new features that are using sql

and they can use the same feature set ,