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.
Beiträge von CYN3
-
-
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.
-
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. -
Itemshop base functions are almost finished.
My UI-Designs suck, i know, it will be improved in the release version.
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()
-
Some ideas are weird, some just QoL. Maybe none of those are interesting for you, but could inspire you.
- Being able to place limited, timed offers in advance, as many as i like. So that i can theoreticly plan christmas for the next 3 years (maybe same as your "special offers")
Could be no problem unless anyone knows how to set timezones on freebsd- Being able to place discounts by price. Every item that is higher then 15€, gets a discount of 10%. So you don't have to think alot about the perfect discounts. This would be universaly for all items in the shop or per page.
I have to think about that one, i would like to have 1 clean config table, but we will see.- A sort function, so i can sort for "most bought", "lowest price", "highest price", "newest", "oldest", "least time left" (for limited offers). This would ignore the selected categorie and show instead a page with all items combined. Or you make it per page.
Also no problem.- A shopping cart, so people can put in a lot of things and get a discount at checkout (toggleable)
Sounds fun but we will see how usefull it is, admins want users to fuckup there calculations so they have to spend multible times. But i´ll implement it with a define.- A gift option, so i can transfer a bought item to the itemshop inventory of another player, with a timed option (as example: if someone has birthday tomorrow, the item gets delivered that day)
Great idea!- A option, where you can preview the items on your own character, only locally for you visible. Especially great for effects like shinings.
I would like to add an renderTarget addon but there are so many versions with different modules out there.- A option for the player, where he gets a in-game message if a item he whitelisted has a discount (email would be great too, but should be toggleable and deactivated by default)
I´ll think about it- Lottery, where people can buy a ticket for 0,50€ (configurable) every day (configurable) and have a chance to win a high priced item from the shop or coins. The lottery number (as example: 241 (max 500, configurable)) must be put in by the player manually. If nobody hit the right number, the price stacks on the lottery next day.
I´ll maybe release a version like "Age of Magis" used. -
-
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)
-
Added <Advance Items>
-
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 -
Added <Add time to costumes>
Added <Minimap-Date & Time>
Added <Give item & equip quest-function> -
Added <Auto-Pickup (Extension)>
-
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
-
Some people would say: "There is no such thing as 'free service;'"
I think those people just did not get the cocept of advetising -
__AppendSearchIcon is not defined
-
Table neu erstellen und die Engine immer auf MyISAM
- > /account/blocked_hwids