Instalar Steam
iniciar sesión
|
idioma
简体中文 (Chino simplificado)
繁體中文 (Chino tradicional)
日本語 (Japonés)
한국어 (Coreano)
ไทย (Tailandés)
български (Búlgaro)
Čeština (Checo)
Dansk (Danés)
Deutsch (Alemán)
English (Inglés)
Español - España
Ελληνικά (Griego)
Français (Francés)
Italiano
Bahasa Indonesia (indonesio)
Magyar (Húngaro)
Nederlands (Holandés)
Norsk (Noruego)
Polski (Polaco)
Português (Portugués de Portugal)
Português - Brasil (Portugués - Brasil)
Română (Rumano)
Русский (Ruso)
Suomi (Finés)
Svenska (Sueco)
Türkçe (Turco)
Tiếng Việt (Vietnamita)
Українська (Ucraniano)
Informar de un error de traducción
It is related to so much fast requests just one big inventory does,to the servers
Because of this, I avoid open big inventories.
It opens a blank /white page, do you confirm this?
When it happens, I change my Ip address, or use TOR to open iventories, for the few next hours
To solve, you can see if an item (a card) is in the user inventory through the user badge page
And you can pre-select the card (1 item per offer) via the trading URL, adding for_tradingcard= in the querystring
For example, you can see what cards I have for Rusty Lake Hotel here:
https://steamcommunity.com/profiles/76561198041010287/gamecards/435120
You can ask me for the third card with this direct link
(remove the white space, I had to add them otherwise it becomes automatically a trade button)
Sorry I do not have a simpler solution
A part of write some in the search area- for that the filter is not necessary
Well, yes, that is what "big inventories" are, when we refer to them as "bots that have a lot of items"
The quotes are there because this is not an error. It is intentional way to keep low the loads.
Energy costs, and Valve pays for keeping alive the servers. After the last few years of economical disaster on power supply, this was meant to contain the costs.
This, instead of optimizing the code, avoiding the download a lot of trash infos during inventories browsing, and the continue requests for thumbnails and pages.
You can figure out for yourself, on how the text research is done. When an inventory is too big, the textual research is so bad even the browser stucks. Clearly an old way to do things. The "small inventories" way.
Whoever use automatic systems to do frequent accesses via api etc, is fu***d, as who used browser plugins.
Good for you.
Therefore, blame your ISP for not giving you a dedicated IPv4 address.
IPv4 addresses are not unique anymore. As there are more humans (8 billion) than IPv4 addresses (4.2 billion), ISPs have chosen to route users together on an identical IPv4 address as more and more people want to get online. This technique is known as CGNAT.
Want no IP related trouble? Get a dedicated IPv4 address. Simple.
The issue is that a group of people, including you, on your ISP, triggers the API limit together. It's an IPv4 based limit. If your ISP is using CGNAT or DSLite, everyone suffers.
If you do have a dynamic dedicated (also known as public) IPv4 address, power cycle your router and possibly your modem (if cable) or ONT (if fiber) to obtain a new IPv4 address. If your ISP uses DHCP (which is commonplace in fiber), you'll have to wait until the end of the lease which can be multiple hours up to multiple days. At the worst, wait 7 hours.
If you have a static dedicated (also known as public) IPv4 address, you will have to wait it out, at least for 6 (better 7) hours. Unless you are a business or have a very expensive data plan it is VERY unlikely that you have a static dedicated IPv4 address. Those are usually reserved for servers.
If you are on CGNAT or Dual Stack Lite, tough luck. You will have to wait until the ban is lifted. Ask your ISP to give you a public IPv4 address (either static or dynamic). Commonly, if it is offered, then usually for a monthly surcharge.
If you use a VPN, stop doing so. You are violating the Steam Subscriber Agreement.
Additionally, if you are using an extension or a plugin which makes extensive use of the Steam API, cease using that extension.
You yourself explained there are not enough ips for everyone, and still propose to get and pay your own one, to solve a videogame-platform caused problem, so the richer kiddos can have their own private road to their inventories.
If in this planet something is not enough for everyone, how can getting your own dedicated one would solve a shared problem? This is the edge of the human sickness. This is the old way to punish who share resources, and whoever know the trick would go ahead of the others anyway.
There is no-one to blame outside of the platform way of doing things.
Valve has all the tools and instrument to limit per-user-account (the steam account) and not per Ips, but still they decide not to do it. An ip related limit can be easily circumvented, but an account one would not, so they are not limiting anyone outside of the unawared ones.
The accounts who want to abuse of too much requests, will continue doing it.
And as op stated, opening big inventories lock very fast an ip out, you just need only ONE big inventory to lock you out, with or without a dedicated ip, so that is not an ip shared issue, but a matter of how badly Steam detects over-load requests.
Ultimately, blame the fools in the 80s that thought there won't be 4 billion systems on earth.
Also, my ISPs do give dedicated IPv4 addresses. I never hit the issue on inventory lockout myself.
German Telekom assigns true dual stack (dedicated IPv4 address and dedicated IPv6 prefix) while E.ON Highspeed offers a dedicated IPv4 address (public dynamic IPv4 address) as an additional option for just 3 euros a month.
In the worse case (if your ISP doesn't offer dedicated IPv4 addresses at all), you can rent a VPS with dedicated IPv4 connectivity for 5-10 euros a month and make it a VPN endpoint. It will not breach the SSA if the VPS is in the same country of your residence.
Valve deliberately chose the IP address as the limit instead of the account because flooders would simply create new accounts to get around the limit.
If you want a quick solution, getting a dedicated IPv4 address is your only option.