The Mana World Forums

No one seems to want to touch tmwAthena code with a ten-foot pole, but I can't stand seeing the code as it is, I'm making good progress with little cleanups. One of my goals is no compilation warning with -Wextra, and 32/64-bit, endian-neutral code.

I've finished my initial cleanup of the common/ objects, I need to do the login and char servers (integrating SQL with the TXT versions, so they don't diverge again - I am NOT looking forward to this) and do the map server and possibly ladmin.

It would be helpful to know what, if any, of the tool/ are actually used, or would be appreciated.
This is not a general request for feature requests, at this time, but I expect I will add some high value, low cost features such as split menus in scripts.

---

An interesting story: when I rewrote the MD5 code, I introduced the following bug, which didn't show up during testing, but only when I added the code to tmwAthena. Can you see the bug? (it is for things like this that I hate C).
(PjotrOrial got it on IRC)

Why? I guess it would be better if you invest your time in TMWServ or the official eAthena project. eAthena sucks but is not really broken, so why fix it?

There is one thing that would help a lot and that kind of fits with the review part of your task once you get to the map server.

I have seen a number of topics concerned with game balance. I am sure some of the people working on this issue know the intricacies of the combat engine, but a lot don't (including me). To be really effective at balancing we need a mathematical model of tmwAthena combat, i.e. exact mathematical functions that completely describe:
- player melee and range hit % vs mob (and vs players if its a special case)
- player physical dodge/block %
- player melee and range damage vs mob (and vs players if its a special case)
- player physical attack speed
- monster hit % vs player (and vs mob if it is a special case, this can happen)
- mob dodge %
- monster damage vs player (and vs mob if it is a special case)
- monster attack speed

As for combat magic I really don't know what rules apply, but I am sure a model can be given for this too. Any in depth documentation on the number crunching would be greatly appreciated.

Sorry if a complete model is already given somewhere, but so far all the ones I have seen are either not applicable to tmwAthena or are not complete.

Matt wrote:Why? I guess it would be better if you invest your time in TMWServ or the official eAthena project. eAthena sucks but is not really broken, so why fix it?

1. TMWServ has been 6 years in coming, and really hasn't shown any sign of being ready soon. Working on this will provide something immediately usable.
2. tmwAthena is a significant divergence from a really old version of eAthena.
3. At the moment, it is not really easy to add stuff to tmwAthena. Improving the code will make it easier to understand, and thus modify.
4. There is a lot of stuff used in eAthena but not usable in TMW.
5. There are potential performance problems and crashes in the code as we have it.
6. It would be good to eliminate endianness and word-size assumptions.

Hello o11c. I got to say that it disappoints me a bit, that you prefer to support the dying tmwAthena instead of the currently quickly advancing Manaserv. Especially considering that Manaserv development is again very active. In March we had 50 commits on the main branch of manaserv, not counting activity on other branches and manaserv-specific client commits (largest construction sites are currently optimization of movement, improvements of what can be done with temporary stat modifiers and implementation of additional game master commands).

o11c wrote:1. TMWServ has been 6 years in coming, and really hasn't shown any sign of being ready soon. Working on this will provide something immediately usable.

Manaserv can currently already do more than eAthena was able to do with the TMW client the moment people started modifying eAthena again. When those people who spent their energy on tmwAthena would have used it on Manaserv instead, Manaserv would already be usable.

Besides, there are already projects like Invertika which are using Manaserv. TMW would use Manaserv too, when the content release 1 project would finally take off.

Doesn't matter PlasmaServ will be ready long before ManaServ

Hi o11c,

I'll try to be pragmatic while considering your will to fix up tAthena. Of course, it's all a matter of taste, and I'm willing to force anybody but to have you on the Manaserv side would have been great.

4144 has made many bugfixes and feature additions on his own version of tA, called EvolServer and located here:
http://gitorious.org/evol/evol-server

(Updates seem private since the 16.02.2011 but I can swear he will provide you the rest when asking politely.)

IMHO, putting your efforts together to merge back the possibilities of tA up to the evolserver,
or at least using the common fixes could be a good start, and a good way to respect the open source spirit.

Note that the biggest problem, and the word is still not strong enough, is the lack of SQL support (even if I know you're not caring about it now.). As for me, if someone ever wants to see others have interest in the tA code again, SQL support (or alike) is a must.

I wish you good luck on tA maintenance.

Best regards.

Kage wrote:Doesn't matter PlasmaServ will be ready long before ManaServ

Are you kidding? What is "PlasmaServ"? oO

Matt wrote:

Kage wrote:Doesn't matter PlasmaServ will be ready long before ManaServ

Are you kidding? What is "PlasmaServ"? oO

a vampire buffet

Big Crunch wrote:

Matt wrote:

Kage wrote:Doesn't matter PlasmaServ will be ready long before ManaServ

Are you kidding? What is "PlasmaServ"? oO

a vampire buffet

See that as KageServ

Once I get to rewriting the script engine, I am likely to invalidate the following syntax. (as well as similar syntax for copyarray and cleararray, but those are not used) A patch is attached which replaces these uses with nondeprecated forms (without the index for the latter 2, using multiple set statements for the former).

And somebody please set the forum to allow .patch extensions. (it's pretty stupid to be assuming extensions are meaningful anyway)

Note: I have (somewhat accidentally, but I probably would have done it anyway) changed the protocol between char-server and map-server, in a manner that is not automatically detectable. Note that this has happened before.

This should not affect the client, it just means that my new versions of the servers must all be run together.

TODO: add protocol version checks so the servers don't try to parse random packets, but instead abort if an incompatible version tries to connect.

I finished going over login-server and char-server, and did a quick review of the map server and ladmin to get rid of compiler warnings


stuff that needs doing:

• The same review I've done for for common, char, and login, to be done to map and ladmin.
• Allow compiling as 64-bit native
• Allow compiling on big-endian machines
• Convert all the homebrew containers to STL. In some cases, this needs a wrapper, e.g. to avoid creating default entries in a map.
• Make a lot of string checks aware of UTF-8.
• version checks between the servers
• more documentation (after converting stuff to use C++ idioms)
• Make the packet handlers uniform - I sort of prefer the way login and char do it - a switch statement - rather than all the structures with lengths and functions pointers used by the inter subserver and the map server.
• http://bugs.manasource.org/view.php?id=344 and new packets depending on it.
• some more meaningful error messages, logged or sent to client.
• Implement a real logging system.
• Cleanup the GM file editing
• New config readers (data link - split config up into multiple files)
• New db readers
• parse scripts ahead of time (this is likely to be a big performance improvement, and the hardest item in the list)
• unify atcommand, magic scripts, and npc scripts in a new scripting language
• implement AIs
• IPv6 support
• Unix domain socket authless server/ladmin connection

Hi o11c,

I do appreciate a lot your efforts done on tAthena.

Yet, when I see this long list of items, I do also question myself about the reasons why
you won't prefer adapting the current eAthena stable version (with years of improvements behind it),
since the work to do could even be shorter, IMHO?

Although the benefits of somebody competent having the will to look at all the mess that was eA will not be immediately apparent, it will be before manaserv.

Also, what have got against manaserv? You seem to promise a full server ready before it, and even if I believe you can achieve it if you keep this development speed, Manaserv has the same spirit than you have, willing to bring a modern-code-wise configurable server with an highly flexible scripting engine and a lot of sympatethic stuff. What made you not consider entering the loop, even in a personal and independant clone?

Best regards.

i'd like to propose a few changes to the code that sound easy to change during a rewrite, but a pain to change otherwise.
change a few of the numbering systems/db
i can't stress enough how much i agree with bertram with the sql support (provided the inputs are sanitized )

right now the mob IDs are capped at 10,000. this doesn't present a problem until you start having tiers and elemental mobs. a simple 5 tiered system that uses elemental mobs would generate 500 entries for each base mob, effectively limiting it to 20 base mobs.

this leads into my next proposal: making elements handled with a numbering system that would allow multiple elements per item/spell/mob
right now, elements are given a single digit number
from the magic file: what i'm proposing is this: this numbering system allows you to add any combination of values together and get a unique one everytime.
so if we wanted, oh say . . undead earth mobs, it would be possible. one could even go all out and give a mob every elemental type if they were so inclined.

stay classy.