[REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Development discussions for Manaplus (Evol's official client) and alternative clients.
Post Reply
User avatar
jesusalva
Administrator
Administrator
Posts: 239
Joined: 14 Nov 2016, 23:20
Location: Brazil
Contact:

[REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by jesusalva » 06 Feb 2020, 02:17


Role wanted: Coder
Difficulty: 5/5 Difficult
Milestone: N/A
Priority: Optional, Important

Language: C++ (QtQuick)
Origin: viewtopic.php?f=56&t=20818


First of all, we will keep supporting ManaPlus for Desktop. With this out of the way.
There's the idea of using tales-client (Source of Tales client) for Mobile. It have a simpler interface, is easier to use on mobile, etc.

To add Evol2/Hercules support with a backend library on tales-client, which would also allow us to make other clients in future and even rewrite ManaPlus in future with a more modern codebase, it is needed a lot of work. Therefore, we plan in assembling a small team of volunteers which are interested on the task.

Obviously, if everyone is fine with using ManaPlus on Mobile, there's no problem.
You can ask Ablu for help with tales-client, he is always on IRC.

Frequently Asked Questions
Q. How does Tales-Client looks like? Where can I find it?
A. http://www.sourceoftales.org/screenshots.html for screenshots
https://gitlab.com/tales/tales-client for git repository

Q. What's the reward?
A. There's already US$ 100 collected to those working on it.
That's how much money we've collected thus far, and for everyone working on it.
So more developers means this will be less money for each, and we'll need to collect more money.
But think on it as an additional incentive.

We may also later add items to rewards.

Q. How much technical knowledge I need to have?
A. You must know about networking and C++. Studying ManaPlus, TalesClient, Evol2 and Hercules source codes also help.
Git and GitLab knowledge helps with coordination.

Q. How do I volunteer myself? How will they reach me out?
A. It is better to write here of your intention to help. A Discord also allows us to contact you faster (but you can be on IRC as well).
GitLab username is also a must.

Q. Why don't devs do it themselves?
A. Lack of (wo)manpower currently skilled in C++.
Also, everyone is busy working on something else already.
And again, this is optional priority.

Q. Who is responsible for deciding upon the final version?
A. Client development is handled outside TMW's, so the final word would be Ablu's and the Source of Tales development team.

Q. I want to make my own client, not to use Tales' client.
A. This is a request for a backend, nor for a client rewrite.
Several other applications and languages can interact with it, and of course, you can always copy-paste the backend and use it elsewhere.

Q. I don't know how to code but I want to contribute on my own way.
A. Alternative ways of contributing include donating real money (which is what a certain group did, as you can see), donating ingame GP and items, etc.
But we still need volunteers, or at least people willing to learn C++ and tackle this project.
(Actually we might accept even prayers so feel free to contribute as you want! This is free software.)

Q. How long do you estimate this task to take?
A. Several weeks. Depends on number of volunteers, their coordination, and several other factors.

Q. Will this delay official server release?
A. Probably not.

Q. What packet version should the backend use?
A. We need server packet version 20170517 support.
Support for earlier packet versions is not required. Support for later packet versions is appreciated, in special, if you manage add support for all 2019 packet versions, we will have inventory boosting items (what, 100 slots isn't enough for you?! Weird.)


Anything else, feel free to contact here as well.
Jesusalva (aka. Jesusaves)
User avatar
tomminator
Developer
Developer
Posts: 90
Joined: 18 Oct 2008, 18:27

Re: [REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by tomminator » 08 Feb 2020, 19:34

So I took a look at the tales client sourcecode and it seems like all you have to do is:
  1. change the packet numbers found in tales-client/src/mana/protocol.h to the ones found in evol-all/server-code/src/map/packets.h
  2. add missing but needed packets and their functionality to tales-client(most likely not all hercules packets are used by tmw)
  3. then also some parsing is most likely also needed, because the data in the packets may not be what tales-client expect
  4. hercules/evol uses login- char- and map-server, source of tales uses chat- account- and map-server (this might or might not be a very big issue)
  5. figure out how tales-client handles the client data and adapt it so it can handle the current client data. (we cant modify existing client data or manaplus will stop working)
  6. add missing features (i dont know if tales-client supports stuff like heights in maps and adding cards to items via inventory)
easy peasy!!! :alt-1: :alt-1: :alt-1:
This is not a placeholder
Ablu
Novice
Novice
Posts: 286
Joined: 23 Jul 2011, 09:31
Location: Germany

Re: [REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by Ablu » 08 Feb 2020, 22:11

The best way would probably to develop a lib which implements the network API and populates the models of SoT. The code is generally designed as a library (and even built as one). So one would not need to fork everything but could benefit from a shared code base.
User avatar
jesusalva
Administrator
Administrator
Posts: 239
Joined: 14 Nov 2016, 23:20
Location: Brazil
Contact:

Re: [REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by jesusalva » 09 Feb 2020, 04:14

tomminator wrote:
08 Feb 2020, 19:34
  1. figure out how tales-client handles the client data and adapt it so it can handle the current client data. (we cant modify existing client data or manaplus will stop working)
  2. add missing features (i dont know if tales-client supports stuff like heights in maps and adding cards to items via inventory)
a. I believe tales-client uses an outdated version of our own client-data files. So it should mostly work. Which brings me to

b. Heights are cool. Adding cards to items via inventory is cool (and important, on ML, the craft system is almost 100% based on drag'n'drop). However, these are only critical if we were trying to replace ManaPlus entirely.

What we want is an alternative, which is easy to play on mobile. Given we aren't focusing on the mobile-only players (yet), I think it is fine to start with only the critical gameplay features and having optional features on Desktop only.

In other words: It is still a huge task, but initially it is not so big as your comment suggests :alt-3:

Keep in mind tales-client techinically comes from Mana Source, and ManaPlus also comes from Mana Source (but more directly).
Jesusalva (aka. Jesusaves)
Ablu
Novice
Novice
Posts: 286
Joined: 23 Jul 2011, 09:31
Location: Germany

Re: [REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by Ablu » 09 Feb 2020, 10:26

jesusalva wrote:
09 Feb 2020, 04:14


a. I believe tales-client uses an outdated version of our own client-data files. So it should mostly work.
The Mana Server does not differ between client and server data. The files are shared. Thus the format only shares the XML structure, but the content will differ. But the parsing logic is fairly decoupled and could be exchanged. But this is not really a thing about newer or outdated files, things are simply different. I would advise that you try to understand how stuff on the Mana Server rather than trying to bend things into the way they worked for TMW in the past.

Regards,
Ablu
User avatar
jesusalva
Administrator
Administrator
Posts: 239
Joined: 14 Nov 2016, 23:20
Location: Brazil
Contact:

Re: [REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by jesusalva » 09 Feb 2020, 16:33

Ablu wrote:
09 Feb 2020, 10:26
jesusalva wrote:
09 Feb 2020, 04:14


a. I believe tales-client uses an outdated version of our own client-data files. So it should mostly work.
The Mana Server does not differ between client and server data. The files are shared. Thus the format only shares the XML structure, but the content will differ. But the parsing logic is fairly decoupled and could be exchanged. But this is not really a thing about newer or outdated files, things are simply different. I would advise that you try to understand how stuff on the Mana Server rather than trying to bend things into the way they worked for TMW in the past.

Regards,
Ablu
I probably removed from my italic text but now I'm regretting it.
What I deleted was about how after splitting from Mana Source both followed their own ways etc.,
but I feel like that argument would be wasted.
Thus I stop commenting here.
Jesusalva (aka. Jesusaves)
User avatar
tomminator
Developer
Developer
Posts: 90
Joined: 18 Oct 2008, 18:27

Re: [REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by tomminator » 15 Feb 2020, 11:38

So lets try to get this ball rolling!

I used protocol.h as a starting point and looked at where it is used everywhere. Presuming all the network related code depends on protocol.h

These files depend on protocol.h:

/tales-client/src/mana/gameclient.cpp
/tales-client/src/mana/messagein.h
/tales-client/src/mana/chatclient.cpp
/tales-client/src/mana/accountclient.cpp
/tales-client/src/mana/messageout.h
/tales-client/src/mana/being.h

I presume if we are going to implement a lib for the network api we have to modify these files to make use of this lib

The following files have protocol.h as an #include, but as far as i can see the don't make use of it:

/tales-client/src/mana/resource/attributedb.h
/tales-client/src/mana/inventorylistmodel.h
/tales-client/src/mana/character.cpp
/tales-client/src/mana/resource/hairdb.h
/tales-client/src/mana/resource/itemdb.h
/tales-client/src/mana/resource/monsterdb.h
/tales-client/src/mana/resource/npcdb.h
/tales-client/src/mana/resource/racedb.h
/tales-client/src/mana/resource/spritedef.h

I removed #include "mana/protocol.h" from them and compiling works.

the following files depend on protocol.h for the declaration of 'ValueType':

/tales-client/src/mana/messageout.h
/tales-client/src/mana/messagein.h


maybe we can declare 'ValueType' in another header file? This would make only the following files dependent on protocol.h and perhaps needs refactoring for the network lib.

/tales-client/src/mana/gameclient.cpp
/tales-client/src/mana/chatclient.cpp
/tales-client/src/mana/accountclient.cpp
/tales-client/src/mana/being.h

Would this be a good starting point?
This is not a placeholder
Ablu
Novice
Novice
Posts: 286
Joined: 23 Jul 2011, 09:31
Location: Germany

Re: [REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by Ablu » 15 Feb 2020, 11:54

The protocol.h is mostly copied from the manaserv code base and ideally should stay that way. MessageIn and MessageOut are also very manaserv specific. What you probably want to do is to separate the network handling from the view model functionality in the *Client classes. Then the hercules lib could reimplement the clients and the models would be shared (they would not depend on the protocol any longer).

Being only depends on the protocol for things like direction and gender. That could easily be refactored, but again splitting the *Client classes into network handling and view models would be the largest work. Feel free to join #mana on freenode to discuss stuff :)

Regards,
Ablu
User avatar
tomminator
Developer
Developer
Posts: 90
Joined: 18 Oct 2008, 18:27

Re: [REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by tomminator » 22 Feb 2020, 15:40

Ablu wrote:
15 Feb 2020, 11:54
What you probably want to do is to separate the network handling from the view model functionality in the *Client classes.
so for example

Code: Select all

void GameClient::authenticate(const QByteArray &token)
{
    // Send in the security token
    MessageOut msg(Protocol::PGMSG_CONNECT);
    msg.writeString(token, 32);
    send(msg);
}
would be replaced by something like: (following code is pseudocode since i don't have experience coding c++/qt yet)

Code: Select all

void GameClient::authenticate(const QByteArray &token)
{
    // Send in the security token
    if servertype == tales{
        tales::authenticate(const QByteArray &token); 
        }
    if servertype == hercules{
        hercules::authenticate(const QByteArray &token); 
        }
}
and then tales::authenticate() would be

Code: Select all

void tales::authenticate(const QByteArray &token)
{
    // Send in the security token
    MessageOut msg(Protocol::PGMSG_CONNECT);
    msg.writeString(token, 32);
    send(msg);
}
and hercules::authenticate() would be

Code: Select all

void tales::authenticate(const QByteArray &token)
{
    // Send in the security token
    // hercules specific code
}
and the tales and hercules functions would be in their seperate *.cpp? maybe even in separate directories?
Ablu wrote:
15 Feb 2020, 11:54
Feel free to join #mana on freenode to discuss stuff :)
my name on irc is toams, I like irc but for longer questions like this i think forums are better :-)

maybe its better if you separate one networking function as an example? so i can base my work on that? only the tales specific part would be enough.
This is not a placeholder
Ablu
Novice
Novice
Posts: 286
Joined: 23 Jul 2011, 09:31
Location: Germany

Re: [REQ] Another alternative client (Difficulty 5/5 Team-Sized)

Post by Ablu » 22 Feb 2020, 20:32

Hi,
tomminator wrote:
22 Feb 2020, 15:40
would be replaced by something like: (following code is pseudocode since i don't have experience coding c++/qt yet)

Code: Select all

void GameClient::authenticate(const QByteArray &token)
{
    // Send in the security token
    if servertype == tales{
        tales::authenticate(const QByteArray &token); 
        }
    if servertype == hercules{
        hercules::authenticate(const QByteArray &token); 
        }
}
You would not want to add if statements for each type. Instead one would simply add a separate QML Object called "HerculesGameClient" maybe. This would be a class in a separate lib which is exported as QML module which can then be used instead of the GameClient of the mana package.

The class names can then simply be exchanged at https://gitlab.com/tales/tales-client/- ... qml#L42-87 (or the equivalent location in the potential TMW-Client code). So essentially one would use QML for dependency injection. However, currently the GameClient also handles logic stuff which is network independent. So that would need to be refactored out of the class to a more generic place.
tomminator wrote:
22 Feb 2020, 15:40
maybe its better if you separate one networking function as an example? so i can base my work on that? only the tales specific part would be enough.
As I said, I think it is more about splitting the non-network related stuff out of the *Client classes. There would need to be a defined interface to the game logic which is not depending on the actual protocol. If you do not fully understand what I am saying it may be the simplest solution if you try to implement the Hercules networking by simply replacing the existing *Client classes (without changing the interface to other classes! (so only add new classes for utilities, but do not do major changes to any other files). That would be a "quick" proof of concept and would be easy to turn into the library format that I am intending :)

Regards,
Ablu
Post Reply