-
Posts
35 -
Joined
-
Last visited
Content Type
Profiles
Downloads
Forums
Store
Support
DOWNLOADS EXTRA
Services
Everything posted by BB1984
-
Following up, looks like any time the Safe Zone option is enabled, all online AND offline players need to be in a safe zone. If I remove the sleeper's FindMonument check in the 2nd part of InOrSleepingInSafeZone, I get the behavior I'm looking for. Since InOrSleepingInSafeZone only seems to be used in CmdFlagPvp in the "Requires Safe Zone" section, I'm not sure if that's intended behavior? Even if we wanted sleepers to log out in a safe zone to make this work, wouldn't they be killed after 20 minutes anyway? To recap, when team sync is enabled, I'm hoping to have the safe zone requirement only apply to online players. I can open a support request if that would be better at this point. -
Yeah, that's what I was seeing, at least with the safe zone option on. The team leader gets the "all members must be in a safe zone" message and can't change the mode. If it should be working, I'll do some more testing and see if I missed something. And to be clear, this is changing the mode for an existing team with /flag, not an initial team sync when a player joins. Haven't specifically tested that part -- it may handle offline players just fine.
-
Is it possible to have some combination of settings where a team leader is able to change the mode of all players on a team, whether online or offline, while SyncModeWithTeamMembers, RequiresSafeZone, RequiresNoHostile, and RequiresTeamLeader are all true? Looking to at least have the team leader be in a safe zone and able to change the entire team, but if all online members also have to be in the safe zone, that's fine too. It's the offline members that currently seem to throw a wrench into things.
-
I apologize. I could have been a little clearer up front but I assumed you knew or could easily see what the +oxide.directory switch did.
-
My oxide folder is at server identity level, as I said: "root/server/<identity>/oxide/config" for the config files. Perhaps none of your other 500 users use the "+oxide.directory" switch or Carbon's "-carbon.configdir"; if so, lucky you. In any case, your code is making assumptions and you will hear from others eventually. Good day.
-
From the bit of searching I did, having the oxide folder at server identity level is not particularly uncommon and is exactly the use for that switch. It breaks nothing that was written correctly, although with the Oxide sandbox having been removed relatively recently, I suppose there could be some other code out there now using System.IO and making assumptions about the config file location. Anyway, I thought perhaps it was something you forgot was an option and might want to know was an issue, but if not, perhaps it'd be good if you put a notice somewhere that this plugin only works when Oxide or Carbon is in the default install location.
-
The new config path code in version 1.0.5 fails if "+oxide.directory" is used to keep the oxide folder anywhere but the server root. I assume the Carbon switches that provide the same functionality would also break it but have not tested that.
-
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.- 186 comments
-
- 1
-
-
- #stacks
- #rust stacks
- (and 22 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? -
Looks like brutalist is yet another stone skin, not hqm. -
The limitentities.admin permission added in 2.0.9 isn't being registered by the plugin. Are we supposed to create a permission in the config with that name, or was it just overlooked and not added to the RegisterPermissions() function, like the immunity permission?