-
Posts
26 -
Joined
-
Last visited
BB1984's Achievements
-
Setting the item name based on the skin is not exclusive to Skinner. Consider making this check an option.
-
Skinner from Whispers88 is the skins plugin I use. You can find it here on Codefling. It's worked fine for the past couple of years and hasn't had an update since February, well before we started to see stacking issues. It does have an option to set item display names based on the skin, which is a feature we use. However, Raidable Bases and AlphaLoot also have the option to randomly skin items and they do not change the display name. So we have identically skinned items that otherwise should stack, but do not because the item names are different. I assume this is a result of stricter checks you added, and I can work around it by removing the item name comparison in CanStackItem. I guess the question is why the name check is necessary. Of course, the aforementioned stacks of c4 obviously weren't skinned so I don't know why removing the name and text comparisons allowed them to stack, but I only heard of that happening twice.
-
Maybe I'm misreading your request but the max protection time setting basically does this, doesn't it? If you set a limit of 48 hours, someone with TC access will be forced to log in and add scrap within that timeframe in order to keep offline protection active. -
Sorry for the delay -- I never got a notice you had replied. I spent a little time tracking down problem stacks and it did seem to be an issue with item names, mostly items with names set based on the applied skin (for example, "Assault Rifle" vs "Blackout AR", even though both have the Blackout skin and would otherwise stack). I'm using Skinner as the skins plugin and AlphaLoot for most loot creation. Raidable Bases creates the rest of the loot, so the Copy Paste plugin could be the source of the problem items, although I think Raidable Bases is set to delete existing loot before creating its own. I will check that. Mainly wondering if one of the recent changes to StackModifier regressed the custom names skin fix from way back in 1.1.9. Commenting out the item.name and item.text comparisons in CanStackItem and the Industrial Patch seems to return everything back to the stacking behavior we had before, but I assume you added those checks to fix stacking behavior on some particular item(s). I couldn't figure out the c4 stacks I mentioned since they can't be skinned, but removing the name and text comparisons apparently did allow the stacks to merge when dropped on the ground. I would have liked to examine them further to see what was set, but didn't see your commented out "checkme" command until later. That's been a help with testing.
-
While most of the stacking problems seem to have been fixed with 2.5.5, I'm still getting a few reports of odd behavior. Some players have two stacks of the same skinned item, but cannot combine these stacks despite the items having identical skins and conditions, or no condition, like with pants and hoodies. You can pull items from one stack and put them back in the same stack, but you cannot combine these stacks or move items between stacks. Changing both stacks back to the default skin, and then skinning back to the initial skin, DOES allow the stacks to combine. I initially thought it may be something with crafted items that were later skinned versus looted items with random skins pre-applied, but then someone showed me the same thing happening with two stacks of c4, so that mostly ruled out any skin-related theories. I haven't been able to identify the cause yet, and there are no errors in the console log. Any thoughts on what attribute or property might be different to cause this?
-
Since the 2.5.3/2.5.4 update, there have been reports of item condition being reset to 100% in certain cases. I was able to reproduce it by stacking guns that have identical, but less than 100%, condition. Let's say I have 4 AKs, each with 90% condition, and I stack them. If I pull an AK off the stack, it now has 100% condition instead of the original 90%. (As an aside, I don't recall if we could stack items with less than 100% condition before, but allowing it for items with identical condition is what I'd consider the correct behavior, so I'm not asking for that to change.) I think I saw this happen with other items as well, but I only specifically tested guns. Can you reproduce this?
-
After a couple of days running with the 2.5.4 update, I can say that it fixed the stacking issues we were seeing. Thank you! There may be a new issue with item condition being reset to 100% in some cases now, but I'll open a support request for that.- 162 comments
-
- 1
-
-
- #stacks
- #rust stacks
- (and 16 more)
-
I ended up going back to 2.3.9 for now, but I did notice with 2.5.2 that some of the items that refuse to stack will stack if dropped on the ground. After you pick up the new stack, you can then put it in boxes and backpacks and it behaves properly. Not a solution but maybe a workaround that can be mentioned to your players.
-
I did have a server restart shortly afterwards and didn't hear about any issues until after that, but that doesn't mean much. I'll see if I can reproduce it on my test server later, but I wouldn't be surprised if it was just certain stacks that had been messed with between the plugin upgrade and the restart. Thanks for the suggestion.
-
I haven't noticed an issue with pumpkins yet, but after installing 2.5.2, I'm seeing something similar with attire, weapons, and attachments (so far). Most items stack normally, then there will be a single item or a small stack that will not combine with the other stack. Items are identical as far as skins or new condition, if applicable, but some apparently hidden attribute is preventing them from combining in one stack. Putting the stacks into a box or a backpack will allow a few more of the stacks to be combined, but not most. I may need to roll back to a previous version to test the problematic stacks.
-
"losttitle": "You have lost the title {0} to {1}." The variables for this message are swapped. I thought I had seen this mentioned and fixed a long time ago but must have been mistaken. I recently replaced my customized lang file with a freshly generated one from 2.2.7 and it still had the problem. -
Yeah, almost identical experience for me. This plugin has always been a big hit to performance but got worse sometime before the Rust water update, which then hurt performance even more. I still ran it on some maps for a while afterwards but that huge fps hit to single digits after some random amount of time made it unusable. Unfortunate -- it was a neat idea for a plugin and fun when it worked. -
I like the idea of the new "Founder Limit" option to limit the number of protected TCs, but currently it's difficult to manage. Could you add the ability for players to choose which TC(s) are protected through some mechanism like the Pause button or something similar? With the limit set to 1, for example, players have been losing track of which TC was the first and not being able to protect a different TC as a result. A method to set (and clear) a specific TC as counting against the limit would be great. Even just a command for a player to clear protection on all owned TCs so that the next one placed would be protected would help.
-
It's also sold on the chaoscode.io site. Perhaps you bought it there?