tarantonio
Old School Player
- Joined
- Jun 21, 2009
- Messages
- 865
- Solutions
- 1
- Reaction score
- 274
I’m only aware of paid software like VMProtect and similar ones.
What are you using or planning to use?
What are you using or planning to use?
That is kind of true, you can encrypt your code but it must be decrypted to be executed. The computer needs to be able to read the code to start the program. So at the start it does get decrypted, meaning the key to decrypt the code is on your pc and it just makes it harder for people to get to the code but still not impossible.To protect your shit you have to encrypt your client if im not wrong.
That is!That is kind of true, you can encrypt your code but it must be decrypted to be executed. The computer needs to be able to read the code to start the program. So at the start it does get decrypted, meaning the key to decrypt the code is on your pc and it just makes it harder for people to get to the code but still not impossible.
VMProtect uses a different style. It runs the program in a virtual environment making it even harder to gain access, but with the possibility of loss of performance.
There are a few ways to protect your software, the easiest way to figure it out is to google it.
There are people out there with way more expertise on the subject than in this forum.
Better take their advice
don't get me wrong but don't you guys see a bit of an issue in protecting something that is open source...
(this is what is wrong with the current OTC community :/)
don't get me wrong but don't you guys see a bit of an issue in protecting something that is open source...
(this is what is wrong with the current OTC community :/)
Recommended. I'm using his protection for 2 years.My own ciphering.
i have your client decryptedRecommended. I'm using his protection for 2 years.
in order to block bots just add in preprocessors BOT_PROTECTION definition that would block the botsI think it's more of an issue regarding botting for example. Leaving your client open = bot heaven.
There is plenty of reasons to protect your files besides keeping people from stealing your scripts. Sprites, antibot, stopping edits to client for gameplay advantage.
If you want to keep your scripts open for viewing yet protected you could look into getting checksum of files and comparing server side, if the checksum differs refuse login. Otherwise mole box or equivalent is a good option.
Really fair points bro. Although for the game play advantage my only frame of reference was from a fix I attempted to make for problems with old versions and targeting with runes. As you can see here someone could easily go back into this and change the scripts a bit in order to be able to send runes through battle windows again, or any equivalent to a problem similar to this.I understand where you are going with this, and it is much better than going out of your way to make sure that your changes can never be had by the community but it's still a waste of time.
- You aren't going to protect your sprites. You have to give us the client to play your server because that is the entire point of all this right? This means we can literally log into the server and screenshot all the sprites and "steal" them.
- The client already has protection for LUA calling any function in certain ways that could be used for a "bot" as long as you don't manually go in and disable it. This is done in the source which of course would not be included with a client download I would assume.
- There are no edits you can do in the client to gain a gameplay advantage, anything that could be automated would be caught by the anti-bot feature that I previously mentioned. Everything important, such as player/item movement limitations, exhaust rates, or view range is and should always be server-sided because programs like WPE and cheat engine exist. Anything else will just be done with a simple keyboard macro that comes standard with any gaming keyboard that was made in the last 5 years and cost $20. In the event that someone does not have such a keyboard (and even some that do), they will just use autohotkey (or worse) which is even more powerful than said keyboards anyway.
- If people really want to cheat your server, they can just modify their own OTC to connect. In all honesty, it wouldn't really be that difficult. How do you think TFS and OTC exist in the first place? It's not like Cip was sharing their updates with the OT community.
I share my poor knowledge here on OTland and Github on almost all the OT repos around there.
This is not incompatible with open a server and trying to keep cheats and bots away. I only want to protect gameplay things I cannot modify on sources to make a client suitable to my server version (example: no hotkeys to aim), or at least still don't know how to modify on sources.
WASD is on standard OTClient.Yea I understand what you and @Apollos are saying here and while I agree in this specific situation 2 things.
The reason I am so... passionate? about this subject is because after playing real tibia for just a month using their new client and all of the features it has to offer (like playing with WASD and tab targeting) I never want to play another version of tibia again. I can't even stand logging into my own server Deathzot anymore without using the OTC Flatlander and myself have worked on which includes many of these features. I would really like to see the OTC become mainstream for OTs but it's going to take us working as a community to make it happen because I think most people right now just don't want to deal with it in its current state.
- Auto hotkey will still allow people to cheat the targeting system.
- The fact that there is not already classic targeting/hotkey protection in the OTC source is exactly the core problem I'm describing. I am quite certain someone has done it already but just refuses to share it with the project meaning everyone that wants to make a classic server is worse off for it. OTC is extremely underdeveloped and has glaring issues that have persisted for years because nobody wants to share what they have and the people that do seem to be lacking the time or motivation to put in the work.
I completely agree. I have been adding pull requests and doing my best to contribute what I can and I know a few others have recently as well, but not enough people. I think since Don created the new repo I have hope people will begin to work on it again, especially since their pull request/issues will be heard.Yea I understand what you and @Apollos are saying here and while I agree in this specific situation 2 things.
The reason I am so... passionate? about this subject is because after playing real tibia for just a month using their new client and all of the features it has to offer (like playing with WASD and tab targeting) I never want to play another version of tibia again. I can't even stand logging into my own server Deathzot anymore without using the OTC Flatlander and myself have worked on which includes many of these features. I would really like to see the OTC become mainstream for OTs but it's going to take us working as a community to make it happen because I think most people right now just don't want to deal with it in its current state.
- Auto hotkey will still allow people to cheat the targeting system.
- The fact that there is not already classic targeting/hotkey protection in the OTC source is exactly the core problem I'm describing. I am quite certain someone has done it already but just refuses to share it with the project meaning everyone that wants to make a classic server is worse off for it. OTC is extremely underdeveloped and has glaring issues that have persisted for years because nobody wants to share what they have and the people that do seem to be lacking the time or motivation to put in the work.
this is just 1 of the things he did but you'll have to wait for dzot launch to see all of it (should not be to long)WASD is on standard OTClient.
Do you have something new on Deathzot OTClient to share with us?