• There is NO official Otland's Discord server and NO official Otland's server list. The Otland's Staff does not manage any Discord server or server list. Moderators or administrator of any Discord server or server lists have NO connection to the Otland's Staff. Do not get scammed!

How to remove duplicate data dependency OTClient / TFS 1.3

Togu

Advanced OT User
Joined
Jun 22, 2018
Messages
308
Solutions
1
Reaction score
178
Location
Brazil
For example:
We have modules/gamelib/spells.lua in OTClient with all spells information.
And in TheForgottenServer we have data/spells/spells.xml with the same information.

If you change on server, you have to manually change on client.

How do I remove that duplicated data?

I know how to send and parse info from server to client, one approach I thought was send all spell data at the moment of the login and store on client. But I don't know if this is the best approach.

The other I thought was copy spells.xml and paste on client and make the client read the .xml file. But I don't know how to do that, maybe it will need to compile client with a xml library (?).
 
First approach could work. You would need to investigate about performance, and maybe version it, so the client only updates the information once per version change... It would be similar to a centralized API....

So, everytime a new client logs into the server, the server sends all the information about spells and saves it locally. And unless there is a change in the server's file, it wont be downloaded again.
 
Send thru protocol for each player or parse data from website, php file for example. Parsing from site is better option.
 
Then you still have the spells duplicated in both server and website
No, „parsing” does not mean downlaod php file, you can get server spells file thru aac via sending request to php file which will output the data, just like aac has the ability to parse config.
 
No, „parsing” does not mean downlaod php file, you can get server spells file thru aac via sending request to php file which will output the data, just like aac has the ability to parse config.
??

I know what parsing means. But what the points of getting the spells parsed on the website if he wants the spells in the OTClient?
 
??

I know what parsing means. But what the points of getting the spells parsed on the website if he wants the spells in the OTClient?

otclient load spells from website
website load spells from spells.xml (the same file)

You update spells.xml, website automatically parses the new file, otclient gets the new file.
The web basically acts as a proxy for spells.xml to your client.
You still need to parse the xml file on the client though (unless you decode and encode it into a different format on website), but you don't have to occupy the TFS process thread (and potentially cause lag in-game) while sending the file.

Why parse spells.xml on web if he wants it in otclient?
Send the file without interrupting TFS process
Potentially transform it into a better format for otclient
Make spells.xml publicly available, without duplicate content.

This is a bit tedious, but I think its our best option until Asynchronous HTTP API with lua bindings is merged.
 
Last edited:
I'm glad to see so many detailed answers, I'm learning a lot. This ZNote's answer up here make a lot of sense but I'll have to investigate and study a lot to implement these things I guess (or not). I'll check later. Thanks!! And keep the discussion going haha
 
To avoid sending the same file over and over again to otclient, the otclient can pass along its current version to this web proxy.
The web proxy then determines if your version is below the latest version, if it is then respond by sending spells.xml, else return an empty OK response.

The client can then see if it loads a new file from web service (or get an empty responsse), if it gets a new file, then increase the internal version number and store the file locally to load up the next time you start the client and retrieves an empty response from the web proxy.

If you use Znote AAC, I can write a simple API module for you that handles the web side of things. But im not sure what the best approach is on the otclient side of things.
 
I see your point now, i think i was understanding a different thing.

The async thing is a feature that will open a lot of possibilites When done...

And as you say, at the moment i see this solution as a very good option.
 
Back
Top