Beiträge von CYN3

    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 :D

    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.

    Wie siehts aus bzgl sicherheit? Wird konsequent drauf geachtet?

    Berechtigte frage bei den itemshops die bis jetzt gepublished worden sind, gab es den einen oder anderen Exploit. Natürlich wird auf Sicherheit geachtet. Da der einzige user-input das Kaufen des Items ist, müsste ich mich sehr bemühen dort so eine Lücke einzubauen.


    Erklärung zur Kaufoption:

    Jedes Item generiert beim "Reload" einen unique-hash, dieser hash wird beim kauf an den Server geschickt und dort wird

    1. Gecheckt, ob der hash zu einem Item gehört (hauptsächlich ist diese Funktion als Absicherung für den User gedacht, falls z.b. ein Admin mitten im Betrieb das Schwert+9 zu einem Schwert+0 ändert und der User kurz davor ist den "Kauf-Button" zu klicken. In diesem Fall geht der Kauf natürlich nicht durch und die UI des Users wird automatisch aktuallisiert.)

    2. Checken wir, ob der User genug Platz für das Item hat.

    3. Checken wir den Preis des Items und die Coins des Users, hat dieser genug Platz sowie genug Coins werden die Coins abgezogen, das Item gegeben und der Kauf ist beendet.


    Durch den minimalen Input des Users garantieren wir, dass es zu keinem dupe, coin Exploits oder sonstigem kommen kann. Da die einzige "DirectQuery" die aktiv ausgeführt wird, nur Coins abzieht und der Abzug abhängig von dem Preis des Items ist, wäre dort der einzige Exploit, wenn der Admin den Preis zu einer negativen Zahl ändern würde.

    Edit.: Der exploit mit einem negativen coin-price eines Items wäre damit auch ausgeschlossen:
    Bitte melden Sie sich an, um dieses Bild zu sehen.
    Edit2.: Oder so:
    Bitte melden Sie sich an, um dieses Bild zu sehen.
    Edit3.: Wenn admins einen discount über 100% geben würde könnte es auch zu einer negativen zahl kommen deswegen nutzen wir dort minmax:
    Bitte melden Sie sich an, um dieses Bild zu sehen.

    Itemshop-Category table is now also fully automatic.
    Disable/Enable category column will be added.
    Multilanguage systems will also be supported with a little config client-side.
    I´ll now start on the wanted features and try to make the UI-Design better.

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

    server-source -> pvp.cpp -> bool CPVPManager::CanAttack(LPCHARACTER pkChr, LPCHARACTER pkVictim)
    client-source -> InstanceBase.cpp -> UINT CInstanceBase::SHORSE::GetLevel()

    Stehen die Mounts mit drin, kann sie aber nicht auf dem Mount ausführen

    client-source -> instancebase.cpp -> bool CInstanceBase::SHORSE::IsNewMount()

    server-source -> pvp.cpp -> bool CPVPManager::CanAttack(LPCHARACTER pkChr, LPCHARACTER pkVictim)
    client-source -> InstanceBase.cpp -> UINT CInstanceBase::SHORSE::GetLevel()

    Hey, I'm thinking about writing an Itemshop (C++, Python only) for free, so I need some feature-ideas.

    Already planed:
    - UI based mainly on own classes (To prevent bugs from previous changes)
    - Item info (description - price - discount - sockets - attr)
    - Promotion-code system (Count & Time based)

    - Special offers (Count & Time based)

    - Dynamic categories

    - Search function
    - Payment option
    - Current coins
    - Show coins

    - Set sockets

    - Set attr


    Maybe:?::

    - RenderTarget Preview (This itemshop will be published for free so i have to write my own... sadge)

    Liegt hauptsächlich dran, dass leute Client-Source sowie Server-Source auf UTF8+ updaten müssen. Dazu kommen dann noch paar Sachen, aber die lasse ich mal als Überraschung für jeden, der sich auf die Suche nach dem OnePiece macht.

    GIbt auf jeden Fall Files die auf Python 3.11 laufen aber nicht public

    Hey, more systems will be added from time to time.
    Dont care if systems are public or still on sale.

    If you want a better UI-Design do it yourself.
    Code is by me, so don't even try to report.

    Systems do work on Fliegev3.

    No support.


    Renewal Regen:

    Advance Items:

    Mobile-Sell:

    Direct-sell:

    Inventory-sidebar:

    Add time to costumes:

    Minimap-Date & Time:

    Give item & equip quest-function:

    Auto-Pickup (Extension):

    Bitte melden Sie sich an, um diesen Link zu sehen.

    Discord: Franky#6315