Mr01sam
-
Posts
1,610 -
Joined
-
Last visited
-
Days Won
28
Content Type
Profiles
Warranty Claims
Downloads
Forums
Store
Services
Downloads Plus Support
DOWNLOADS EXTRA
Everything posted by Mr01sam
-
You are correct, if you disable TruePvE that will resolve conflicts - but you don't have to disable all of TruePVE, you only need to disable that parts that WarMode already covers. The rule of thumb for managing conflicts is you dont want two plugins trying to do the same thing. So for example, if you want TruePVE to handle player damage but you want WarMode to handle raid damage, then you would turn off player protection for WarMode and you would turn off building protection for TruePVE. -
The fire damage over time damage is disabled by WarMode, and this is because Facepunch currently does not give us the info on who the source of the fire was, so WarMode doesnt have enough info to determine if someone should take damage or not - so by default it disables all fire damage so that PVP players cannot use fire to damage PVE players. This is only for the damage over time effect though, the direct damage from incendiary rockets and bullets will still follow normal rules - just the damage over time is disabled. In the next patch I'm adding a config setting so that you can control this a little more. If you want the better chat prefixes to be colored, you have to set the color in the ModeTitleFormat setting under the BetterChat section of the WarMode config. For example, if you wanted the prefix to be a reddish color you can do something like "BetterChat": { "ShowModePrefixInChat": true, "Modes": { "pvp": { "ShowModeTitleInChat": true, "ModeTitleFormat": "<color=#eb4034>[{0}]</color>" }, "pve": { "ShowModeTitleInChat": true, "ModeTitleFormat": "<color=#34eb65>[{0}]</color>" } } }, This should make it so the mode pvp shows up as a reddish color (eb4034) and pve shows up as a greenish color (34eb65) these are codes for hex colors, so you can Google different colors if you want. I know its confusing because in the warmode admin panel it allows you to pick a color for each mode, so it would be nice if it just applied those to BetterChat as well. However, BetterChat allows you to format more than just colors, so it needed its own configuration setting. I hope this clears things up.
-
I'm confused, it already shouldnt show again on reconnect - it should only show again when the map wipes. You can also already disable the /flag command if you dont want people to be able to change later.
-
I'll check it out then!
-
Changed Status from Pending to Work in Progress
-
The problem is that for that specific hook, the umod documentation defines it to return a bool, however it seems this can be changed to an object. If this was done in both WarMode and DCProtect, then this hook conflict in theory would be resolved. I might include this change in the next WarMode patch, I'll DM you what this would look like for both plugins and you can let me know if it resolves it for you.
-
Hey, so I did try this the other day (as I was fixing some other bugs) and the ignore permission seemed to be working correctly... even without a plugin reload. I know its been awhile, can you walk me through the steps of what exactly you are doing with the permission. For instance, are you assigning it directly to a player, or are you assigning it to a group? Is the person you are assigning it to the "founder" of the base, or are they just an "owner". Are they also an admin?
-
When you say "backpacks" do you mean like a wearable backpack that has been dropped, or a corpse bag?
-
Changed Status from Pending to Closed Changed Fixed In to 1.3.3
-
Changed Status from Pending to Closed Changed Fixed In to 1.3.3
-
Added that name now
-
DM sent
-
I might have a fix for you to try out in a few minutes, I'll DM you when ready
-
Are you on oxide or carbon? And do you have any plugins that add npc players?
-
That might be doable
-
Added you on discord
-
Changed Status from Pending to Closed Changed Fixed In to 1.3.2
-
Changed Status from Pending to Closed
-
Adding it to suggestion board - closing this out
-
Changed Status from Pending to Not a Bug
-
So although its not ideal, this is intentional - and here is the reason.. In order for WarMode to provide protection it needs to know who the attacker is, and who the victim is. For most entities/projectiles the information for who the attacker was is sent along with the projectile. However, for whatever reason, Facepunch doesn't provide this information for fire, so for any given fire entity there is no saying whether it came from a pvp or pve player, and therefore WarMode cant apply rules to it. So we could have it just always allow fire damage, but this is an issue because pvp players would use this exploit to raid pve players bases. So alternatively, fire damage is just disabled to prevent these exploits, at least until Facepunch makes the attacker info available for fire. This only happens when there's a TC because WarMode doesn't provide protection for most things if they are outside a base. Its also worth noting that its only the fire damage over time that is disabled. The initial fire damage from incendiary rounds/flamethrowers/molotovs and whatnot should still follow rules appropriately. Hope that clears things up - going to close thing one since its intentional.
-
Changed Status from Pending to Not a Bug
-
Hello! So I looked into this for you and what I found was kind of interesting. So it appears that this is actually working correctly, but it is a bit confusing, so let me explain. The InitialPlayerMode only is used for players who have never been assigned a mode in the past. Modes are driven by oxide permission groups, so if a player already belongs to the group "warmodepvp" then the InitialPlayerMode will not apply to them - it will only apply to people who have never joined your server since WarMode has been installed. If you want to make sure everyone has a "clean slate" then first unload WarMode, then run "oxide.usergroup removeall warmodepvp" this will of course make it so no one is in the pvp group. Then, if you have InitialPlayerMode set to pve, when you reload the plugin, everyone should be pve now as they do not already belong to another mode group. Keep in mind this is assuming you haven't added any other custom modes - if you have, you'll just want to clean those up as well.
-
I don't know if this helps, but just to clarify the "NPC" mode only applies to "npc players" as in, player entities that are spawned in by other plugins. NPC raiders should fall under this category and if I recall correctly I think that Zombies Hordes would too. Assuming they're both counted, there's currently no way to designate which ones are counted as NPCs. What's tricky about this is that these all are "player" entities, so its difficult to distinguish which plugin they came from in a way that could be provided by a config. I'm open to ideas though on how this might look in a config?
-
permissions for looting (use) at the bases
Mr01sam replied to Peter Friesenbichler's Support Report in Support
How would you suggest that a player is able to designate a friendly "neighbor" base, versus a neighbor they do not want to share stuff with?
