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

OTClient 1.0 (Release)

Open source encryption method is such a bad idea. It's like publishing your personal passwords. It just doesn't make sense, anyone with access to that source can decrypt your files with ease so what's the point?
You can open source the method, but you can't decrypt something with a good encryption key. All of the encryption methods are open source AFAIK.

But, anyway, I don't want to make this thread a flame. I'll keep reading for now.
 
You can open source the method, but you can't decrypt something with a good encryption key. All of the encryption methods are open source AFAIK.
No. You are publishing a method, an algorithm, something that should be unique for each encryption. Using open source libraries that help you write NEW algorithms is a different thing.
 
Last edited:
I also support the idea that no encryption should be available publicly, not just, because its literally stupid, but not sure why would you expect the developer that reworked so many things and made the base otc A LOT better to implement encryption "to lure people into using it". It's your choice, he donated a lot of code and if you prefer otcv8 then use otcv8. Also most if not every encryption is breakable, if you'd made it public you are just asking for people to penetrate your security.
About the release, nice one, good job man. I love people that contribute out of their generosity.
 
Last edited:
No. You are publishing a method, an algorithm, something that should be unique for each encryption. Using open source libraries that help you write NEW algorithms is a different thing.
I hope you're kidding, otherwise that's completely lack of knowledge and innacurate.
There are thousand of well known encryption methods that are safe enough to be public, it's completely not logic what you're claiming.

@thread
Amazing job Mehah! Keep it up!
I also in favor of focusing in features and improvements, taking care of ppl super secret custom files and features, definitely is not the job of a open source developer.
 
I hope you're kidding, otherwise that's completely lack of knowledge and innacurate.
There are thousand of well known encryption methods that are safe enough to be public, it's completely not logic what you're claiming.
It's not the same... If you publish code (not the name of the method/algorithm, but the code 1:1), it's very easy (compared to "guessing" and reverse engineering) to write decryption. It's safe to use open sourced cryptography for CLOSED source projects. But when you share how you are encrypting your files then private key is enough to decrypt them.
 
Last edited:
View attachment 58448

View attachment 58449

@oen42 you just disproved kerckhoffs's principle, go claim your nobel prize
Public encryption methods are fine. thats why FIPS-140-2 exists What is FIPS 140-2 and Why it's Important - PreVeil (https://www.preveil.com/blog/fips-140-2/) I believe Oen42 was talking about examples such as: Sygnia Advisory: Detection of Golden SAML attacks (https://www.sygnia.co/golden-saml-advisory) maybe I misunderstand him.

When all an attacker has to do is obtain the private key and already knows how its implemented, you can be screwed when compared to an attacker having to figure out hashing and implementation. Granted you still have to gain access to the private key. Knowing networks cannot be secured 100% due to disgruntled employees etc stands to reason that further security is needed such as keeping code used to implement cryptography methods private or segregated with logical separation in some way. (more reason not to put encryption in this as OP and other users have said)

In my experience in the USA, at least federally, any applications involving HIPAA and controlled data are only considered fully compliant when the implementation is validated by FIPS, not just the fact it uses a public FIPS validated encryption. FIPS Validated vs FIPS Compliant, What's The Difference? (https://www.mocana.com/blog/fips-validated-vs-fips-compliant-whats-the-difference) Where I work, part of being completely validated/compliant is making sure implementation is protected and private. https://csrc.nist.gov/csrc/media/pr...on-program/documents/fips140-2/fips1402ig.pdf We use public encryption modules but if the implementation were shared, we wouldn't be in compliance, because NIST/Gov considers it insecure to do that.

@OP thanks for your release!
I suggest you add donation links
 
Last edited:
View attachment 58448

View attachment 58449

@oen42 you just disproved kerckhoffs's principle, go claim your nobel prize
Another person not getting what I'm talking about.
For the client to use encrypted image file (or any file), that file needs to be first decrypted by that client to get its original binary data, otherwise it's not usable at all. Now, because this encryption/decryption is within OPEN SOURCE project, one can EASILY save that DECRYPTED data into new files.
 
Congratulations mehah, very good your work, I always admire your version, and thanks for making this available.
 
Hey, mehah! You've done really good work, thanks for sharing it with the community.

I have one doubt, how have you changed the scale? In my usual OTC, I use 34x34 and it works pretty well. So, I made the same changes to use 34x34 in your client too, but it didn't work well.
1626020038998.png
 
Hey Guys,

I've been away lately because I almost don't have more spare time, but for a few days now I've been taking a look at how things are rendered in otclient and realized that I can batch render the images. In other words, I don't need request to draw the same image N times, instead I can give call that I want to draw X images in the Y Positions at once. With this approach I got a 74% increase in performance.

tibia.png

otclient.exe = queued rendering
otclient_noDrawPool.exe = old rendering.

At first I was not interested in implementing this optimization in 1.0, as I had already said that I would no longer support this client (the test I perform above, was done on client 12.64). However, I've changed my mind and soon will be applying this optimization in 1.0.
 
Hey Guys,

I've been away lately because I almost don't have more spare time, but for a few days now I've been taking a look at how things are rendered in otclient and realized that I can batch render the images. In other words, I don't need request to draw the same image N times, instead I can give call that I want to draw X images in the Y Positions at once. With this approach I got a 74% increase in performance.

View attachment 60237

otclient.exe = queued rendering
otclient_noDrawPool.exe = old rendering.

At first I was not interested in implementing this optimization in 1.0, as I had already said that I would no longer support this client (the test I perform above, was done on client 12.64). However, I've changed my mind and soon will be applying this optimization in 1.0.
add encryption too ! the code has been released you can found it here
 
Hey Guys,

I've been away lately because I almost don't have more spare time, but for a few days now I've been taking a look at how things are rendered in otclient and realized that I can batch render the images. In other words, I don't need request to draw the same image N times, instead I can give call that I want to draw X images in the Y Positions at once. With this approach I got a 74% increase in performance.

View attachment 60237

otclient.exe = queued rendering
otclient_noDrawPool.exe = old rendering.

At first I was not interested in implementing this optimization in 1.0, as I had already said that I would no longer support this client (the test I perform above, was done on client 12.64). However, I've changed my mind and soon will be applying this optimization in 1.0.
niceee, it seems cool!
add encryption too ! the code has been released you can found it here
Bro... He already said that he's not going to add encryption :/
 
Draw queue is already in ot 1.0, you can already test it, on this brach: mehah/otclient (https://github.com/mehah/otclient/tree/drawpool)

I did a quick comparison with v8, here are the tests:

[Fullscreen]
1626301027556.png

[Side by Side]
1626301339416.png

It hasn't been officially released yet, as I will refactor it and put it to open a thread for each queue, so the fps is more stable when there are many objects to be drawn, like 40x20 scale.


Note: tests were performed with an rx580 and i7 4770
otclient.exe = 1.0
otclient_gl.exe = v8
 
Draw queue is already in ot 1.0, you can already test it, on this brach: mehah/otclient (https://github.com/mehah/otclient/tree/drawpool)

I did a quick comparison with v8, here are the tests:

[Fullscreen]
View attachment 60283

[Side by Side]
View attachment 60284

It hasn't been officially released yet, as I will refactor it and put it to open a thread for each queue, so the fps is more stable when there are many objects to be drawn, like 40x20 scale.


Note: tests were performed with an rx580 and i7 4770
otclient.exe = 1.0
otclient_gl.exe = v8
What if you are moving around tho?
 
it doesn't matter, textures are stacked, so textures that are similar and close together are drawn at the same time, in batch...
Great job then. So how is that 2nd OTC going? Any updates?
 
Great job then. So how is that 2nd OTC going? Any updates?

are you talking about 12.64?

This project is a bit stopped, I'm really out of time for anything, I was only able to make these changes because I took a quick look at the otc rendering part and started to understand and think about a theory and I applied it, and there you have it, a good one gain and with a much cleaner code.
 
Back
Top