Skip to content

Trader tool PoB1 improvement ports and PoE2 specific fixes#1801

Open
vaisest wants to merge 30 commits intoPathOfBuildingCommunity:devfrom
vaisest:trader-tool-port
Open

Trader tool PoB1 improvement ports and PoE2 specific fixes#1801
vaisest wants to merge 30 commits intoPathOfBuildingCommunity:devfrom
vaisest:trader-tool-port

Conversation

@vaisest
Copy link
Copy Markdown

@vaisest vaisest commented Apr 18, 2026

Fixes:

#469 might be related

Description of the problem being solved:

  • Ports PoB1 trader improvements
  • Fixes mod weight generation, where for example some local modifiers were not correctly generated as PoB does not internally use the (local)
  • Fixes radius jewels and improves the jewel search in general by removing the any option, which would have caused poor results due to the lack of available filters
  • Uses OAuth header instead of poesessid. Handling logins in different view is solved by putting the PoEAPI instance in main. Hopefully this is fine?
  • Uses poe.ninja currency page endpoint for currency data
  • Adds a countdown when rate limited to clarify why the tool is being slow

Most of these changes could probably be ported to pob1 for consistency.

Steps taken to verify a working solution:

Possible issues

I had problems with 429 rate limiting. I'm not sure if that's because of me mashing f5 to test changes, or a real issue.

Issue was caused by Cloudflare, fixed by GGG.

Radius jewels don't generate a weight for the mod that increases the radius. I'm not sure how this should be generated as its value depends purely on the other mods on the jewel. This only affects the weighted sum, though.

Link to a build that showcases this PR:

Nothing specific, but:

Before screenshot:

(not sure why the previous version doesn't work at all)
image

body:
image

amulet:
image

After screenshot:

image image

body:
image

amulet:
image

In search results it should also be clear that more mods are generated. For example a lot essence mods and local-only mods were previously missing which made results very bad.

Depends on #1798.

@vaisest vaisest marked this pull request as ready for review April 20, 2026 10:53
@vaisest vaisest marked this pull request as draft April 20, 2026 13:42
@vaisest vaisest marked this pull request as ready for review April 21, 2026 06:19
@@ -553,7 +553,10 @@ Highest Weight - Displays the order retrieved from trade]]
main:ClosePopup()
-- there's a case where if you have a socket(s) allocated, open TradeQuery, close it, dealloc, then open TradeQuery again
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what this is exactly referring to, but its fix causes another crash

Comment thread runtime/lua/socket.lua
end
if not sock then return nil, err end
sock:setoption("reuseaddr", true)
-- sock:setoption("reuseaddr", true)
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seemed to make PoB think it's listening on the first port when another program was already listening, which meant the key goes to the wrong program

Copy link
Copy Markdown
Member

@Wires77 Wires77 Apr 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I thought I tested this specifically since it's a security issue, but I can check again. Regardless, the right fix for this would likely be to use the option in LaunchServer.lua instead: server:setoption(option [, value]) from https://lunarmodules.github.io/luasocket/tcp.html

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested again, you can see PoB change port to an unused one if a server is running elsewhere:
image

Copy link
Copy Markdown
Member

@Wires77 Wires77 Apr 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've figured out the root issues here:

  • We're only allowed to redirect users to http://localhost from GGG's server due to their implementation restrictions
  • Binding to port 0.0.0.0 (or *) with LuaSocket will still connect because that address is not conflicting with 127.0.0.1 (apparently)
  • Binding with the default method will choose an IPv6 address if the IPv4 one is busy, but with the same port

So in this case:

  • Start a server with python3 -m http.server -b 127.0.0.1 49082
  • LuaSocket connects to :: as IPv6
  • Redirect to http://localhost reaches the python server instead because localhost resolves to the IPv4 address and server

Forcing IPv4 revealed the other issue, where 0.0.0.0 doesn't conflict with 127.0.0.1 when binding to the port (at least on Windows). This picture reveals some of the results. Port 49083 was the only one that works properly.
image

Here's the fix to go into LaunchServer.lua:

local luaSocket = require("socket")
local server = luaSocket.tcp4()
local function bindSocket()
	local res, err
	server:setoption("reuseaddr", true)
	res, err = server:bind("localhost", 49082) or server:bind("localhost", 49083) or server:bind("localhost", 49084)
	if not res then
		server:close()
	else
		res, err = server:listen(1)
		if not res then
			server:close()
		else
			return server
		end
	end
	return nil, err
end
assert(bindSocket())

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants