Jump to content

The_X_

Member
  • Posts

    5
  • Joined

  • Last visited

Everything posted by The_X_

  1. Okay... What do you suggest doing with this legacy logic? Perhaps you could simply call the method for obtaining the actual item skin and link your outdated logic to it? Or, you could decide not to do anything related to changing the plugin and provide the product ‘as is’?
  2. Hello! I am writing here to make a small request. In its current version, the plugin is heavily dependent on the presence of a skinid for an item, which is essentially a flawed idea. A custom item is a combination of a short name, skin ID, and item name. Relying solely on the skin ID invariably leads to problems. For example, I use CID for custom items as a single control centre for all items. The key for it is the short name, and the skin ID for custom items is generally 0. It would be great if you could add a more detailed configuration for custom items, linking to the full description of the ‘item definition’ instead of using only skinid. If this is not feasible, then at least add a checkbox, similar to ‘CID’, which separately takes the custom shortname of items for CID. In general, the ideal option would be if you could register custom items for CID from your plugin, as at least one of the options. Then you wouldn't need to have some kind of plugin layer that registers items for the library, and you would control the items directly from your plugin. Thank you in advance!
  3. Hello! I would like to make a small request. The plugin works, in general, strangely from the administrator's point of view (I don't understand the logic of displaying not all items for addition and implementing an unclear search by shortname), but from the user's point of view, there are almost no complaints. However, could you add more correct CID support? In version 2.* of the library, the names of items have become localised. In your plugin, you use something like `displayName?.english`, where cid stores the base message (without translations). It usually looks like: ‘“example.shortname” in lang file'’. Could you add an optional dependency on CID, which, if present, would pick up the localised item names for the current user? If you could also pick up the item description, that would be great! Also, could you please make the item name field ‘erasable’? If something is accidentally entered there, then that name will be applied to the item itself. And when erased, a ghost effect of such a save remains. As if it is trying to put an ‘empty’ name. For CID, the Name field in the plugin should not interfere with the item itself, but only personalise the name displayed within the plugin, without affecting the item. A quick search even revealed that CID has a simple API method for obtaining a localised name. The first is by the usual user ID, the second is by directly specifying the language for translation: private string GetTranslatedDisplayName(ItemDefinition customDefinition, ulong userID) private string GetTranslatedDisplayName(ItemDefinition customDefinition, string languageOrUserID)
    Amazing Plugin! The interface, at first glance, seems quite complex, however on the very first attempt to work with it, it turns out to be intuitively understandable. All elements are located exactly where they should be. Editing loot tables is intuitive, yet very flexible at the same time. You can configure individual item drops, blueprint drops, as well as item "categories". Regarding the default loot table, as some reviews point out, it doesn't match Rust's default table. I categorically disagree with this - even with minimal research, I discovered that when loot isn't specified as custom, the developer simply calls Rust and asks it to fill the loot instead of the plugin. This is the most correct logic possible. I've also seen comments regarding plugin performance, referring to high Hook Time. I don't know since when this became an indicator of plugin "performance" when this can only be discovered through actual observations, but it's probably high. No actual performance impact was detected. Whether the plugin is there or not, the server doesn't really care. The plugin takes control exactly at the moments it should, and timely returns control to the game for everything else. From the downsides, due to how much the developer has to display within Rust's standard toolkit framework, the interface sometimes "freezes". This doesn't affect server performance at all, and is solved by simply reconnecting to the server. Stack Sizes Feature Additional functionality, such as Stack Sizes, seems like it will be implemented as secondary. But the stack editing is done so well that you could say it's a plugin within a plugin. The item list is dynamic - the plugin doesn't need updates every new wipe. Each individual item is configured both separately and as part of a "unified whole". You can take standard stack sizes and multiply them by a certain number with one value. Immediately for all items. This same option is available for each separate item category. If some item that has multipliers applied also has a manually set stack size, the plugin will handle this correctly, choosing exactly the manually entered size. From the downsides, when there are quite a few items in a category, they're divided into several pages, and finding a specific one requires some effort and visual representation of the item icon you want to edit, which can be inconvenient. But in version 2.1.15, the developer added a search bar, which completely solves the problem of finding specific items. Custom Items Manager The built-in custom items manager seems quite flexible. It automatically picks up the most trivial custom items, allows adding new ones, and accordingly the entire loot table now assumes the existence of such items and the possibility of their drops. LoottableAPI Integration At some point while interacting with the plugin, I faced a task - I needed to configure a very large loot table in ANOTHER PLUGIN, and that one didn't provide Loottable support. And it even blatantly ignored standard loot, deleting box contents and rewriting it with its own. This is, at the very least, inconvenient. I thought to myself that the effort to configure loot would be much greater than the effort to manually add Loottable support to existing code. I went with the second path, and very successfully discovered LoottableAPI in the plugin description. This is essentially ready-to-use, modular code that provides a simple and static interface for adding support to ready-made code for configuration through Loottable. The developer even wrote an example that, in a maximally simplified yet clear and precise way, demonstrates the working principle: Register presets for NPCs/boxes Assign the preset when spawning a box or NPC Total additional lines of code needed for any plugin, including the ready-made code provided in the description: 100-150 additional lines. I've currently added interface configuration to 18 plugins, and everything works stable as clockwork. There was a problem that with more than 6 plugins configured through Loottable, the display of new plugins started breaking (the developer didn't expect someone to have more than 6 plugins configured through Loottable), however in version 2.1.16 the developer added multi-page functionality to this section, and the problem resolved itself. Developer Appreciation Special thanks to the developer. Such responsiveness, it seems, is rarely encountered. I personally needed correct work with Custom Item Definition (CID) for my purposes. I knew that in version 1.1.6 stacks were properly fixed to work with custom items. And indeed, there were no problems with stacks. However, several small details were discovered where the plugin incorrectly handled CID. Simply collecting them into a single bug report and informing the developer, already in the next update the developer quite extensively fixed the plugin so that it would completely correctly load custom items. And all this - from just one bug report. Now the plugin works perfectly with CID, and I'm confident that if any problems still surface, the developer will fix them. But this is individual experience. It's also worth noting that the developer constantly updates the plugin, adding various QOL functions. For example, in update 2.1.15, the developer added multiple item selection. This is a small detail that could be done without, but it improves user experience and accordingly the overall impression of the plugin. Huge thanks for such excellent work! P.S. Review written at the time of version 2.1.16. On this version everything works as described in the review. If suddenly the developer goes crazy, breaks all plugin performance, gets rid of all useful functionality, I'll definitely update the review xD
2m

Downloads

Total number of downloads.

9.5k

Customers

Total customers served.

138k

Files Sold

Total number of files sold.

2.9m

Payments Processed

Total payments processed.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.