Disable Rune Trow Assist

[DamianMeneses]

Does anyone know how to make the runes to target on tile instead of following the creature where it moves?This is the behavior i get normally, im using tfs 1.4.2

https://imgur.com/a/inXU64D

 

[sharinn]

this is normal
runes hit tile creature, walk animation is only client side think
when creature start walking is mean on server side creature is on next tile already

 

[Recreant]

this is normal
runes hit tile creature, walk animation is only client side think
when creature start walking is mean on server side creature is on next tile already

Its not, that's aim assistance on display on that gyazo

 

[Adposatnr]

this is normal
runes hit tile creature, walk animation is only client side think
when creature start walking is mean on server side creature is on next tile already

did u even watch gif posted here? dude literally wait for npc to start moving to next sqm and shoot rune on previous sqm still hitting target

 

[JeiDi]

did u even watch gif posted here? dude literally wait for npc to start moving to next sqm and shoot rune on previous sqm still hitting target

The NPC hasn't been on the next SQM yet. They had about 80-90% progress towards it, but in the tibia, you are either on SQM A or SQM B, so in this case, the creature was treated as "Still on the starting SQM/SQM A"

I was digging this about a year ago. A perfect scenario for your case would probably be marking the creature on SQM B somehow faster or immediately after the movement started(?).

For the best feeling, you'd probably want to have perfect aim with exact creature location, but that's not supported on any OTS, either RL. I'd love to see an implementation, as paralyzing rune and paralyze canceling would also be excellent with that change.

 

[Adposatnr]

The NPC hasn't been on the next SQM yet. They had about 80-90% progress towards it, but in the tibia, you are either on SQM A or SQM B, so in this case, the creature was treated as "Still on the starting SQM/SQM A"

I was digging this about a year ago. A perfect scenario for your case would probably be marking the creature on SQM B somehow faster or immediately after the movement started(?).

For the best feeling, you'd probably want to have perfect aim with exact creature location, but that's not supported on any OTS, either RL. I'd love to see an implementation, as paralyzing rune and paralyze canceling would also be excellent with that change.

animation doesnt matter once u see player npc or monster moving from sqm A to sqm B hes already on SQM B

 

[JeiDi]

animation doesnt matter once u see player npc or monster moving from sqm A to sqm B hes already on SQM B

Recorded on Cipsoft server files and Cipsoft client. (credits to Rawesh)

It looks like it is client-based aiming, not server-based aiming, so if your statement is true and the creature is marked as on SQM B when the movement starts client-sided, it's still a hit.

My guess is that it uses trust & verify policy to make the game responsive on the worst internet connection, so you can still play on ping 80+ relatively fine. The client checks if you hit and sends the information to the server, and the server only checks if the creature is in range or something(?). Maybe someone who can actually peek the code could explain it, very interesting topic.

https://imgur.com/27ynCbO

 

[Nekiro]

The NPC hasn't been on the next SQM yet. They had about 80-90% progress towards it, but in the tibia, you are either on SQM A or SQM B, so in this case, the creature was treated as "Still on the starting SQM/SQM A"

I was digging this about a year ago. A perfect scenario for your case would probably be marking the creature on SQM B somehow faster or immediately after the movement started(?).

For the best feeling, you'd probably want to have perfect aim with exact creature location, but that's not supported on any OTS, either RL. I'd love to see an implementation, as paralyzing rune and paralyze canceling would also be excellent with that change.

or sprite based aim

Recorded on Cipsoft server files and Cipsoft client. (credits to Rawesh)

It looks like it is client-based aiming, not server-based aiming, so if your statement is true and the creature is marked as on SQM B when the movement starts client-sided, it's still a hit.

My guess is that it uses trust & verify policy to make the game responsive on the worst internet connection, so you can still play on ping 80+ relatively fine. The client checks if you hit and sends the information to the server, and the server only checks if the creature is in range or something(?). Maybe someone who can actually peek the code could explain it, very interesting topic.

https://imgur.com/27ynCbO

whats interesting about it? client sends creature id at the moment you click the rune and aim on someone, the rest is server walking to the rune to pick it up (if needed) or just throw on the chosen target (by creature id, so position doesn't matter, that's why it always hits)

 

[czouski]

maybe this should be the concept of TFS from now. we have to create our own additions in config lua and always add preference. yeah the engine will weight more than a megabyte but so what its 2024 we ain't short of ram making everything in the protocol and client customizable is a way to go. I mean there is so many ways to explore the client and maybe we could start creating new games out of it not specifically tibia even related i mean you have squares there figure something out.

Post automatically merged: Nov 14, 2024

as soon as you use the rune the spell handles everything because it has flag needtarget set to 1 instead of 0 if rune wont need creature target then it will hit tile just look at how GFB works . use area to create the spell area and then the server will have mistically 0 ping because the packet will have to be accepted while the player is still on the tile *to deal damage.
this way you lose the ability to use a rune which in case of sd cost is huge to the economical part and making game going into extreme skill based. however you will quickly see how they set hotkeys or macros going into the screen so there is also the botting part which will make them unbelievably accurate.

 

[Adposatnr]

Recorded on Cipsoft server files and Cipsoft client. (credits to Rawesh)

It looks like it is client-based aiming, not server-based aiming, so if your statement is true and the creature is marked as on SQM B when the movement starts client-sided, it's still a hit.

My guess is that it uses trust & verify policy to make the game responsive on the worst internet connection, so you can still play on ping 80+ relatively fine. The client checks if you hit and sends the information to the server, and the server only checks if the creature is in range or something(?). Maybe someone who can actually peek the code could explain it, very interesting topic.

https://imgur.com/27ynCbO

thats how people could sd off screen on old tibia u can see it on cams sometimes when they used auto aim

however aim assistance on otc is much stronger making it even worse in pvp

 

[kay]

whats interesting about it? client sends creature id at the moment you click the rune and aim on someone, the rest is server walking to the rune to pick it up (if needed) or just throw on the chosen target (by creature id, so position doesn't matter, that's why it always hits)

That's not how it works. The client won't allow sending the 'UseOnCreature' packet with a creature's id lower than 0x40000000. Even if you sent it artificially, the server would ignore it, because you can't shoot directly on players. If you click on a monster or an NPC, the client will send the 'UseOnCreature' packet (with the creature's id), but if you click on a player it will send the 'UseTwoObjects' packet instead (with object id 99 and the coordinates).

What @JeiDi has shown is not related strictly to aiming. It results from how the delayed actions work in Tibia. When you use a rune from distance and click on a player, the client sends the 'UseTwoObjects' packet, as said above, with object id 99 (which stands for any character) and the coordinates - instantly. If a character is still there once that packet reaches the server, the action is considered valid and it is added to your ToDo list (i.e. go to place A and use rune B on character C). This is the point from which it is one specific character, and not just any character. In fact, the same goes for the rune which now becomes defined. So, you will move and use that specific rune on that specific player, regardless where it happens to be at the moment of shooting, because you've already aimed on it. Assuming, that it's still in range.

You would get the same result if you for example tried to pick up an item from distance. Try to pick it up from one square and as soon as your character starts going for it, move it to another square with the other character - you will still pick it up from the new square, unless it becomes not reachable from the place you went to. It's because the server 'marks' the objects related to the queued action. E.g. if you'd replace that item with its exact copy (the same object id and all attributes) in the meantime (after it's been queued but before it's executed), and even placed it on the same square, it won't pick it up because the server knows it's not the same item.

And back to aiming: if the target wouldn't be there anymore when your packet reached the server (e.g. it moved away in that short span between sending your packet and it reaching the server), the server would see that there's no object of id 99 (a creature) on given coordinates, hence you would get the "Sorry, not possible" result immediately (without going to the rune). Note, that it's NOT the same as "You can only use this rune on creatures" with the 'poof' animation. This happens when you send a packet with a floor id and there's no creature on that square at the moment of execution (not when reaching the server). It's two different scenarios, based on how the packet was built.

@Adposatnr Is right here. You cannot be "between squares". Once a character "starts moving", it is technically already on that new square and only clicking there should allow a hit in this case. Ofc, everything I said refers to the real Tibia 7.7 and the original client. There is definitely some "aim assistance" shown by the OP, which almost feels like an aimbot. I don't know how to fix it though, cause I'm not familiar with the OTC and/or TFS sources. I can only tell how it should work, but not how to fix/implement it in an OT. The fault must be either on the client's side or both. The client is clearly sending a wrong packet, but additionally there could be an error on the server's side as well (e.g. allowing direct shooting on players).

 

[Nekiro]

That's not how it works. The client won't allow sending the 'UseOnCreature' packet with a creature's id lower than 0x40000000. Even if you sent it artificially, the server would ignore it, because you can't shoot directly on players. If you click on a monster or an NPC, the client will send the 'UseOnCreature' packet (with the creature's id), but if you click on a player it will send the 'UseTwoObjects' packet instead (with object id 99 and the coordinates).

That's how it works. in never tibia, at least in OTC. Don't remember newer cip tibia specifics. OP runs a new tibia as far as I can tell. Not sure why the shared gif is in this certain protocol, but it is irrelevant.

Looking at the image from first post, it shouldn't behave like that, client must have corrected the throw. Creature that moved off the tile and is walking animated to next one isn't on the first tile anymore.

@DamianMeneses is this otclient or cipsoft client?

 

[czouski]

technically all this tile or target stuff is weak because in the end macro will always learn to do it better than human.
its probably best to make it feasible for all that when u actually hit the object and not where they are is more interesting because you actually have to aim at your target.

 

[kay]

That's how it works. in never tibia, at least in OTC. Don't remember newer cip tibia specifics. OP runs a new tibia as far as I can tell. Not sure why the shared gif is in this certain protocol, but it is irrelevant.

@JeiDi posted a recording from the stolen cipsoft server and client. That's what you commented on, and that's what I corrected.

 

[getema27]

looks like it is client-based aiming

yes

how to make the runes to target

play cip client

otclient have auto aim

 

[kay]

technically all this tile or target stuff is weak because in the end macro will always learn to do it better than human.
its probably best to make it feasible for all that when u actually hit the object and not where they are is more interesting because you actually have to aim at your target.

It's not as clear as it may seem. While aimbot is expected to be more accurate than human, it is not always the case. Because you can't shoot directly on players, it's always based on coordinates, so aimbot won't be perfect. I mean, in the cip engine you can't. I don't know if TFS allows that, but it's wrong if it does.

So, the bot will always try to hit on the square where the target currently is in the client (standing on, or "walking" to that square). However, if the target's speed is high in relation to your ping (plus all the software/hardware delays), it may be not enough to land a hit. Once your packet reaches the server, that character may already be on the square even further. The same goes for where the bot "sees" the target - the client is always late to the server. So a strategy of anticipating/guessing and aiming for the square "ahead" may yield better results, especally if the target is running in lines easily predictable for human. It probably takes an experienced player, but human may adapt to that, and a "simple macro" won't.

That "aim assistance" makes it easier for players, but for aimbots too. In the above scenario, even if it's late, it may still hit, so you're losing that low margin where human could possibly do better.

 

[Rawesh]

The desired non-aimbot behaviour can be achieved with OTC. However I don't use TFS either, so not sure about server side stuff.
Here is cip engine (Revol) + Tibiara otc:

 

[czouski]

It's not as clear as it may seem. While aimbot is expected to be more accurate than human, it is not always the case. Because you can't shoot directly on players, it's always based on coordinates, so aimbot won't be perfect. I mean, in the cip engine you can't. I don't know if TFS allows that, but it's wrong if it does.

So, the bot will always try to hit on the square where the target currently is in the client (standing on, or "walking" to that square). However, if the target's speed is high in relation to your ping (plus all the software/hardware delays), it may be not enough to land a hit. Once your packet reaches the server, that character may already be on the square even further. The same goes for where the bot "sees" the target - the client is always late to the server. So a strategy of anticipating/guessing and aiming for the square "ahead" may yield better results, especally if the target is running in lines easily predictable for human. It probably takes an experienced player, but human may adapt to that, and a "simple macro" won't.

That "aim assistance" makes it easier for players, but for aimbots too. In the above scenario, even if it's late, it may still hit, so you're losing that low margin where human could possibly do better.

im talking about the sprite size on your screen when you from moment you press rune button to aiming onto the creature sprite yes game is tile'y but it does not mean the combat has to be. it can still be skill based clean and look good in the end. making for a smoother experience.

 

[Maps]

View attachment 88240

nice rolex

 

[Gesior.pl]

im talking about the sprite size on your screen when you from moment you press rune button to aiming onto the creature sprite yes game is tile'y but it does not mean the combat has to be. it can still be skill based clean and look good in the end.

Hmm.. that's what OTC does. When you click Use on tile X, it gets +/- 1 tiles and checks which creature/item is drawn on given position. This code is to fix clicking on monster that has 64x64 sprite (you can click on other tile - looking on graphics - than he is standing on) and to fix problem with clicking on creature that is standing on 3 parcels (again, his elevation is high, so he is drawn +1 sqm from his real in-game position tile).

Maybe 'draw area' detection is wrong in OTC and it detects whole tile, not only part of tile that is covered by creature outfit (while moving).

You can remove these fixes and then player will have to click on tile to which walking creature is walking right now, not on position from which it started walking.