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

When will TFS 1.4 be released?

Status
Not open for further replies.
is like iPhone, miss the version numbers? hahaha 1.2 to 1.4
 
Last edited:
First you'll have to get 1.3 out before even thinking about releasing 1.4
 
Are they going the same stupid versioning route as phone makers where they randomly decide to skip increments? Same shit goes for Microsoft with Windows too
Why should 1.3 release be called 1.3 at this point when it's been so long in development? When people say 1.3 nowadays you have absolutely no fucking clue which point in the development cycle they compiled 1.3 at, you have no idea what's been fixed or implemented. At least making it 1.4 as release, when people say 1.4 you know they'll mean the release version instead of the development version.
That's the logic behind the new version system.
 
danger island fall GIF by Archer
 
Are they going the same stupid versioning route as phone makers where they randomly decide to skip increments? Same shit goes for Microsoft with Windows too

We call the next tagged release TFS 1.4, not 1.3. Making version (1.2, 1.4, 1.6) officially tagged releases, and odd versions (1.3, 1.5, 1.7) development versions.

That way, when people say "I use TFS 1.3" then we know they refer to this development phase (which could mean they have a compiled server anywhere between 2016 - 2020). When they say "TFS 1.4" we know they refer to the official release (or based). When they say "TFS 1.5" we know they refer to the next dev phase. etc

Tagging the next version TFS 1.3 would be a major headache since there has been so much implemented since 2016, and we have no idea at what point in the dev cycle they refer to, or if they refer to the official release.

I hope our TFS version logic is not something people consider as "stupid", to me it makes sense and add more clarity at least.
 
Last edited:
We call the next tagged release TFS 1.4, not 1.3. Making version (1.2, 1.4, 1.6) officially tagged releases, and odd versions (1.3, 1.5, 1.7) development versions.

That way, when people say "I use TFS 1.3" then we know they refer to this development phase (which could mean they have a compiled server anywhere between 2016 - 2020). When they say "TFS 1.4" we know they refer to the official release (or based). When they say "TFS 1.5" we know they refer to the next dev phase. etc

Tagging the next version TFS 1.3 would be a major headache since there has been so much implemented since 2016, and we have no idea at what point in the dev cycle they refer to, or if they refer to the official release.

I hope our TFS version logic is not something people consider as "stupid", to me it makes sense and add more clarity at least.
I dont like that versioning convention to be honest, but i get your point.
 
Show your better versioning convention that you actually like. I want to see it
I didn't say i had one better for this purpose and how things has been done till now, i said i dont like it.

If all the versioning were done better since 1.X started, the minors version could only be used for real stable versions (1.2, 1.4) and you could use the patch number when adding important and relevant stuff (development versions)

That way we would probably be now releasing 1.2.0, but had 1.1.1, 1.1.2, 1.1.3.. .whatever.

I know this requires working with more iterations in the codebase and someone deciding when to cut and create new patch version. But i really think would be better.
 
I didn't say i had one better for this purpose and how things has been done till now, i said i dont like it.

If all the versioning were done better since 1.X started, the minors version could only be used for real stable versions (1.2, 1.4) and you could use the patch number when adding important and relevant stuff (development versions)

That way we would probably be now releasing 1.2.0, but had 1.1.1, 1.1.2, 1.1.3.. .whatever.

I know this requires working with more iterations in the codebase and someone deciding when to cut and create new patch version. But i really think would be better.

We can do that while still using our versioning convention, I think most of us agree that there have been way to long since last official release, and doing sub-releases is a good thing. Nothing is set in stone, but hopefully we will be able to come up with a sub versioning system after 1.4(.0), to prevent this 6 year release gap from happening again.
 
Ok so let's break it down:
  • creatures stacking - ready, needs testing only
  • monsters pathing/isSightClear - WIP, but solution was found and it moves forward fast now
  • scheduler timers - what's going on there? I have no idea what they talk about. How far is it from being finished? Explain it to me like I'm 5
 
Ok so let's break it down:
  • creatures stacking - ready, needs testing only
  • monsters pathing/isSightClear - WIP, but solution was found and it moves forward fast now
  • scheduler timers - what's going on there? I have no idea what they talk about. How far is it from being finished? Explain it to me like I'm 5
Here are my thoughts, keeping in mind that I'm too stupid to comprehend smart C++ stuff, and I havent played cip tibia in 10 years. (thus unable to properly contribute to behavior testing).

creatures stacking - Wrong OTC behavior, otland/otclient needs to be patched to account for creatureindex -1 (display in battle list, dont render on screen), currently it throws an error (according to feedback)?
- otbr had a issue with the client 12 patch I submitted to their repo (to test client 12 behavior to confirm native 10.98 client bug) and reverted it because it caused a crash on rare occasions on some populated monster locations, they blamed my PR (which hopefully was just a bad stitch of git conflicts), but the fact is we havent "battle tested" this properly on our repo, so there might be a crash bug ghost in there somewhere.

This needs extensive testing, I'm considering trying to spin up a vanilla TFS server public to try to get this tested properly (And perhaps do some last datapack finetuning). I think I have push access to this in case we need to add a patch, slavidodo is unfortunately no more.

I might be forced to look into otclient, I have never used it properly, don't understand the source and have never compiled it from source before, so I really don't want to be the one to fix it. (But I might not have a choice if everyone feels the same). I was really hoping some of our OTC brain guys who have epic custom clients and so on could have a look at this, considering their extensive knowledge of the client.

monsters pathing/isSightClear - Need testing, the devs seem to be in algorithm deadlock and doesn't quite seem agree on provided solution

scheduler timers - Not sure whats going on here, some sort of big brain code that seems to have an overall performance gain? :p Code seems solid but the developer hasn't taken care of review feedback so its stalled until he do or we decide to postpone it. (Which we are very hesitant to do, sounds like it would be perfect for 1.4). Read something about 25% performance gain, not sure if this is for isolated cases such as event edge cases, or in general. I also have no idea on how this can be tested properly.
 
Last edited:
monsters pathing/isSightClear - Need testing, the devs seem to be in algorithm deadlock and doesn't quite seem agree on provided solution
I talked with Nekiro on discord, he proposed Xiaolin Wu algorithm (and confirmed that it gives desired results after some adjustments), but the code itself has to be adapted to TFS. I agree on his solution if it helps. I will be looking into that algorithm tomorrow.
 
What is left for 1.4? I seen some people saying all the fixes for 1.4 are ready to be tested?
 
Status
Not open for further replies.
Back
Top