• 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!

Suggestion New prefixes for support threads - Canary, Otservbr-global

Michael Orsino

Premium User
Premium User
Support Team
Joined
Nov 15, 2007
Messages
854
Solutions
10
Reaction score
389
Location
Santiago, Chile (Australian)
Pretty straight forward suggestion - implement new prefixes "Canary" & "Otservbr-global" for the support board.
The Canary gameserver and Otservbr-global datapack are not entirely inter-compatible with TFS - adding these prefixes would help both those seeking support and those offering it.

Inspired by this discussion thread

Updated 04/12/2023:

Bumping this feedback thread for further consideration.

I'm still not sure what the best overall approach is, but this is the state of play as I see it:
  • TFS & Canary are becoming less inter-compatible;
  • The user base of Canary is ever expanding;
  • Providing support for Canary often requires somebody with specific experience with that engine;
  • Being able to filter by the Canary engine would increase visibility for those willing & able to offer that support

As Don pointed out, prefixes are already somewhat problematic, however, in lieu of any better system currently available, I recommend introducing a "Canary" prefix.
 
Last edited:
Lol I was just making a thread like this. Damn you.

But yes, from what I'm hearing (and have seen) this is desperately needed, since it confuses people trying to help and wastes a ton of time having to reformulate solutions because the thread creator assumed TFS cause that's all that's "allowed" on the Support forums based on the available tags.

Most people with little knowledge of the difference between TFS and OTBR would look at the forum tags and probably just go "Oh they don't list otservbr, but otservbr makes references to TFS, so I guess TFS is the core or alternative name? Ok. Hi I need help with TFS!".
 
UNPOPULAR OPINION:

my suggestion is prohibiting otbr support at all, they like to give/recommend support by discord only, and bash tfs/staff :) if users want otbr support they can just go to https://forums.otserv.com.br/ or discord and receive support there.

yeah I know we are otland and not tfsland, but canary/otbr is a totally different/specific thing, only otbr staff themselves knows how that engine work, otland forum might be their highest source of visits, but what do they give in return other than support threads that the community can't help and an engine users can't run eventcallback scripts unless they learn how to convert them? 🤔

please no drama
 
UNPOPULAR OPINION:

my suggestion is prohibiting otbr support at all, they like to give/recommend support by discord only, and bash tfs/staff :) if users want otbr support they can just go to https://forums.otserv.com.br/ or discord and receive support there.

yeah I know we are otland and not tfsland, but canary/otbr is a totally different/specific thing, only otbr staff themselves knows how that engine work, otland forum might be their highest source of visits, but what do they give in return other than support threads that the community can't help and an engine users can't run eventcallback scripts unless they learn how to convert them? 🤔

please no drama

That's also an option, especially if it's true that they sit on Discord and crap on TFS/staff.
But the question is... wouldn't that put more strain on the moderators?

Having to delete + warn everyone who plops in and goes "Hi, support otservbr, yes" and redirect them to the relevant forum or discord would take up a lot more time and effort than just adding support tags and just let people do their thing.

Sure you could probably set up some kind of automated thread rejection if it contains the words "otservbr" or "otbr", but that would just encourage people to say "TFS" instead, and thus we're back to the original problem of a long thread where after 5 non-working solutions they admit they're actually using "🅾T🅱® sorry I can't write that word it's blocked or something".

Definitely a bit of a 🤔 situation...
 
UNPOPULAR OPINION
Personally I think we should just let people choose if they want to offer support for canary/otservbr-global
Those who can and/or want to will, those who can't and/or don't want to won't - and everything is easier for everybody. Nobody loses and we certainly don't continue to fuel division in our already small community.
 
The problem with prefixes is that:
  1. some are overlapping but you can only pick one, e.g. most of all "Lua" prefixed issues should also choose the engine prefix but you can only pick one
  2. We can't possibly have prefixes for all engines that exist
  3. Historically, threads weren't prefixed properly for a while
  4. Tags can be used in addition to prefixes and multiple can be used, but it's free-form and not useful either
The main advantage of prefixes is that as a Q&A board, the "Solved" prefix is what is being used for the actually solved threads.

I - for one - don't know what is the difference between otbr and canary? Do they need two prefixes?

my suggestion is prohibiting otbr support at all, they like to give/recommend support by discord only, and bash tfs/staff :) if users want otbr support they can just go to OTServ Brasil - O seu Portal para o mundo OTServ! (https://forums.otserv.com.br/) or discord and receive support there.
Here we don't cater to the "developers" at otbr, we cater to users who choose Otland to learn and ask questions, so nobody is benefitting from us prohibiting support on any topic. I don't see a reason to do that, worst case someone doesn't get an answer at all, because we also can't force anyone to answer a question :)
 
UNPOPULAR OPINION:

my suggestion is prohibiting otbr support at all, they like to give/recommend support by discord only, and bash tfs/staff :) if users want otbr support they can just go to https://forums.otserv.com.br/ or discord and receive support there.

yeah I know we are otland and not tfsland, but canary/otbr is a totally different/specific thing, only otbr staff themselves knows how that engine work, otland forum might be their highest source of visits, but what do they give in return other than support threads that the community can't help and an engine users can't run eventcallback scripts unless they learn how to convert them? 🤔

please no drama
this is indeed an unpopular opinion, first of all because it might be the opinion of you (and your friends who blindly agreed instead of thinking in what they are agreeing with) and secondly because it's also a lie(?).
We already explained several times why we don't refer to otland for support, but basically the problem is how the project is treated here. I already explained inumerous times how the project began and what is our objective but despite you saying that you understand the sad truth is that you can't, mostly because you don't want to understand it as it's too comfortable being just a hater.
Even so, every now and then when we see a post we reply ourselves, so don't need to be bothered at all. Most of the times all you do is commenting "yea, this base is shitty and bugged", don't bother man... you will be doing us all a favor and you can "unburden" yourself from supporting canary/otbr.

Now, we never bashed tfs/staff, quite the opposite actually. We recognized the project and the several contributions that happened in TFS base, but the thing is that the devs are too egocentric to admit something is right unless they have come up with the idea themselves. What was the alternative? Fork and work in our own base.
Canary is not that different from TFS, actually most of the issues we have are common, but when we modified the base it's when we figure out some parts of the source were hanging by a thread (literally sometimes). The moment you understand that, everything will be better.
The code is open, everything is documented, including the roadmap. We have very detailed tutorials and discussion on why things are being done one way vs. another, including half of the contributions from you and marcopires in tfs are actually cherrypicks from the base. You want the project banned from here so you can cherry pick without people realizing that?

Lastly, eventcallback was not added because I program Lua 16 years and I failed to understand this particular design choice. If you can enlighten me with your rationale on why this is better than just revscripting I'm all ears. Plus, you can easily convert the events to a non-eventcallback format, if you want I can give several exemples, or even better, port all events to otbr.. who knows?
Post automatically merged:

I - for one - don't know what is the difference between otbr and canary? Do they need to prefixes?
canary is the engine, otservbr the datapack.
You can run canary without otservbr, with its own "minimalistic" map and datapack
 
The problem with prefixes is that:
These are good points - perhaps a more robust solution to the overall problem here would be using the 'custom thread fields' feature.
  • Drop all engine prefixes (remove tfs, client, aac)
  • Bolster language prefixes (add php, js)
  • Include new custom thread fields for structured but optional relevant specifics like engine
 
Bumping this feedback thread for further consideration.

I'm still not sure what the best overall approach is, but this is the state of play as I see it:
  • TFS & Canary are becoming less inter-compatible;
  • The user base of Canary is ever expanding;
  • Providing support for Canary often requires somebody with specific experience with that engine;
  • Being able to filter by the Canary engine would increase visibility for those willing & able to offer that support

As Don pointed out, prefixes are already somewhat problematic, however, in lieu of any better system currently available, I recommend introducing a "Canary" prefix.
 
Back
Top