Client Systems & Python UI
Metin2 Extended Sell: reviewed selection, confirmation and inventory checks
M2City Client · Editorial · Published 2026-11-05 · Branch-specific details should be checked against your own source.
Source merge kit based on the owner-supplied Extended-Sell Asky.zip, whose changelog ends at v1.0.3. Intended for developers who want players to select several bag items, review the estimated total and queue ordinary NPC-sale requests. The original archive is preserved separately for provenance. The recommended r1 path replaces its selection logic with two small Python modules and an end-to-end merge guide; it is not a ready client, an atomic server batch-sale implementation or a certified replacement for your whole shop UI.
Defects found and r1 changes
The original stores mutable lists of cell numbers, deletes while iterating with i-1, accumulates stale prices and interprets special-storage cells through one changing global category. Sell All reads whatever is now in those cells, without comparing the originally selected item. It sends the whole selection immediately and clears it without a delivery acknowledgement. The supplied full shop/storage examples also contain unrelated tab-index, lifecycle and optional-feature issues; do not overwrite maintained client files with them.
The r1 core uses (native inventory type, global cell) keys and immutable snapshots of VNUM, count, all sockets and all attributes. Selection changes invalidate confirmation. Missing, modified or newly unsellable items require a new review; a changed item during dispatch stops the remaining batch. Confirmations are single-use, and closing releases callbacks and cancels unsent requests. Optional storage windows must be explicitly configured; changing categories cannot reinterpret existing cells.
The default limit is 20 stacks, with a hard ceiling of 50. Dispatch queues at most one existing sale request per 250ms. Failed or uncertain sends are never automatically retried. The conservative legacy count ceiling is 255, invalid cells/types are rejected and the one-gold-price calculation handles a zero divisor. Preview values are estimated gross Yang, not guaranteed proceeds or a fabricated tax configuration.
Integration and compatibility
Install reviewed/root/bulk_sale_model.py and bulk_sale_adapter.py, then follow INTEGRATION.txt in your existing NPC-shop, inventory and logout methods. Add a standard Sell selected button and use the normal QuestionDialog for confirmation. Preserve current item, equipment, lock, exchange, shop-distance and server permission checks. The merge guide includes opening/closing, selection, confirmation, dispatch, buy-mode cancellation and account/phase teardown. It also includes a stock-texture button layout example. No new image download or custom texture is required.
The adapter expects typed GetItemIndex/GetItemCount(window,cell), typed socket/attribute getters and the existing SendShopSellPacketNew(cell,count,window) contract. Verify those exports and actual bag capacities in your fork. Start with the normal inventory; configure special windows only if both client and server already support them. Python syntax is compatible with the legacy 2.7 style, but executable tests here used Python 3 with explicit engine fixtures. There is no new database schema or server currency calculation.
Important protocol boundary
A client-side fingerprint check cannot eliminate a server-side race or distinguish an identical replacement item. The original packet identifies a cell, not an immutable item ID/revision. Strict atomic bulk sale requires a server extension with item identity, validation, acknowledgement and idempotency; that extension is not supplied here. Queued does not mean sold. Check inventory and currency after a rejection before manually trying again. Keep all server-side validation.
Validation
All ten supplied text/source files were read. Fifteen isolated tests execute the exact replacement core and typed adapter: separate inventory identities, duplicate toggles, cell/count limits, immutable snapshots, socket/attribute changes, stale confirmation, one-use proof, changed context, mid-batch changes, clock rollback, pacing, failed transport and callback cleanup. No supplied executable was run. No actual client rendering, full native client/server build or live sale was tested. Staging acceptance steps and rollback are included. The original skin and complete optional-storage examples remain reference material, not approved replacements.
Origin and rights
The supplying owner confirmed redistribution. Original notices remain; no blanket open-source licence or unverified author credit is invented. A same-title public listing from 2020 exists, but its download is login-gated and was not used. That establishes a related reference, not byte equivalence or authorship. No remote media or source was copied.
Editorial resource — M2City
Version: Owner-supplied legacy integration; M2City r1 (2026-11-04); exact fork unspecified
Rights: Owner explicitly confirmed public redistribution. Preserve original notices; no open-source relicensing.
Validation: All 10 supplied text files read. 15 isolated tests of exact replacement selection core/typed adapter: snapshots, invalid cells/counts, sockets/attributes, one-use confirmation, category identity, lifecycle, throttling and uncertain transport. No real Metin2 client/server/render/sale test; merge kit, not atomic server bulk-sale protocol.
Source: Owner-supplied Extended-Sell Asky, changelog 1.0.3; related public listing only
SHA-256: dbadf182ea57340ebc546c7281d4634b5e6de6ae9f6bcbf4d4823c2c6cd83bb8
Download package
3 download options · Sign in to download
metin2-extended-sell-m2city-r1.zipM2City downloadmetin2-extended-sell-m2city-r1.zipGoogle Drive mirrormetin2-extended-sell-m2city-r1.zipMEGA mirrorMAKE THE NEXT ANSWER BETTER
What happened on your build?
Share a small example, the exact error and how you verified your fix. The discussion is open on the forum.
Need a scoped quest, UI or proto fix? · Explore more development guides · Check your proto files free