Loot stolen on permanent allocation?

I wish the common person would learn what can and cannot be done with scripts.

A scripting language does not change the rules on the server side
A scripting language does not change the rules in the client

What a scripting language can do and commonly does is emulate human behavior by performing mouse clicks, keystrokes, text parses, bitmap parses of screen grabs, etc.

No scripting language has the power to go into server side code and change allocation. In order to do anything like that, you are talking about packet hacking, reverse engineering client, and things of that nature, which I am sure GGG has made very difficult to do. You cannot do those things with scripts. C++ maybe. C maybe. Assembly and 10 years, sure.

"

Fleshbits wrote:

I wish the common person would learn what can and cannot be done with scripts.

A scripting language does not change the rules on the server side
A scripting language does not change the rules in the client

What a scripting language can do and commonly does is emulate human behavior by performing mouse clicks, keystrokes, text parses, bitmap parses of screen grabs, etc.

No scripting language has the power to go into server side code and change allocation. In order to do anything like that, you are talking about packet hacking, reverse engineering client, and things of that nature, which I am sure GGG has made very difficult to do. You cannot do those things with scripts. C++ maybe. C maybe. Assembly and 10 years, sure.

It is feasible that a script looking at the information coming down can act faster than the client does to implement locks on items on your end, using desync to your advantage. and the server having no way to respond appropriately.

Basically exploiting order of operations, and glitching the natural flow of events by responding to an event up the chain.

"

LostForm wrote:

"

Fleshbits wrote:

I wish the common person would learn what can and cannot be done with scripts.

A scripting language does not change the rules on the server side
A scripting language does not change the rules in the client

What a scripting language can do and commonly does is emulate human behavior by performing mouse clicks, keystrokes, text parses, bitmap parses of screen grabs, etc.

No scripting language has the power to go into server side code and change allocation. In order to do anything like that, you are talking about packet hacking, reverse engineering client, and things of that nature, which I am sure GGG has made very difficult to do. You cannot do those things with scripts. C++ maybe. C maybe. Assembly and 10 years, sure.

It is feasible that a script looking at the information coming down can act faster than the client does to implement locks on items on your end, using desync to your advantage. and the server having no way to respond appropriately.

Basically exploiting order of operations, and glitching the natural flow of events by responding to an event up the chain.

You assume a scripting language can cause a desync. Other than flooding your own network, good luck and if the server side depends on a response for allocation, then it would be complete sillyness. A timer is a timer, who waits for the client to say anything? I don't think that is feasable at all. Not with a game of this quality, you'd have to be using something written by idiots for such a thing to work....or in 2002. From what I've seen of the game, I really doubt GGG has that level of incompetance on their staff. I think the opposite of them. They are people who think things out.

You could automate screen parse and auto click in location, but that's about it. I also think it is likely to take longer than a human would in a any scripting language. Parsing a screen size of 1680x for all labels is > 500ms, which is about how long it would take an eyeball looking for it. I know this because I've done it with every suggested method I could find in Magic the Gathering Online, because they proposed it to be legal for automated trading, rather than implementing it themselves, as long as we didn't hack the client code or the packets. Even written in native code with optimizations, it is slow unless you want to packet hack, which you aren't going to do in a script.

there are some people manipulating packet code but only to do small things on the client such as changing colours of drops to make them easier to see.

I highly doubt someone scripted anything to warrant this effect as, like has been said, it means hacking server side and that is next to impossible (but not impossible).

Im 99% sure this is a bug with the type of items that are allocated such as 4l/5l/6l and 5/6sock.

I have seen it on currency however but only with whetstones and scraps so far. I havent missed any decent currency but who knows.... it might be random.

The scripting language does not have to cause desync. The server and the client maintain a constant state of being momentarily out of sync.

The client must create and drop an item on the client side (the picture of the item, and the allocation effect)

If the item is created by the client, and then assigned allocation rules, there feasibly is a small window of opportunity for a script looking for the item creation event to snag the item before the allocation rules are assigned.

Due to the asynchronous nature of PoE's model, it is also feasible that the server has no way to respond to the unexpected occurrence that the loot was picked up by the wrong player.


Another feasible option is the scripts are able to fire off the 'pick up item' event with different parameters than what are normally passed from the command issued by the client, and it is possible again due to desync, for the server to have no error checking in place for this unexpected event.


Again, I am not saying this is what is happening, just that it is feasible that a script is allowing players to pick up permanent allocated loot, especially since permanently allocated loot is a new type of thing <-(polymorphism at its finest xD)

"

LostForm wrote:

If the item is created by the client, and then assigned allocation rules

Has not happened since the days of Origin's UO. Anyone doing client server game programming knows full well that you depend on the client for _nothing_. Server creates an item, Server allocates it to player, Server tells the client, client displays it.

sometimes if the person tries to pick it up without bag space, it will then look allocated to you.. then they just hit I and hurry up and pick it up

"

Chris wrote:

I'll look into getting it so that if you bounce (due to a full inventory) an allocated item then it stays allocated.

The QA guys are investigating the other reports in this thread but as far as I can see it's working correctly.

My own personal suggestion would be to correctly identify when and item is dropped due to inventory and when dropped intentionally.

I often pick and drop items I have no use for specifically so that it becomes FFA for whoever may need it. I would be sad to see this ability go.