Leaderboard
Popular Content
Showing content with the highest reputation on 08/28/21 in all areas
-
1 point
-
Gravity finally released the 4th class job sprites! Their maximum level is 250 and they will add new "status points" Some animations can be found in their youtube video. original post : https://divine-pride.net/1 point
-
Objective Load scripts not from your standard `rathena/npc` directory but instead, from a remote server via http/https. Design goals Parameters for NPC script loading would be: (a) remote http/https URL (b) support for request header for authorization purposes (e.g. API key) e.g. https://some-ro-developer.com/servers/some-ro-server-1/scripts/my-private-script?version=0 Authorization: Bearer <API token or key> The API token or key can be stored in a git ignored ENV file, so that unauthorized users don't have access to the source code Failure to download the script will result to no operation- warnings but not fatal server crashes The downloaded file must be a single `.txt` file The file is then hashed by the server, and cross-checked to ensure data consistency e.g. https://some-ro-developer.com/servers/some-ro-server-1/scripts/my-private-script?version=1.0.0&type=hash returns "70460b4b4aece5915caf5c68d12f560a9fe3e4" which should match the file's hash The file's existing supported versions can be checked (returns JSON array) e.g. https://some-ro-developer.com/servers/some-ro-server-1/scripts/my-private-script?type=versions returns ["1.0.0", "1.0.1", "1.1.0"] Caching - Can download the files into a git-ignored directory on the actual server for caching purposes If the requested file and version already exists in cache AND the file's hash matches the hash of the server, no need to download the file again NOTE: Not entirely sure yet if I want the download to be perform the caching, because it goes against the whole idea of "not having the source code on your server" aspect. Benefits By adding this source capability, we: enable RO developers who produce intellectual property (NPC scripts in this specific case) to have some control over their IP. NOTE: It is still possible for RO developer scammers to sell shady scripts/sell scripts that aren't theirs, grant their customers temporary access, and then remove access from their customers. enables RO developers to sell licenses to their IP, and revoke license (disable API token) after some validity period (e.g. 3 months). Opens up the opportunity for a monthly or yearly pricing of their NPC script licenses. enable RO developers to share their rAthena server folder to co-developers without risk of accidentally granting them access to other IP that they aren't supposed to share. e.g. RO Admin builds server. RO Admin buys 10 NPC scripts, with license to use in one RO. server. RO Admin hires RO Support dev. RO Support dev granted access to rAthena server files because they have work to do. RO Support dev now has access to npc scripts they didn't purchase, and is a vulnerability. Related source code Specifically, the following files need to be changed/extended: int npc_addsrcfile(const char* name, bool loadscript) - in src/map/npc.cpp Probably adding a new function called int npc_addremotesrcfile(const char* resource_url, char* resource_hash, char* resource_version, bool loadscript) - in src/map/npc.cpp Usage Potentially using it on an npc script would look like this: remotenpc: <URL> <VERSION> <HASH> remotenpc: https://some-ro-developer.com/servers/some-ro-server-1/scripts/my-private-script 1.0.0 70460b4b4aece5915caf5c68d12f560a9fe3e4 Thoughts I wanted to get the thoughts/vibe of the community before pushing through with this idea. I know that we're an open-source community that wants to encourage full-sharing of source code. But I think that the strict constraints that follows from that is something to consider. It limits the number of developers you can onboard onto your team, or needing to think about whether "you trust everyone". I think doing this (a) encourages developers to produce great NPC scripts, (b) enables developers to make good money on it, (c) positions rAthena or whoever to start up some kind of dependency management/NPC scripts platform (similar to npm, or composer) where server owners can shop for NPC scripts. Securely designed remote script access enable developers to focus on writing NPC scripts opportunity for NPC script customization layer developers can now easily scale up their marketing on some dependency management/NPC scripts platform well-paid developer happy developer more scripts happy community I will definitely be exploring this on my own, but I wanted to know what the community thinks about it. PS: Potentially a source of revenue as well for rAthena to sustain itself. I am open to the idea of assisting in the architecture design for that platform.1 point
-
1 point
-
1. if you are checking for total of item count in current inventory getinventorylist; dispbottom "Your inventory has "+ @inventorylist_count +" items"; 2. if you are checking whether the player can hold the upcoming rewards if (checkweight(512, 100)) { getitem 512, 100; } else { dispbottom "You cant hold 100x Apple."; }1 point
-
ItemDB -> YAML! As of Git Hash: 04cfe17, rAthena's item database has been converted to YAML! What this means: The item database being in YAML format means that the database is now much more human-readable. This allows for quick review, modification, and addition of items without having to memorize the CSV format or use any third party tools. The parser now also has much better error handling when reading items into memory so tracking down those pesky typos is a thing of the past! The update combines item_avail, item_buyingstore, item_delay, item_flag, item_nouse, item_stack, and item_trade databases into the item_db so there is much less searching around multiple databases when doing anything with items! As items are no longer defined in a single row, this means the flat file has grown in size. To ease the on load text editors for people's computers who may not have the horsepower we split the items as they are in game via Consumables, Equipment, and Etc. The Job restriction for items has been cleaned up so that custom masks don't have to be made and removes a horrible restriction for those adding custom classes to their servers. Now it's as easy as defining the EAJ_* constant... and that's it! The item combo system has had a massive cleanup in the background. We no longer do sketchy memory management and manipulation with a move to use standard libraries provided by C++11! As with any YAML conversion we have provided an option in the CSV2YAML tool built right into rAthena! Just build the CSV2YAML tool within Visual Studio or via Make and run the executable. The tool will provide you with general steps and convert your custom items right on over to the YAML format. No muss, no fuss! Something that was brought up in the Pull Request was the support for SQL. Many people were against the move to YAML because the support for SQL was compromised. Well, we are happy to say that SQL is still supported and isn't going anywhere! We've developed a new tool, YAML2SQL, which can convert the YAML item database into SQL format. This allows servers who utilize SQL to continue with this method. We've also gone a step further and provided a SQL View which will create a new compatibility table without breaking support for your Control Panel/databases. The SQL View is optional though once the Control Panel/database is setup to utilize the new table. The new and fuller item data in this table also provides much more detail to the item database than ever before! You can read more details in our README! What this means to developers: Pull Requests can be reviewed much quicker and much more simpler. Identifying the actual change to the item and easily verifying said change without having to count commas! Additional features being added to the item database no longer requires the development of a side database. A vast majority of the item data is now part of the item_db structure and can continue to grow in this format! Redefined Import System: Now that the item_db is in YAML format, the adjustment of items is much simpler. If a change is being made to an item only the parts that are being changed have to be defined in the import. Below are some examples: Adjusting Red_Potion weight to 10 and increasing the heal rate in the script. - Id: 501 Weight: 100 Script: | itemheal rand(100,120),0; Remove the Thief classes from being able to equip the Cap. - Id: 2226 Jobs: Assassin: false Rogue: false Thief: false Add a stack limit of 10 to Meat for inventory only. - Id: 517 Stack: Amount: 10 Inventory: true Check out the item_db documentation for further details! Thanks to @Lemongrass, @Capuche, and @Cydh for their help!1 point
-
Ever wonder why these random number show up in your RO game client? It's called Character Code (C-CODE), an old system that implemented around 2013. If you enable this system you'll be protected against fraud since it offers a unique additional protection for each player present in-game. As you can see from the screenshot above, there exists an extra set of codes (It show up int he basic information window, and the right-click menu of player object). According to KRO, these codes doesn't repeat/overlap and its unique for every players. It offers a unique additional protection for each player present in-game. When you right-click on any player object, the C-Code are shown at the last menu ([C-Code] : ### - ###) Its ranging from 000-000 ~ 999-999, around 1,000,000 set of codes. However its not confirmed that the numbers won't repeat itself if there are multiple server setup. Click on the menu, the C-Code will be copied to clipboard. Open up any text editor or notepad, press on CTRL + V, the codes will be shown in the editor. Notes: If you copied the codes, and take a screenshot right away, the codes will be removed from the clipboard. The codes are shown display behind character's level in the trading window. Sample of different C-Code for different characters. References: home.gamer.com.tw1 point