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

Moving towards OTC

What should we do


  • Total voters
    57
  • Poll closed .
Status
Not open for further replies.
Well I get your point, but I also think it should be easy to change things.
Otherwise we will end up with 2-3 devs working on the C++ code and nothing else, maybe some bug reports.

It could be a good ide to have 2 forks, one that is pure C++ and another that uses both C++ and Lua.
Some things could be moved from Lua to C++ to make it harder, ex remove all the health and mana things or the useItem functions, thus making health and mana bots imposible without source edits.
But this would also make it harder to customize your client.

There must be a good way to compress the Lua files into one big exe file or something like that.
Pretty much having files that only you, the person who compiled the client can change.

And things like the lightning system should be optional, I hate playing with light effects I always set it to max haha

You can already make it basically impossible to bot with the BOT_PROTECTION the client already has in it. (I haven't found a way around it yet0

If someone is going to put a lot of custom changes to their client, they will simply use encryption to it.
True enough.
 
About the client modifications.
I dont think OTC needs something liek this yet, but maybe its possible from server to ask few questions from client what tries to connect to it.
like how much bytes it has, or what is returned on line 400 on this file, etc etc.
only you know the questions and answers. The user who uses your client does not.

However, you mentioned I can simply add things what I want to change to source so I could change them in LUA.
Are you talking about these modules?

How I go about and make it so that whenever I send look request to server, I start player:eek:nlook() function I have made in there?
 
You can already make it basically impossible to bot with the BOT_PROTECTION the client already has in it. (I haven't found a way around it yet0

True enough.

Well we still have the issue that ppl can download the client and compile it with the flag activiated.
Only way around it (as I can see it) is doing changes in the protocol, that will slow the botters down alot.
And unless you have 2k + players I highly doubt people will release the protocol changes.
The more players the server has, the more you can earn by selling the changes :p

About the client modifications.
I dont think OTC needs something liek this yet, but maybe its possible from server to ask few questions from client what tries to connect to it.
like how much bytes it has, or what is returned on line 400 on this file, etc etc.
only you know the questions and answers. The user who uses your client does not.

However, you mentioned I can simply add things what I want to change to source so I could change them in LUA.
Are you talking about these modules?

How I go about and make it so that whenever I send look request to server, I start player:eek:nlook() function I have made in there?

Well there are easier ways, you could see if the client that is connected is an OTC client, then add some random byte in a random place and see if the client returns that byte or not.
Tibia has these things in some packages, just look for msg.getByte() == (0x01 or 0x00), they are most likely just blank (and they do exist in flash aswell, so they are blanks).
Just make sure to code it in C++ haha :)

Idk what you ment, if you change the src code you have to compile it - like always with C++.
If you do changes in Lua (not LUA)
http://www.lua.org/about.html
"Lua" (pronounced LOO-ah) means "Moon" in Portuguese. As such, it is neither an acronym nor an abbreviation, but a noun. More specifically, "Lua" is a name, the name of the Earth's moon and the name of the language. Like most names, it should be written in lower case with an initial capital, that is, "Lua". Please do not write it as "LUA", which is both ugly and confusing, because then it becomes an acronym with different meanings for different people. So, please, write "Lua" right!

You can reload them using the module manager(I think it's called), same as with TFS where you have to login and write /reload ...
And then you have the terminal (in the top menu, looks like the CMD icon), where messages, errors, warnings etc are written out.

When you look you want it to load Player:eek:nLook()? it should do that by default, if you are talking about TFS.
If you are talking about OTC it depends on what you wanna do, you can call the function from C++ (check game.cpp, protocol*something(ive merged the files because of this...).cpp) for g_lua.*
But you should be able to use some onLook connect function to load your Player:eek:nLook function when the player looks at something.
 
If you are talking about OTC it depends on what you wanna do, you can call the function from C++ (check game.cpp, protocol*something(ive merged the files because of this...).cpp) for g_lua.*
But you should be able to use some onLook connect function to load your Player:eek:nLook function when the player looks at something.
You make it sound so easy, probably is. Yet I still don't understand What files i have to change to activate TFS Player:eek:nLook function.

Idk how to explain better, so I will make it with pictures.
rArW0ra.jpg

qVhk4hN.png
So the text should not happen, instead if you look the code in tibia client it will execute the npcMW function.
 
You make it sound so easy, probably is. Yet I still don't understand What files i have to change to activate TFS Player:eek:nLook function.

Idk how to explain better, so I will make it with pictures.
rArW0ra.jpg

qVhk4hN.png
So the text should not happen, instead if you look the code in tibia client it will execute the npcMW function.

What do you want to happen when a player looks at something?
Did you want a window to pop-up similar to how Necronia has it?
 
What do you want to happen when a player looks at something?
Did you want a window to pop-up similar to how Necronia has it?
I want to execute the function I have already written in TFS xD (see the line after "I WANT TO ACTIVATE THIS LINE NEXT")
 
You make it sound so easy, probably is. Yet I still don't understand What files i have to change to activate TFS Player:eek:nLook function.

Idk how to explain better, so I will make it with pictures.
rArW0ra.jpg

qVhk4hN.png
So the text should not happen, instead if you look the code in tibia client it will execute the npcMW function.

Does it work with the standalone client?
No ide what it could be, you have to serach around to see what codes are executed.

I think the client adds the "You see" but im not 100% on that.
 
Does it work with the standalone client?
No ide what it could be, you have to serach around to see what codes are executed.

I think the client adds the "You see" but im not 100% on that.
Yes of course. The problem is with OTC it does not activate this event Player:eek:nLook() when I look any creature.
 
Yes of course. The problem is with OTC it does not activate this event Player:eek:nLook() when I look any creature.

Well just look around and tell us what you found :p
Might be a missing package or a diffrence in the display text ~ with OTC and the cipsoft clients.
 
I want to execute the function I have already written in TFS xD (see the line after "I WANT TO ACTIVATE THIS LINE NEXT")

Ok! I see the issue.
This is what is happening.

First, the only things that are sent to the OTClient, are in protocalgame.cpp of TFS.
There is NO onLook function sent to the OTClient.

When you look at something, it sends a Green Text Message.
So in protocalgame.cpp, there is probably a function called "sendTextMessage" or something and then in OTClient there is a function called "parseTextMessage" (you can pretend Parse means receive, so this receives the text message)

But, in YOUR onLook function, you also do the function npcMW. (Which I assume is NPC Modal Window, which opens a Modal Window for this NPC).
So then you'd have to go to protocalgame.cpp. Find the function that sends a modal window. ("sendModalWindow" maybe? I'm too lazy to look), then go to the OTClient and find the "parseModalWindow" function.

Each protocol has a hexadecimal number associated with it. The number will match on both TFS and OTClient. So if "sendTextMessage" = 100, then the otclient will look for #100 when it receives a message. If it sees #100 it knows to use parseTextMessage function to receive this protocol.

So "sendModalWindow" might be protocol #101 in TFS. TFS sends this protocol to the client, The OTClient see #101, and uses the parse function #101 (which is probably something like "parseModalWindow")

It is actually really simple, but yea, you aren't looking for onLook in the otClient, you are only looking for the function that receives what protocalgame.cpp sent in TFS
 
So TFS sends out this to client?
Code:
case 0xF9: parseModalWindowAnswer(msg); break;
void ProtocolGame::parseModalWindowAnswer(NetworkMessage& msg)
{
    uint32_t id = msg.get<uint32_t>();
    uint8_t button = msg.getByte();
    uint8_t choice = msg.getByte();
    addGameTask(&Game::playerAnswerModalWindow, player->getID(), id, button, choice);
}
Code:
void ProtocolGame::sendModalWindow(const ModalWindow& modalWindow)
{
    NetworkMessage msg;
    msg.addByte(0xFA);

    msg.add<uint32_t>(modalWindow.id);
    msg.addString(modalWindow.title);
    msg.addString(modalWindow.message);

    msg.addByte(modalWindow.buttons.size());
    for (const auto& it : modalWindow.buttons) {
        msg.addString(it.first);
        msg.addByte(it.second);
    }

    msg.addByte(modalWindow.choices.size());
    for (const auto& it : modalWindow.choices) {
        msg.addString(it.first);
        msg.addByte(it.second);
    }

    msg.addByte(modalWindow.defaultEscapeButton);
    msg.addByte(modalWindow.defaultEnterButton);
    msg.addByte(modalWindow.priority ? 0x01 : 0x00);

    writeToOutputBuffer(msg);
}

And the places where it has something to to with them
game.h file
Code:
    void processModalDialog(uint32 id, std::string title, std::string message, std::vector<std::tuple<int, std::string> > buttonList, int enterButton, int escapeButton, std::vector<std::tuple<int, std::string> > choiceList, bool priority);

    void answerModalDialog(int dialog, int button, int choice);
game.cpp file
Code:
void Game::processModalDialog(uint32 id, std::string title, std::string message, std::vector<std::tuple<int, std::string> > buttonList, int enterButton, int escapeButton, std::vector<std::tuple<int, std::string> > choiceList, bool priority)
{
    g_lua.callGlobalField("g_game", "onModalDialog", id, title, message, buttonList, enterButton, escapeButton, choiceList, priority);
}
Code:
void Game::answerModalDialog(int dialog, int button, int choice)
{
    if(!canPerformGameAction())
        return;
    m_protocolGame->sendAnswerModalDialog(dialog, button, choice);
}
protocolgame.h file
Code:
    void parseModalDialog(const InputMessagePtr& msg);
    void sendAnswerModalDialog(int dialog, int button, int choice);
protolgamesend.cpp file
Code:
void ProtocolGame::sendAnswerModalDialog(int dialog, int button, int choice)
{
    OutputMessagePtr msg(new OutputMessage);
    msg->addU8(Proto::ClientAnswerModalDialog);
    msg->addU32(dialog);
    msg->addU8(button);
    msg->addU8(choice);
    send(msg);
}
Even seeing all this, I can't understand it xD
So am I missing some kind of line in the creatures what will fire modal window request every time creatures are looked? or something is stopping to reach to send the modal window?

And you sure you undertood me. It doesnt only affect the modal window the Player: onLook function WILL NOT BE EXECUTED, when the look target is creature.
 
Is the line that sends the modal window even executed?
Are modal windows bugged or looking at things in otc.
 
Is the line that sends the modal window even executed?
Are modal windows bugged or looking at things in otc.
I don't know is it bug or not, I'm just trying to understand what am I suppose to do, to make it possible to execute my custom scripts by looking creatures in the game.

Currently when you look creature, the Player: onLook() does not execute (Talking about the LUA function in data folder; data>events>scipts>player.lua)
 
I don't know is it bug or not, I'm just trying to understand what am I suppose to do, to make it possible to execute my custom scripts by looking creatures in the game.

Currently when you look creature, the Player: onLook() does not execute (Talking about the LUA function in data folder; data>events>scipts>player.lua)

Here is the question.

In the normal Tibia client, does your modal windows work for these NPCs? But when you use the OTClient it does not work?
--If it works on the normal tibia client, then the OTClient does not have modal windows working correctly which needs to be fixed.
--If it doesn't work on the normal tibia client, then it may be an issue with your script.
 
When you look at a creature with otclient it will always execute
Player:eek:nLookInBattleList(creature, distance)
instead of Player:eek:nLook(thing, position, distance) like the regular tibia client does and the regular client just uses the above function when you're looking at creatures in the battle list
 
Here is the question.

In the normal Tibia client, does your modal windows work for these NPCs? But when you use the OTClient it does not work?
--If it works on the normal tibia client, then the OTClient does not have modal windows working correctly which needs to be fixed.
--If it doesn't work on the normal tibia client, then it may be an issue with your script.
already answered before. It works with normal client.

When you look at a creature with otclient it will always execute
Player:eek:nLookInBattleList(creature, distance)
instead of Player:eek:nLook(thing, position, distance) like the regular tibia client does and the regular client just uses the above function when you're looking at creatures in the battle list
Nice notice. Yeah if I would move my script there it works.
 
Ok! I see the issue.
This is what is happening.

First, the only things that are sent to the OTClient, are in protocalgame.cpp of TFS.
There is NO onLook function sent to the OTClient.

When you look at something, it sends a Green Text Message.
So in protocalgame.cpp, there is probably a function called "sendTextMessage" or something and then in OTClient there is a function called "parseTextMessage" (you can pretend Parse means receive, so this receives the text message)

But, in YOUR onLook function, you also do the function npcMW. (Which I assume is NPC Modal Window, which opens a Modal Window for this NPC).
So then you'd have to go to protocalgame.cpp. Find the function that sends a modal window. ("sendModalWindow" maybe? I'm too lazy to look), then go to the OTClient and find the "parseModalWindow" function.

Each protocol has a hexadecimal number associated with it. The number will match on both TFS and OTClient. So if "sendTextMessage" = 100, then the otclient will look for #100 when it receives a message. If it sees #100 it knows to use parseTextMessage function to receive this protocol.

So "sendModalWindow" might be protocol #101 in TFS. TFS sends this protocol to the client, The OTClient see #101, and uses the parse function #101 (which is probably something like "parseModalWindow")

It is actually really simple, but yea, you aren't looking for onLook in the otClient, you are only looking for the function that receives what protocalgame.cpp sent in TFS

The only part wrong here is that both OTC and TFS use hex values, OTC uses decimals (0) while TFS uses hex (0x00) :p
 
Here:
Code:
    if(thing->isCreature() && m_protocolVersion >= 961)
        m_protocolGame->sendLookCreature(thing->getId());
    else
        m_protocolGame->sendLook(thing->getPosition(), thing->getId(), thing->getStackPos());
It always are sending the battle list look type.
 
I saw this list and thought that I would offer some insight..

1. The want to keep up with other people botting.
Even if its the first player on a server and there were no bots he would try to bot. Even if he was top level. Why? To impress and to dominate the server. A lot of good servers are PvP and you win pvp by having more hp, more dmg.

2. The want to keep up with "freaks" that can play games as if they are a computer themselves.
3. Lack interest in the game they are playing but still want to progress in it.
This is due to the slow leveling. And all servers being based of rl tibia so it does get boring

4. Lack the time to invest into the progression of the game but want to keep up with their friends.
5. Are compulsive cheaters.

If you think killing monsters on tibia is boring. Refer to #3
If you have a job. Refer to #4
If you are hyper competitive. Refer to #1 and/or #2 and in some extreme cases #5
If you play tibia/ots for fun. None of these apply to you, and you likely enjoy most if not every server you log into.

The truth is, no matter what the reason, the majority of tibia players use and even prefer bots. It doesn't matter how interesting you make a server, as long as there is a tool that is capable of doing things automatically, players will use it.
The only way to stop it is to create a client that does not have a bot and continue to make that client evolve in a way that nobody is interested in putting time/effort into creating a bot for it.
The question then is, how many tibia players would want something like that?

Well everyone wants to bot like you said and so IF you were wanting to bot a server and you saw a server that couldn't be botted would you go there or just go to the nect one that had a bot? Doesn't matter anymore how easy the server is. People don't even try, they have a system. Download OT client, inject bot, log on. Start botting..
 
I saw this list and thought that I would offer some insight..

1. The want to keep up with other people botting.
Even if its the first player on a server and there were no bots he would try to bot. Even if he was top level. Why? To impress and to dominate the server. A lot of good servers are PvP and you win pvp by having more hp, more dmg.

2. The want to keep up with "freaks" that can play games as if they are a computer themselves.
3. Lack interest in the game they are playing but still want to progress in it.
This is due to the slow leveling. And all servers being based of rl tibia so it does get boring

4. Lack the time to invest into the progression of the game but want to keep up with their friends.
5. Are compulsive cheaters.

If you think killing monsters on tibia is boring. Refer to #3
If you have a job. Refer to #4
If you are hyper competitive. Refer to #1 and/or #2 and in some extreme cases #5
If you play tibia/ots for fun. None of these apply to you, and you likely enjoy most if not every server you log into.

The truth is, no matter what the reason, the majority of tibia players use and even prefer bots. It doesn't matter how interesting you make a server, as long as there is a tool that is capable of doing things automatically, players will use it.
The only way to stop it is to create a client that does not have a bot and continue to make that client evolve in a way that nobody is interested in putting time/effort into creating a bot for it.
The question then is, how many tibia players would want something like that?

Well everyone wants to bot like you said and so IF you were wanting to bot a server and you saw a server that couldn't be botted would you go there or just go to the nect one that had a bot? Doesn't matter anymore how easy the server is. People don't even try, they have a system. Download OT client, inject bot, log on. Start botting..

I am not sure what list you are looking at, but I don't like your hypothesis, because I think it is untrue.

Not all tasks in Tibia are equal.
There are boring tasks:
  • Normal Hunting (usually solo against easy monsters)
  • Rune Making
  • Fishing
  • Training
  • Selling Items
  • Managing your Depot
  • Looting Creatures you've killed
  • Tossing and Sorting Lootbags
All of the above are (in my opinion) badly designed by Cipsoft. They are boring, not fun, generally considered "work" and the "reward" at the end is you can do the following fun tasks:

  • PvP
  • Extreme Hunting (Usually with a team)
  • Decorate your house/guildhall
  • Quests (some quests are so boring and easy they are botted too though)

Now, some tasks in Team-Hunting are also boring and un-skilled tasks.
  • Healing the Knight (Hours of pressing Heal Friend when your knight is in yellow is no fun)
  • Dealing Damage (Generally in a team hunt, you stand still while the knight blocks and press 1 button until monsters are dead)
  • Using buff spells (Every 2 minutes you use your team party buff, remembering to do this is annoying and boring)
Now, some things in PvP are also done badly.
  • You cannot mark targets. (As in, mark a target so everyone can see who to combo in-game)
  • It's generally impossible to type during a battle (no communication)
  • Magic Walls have no visual sign of when they are going to disappear.
  • There is no way to Ping a location on screen or on the mini-map to communicate to your team where to go or what to do.
  • For Heal-Friend, it is too hard to manage your entire team and keep them alive (since you'd either have to hotkey every name or type them)
  • Most people use dash to help them run at normal speeds. (Dash is your normal walking speed, the normal client gives you a lag-walk if you have higher pings)

If you notice, most of the above issues are solved by bots. The bad game and client design causes issues, and the bot corrects them.
I'm not saying everything a bot does is good and fair, but a lot of what bots do are completely fine and simply make the game more enjoyable.

With the OTClient, you can make automated features that make your game more enjoyable.
 
Status
Not open for further replies.
Back
Top