[Discussion] TFS direction (to do list/new milestones)

[zbizu]

Since it quite doesn't fit issue format, I'm posting it here.

We had a rough week discussing the client and how fixes should be shared, now what about the server? I think that we need a solid to do list that won't be just 2 positions unchanged for years or just a link to issues.

Now you may think that pushing tfs forward is not worth it when otx/that global project is ahead, but remember which repo is their server based on.

Another thing regarding otx: I want to remind you that both projects are open source so it's not a shame to copy a fix from another open project that is based on ours if that leads to improving both. We're a community after all and authors can be credited in commit description. Don't worry, we aren't leechers - our improvements that don't come from them get added to their project eventually so the progress can be mutual.

I feel that we're lacking a direction and at least some user to job list (eg. users a, b and c will code, d and e will do tests, f will control code quality, something like that).
Please take this one seriously. While I understand that we're an open community and everyone can contribute any part, I think that a bit of formal approach could move our project forward.

It's much easier to get work done when we say "you, go do it" instead of "somebody should do it". Of course ideal solution would be "I will do it", but it leads to one person doing a lot and burning out very fast due to lack of any help or recognition, therefore I'm inviting everyone, especially people who have write access to TFS repo to write their thoughts here.

I would also like some short list of

• which things should be done (absolute high priority)
• which "jobs" are needed in tfs repo (so we can create a list of people who would be willing to help). Personally I think that we need more reviewers.
• what is holding us back from moving to client version 12 support? Is that otclient?

 

[Nekiro]

Start reviewing pending pull requests and thats enough.

 

[Yamaken]

Yeah otclient do not support any protocol above 10.98.
I believe we should not update TFS to support a protocol beyond 10.98. Why? TFS main repo should focus on performance, security, stability, key features(like revscriptsys) and so on and supporting a new protocol means it needs to support even more Tibia features which people may disagree or not on the implementation and more discuss/work will follow. I believe those that want to run tibia 12 otservers should make it by themselves(opensource or not) while the main project focus in key things that benefits everyone(like people doing custom rpgs, franchise related servers like poketibia, dbo, etc).

 

[Diarreamental]

but

Yeah otclient do not support any protocol above 10.98.
I believe we should not update TFS to support a protocol beyond 10.98. Why? TFS main repo should focus on performance, security, stability, key features(like revscriptsys) and so on and supporting a new protocol means it needs to support even more Tibia features which people may disagree or not on the implementation and more discuss/work will follow. I believe those that want to run tibia 12 otservers should make it by themselves(opensource or not) while the main project focus in key things that benefits everyone(like people doing custom rpgs, franchise related servers like poketibia, dbo, etc).

those are more features that could be handle that lready are being handled in otcv8 ? and that could also work in any other custom rpg with features take from tibia.. tibia has taken many features from others games
something like enable /disable it at config lua should work pretty well in order to achieve this , i think

 

[Yamaken]

but

those are more features that could be handle that lready are being handled in otcv8 ? and that could also work in any other custom rpg with features take from tibia.. tibia has taken many features from others games
something like enable /disable it at config lua should work pretty well in order to achieve this , i think

We don't count with otclientv8. My main argument its wasted dev time to focus on tibia specific things while we can focus in improve the engine in general so everyone can enjoy a decent and stable base engine(and if people want to have a complete tibia server, they will find it in other repos or they will do it on their own).

 

[Night Wolf]

I'm currently in contact with some devs I know and the otservbr team (12.31).

Some of us (me included) will donate the full sources of our projects in order to compare what we have done and merge the fixes/improvements within otservbr github opentibiabr/otservbr-global (https://github.com/opentibiabr/otservbr-global).

Once this is done, since this github is also tfs based, we can pass the changes also to tfs in a safer way than doing it directly.

Post automatically merged: Apr 26, 2020

I also intend to find someone willing to do a similar thing with an otclient my team have been developing in the past 2 years. Basically we did lots of fixes and improvements, but we also broke some things so it would require someone that knows otc to merge the improvements (and possibly the dark Tibia-like UI)

 

[Yamaken]

And if it was my call(i would do this for a brand new engine), the protocol version and the targeted game features should be 7.7 and not 10.98.

 

[zbizu]

And if it was my call(i would do this for a brand new engine), the protocol version and the targeted game features should be 7.7 and not 10.98.

why would we do such hardcore downgrade? That would mean removing mounts, market and other things.

 

[Evil Puncker]

my proposal was:
lets keep both 10.98 and 12/11 support (as many server have success using both 10 and 12 version together)

and start adding the 12/11 features (development) while still having 10.98 support (stable), and once everything is stable on the 12 side, we just ditch the 10.98 support... but as @Mark said a long time ago, for this we first need to update OTC to support any client higher than 10.98

 

[zbizu]

@Evil Puncker
you mean two branches or one supporting both?

 

[Evil Puncker]

@Evil Puncker
you mean two branches or one supporting both?

one branch just like otserbr (used?) to support both 10 and 12 client login

 

[gudan garam]

I completely agree with @Yamaken, but I don't think we should downgrade to 7.7 version.

I also don't think we should keep updating the protocol without fixing already known issues and testing/merging things such as gesiors binary items save and cache. TFS has a lot of known performance issues (open issues on github) that I'm pretty sure a lot of people have already fixed.

New protocol versions would be nice but TFS was made to be compatible with OTC, as much as I would like to have latest protocol support, I don't think it should be done without a client other than CipSoft's and without a bunch of fixes that we all know should have already been merged.

Things I think should already been looked into:

getSpectators
checkDecay
checkCreatures
item::canDecay
Players login/logout with too many items (gesiors fix)
PathFinding
High Memory Usage - OutputMessageAllocator!
Why don't we have a cast system yet?
MoveEvent::onRemoveItem: Stackoverflow · Issue #1893 · otland/forgottenserver (https://github.com/otland/forgottenserver/issues/1893) (this one I took at random just so we appreciate 2016 bugs not being resolved)

I think people look at big playerbase servers with version 12x and think the only thing they need is the protocol. Let me tell you boys, you need way to many things before that.

 

[zbizu]

Why don't we have a cast system yet?

the proposed pull requests were either unstable or not meeting TFS quality standards

Cast system by viperthepala · Pull Request #973 · otland/forgottenserver

Cast system version 0.1, its not completed yet. It bugs on logout if there are viewers. ifdef CAST_SYSTEM if (clients.size() > 0) { for (auto& client : clients) { <----- client->logout(...

github.com

Casting system by djarek · Pull Request #994 · otland/forgottenserver

Closes #984 As for the internal details: broadcasting is done by the ASI/O thread. The dispatcher thread does only one additional copy (it is required, as the ASI/O thread receives the message obje...

github.com

Cast system, 10.99 support and premium display in character list fix. by Milice · Pull Request #2001 · otland/forgottenserver

I have added a cast system fully compatible with tfs 1.3, with multiple chat commands including but not limited to /kick, /togglechat, /ban, etc. I also have changed the definitions to support logi...

github.com

Cast system by Milice · Pull Request #2007 · otland/forgottenserver

Hopefully this cast system will be acceptable.

github.com

 

[gudan garam]

the proposed pull requests were either unstable or not meeting TFS quality standards

Cast system by viperthepala · Pull Request #973 · otland/forgottenserver

Cast system version 0.1, its not completed yet. It bugs on logout if there are viewers. ifdef CAST_SYSTEM if (clients.size() > 0) { for (auto& client : clients) { <----- client->logout(...

github.com

Casting system by djarek · Pull Request #994 · otland/forgottenserver

Closes #984 As for the internal details: broadcasting is done by the ASI/O thread. The dispatcher thread does only one additional copy (it is required, as the ASI/O thread receives the message obje...

github.com

Cast system, 10.99 support and premium display in character list fix. by Milice · Pull Request #2001 · otland/forgottenserver

I have added a cast system fully compatible with tfs 1.3, with multiple chat commands including but not limited to /kick, /togglechat, /ban, etc. I also have changed the definitions to support logi...

github.com

My question persists, why do we still not have a cast system?

Why the hell do all the live servers have it and the main source code doesn't?

Doesn't make sense to me. I'm not being salty or anything I'm just putting it out there so we think about it, not especifically cast system but things in general.

Why do all TFS based live servers have things that TFS itself doesn't? Basic stability things.

 

[Night Wolf]

@Lyu your server has one of the best casts out there, did you bought it or done yourself? mind sharing a few insights?

 

[gudan garam]

Also, wouldn't it be nice for otland itself (maybe high moderators and github contributors) to host a live server? Idk if a server focused on players, but lets have a live TFS latest version server so we can test everything as community. I think it would be cool, so we can have multiple people testing shit that normally no one wants to test because the don't have everything set up.

 

[Yamaken]

Yeah i'm not saying there should be a downgrade. I'm saying less game features means we can focus on the core issues/improvements. @gudan garam post explains even better what i meant before.

 

[Night Wolf]

Also, wouldn't it be nice for otland itself (maybe high moderators and github contributors) to host a live server? Idk if a server focused on players, but lets have a live TFS latest version server so we can test everything as community. I think it would be cool, so we can have multiple people testing shit that normally no one wants to test because the don't have everything set up.

I find this idea very nice but it would require to constantly rebuild source and re-open it after each commit to always stay 'fresh'
@Don Daniello would it be a viable option for the team to have? We could have some automatic bashes for recompiling upon any commit merged in src in order to avoid manual work. Then we would know everyday in the server save it would be 'refreshed'

 

[zbizu]

I find this idea very nice but it would require to constantly rebuild source and re-open it after each commit to always stay 'fresh'

not really, just a script that does this every 24 hours if there were new commits on github:

- download and compile newest build in repo directory
- copy changes to server directory
- copy datapack changes to server directory (overwrite existing files)
- restart server once everything is done

automated maintenance warning message could be broadcasted like server save
it only requires 3 folders:
1. server folder
2. repo folder (where git changes will be downloaded and shit compiled)
3. a folder with things we changed in datapack (config.lua, game map, etc)

 

[gudan garam]

not really, just a script that does this every 24 hours if there were new commits on github:

I find this idea very nice but it would require to constantly rebuild source and re-open it after each commit to always stay 'fresh'
@Don Daniello would it be a viable option for the team to have? We could have some automatic bashes for recompiling upon any commit merged in src in order to avoid manual work. Then we would know everyday in the server save it would be 'refreshed'

This is what CI/CD does, dont complicate it.

I don't think it would be a good use case though. Knowing that there would be people testing stuff and simply restart the server. Deploys could be half automated but started manually.