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

Theorizing a Modern Engine Design

I'm 100% in Nekiro's camp with No Python.

Well I kinda agree, but the problem is that you need to chose a language which is used a lot or atleast anything with a similar syntax or your contributions will suffer.
 
Well I kinda agree, but the problem is that you need to chose a language which is used a lot or at least anything with a similar syntax or your contributions will suffer.

Yep... I thought about this a lot over the past few weeks (And I don't mean specific to OT's, I mean at a global scale) and really dug on the topic hard. It was quite a little tangent for me after having a discussion in PMs with Edubart about Lua and it's future, instigated by that thread about Baron von 5KUSD Patchset. I probably annoyed all my friends with it, cuz it's all I would talk about. "What's going to be the next gluescript since Lua is fragmented and waning*?"

And no matter how much I tried to avoid it, it always came back to ECMAScript or "nearby". And that lead me down the rabbit hole of critically examining JS engines, and my god there are so many of them. So many. I even came across JS gluescript implementations I already knew existed, but it hadn't really "occured" to me that's what they were. And then I tried actually seeing what work would be involved in embedding one. DukTape and QuickJS make this easy, but neither are JITs, and DukTape's compliance with syntax sugar I'm already too fond of to part with is very poor. V8 is an absolute monster, and those who do battle with it are probably getting paid, cuz no one would do it for fun. The extant libs to make that easier are either dark sorcery or are meant for external binds.

The only other players in the JIT game are SpiderMonkey and Chakra. I won't touch SpiderMonkey myself for personal reasons, but did note there is a Rust crate ready to go for it. After a pit stop to marvel at just how amazing Fabrice Bellard is. Just omg, I moved on to Chakra. Chakra is the only hope for mere mortals who aren't willing to sacrifice their firstborn child and 30 pieces of silver to have a non-Lua JIT-backed gluescript, and if I were not so busy with so many other things aleady it's where I would be spending my FOSS effort, because it's now a product I believe in, filling a niche no one else is. (Yes I mean that. Yes I know about Angel and Chai.)

*: By waning, I mean in the same way Emacs and Perl are. Not really dying, but the golden years are past. Amazing, but not something most people are going to go out of their way to use and learn. Those who already know and love will probably take that all the way to the next life.
 
TL;DR: TFS structure is good, just lacks documentation and some improvements in areas where the calculations are really really expensive.
We still have bugs from years ago and for some of them you can easily find the answers in the forum but not in the repo.
Also we still have some crashes and with them item dupes. This can be easily avoidable if we manage to merge more of the cpp part to Lua and if we rewrite the save system to be something "on demand"¹

as @Lessaire pointed out, there is just a few small parts where I see the use of NoSQL being useful. NoSQL is indeed faster but is no different than caching things at Lua tables [key-value] and then just dumping on server shutdown... NoSQL in otherhand could be VERY USEFUL if we used it ALONG with mysql/mariadb to store user actions in real time. This could severely improve debugging and understanding what lead to crashes. This would also severely improve my source-side anti bot with Python, specially if I can create a callback to source after those scripts are run.

as @Lessaire also pointed out, our main goal now should be focusing to drop tibia client and improving the tibia tools. Specially RME and Object builder.

I'm trying to play with a few SinGANs to create sprites to replace the tibia ones since relying in the help of spriters to recreate 200k sprites isn't something feasible anymore. Having a client that could at least behave equally the tibia one should be a goal too, otclient still have some critical errors and otcv8 is not open source (also it has some critical errors too).

¹: One option to manage on demand saving could be to make a queue and inserting people on this queue based on some actions such as trading items or picking things from ground that previously had another owner (we could have an attribute 'last owner'). Since players would be flagged to be saved later, we also would need to cache their data and remove the saves onLogout and onDeath, but rather enqueue them upon those actions.
Since the queue is processed at once, you guarantee that all players would share the same state, plus, not being able to dupe items anymore.
 
I don't think that changing the programming language of our TFS engine is worth it at this point. A new language for scripting perhaps, but instead we should focus on having a functional OTClient (be it Slavi's, Edubart's or a completely new one). Dropping Cip client, tibia.dat & .spr and all the limitations that come with them would be the best thing thing to happen to OT ever.

This would do away with the community's unhealthy fixation with "Tibia versions", and the endless game of catch with Cip... do you want to make your server have a 7.x look? 8.x? 10.x? 12.x? just modify the easily readable & organized "spr/dat replacement" file. Do you want your server to have / not have features from certain versions? enable / disable said features in your config.

Basically, an engine & client which are fully integrated with each other and modular, where the term "Tibia version" is obsolete. Having a functional OTClient is imperative to be able to achieve this.
 
The idea of developing a new distribution is great. I’m all for it. As stated above, it may not be a good idea right now to completely flip the table.

I can’t help but wonder if it will ever be near TFS’s level of functionality based on people’s schedules, priorities, and lack of interest. We have to be honest with ourselves. Is starting anew going to be worth while? Will it fade out as so many projects have, including my own due to life and priorities of adulthood?

In my opinion, we may be better off transforming the current version of TFS into something better (as we have seen in the past). Start a new branch once 1.4 is released and have two: one continues as is and the other begins to change from within until it is something new entirely, and we hope for the best. Why take this route? Worst case scenario, it will benefit both branches of TFS regardless if the new one were to die out or become dormant as the new distribution is based off the old. Perhaps we could call it TFS 2.0?

Something we should, at the very least, consider.
 
I know that my opinion probably doesn't matter, since I'm not a programmer at all, but I think that its really a time that Otland staff should take some "lead" in probably upcoming wave of changes. I'm worried that many talented programmers like all of you will start bunch of different projects with the same goal and all of them will be abandoned.

But coming back to the main post, items.otb should be changed together with .spr. It's obviously easier to use spritesheets like Cipsoft but then .otb for TFS and RME needs a change too. It needs to be a complex solution.
Map chunks are not necessary in my opinion, more interesting feature could be "instances", instead of making huge maps in x,y dimensions, you could just go to a "level1" for example. Or when you want to generate random terrain/dungeon, you don't need extra space on your map, just make new instance. I know that there are floors, but imagine generating XX dungeons at the same time.
#edit and ofc possibility to edit the map ingame and save it, but in much more complex range than just saving everything dropped on the floor and added/removed structures. Like building house (physically, walls, door etc) and after that adding a house entity.
 
Last edited:
where the term "Tibia version" is obsolete

At which point it will be OpenUltima. The long game I've been playing this entire time.
D8fqR0MUcAAO-RH.png
 
Apologies for the late response; I haven't been at my computer for some time and replying on mobile would have been a pain.

Engine thoughts:
When Roslyn was released a few years ago it had me thinking it would be cool to see a c# engine with c# scripts. Roslyn has scripting APIs that allow it to run C# script files. I have made use of the scripting APIs at work to make a program which allowed scripts to be run at anytime dynamically. This allowed the hardware guys to right small scripts to control the hardware the program was written against. I was able to write some more advanced scripts for them with multiple threads and events.

Map thoughts:
stian created a (.sec) sector map format for use with PyOT. I believe it was 256x256 chucks of map. One cool feature was the use of a 4th dimension in the map format. The idea was to be able to control which instance was loaded via scripts or even add new instances. This would allow a town to be mapped with different weather conditions. On a time or event bases the map chunk could dynamically be changed in the server. The use of the 4th dimension allowed multiple instances of the same map to load in the same location. I think the idea was to be something like WOW raids. (never played WOW myself to know for sure). Where each group of players is in the cave in their own instance. I'm not sold about json format for the map but I do like the improve version control abilities but really who is going to be able to diff that in text format besides minor edits. A visual diff tool would be required and could be added to a map editor.

Item thoughts:
PyOT put all items in the database. I can't remember much else about items for pyOT. I don't know have an idea for a better item format but a single file would be preferred. Ideally a file that is human readable without another program. I find keeping items.xml up to date and remembering which items were customized a real pain. A good way to solve that would be two "item files" of the same format. One with the cipbia item definitions and another one for custom items which overrides the defaults.
I'm a huge fan of C# (in my top 3 languages along with C++ and Rust), and the idea of an engine written in C# along with scripts written in C# always interested me. With .NET Core being cross-platform, and generally faster/better than .NET Framework, this idea still interests me; as long as players don't ever feel the effects of the garbage collector. However, the community is so used to Lua that I would be surprised if a switch to a different scripting language would actually happen.

Instances would be cool, but the official Tibia client would need to be dropped in favor of an open-source client that could handle instances properly.
Thoughts in the pdf
I'm not sure I agree that Lua is that obscure. A LOT of companies, and not just gaming ones, use Lua.

To be completely honest, I'm just not a fan of Java. C# is basically a better, more user-friendly version of Java; in my opinion.

I'm not a fan of how a lot of engines support different client versions with if-statements. Sure, branch-prediction will cut a lot of time out once it realizes those if-statements always return the same value, but a processing cost still exists. I'd prefer versioning to be done with conditional compilation.

I pretty much agree with everything else in your document.
Great topic. I wish I were not on a phone or I’d share much more...

In my opinion, it would be beneficial - to OpenTibia as a whole - if the software were user friendly for Windows users as well. I know, Windows sucks... But it’s used by the majority and I don’t believe it should be a requirement for newcomers to know how to use Linux for them to be involved in OpenTibia and development. A lot of people I know are interested in this game but have no idea how to use a Linux OS, and quite frankly are not patient enough to learn how to do so. That’s how the new generation is. OpenTibia will be around for years and years, sure. How popular it will become is determined by how easily it is to enter. Minimal barriers to entry will be more inviting.
That's where something like Docker comes in handy, which TFS already uses for compilation. However, it could be made better by spinning up a database, a login server (if you're using 11.00+ protocol), and building/running the engine in a single command.
I'd love to see a C# .NET Core server. Yeah, its higher level and microsoft..
But yet, cross platform is easy now with Core.
Have you seen caioavidal/OpenCoreMMO (https://github.com/caioavidal/OpenCoreMMO?)
This has nothing to do with the software being unfriendly to Windows and everything to do with Windows being unfriendly to software. The developer toolchain is a 2nd class citizen on Windows. On Linux I can find an interesting syscall like this, find an example of it, and turn that example into a compiled binary in the PATH and usable by all users on the system is less than 2 minutes. Try doing that on Windows.



Oh god, I can't believe you seriously suggested MongoDB... please don't ever do that again. Mongo is never ok.

The rest of it... I like to ponder these things too. And do so often. But to be honest, just with the coders in this thread alone we could brew up new RFC-style specifications/standards for the whole stack, start a new server codebase from scratch, and get it up to passable usefulness in just under 4 months.

... and then we'd still be right where we are at now with the rest of the stack:

  • Look at the state of "open source spritepack". CipSoft may have no moral highground as they basically stole the entire skeleton of their game from Ultima 6, but this situation is not tenable forever.
  • Look at the state of the primary community client.
  • Look at the state of the map editor.
  • The object editor is built on dead tech, and a cursory glaces shows me the libs that underpin it are precompiled, which is a nuisance to porting.

But since some points were brought up that I have opinions on...

Java: Why? That just brings an air of souless corporate machinery. Switching to this gains you nothing. All the people who are excellent Java programmers, already code it all day at work, and do not want to look at more when they get home. The JVM is kicking ass, but the pure Java entry point is basically legacy and is floating on borrowed time. That's what Graal is all about. Now if you had suggested Scala and Akka I could understand but still, these are not things I would touch for "fun". C++, despite it's problems, isn't something that makes me sick to my stomach to look at after work.

ORM: This is how you royally tank your performance for almost nothing gained whatsoever. The translation between the type schema the engine uses internally and the persistence layer is already a solved problem. ORMs are invariably a pain in the ass layer that business uses because they have to and coders work on because they get paid to.

NoSQL: Like, it is rumored that every time you search "why MongoDB sucks" a computer in Google's datacenter catches fire, and that's why the results returned come as an integer and not infinite. The "No" in NoSQL is supposed to mean "Not only" but actually means '"No" good handling for typical SQL workloads.' in practice; which is why you will see the NoSQL engines that don't actually suck still paired with Postgres/MariaDB. However I can't really think of something OTs would need Elastisearch, Cassandra or Redis for, and that's the shortlist of ones that don't suck.

Rust: I like this idea a lot, if only because it mean using Javascript as gluescript is 100% feasible out of the box with this. Delicious heresy.

Item.xml + Item.otb being merged into a new format, and tooling the loader to allow overloading so projects can keep their custom items as a separated concern: This is precisely what I had already planned on doing myself. Aren't a significant amount of items.xml / item.otb the same across Tibia versions? It seems like if the item information packages were arranged like Master Set is some minimal version, like 8.0, and then overloaded by Set A is like 8.6, then overloaded by Set C and so on until you get to current Tibia version, it would be a lot easier to deal with. And if the client consumed the same or very similar file format? The community could claim some section of IDs of outside the range Cip is likely to get to soon and start collaborative item pack overload set. The server could also have tooling to make a "squashed" local copy so startup time isn't seriously hindered by doing the overloads on each startup.

The only thing I think the daemon is really missing is async event model and bindings for such in Lua. Some of it's there internally, but there have been many many times I thought to myself "God I miss EventEmitter" when doing something 20 LOC in Lua that would have been like 5 in Node. I've seen a few examples of this being pursued here on OTland, so I know it's in the pipeline but it's long overdue. I'm much more familiar with libuv than I am with Boost's ASIO, and if ASIO wasn't already what the other devs had pinned their hopes on I'd be working on integration of libuv right this second, because that would open up this for the gluescripters.

The Map Editor:

Anyway, as far as any map format ideas you guys have, I'm all ears, cuz replacing RME is a journey I've already dedicated myself to. Though, tbh, if I had to come up with my own format, I'd use 100% off the shelf: a tarball holding hjsons for spawns, houses, and metadata, and a zstd compressed protobuf for the map. A very programmer-centric format. Which is why I was probably just going to reuse OTBM and, as an optional thing, bump the version number add a "groupid" extension for items, since the group of users that just use multiple uniqueids in maps and ignore the errors that scrollby at daemon launch is rather large. So clearly uniqueid + actionid is not enough.

I really do like the idea of chunking up the map, and was already going to make my own tooling for it one way or another. I dunno if you guys remember, but before Menoxcide retired and transferred ownership of the FH dataset to me, he was betrayed by one of the other staff members because of lack of communications between the two of them, misunderstandings, and whatever else. Either way, that person leaked a copy of the dataset. However it had my work in it at that point, which I aggressively leveraged DMCA against everywhere. The cost in my time that little stunt sucked up I can never get back, and since then how to "componentize" the gameworld map is something I've thought about a lot, out of hard learned lessons on minimizing risk exposure to people protected from my wrath by oceans.

I think the real issue to be solved here is a workable scheme to abstract Position()s in the map chunks. Basically, the person working on the map chunk doesn't necessarily know where it will end up in the actual game world. Neither would the scripters making features for a particular map chunk. So I think a way for them to both collaborate and use waypoints, or some other similar abstraction layer, that basically become "Position symlinks" so that no matter where the map chunk gets deposited, scripts calling for positions in it still work.

Though I think duplicate unique ids in two different map chunks should 100% be a fatal error.

Once that's in place it's game on. Unfortunately, others have started to try to replace RME and it seems all gave up. I refuse that fate. Since Object Editor and Item OTB editor are some what in the same scope I may try to target them too. But I'm only one person and that means what really needs to be solved for the community now is the client, and I can't help there, because burn out is real, and I refuse that too.

Though, anyone who is working on such a thing, please please do yourself a huge favor and make it easy on me to help you when I am finally free to do so: imgui
How is Mongo never ok? Sure, it may not be necessary here, but it's definitely a great option in the right case. I can agree with the rest of your statement.
I agree a lot with what you said jo3bingham. The bare server itself should be coded in Rust to ensure no crashes, everything else should be done in a well-known scripting language which is more modern like julialang or python, also formats should be either json, bson or just basicly anything else which is standardized. I once translated the otb format into Rust (https://crates.io/crates/ot - Shawak/otbmview (https://github.com/Shawak/otbmview)) but it's hell of a mess and all these custom formats prevent developers to build their own engine (ofcourse thats not the only reason).
Rust won't ensure no crashes, but it does make it a lot harder to write unsafe code. I'll check your code at when I get time, I quite enjoy looking at Rust code.
I'm 100% in Nekiro's camp with No Python. The role of "gluescript" is mutually incompatible with languages featuring enforced whitespace. If I was gonna spend any amount of effort replacing Lua, I'd be helping the Chakra team, so I could use an ECMAScript JIT instead. (working with Google's V8 is unpleasant at best, so I really hope this is the direction Chakra takes now that it's been cast off since MS builds Edge atop Chromium. Seems like they are kinda planning on it.)

But if you guys are gonna target Rust, Rhai is just sitting there waiting for you.

Another thing to consider when trying to replace Lua with anything else is most of the pedestrian OT users that are gonna lay their hands on the gluescript are not real coders. And if you put in something that lacks (Ducky|Dynamic)-typing, they are gonna get frustrated. It's a trainwreck waiting to happen.
I agree with no Python (mainly because it offers no benefit over Lua), and I can agree with your last point.
I don't think that dropping Cipsoft client support is going to happen.
Unfortunately, I think you're right. And I think the reason for this is that the official client is recognizable; users are used to the look/layout and know how to use it. They get the same experience, more-or-less, between Open-Tibia servers and official servers when it comes to the client. Plus, for server developers, it's one less thing they have to maintain.
We should move on. Make OTC or Slavi unity client better than CipSoft client so we can make OT better than Tibia itself.
Nothing against OTC, but I think @slavi's Unity client is the way to go.
Python would be interesting. It’s a powerful language, easy enough to learn and similar to LUA.
Python is much slower and less readable than Lua (LuaJIT in this case).
I have to agree with @oen432 here. I can't think of any benefits that Python would offer that would be worth completely derailing the scripting language that the community is used to. Maybe if Lua was outdated and painfully slow, but that's not the case.
TL;DR: TFS structure is good, just lacks documentation and some improvements in areas where the calculations are really really expensive.
We still have bugs from years ago and for some of them you can easily find the answers in the forum but not in the repo.
Also we still have some crashes and with them item dupes. This can be easily avoidable if we manage to merge more of the cpp part to Lua and if we rewrite the save system to be something "on demand"¹

as @Lessaire pointed out, there is just a few small parts where I see the use of NoSQL being useful. NoSQL is indeed faster but is no different than caching things at Lua tables [key-value] and then just dumping on server shutdown... NoSQL in otherhand could be VERY USEFUL if we used it ALONG with mysql/mariadb to store user actions in real time. This could severely improve debugging and understanding what lead to crashes. This would also severely improve my source-side anti bot with Python, specially if I can create a callback to source after those scripts are run.

as @Lessaire also pointed out, our main goal now should be focusing to drop tibia client and improving the tibia tools. Specially RME and Object builder.

I'm trying to play with a few SinGANs to create sprites to replace the tibia ones since relying in the help of spriters to recreate 200k sprites isn't something feasible anymore. Having a client that could at least behave equally the tibia one should be a goal too, otclient still have some critical errors and otcv8 is not open source (also it has some critical errors too).

¹: One option to manage on demand saving could be to make a queue and inserting people on this queue based on some actions such as trading items or picking things from ground that previously had another owner (we could have an attribute 'last owner'). Since players would be flagged to be saved later, we also would need to cache their data and remove the saves onLogout and onDeath, but rather enqueue them upon those actions.
Since the queue is processed at once, you guarantee that all players would share the same state, plus, not being able to dupe items anymore.
That's an interesting use of NoSQL that I hadn't considered.
I don't think that changing the programming language of our TFS engine is worth it at this point. A new language for scripting perhaps, but instead we should focus on having a functional OTClient (be it Slavi's, Edubart's or a completely new one). Dropping Cip client, tibia.dat & .spr and all the limitations that come with them would be the best thing thing to happen to OT ever.

This would do away with the community's unhealthy fixation with "Tibia versions", and the endless game of catch with Cip... do you want to make your server have a 7.x look? 8.x? 10.x? 12.x? just modify the easily readable & organized "spr/dat replacement" file. Do you want your server to have / not have features from certain versions? enable / disable said features in your config.

Basically, an engine & client which are fully integrated with each other and modular, where the term "Tibia version" is obsolete. Having a functional OTClient is imperative to be able to achieve this.
I like this idea; choose the features you want your server/client to use and not worry about a "version".
The idea of developing a new distribution is great. I’m all for it. As stated above, it may not be a good idea right now to completely flip the table.

I can’t help but wonder if it will ever be near TFS’s level of functionality based on people’s schedules, priorities, and lack of interest. We have to be honest with ourselves. Is starting anew going to be worth while? Will it fade out as so many projects have, including my own due to life and priorities of adulthood?

In my opinion, we may be better off transforming the current version of TFS into something better (as we have seen in the past). Start a new branch once 1.4 is released and have two: one continues as is and the other begins to change from within until it is something new entirely, and we hope for the best. Why take this route? Worst case scenario, it will benefit both branches of TFS regardless if the new one were to die out or become dormant as the new distribution is based off the old. Perhaps we could call it TFS 2.0?

Something we should, at the very least, consider.
One of my main points, and something @Dkadsfe touched on, is that TFS's monolithic architecture makes it hard to make substantial changes to the core of the system. Again, TFS is great at what it does, but forking it with the goal of creating a "TFS 2.0" that would be entirely new over some time would take more time than starting fresh. But that's just my opinion.
I know that my opinion probably doesn't matter, since I'm not a programmer at all, but I think that its really a time that Otland staff should take some "lead" in probably upcoming wave of changes. I'm worried that many talented programmers like all of you will start bunch of different projects with the same goal and all of them will be abandoned.

But coming back to the main post, items.otb should be changed together with .spr. It's obviously easier to use spritesheets like Cipsoft but then .otb for TFS and RME needs a change too. It needs to be a complex solution.
Map chunks are not necessary in my opinion, more interesting feature could be "instances", instead of making huge maps in x,y dimensions, you could just go to a "level1" for example. Or when you want to generate random terrain/dungeon, you don't need extra space on your map, just make new instance. I know that there are floors, but imagine generating XX dungeons at the same time.
#edit and ofc possibility to edit the map ingame and save it, but in much more complex range than just saving everything dropped on the floor and added/removed structures. Like building house (physically, walls, door etc) and after that adding a house entity.
This is going a bit off-topic, but a big issue I've noticed is that there seems to be two types of contribution. You have TFS which is tied to OTC and the 10.98 version (even though it's not 100% 1:1 with 10.98, as far as I'm aware) and has a few devs who have the ability to review and merge PRs (and so very few changes actually make it in), then you have something like otservbr-global (which is a fork of TFS) where it seems like everything gets merged (no offense to them, but the code quality there is not great). But a big underlying problem with both structures is that they both lack testing.

Instances would require the official client to be dropped completely, but I do like the idea of instances in Tibia. If I were doing instances I would use the main engine to spawn a separate process where that instance lives and tell the client to connect to that instance. Then, when the player(s) leaves the instance, the client connects back to the main engine and that instance process is killed. I would not house instances in the same process as the main engine; imagine 100s of players jumping into their own instance, the process would probably run out of memory. However, maybe there's a better way to do instances.
Few more posts and this thread will be about completely new game.
At which point it will be OpenUltima. The long game I've been playing this entire time.
That's where we have to be careful. TFS is "stuck" on the 10.98 version because the whole point of Open-Tibia is to emulate the official servers. So if someone were to start the development of a new engine, they would need to make the decision from the beginning as to whether or not the engine would be an emulation or it's own thing. And if you opt for your own thing, then why use CipSoft's client, or sprites, or map, or battle mechanics, or monsters, or NPCs, etc.? At what point can it no longer be called Open-Tibia?
 
This is going a bit off-topic, but a big issue I've noticed is that there seems to be two types of contribution. You have TFS which is tied to OTC and the 10.98 version (even though it's not 100% 1:1 with 10.98, as far as I'm aware) and has a few devs who have the ability to review and merge PRs (and so very few changes actually make it in), then you have something like otservbr-global (which is a fork of TFS) where it seems like everything gets merged (no offense to them, but the code quality there is not great). But a big underlying problem with both structures is that they both lack testing.
This perhaps could be true in the past but not anymore, we have a exclusive chat with testers and several people running servers with PRs. We also have an official test server. Codes are only merged after intensive testing and if they are passing the checks unless they get "approved" by one of the reviewers.

Just check the tags:
1589814115209.png

The vast majority of the PRs I have opened have been running in my personal server for the past 4 years without any problems and even though, I still haven't merged them before people test in this base.

The problems with code quality are in the vast majority because in the past we had some people intentionally inserting bugs in the server to sell fixes later (before this repo becoming public) but those people were identified and properly banned already.
Post automatically merged:

Nowadays our process is very complete and it seems to be working a lot better, I still fear that in some way we are wasting time with duplicate efforts with people doing things for TFS and other forks/projects. We lack specially the coordinator figure in the community and there's not really someone that could be suitable for this position as of now.

My choice to help otservbr and not tfs is mainly because people that support tfs are extremely toxic, ungrateful and egocentric. They discuss more your credentials or your right to say what you are saying than the content of it.
 
then why use CipSoft's client, or sprites, or map, or battle mechanics, or monsters, or NPCs, etc.?


I will avenge the stolen aesthetics of Ultima 6 by using Tibia's corpse to fertilize a singularity of pseudo-nostalgic technophilic self gratification. Something so extensible and powerful, filling the role of OpenTibia is just a checkbox. It will be like comparing the The IBM 029 Card Punch to a fully loaded modern IDE.

1589813845901.png

The Avatar has willed it so.


That or working on OT stuff consists of relatively pleasant easy coding to pass the time while I wait to die. Whichever explanation suits you better.
 
This perhaps could be true in the past but not anymore, we have a exclusive chat with testers and several people running servers with PRs. We also have an official test server. Codes are only merged after intensive testing and if they are passing the checks unless they get "approved" by one of the reviewers.

Just check the tags:
View attachment 45705

The vast majority of the PRs I have opened have been running in my personal server for the past 4 years without any problems and even though, I still haven't merged them before people test in this base.

The problems with code quality are in the vast majority because in the past we had some people intentionally inserting bugs in the server to sell fixes later (before this repo becoming public) but those people were identified and properly banned already.
Post automatically merged:

Nowadays our process is very complete and it seems to be working a lot better, I still fear that in some way we are wasting time with duplicate efforts with people doing things for TFS and other forks/projects. We lack specially the coordinator figure in the community and there's not really someone that could be suitable for this position as of now.

My choice to help otservbr and not tfs is mainly because people that support tfs are extremely toxic, ungrateful and egocentric. They discuss more your credentials or your right to say what you are saying than the content of it.
That's good to know. The skewed view of my claims came from looking at a few systems in place. For example, imbuements; I noticed dead and non-optimal code from a quick look-through.
I will avenge the stolen aesthetics of Ultima 6 by using Tibia's corpse to fertilize a singularity of pseudo-nostalgic technophilic self gratification. Something so extensible and powerful, filling the role of OpenTibia is just a checkbox. It will be like comparing the The IBM 029 Card Punch to a fully loaded modern IDE.

View attachment 45704

The Avatar has willed it so.


That or working on OT stuff consists of relatively pleasant easy coding to pass the time while I wait to die. Whichever explanation suits you better.
I'm fully aware Tibia was/is a rip-off of Ultima, but that's not the point I'm making.
 
That's good to know. The skewed view of my claims came from looking at a few systems in place. For example, imbuements; I noticed dead and non-optimal code from a quick look-through.
yes, there are some PRs that were added in the past just for the sake of having them. A similar thing that tfs is doing lately with some scripts from ORTS. Even though in my personal opinion is best to have a missing feature inserted and tested/corrected/improved later than not having it at all.

Those were essential in the early stage of development to have the adoption of the base, now that we have players testing it regularly we have more room to start worrying about quality of what was implemented/will be.

We make an enormous effort to don't let things staying in 'to be tested' for too long, sometimes it was tested only with unit testing (and not regression) but is still valid to insert in the base and detect problems later on than to wait 1 year to make an improvement that everyone uses on their server but don't comment in github.

We do not lack testers, we lack people to confirm they are testers. There are several improvements that are simply not brought to tfs at all and even some in PR list forever and that everyone has tested through already. Also backwards compability is a heavy anchor to be carrying around...
people tend to ignore that destruction is part of the creation.
 
I believe we should target the 7.7 game. Because the game is so simple yet has all the fundamental features and all the content can be translated from cipsoft original file and everyone can build their own tibia server or custom served based on that if they want. Each feature/mechanic they want from a newer version can be implemented in a fork, bought, shared on a forum post, etc. Also targeting the newest tibia version is not viable anymore thanks to so much content and features that cipsoft added.
 
I believe we should target the 7.7 game. Because the game is so simple yet has all the fundamental features and all the content can be translated from cipsoft original file and everyone can build their own tibia server or custom served based on that if they want. Each feature/mechanic they want from a newer version can be implemented in a fork, bought, shared on a forum post, etc. Also targeting the newest tibia version is not viable anymore thanks to so much content and features that cipsoft added.
by doing that you would simply split the community even further.
Ot admins would continue improving features and making worse and more bugged versions that would be used to increase even more the amount of fixes being sold in 'black market'.

I don't think that this should be the way, instead we can simply bring more light into some areas. I'll give you an example that we had this week:
One of the big test servers that is using otservbr base was being attacked with a dupe in the coins, I talked with the guy that designed his website to log everything and we did the same with TFS.
Within the logs we found out a problem with packet editor in the transfer, after fixing it I found a topic here on otland where znote solved in 2017.

Since we do not have store in default TFS, this bug has been exploited for about 3 years now because someone said how to reproduce but the solution was not "forwarded" to the repositories that use this system. A guy tried to scam this otadmin in R$ 200 for the fix which was available deep somewhere in otlands discussion threads.

We also found out that even after fixing there were still people duping coins in his server and we got the logs from the website to find out the vast majority versions of gesior simply do not sanitize the 'lost account' page for sql injections.

That's exactly why we need to have such discussions and try to 'standardize' the tools were are using and working on.
 
yes, there are some PRs that were added in the past just for the sake of having them. A similar thing that tfs is doing lately with some scripts from ORTS. Even though in my personal opinion is best to have a missing feature inserted and tested/corrected/improved later than not having it at all.

Those were essential in the early stage of development to have the adoption of the base, now that we have players testing it regularly we have more room to start worrying about quality of what was implemented/will be.

We make an enormous effort to don't let things staying in 'to be tested' for too long, sometimes it was tested only with unit testing (and not regression) but is still valid to insert in the base and detect problems later on than to wait 1 year to make an improvement that everyone uses on their server but don't comment in github.

We do not lack testers, we lack people to confirm they are testers. There are several improvements that are simply not brought to tfs at all and even some in PR list forever and that everyone has tested through already. Also backwards compability is a heavy anchor to be carrying around...
people tend to ignore that destruction is part of the creation.
That's good to hear. Sorry, don't want to go off-topic any further.
I believe we should target the 7.7 game. Because the game is so simple yet has all the fundamental features and all the content can be translated from cipsoft original file and everyone can build their own tibia server or custom served based on that if they want. Each feature/mechanic they want from a newer version can be implemented in a fork, bought, shared on a forum post, etc. Also targeting the newest tibia version is not viable anymore thanks to so much content and features that cipsoft added.
I wouldn't say it's not viable so much as they make a lot of useless/questionable decisions. Compendium(sp?), friends, inspect...do players actually use these features? What about the recent nerfs they made to spawns? This is another advantage of having our own client, we can keep up with the things that are useful/interesting, and ignore things that aren't; with the added benefit of adding custom features.
 
For me as a web developer tfs lack restful api. Imagine changing game state from website(e.g. voting for today's event). JWT for authorization should be just fine. With it community could create some new, fun stuff and admins could manage their server from admin panel. Just a concept I've been thinking on.
Another thing I was wondering, apart from tfs itself, is creating strictly a back-end service(without any template generation) for tfs, so there is a possibility for community to use any framework to implement their front-end solutions, but this is different topic.
 
Back
Top