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.
Beiträge von CYN3
-
-
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 -
So wie ich es mitbekommen habe, ist das Projekt noch von vorne bis hinten verbuggt, selbst eure gehypten beta Spieler denken, dass ihr später starten solltet. Bin mal gespannt, ob ihr es hinbekommt und den Hype wieder für euch gewinnen könnt.
-
Zitat von 'AsaselIch 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. -
- Cross-core works
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 pageBitte 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.
-
Wird es auch single-use codes geben? Sprich 1 mal einlösen und danach ungültig
Klar, musst den useCount nur auf 1 setzen
-
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! 
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.
-
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. -
SELECT account, companion FROM messenger_list" WHERE account='edward95'
-
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 verschwindetEs 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.
-
Current itemshop state:
- Added hot-offer animation
- Added auto special-offer function
- Special-offer do work on "reload" and on "boot"
Note: We are working with UNIX so embrace timezones
Bitte melden Sie sich an, um dieses Bild zu sehen. -
ist das count input feld sicher gegen abuse? Ich bin ja nicht so der fan von input feldern an stellen wo eine vorgefertigte auswahlmöglichkeit auch reichen könnte
Was kann man denn da abusen? Ein Inputfeld ist ja genauso abusable wie sämtliche Daten die du vom Clienten an den Server sendest. Ich denke, solange man Serverseitig den Input vernünftig escaped / handled, sollte es keine Probleme geben
Danke für die Antwort, habe gerade auf den Bildschirm gestarrt und mich gefragt, wie ich die aussage angehen soll.
Aber um ihm seine Angst zu nehmen, meine Antwort:
1. <Antwort von Steap einfügen>
2. Du hast vermutlich Erfahrung bei anderen Leuten gemacht, die entweder den Datentypen, den sie nutzen, nicht verstehen oder davon ausgehen, dass nur die Values beim Server ankommen, die sie gerne hätten. Indem fall ist es nur der Count. Wir prüfen hier auf count <= 0 , ((itemcount* count) / itemcount) != count und count * stackcount > STACK_MAX
-
Current itemshop state:
- Adjusted item-info display
- Removed itemshop reload from init_proto
- Added init_itemshop to CClientManager
- Added "/reload i"- Adjusted price calc
- Changed force socket function for LIMIT_REAL_TIME & LIMIT_TIMER_BASED_ON_WEAR.
- Added max(1, price) to prevent free items because of discount.
- Added price * count overflow check. (if item price is over 0xffffffffffffffffui64 for some reason)
- Changed item-price to unsigned long long.
- Added ENABLE/DISABLE categorie to itemshop_categories.
- Adjusted UI to prevent errors after disabling used category.
- Adjusted itemshop reload function to proper clear categories and items.
- Added "buyinfo" close if itemshop gets reload.
Bitte melden Sie sich an, um dieses Bild zu sehen.
Bitte melden Sie sich an, um dieses Bild zu sehen. -
Current itemshop state:
- Adjusted some UI elements.
- Added buy count with max stack.
- Added coin display.
- Added some flag / antiflag related checks to buy function.
- Adjusted price calc for discount with count:
Edit.:
max(1,floor(itemInfo.ullPrice - (itemInfo.ullPrice / 100.f * discountPercent))* wCount
Bitte melden Sie sich an, um dieses Bild zu sehen. -
Das Problem ist halt das es zig Verschiedene Schulterbandsysteme, Offlineshops etc. gibt. Am einfachsten fände ich wäre eine art Abfrage wie beim Lager (IsSafebox) zum Beispiel. Das wäre nur eine Abfrage im System und diese Zeile könnte man dann beliebig um seine Abfragen erweitern.
ja wegen der verschiedenen varianten hab ich mein beitrag mit dem teil „schnittstelle bereitstellen“ ergänzt, wo man dann eben auf sein jeweiliges system anpassen kann, ohne vorerst die groben funktionen dafür im Is selbst noch hinzu zufügen
Ich nutze nur die CreateItem funktion aus dem item_manage, solange diese angepasst ist, sollte alles passen.
Für Sockets & Attributes nehme ich im moment SetSockets & SetAttributes, für sachen wie time-based items wie Kostüme werde ich vermutlich einfach die sockets einzeln checken.
Ein socket oder attribute wird erzwungen, sobald er im itemshop_item table gesetzt wurde.
Um so Probleme zu entgehen, kann ich z.b. folgendes machen:
Wenn das Item einen limit type wie z.b.: LIMIT_REAL_TIME hat forcen wir den socket nicht, sondern adden nur, in dem fall dann Zeit.
Systeme wie offlineshops, schulterband Systeme oder sonstiges sind in unserem fall irrelevant.
