Beiträge von CYN3

    Wozu eigentlich der ganze Hash Kram? Ich kann mir auf die schnelle überhaupt keinen Anwendungszweck im Item Shop dafür vorstellen, außer als Identifier oder ähnliches. Sowas ginge aber auch ohne Hashes. Belehren Sie mich

    Es war eigentlich dafür gedacht, dass wenn ein Spieler z.b. das ein Schwert+9 kaufen will und der Admin aus dem Schwert in der DB ein schwert+0 macht aber das packet zum kauf schon raus ist mitten im reload das der spieler dann nicht ausversehen das +0 schwert kauft. Was aber im aktuellen design nicht wirklich passieren kann aber sicher ist sicher. Eine art random index muss sowie so rein.

    Current state:
    - Added promotion-code answer packets
    - Added promotion-reward fadein animation
    - Added answer text to promotion-code UI

    - Added some checks to prevent bugs if admins use item count < 1
    - Adjusted binary "py-object build" loops
    - Adjusted UI animations
    - Added limited count badge
    - Added new badges for items with discount
    - Hide/Show item increase/decrease button if min/max value
    - Adjusted limited-time animation color
    - Added check to "OnType" event in editline to prevent error if event not set

    - Adjusted itemshop hash to "random" MD5 hash

    Next:
    - Replace "popup" promotion-code reward animation
    - Code refactoring if needed
    - Create list in itemshop.py for fast multilanguage adjustments
    - Create tutorial for "ENABLE_ITEMSHOP"

    Wir geben unser bestes um dieses Projekt an die Spitze zu bringen. Das wir so viele Fehlermeldungen hatten ist auch irgendwie klar wenn man bedenkt das wir Juni 2021 auf komplett neuen Files angefangen haben zu basteln. Das war früher auch gar nicht gedacht das wir das Konzept so weitern. Wir haben beim Spielen selbst bemerkt das es langweilig ist und haben uns dann entschieden etwas mehr Content einzubauen. Bei der Menge an Content häufen sich nunmal auch Fehler an. Die wurden in der Beta gemeldet und wir beheben diese alle bis zum Start :)


    Ich wünsche euch viel Erfolg und hoffe ihr packt es bis zum Start alles hinzubekommen. Viele denken, die Beta wäre dafür da das erste Mal nach Bugs zu suchen & sie zu fixen, da bin ich aber anderer Meinung. Die Beta sollte da sein, um den Spielern schon mal den Server vorzustellen & letzte Anpassungen zu machen. Jeder qualitative Server der dachte "Wir fixen das in der Beta" hat versagt, weil sich meistens zu viele oder zu große Bugs ansammeln, die gefixt werden MÜSSEN, während der Hype langsam stirbt. Aber ich vertraue darauf, dass ihr alles bis zum Start hinbekommt, falls der Start nicht glattläuft werden die User euch genau das vorwerfen.

    Current state:
    - Added category-listbox sort hierarchy -> lower index = higher UI pos

    - Added item-listbox sort hierarchy :
    First -> limited-time items
    Second -> limited-count items
    Third -> discount items
    Fourth -> weight
    Fifth -> vnum

    Current state:
    - Added random items to preview landing page
    - Adjusted promotion-code design
    - Adjusted listbox & scrollbar
    - Added editline to stackable items & not limited count
    - Added -/+ buttons to stackable items & not limited count
    - Removed "BuyInfo" page - > Add little popup to prevent missclicks

    Next:
    - Adjust limited-count & limited-time effects.
    - Add animation for promotion-code rewards.
    - Add some checks to random-items to prevent errors if itemshop has less than 4 items.

    Bitte melden Sie sich an, um dieses Bild zu sehen.

    Current state:
    - Removed "AddViewer" functions
    - Added category-sort into binary
    - Added force-flush before "/reload i"
    - Added itemshop packet cooldown if invalid action (To prevent query-spam without paying for it xD)
    - Added promotion-code cooldown just because
    - Started implementing new design
    - We only use .sub files so if you want to adjust something you only need to edit 1 dds file

    Bitte melden Sie sich an, um dieses Bild zu sehen.

    Für mich sieht es eher danach aus das m_vec_itemTable im clientmanager bei dir nicht den richtigen size hat bzw. weniger ansagt als er schickt. Daher verkackt er den decode und hat keinen size mehr. Ohne deine changes zusehen ist es schwer zusagen.

    Er nimmt den size vom vector und erwartet dessen anzahl * TItemtable, solange TItemtable beide aus tables.h kommen sollte es da eigentlich keine probleme geben außer du hast irgendwas gelöscht. Du hast in TItemTable vermutlich gold und shopbuyprice auf den neuen datentypen geändert aber das sollte keine probleme machen solange es die selbe struct ist. Er könnte natürlich auch in der init funktion vom item_proto table abkacken und der vec hätte den size 0 und daher beim decode einfach die daten vom nächsten table bearbeiten wollen aber dann sollte es eigentlich einen anderen error geben

    Du musst in clientmanager_boot.cpp den size von yang beim auslesen von gold & shop_buy_price auf den size von deinem gold ändern. Er erwartet vermutlich noch den alten und bei der annahme im game-core weiß er nicht was zur hölle du ihm schicken willst

    Edit.: Schau dir auch mal in input_db.cpp -> void CInputDB::ReloadProto(const char * c_pData) das encoding von der item_proto an, da ist vermutlich auch was falsch

    Zitat von 'Asasel

    Ich gehe auch mal davon aus, das eine feste wahl schwerer zu manipulieren wäre als wie ein offenes input feld. Da ich aber jetzt nicht weiß wie das hier alles umgesetzt wurde kann ich das an dieser stelle auch nur vermuten

    Das hier finde ich etwas fragwürdig. Das habe ich privat in der Szene schon ziemlich oft lesen und hören müssen. Es geht ja nicht darum, jemanden die Manipulation zu erschweren. Es geht darum, die Manipulation Ausnahmslos zu verhindern. Du würdest doch nicht mit einem Server starten, wo du Exploits zwar ausnutzen kannst, es aber sehr schwer gemacht wurde, oder? Wenn es mir wirklich danach ginge, ein System sicher zu gestalten, würde ich es wahrscheinlich drauf ankommen lassen und einfach ein Inputfeld nutzen. Ich will ja wissen, ob mein Server sicher ist oder nicht. Außer, es sieht beschissen in der UI aus. Sicherheit sollte für dich die höchste Priorität sein, nicht für den Spieler.


    Die praktischste (nicht schönste) Designentscheidung wäre wahrscheinlich eine Mischung aus Inputfeld und Buttons.

    Selbst wenn in z.b. einem User-input ein overflow exploit oder eine sqli ist merken es die wenigsten, weil dafür einfach die checks fehlen. Solange der core dabei nicht abschmiert und leute debuggen kommt es meistens auch nicht raus und solange wird Yang und ggf dupe items auf epvp verkauft.

    Nochmal zum thema input / button -> Ich werde für beide cases optionen einbauen. Sprich es wird input & +/- button geben kann beides visuell enabled werden oder die eine oder andere option bleibt hidden.

    Current state:

    - Added real cache for items with limitedcount.

    - Re-wrote Listbox (item_count x & y added).

    - Re-wrote most UI-classes used and added them to uiitemshop.py.

    - Added "RemoveSingleItem" instead of refreshing all items.

    - Adjusted "ReloadSingleItem".

    - Re-wrote "AddViewer" (We can probably remove it, because we don't send little updates to client if user not viewer, so we have to send all current items when opening the UI. So overall, we send more packets this way. <- But nice idea for offlineshop systems). <- Revert

    - Fixed OnMouseWheel events on listbox items.

    - Adjusted "Main" RecvItemshopPacket to optimize python object.

    - Added some promotion-code checks to return in some cases before sending db packets.

    - Re-wrote DG init function for itemshop tables & promotion table (now readable xD).

    - Adjusted main python class.


    Next:

    - Designer is still working, but looking good so far.

    - Separate some uiitemshop functions to make it easier to implement addons / updates. main python class

    - Add better tooltip function to display item informations.

    Current state:
    - Added promotion-code cache.
    - Promotion-codes can only be used once per account.
    - Removed cmd & added CG packets
    - Added promotion-page

    What happens next:
    - My designer is currently working on a blueprint for me to build a better UI:
    - Start-page with event-banners
    - Buy-Page

    - Promotion page

    - Promotion-page gets an animation for each item given.

    Bitte melden Sie sich an, um dieses Bild zu sehen.

    Current state:

    - Added single item update packet
    - Adjusted for_each_viewer

    What we do next:
    - Adjust hash function
    - Adjust UI-Design
    - Implement promotion-code page


    Bitte melden Sie sich an, um dieses Bild zu sehen.

    Current state:

    - Added GD checkbuyitem.

    - Added DG answerbuyitem.

    - items are now cached on db-core.

    - game still gets items, so we can check there before sending db_packets.

    - Added "SetViewer" (When a player opens the itemshop he gets added and removed if he closes the UI or character instance gets destroyed).

    - We check itembuy before sending db check and after to prevent exploits while packets are sent.

    - Limited-count items are cached and flush every 5 seconds


    What we do next:

    - Add waitlist for reload itemshop command to flush cache first then reload

    - Rework UI for single-item update (So we don't have to update listbox itself)

    - Adjust itemshop_packet for single change updates

    - Maybe move most db code from clientmanager.cpp into own instance

    Bitte melden Sie sich an, um dieses Bild zu sehen.

    Generell schon sehr cool das du das machst und vor allem auch noch kostenlos anbieten möchtest, würde es persönlich aber noch besser finden wenn du beispielsweise das offizielle Itemshop Design benutzt und deinen Code dahinter packst. Dann musst du a) selbst nicht groß etwas designen und b) hätte man einen an den sich die meisten Spieler schon gewöhnt haben :) Aber wie gesagt auch so schon sehr cooles Projekt, weiter so! :thumbup:

    Keine Sorge, ich werde das Design 1x in "metin typisch" aus Standard-klassen und 1x in neu designt posten, damit jeder für sich entscheiden kann. Aber ich bin ehrlich, hätte ich die Idee von Anfang an gehört, wäre es vermutlich dazu gekommen. :sweat_smile:

    Current itemshop state:
    - Added remaining time to hot-offers UI
    - Added promotion-code prototype

    Current promotion-code state:
    - All promotioncodes are cached
    - Dynamic reward count
    - Code will be useable once per account
    - We dont use Querys outside of "save-cache" functions
    - Promotion-code page will be added to itemshop UI as new TAB

    What will happen the next days:
    I had to think about the way the itemshop works at the moment because some of you guys want limited item offers.
    I´ll move most of the code to the db core to get rid of desync problems with limited offers between cores.
    Game-core will probably have just the item-create function.
    Also there will probably something added like "AddViewer" so we can reduce update-packets.

    Bitte melden Sie sich an, um dieses Bild zu sehen.

    Limitierte items mit sichtbarer restanzahl find ich auch nh coole idee


    limitiert in form von maximale käufe oder nach zeit, wo es an datum xy aus dem shop automatisch verschwindet

    Es verschwindet bereits automatisch aus dem shop, das Gif ist nur scheiße geloopt.

    Habe mir etwas Gedanken gemacht über Items mit limitierter Stückzahl, und zwar wäre es möglich es über eine art "returnquery" einfach zu regeln so wie z.b. das ändern des Lagerpassworts. Das einzige Problem was ich aktuell sehe wäre, dass ich nach jedem Kauf des „Limitierten“ Items global 'nen ItemshopUpdatePacket schicken würde, was ggf. 'nen packet-cross fire sein könnte, wenn viele Spieler in einem kurzen Zeitraum das item kaufen.


    Notfalls könnte ich es nicht "OnBuy" updaten, sondern eher in einem internal, aber die Lösung gefällt mir nicht wirklich.