NoEscape 1.1.6

Has this plugin fixed the RaidBlock timer when you leave the zone? I mean, if the raidblock is for example 3 minutes, your colleague stays inside and has 1 minute 20 seconds left, you go out and come back in, you have 3 minutes of raidblock or 1 minute 20 seconds like everyone else who is in the zone? 

Not sure what you are referring to as this plugin was built from the ground up.
So it does not suffer from any issues or bugs that the free umod version has.

4 hours ago, MandangaRust said:

Has this plugin fixed the RaidBlock timer when you leave the zone? I mean, if the raidblock is for example 3 minutes, your colleague stays inside and has 1 minute 20 seconds left, you go out and come back in, you have 3 minutes of raidblock or 1 minute 20 seconds like everyone else who is in the zone? 

But in general the issue you are describing has never been a problem with my plugin here on codefling.

1. We need the ability to enable or disable raid block when damaging our own structures for testing purposes through the config.

2. For testing purposes, when we spawn an entity using "entity.spawn player" and shoot at it, we should enter combat block. I don't have a friend to test with.

3. We should be able to configure whether the raid block continues or stops when we leave the area.

4. The config is a bit complex and could be organized better.

5. The raid block and combat block times should be shared in the hooks.

Thank you, I will look into doing these suggestions.

@Rioelchavo 
I went ahead and added 1 & 2.
Along with a few other additions I did.

I am willing to discuss the rest with you in discord vc or dms, just shoot me a msg, my discord id is khan8615

with what @Rioelchavo said @Khan said prior in " 

1. We need the ability to enable or disable raid block when damaging our own structures for testing purposes through the config.

2. For testing purposes, when we spawn an entity using "entity.spawn player" and shoot at it, we should enter combat block. I don't have a friend to test with. 

3. We should be able to configure whether the raid block continues or stops when we leave the area.

4. The config is a bit complex and could be organized better.

5. The raid block and combat block times should be shared in the hooks.
"

I know you added support for 1 & 2 , I wanted to know if 3 and 5 were added?

Havent had time to read any of the updates.

@Kaooa
Denied Requests 3 & 5: Explanation

Requests 3 and 5 were not added, and I have no plans to do so. Here's why:

There is already a configurable timer that you can set for how long the raid lasts once it starts. I typically set this to 5 minutes. When continuous damage is inflicted on the base, the timer resets with each new damage, effectively prolonging the raid (the same applies to combat).

For this reason, it doesn't make sense to pass through the raid block or combat block times, as they are always updated in real-time.

The provided API hooks already give you everything you need to know to block or allow a player to do something, including auto-canceling an action when a combat or raid block occurs.

We require request number 5 in order to create notifications using additional plugins such as 'SimpleStatus,' 'AdvancedStatus,' and similar ones.

I was going to purchase until I saw 3 and 5 there denied. That's VERY common to have with raid block. SO unless you add that when a player leaves a raid blocked area, I can't justify purchasing.

You can already do this, it just adds combat blocking when you leave a raid zone.
Config toggle.

6 hours ago, 20K said:

I was going to purchase until I saw 3 and 5 there denied. That's VERY common to have with raid block. SO unless you add that when a player leaves a raid blocked area, I can't justify purchasing.

ohhhhhh. OK that's not bad.  And can you configure being permitted to teleport into a raid blocked zone but not out of one?

@20K
You can on both accounts just block tp for both combat block & raid block in the config & just have 

but what I'm after is allowing players to teleport into an active raid zone but not out of one. Just wanna make sure we are on the same page

Ah, I believe this would work as you want to because you can still TP while not raid or combat blocked.

Quote

that's the ONLY  thing holding me up from purchasing

Is this still not compatible with carbon?

On 10/16/2024 at 8:15 PM, dustyhansen said:

Is this still not compatible with carbon?

No, it has never worked on carbon. 

I could look into adding additional features / functions to support those.

4 minutes ago, dustyhansen said:

I think that there should be a config option for disabling combat block for the player getting damage. On our server this would prevent griefing other players by shooting them just to combat block them. There should also be a damage threshold to getting combat blocked, like there is for raiding. I have added this to support.

So here's something i cant seem to figure out. 
What is the config i can change to make it if you are inside the RaidArea you cannot repair?

I sill want them to be able to upgrade but dont want them to be able to repair.

Set the repair field to 0 to disable repairs.

{
 "Override facepunches default repair wait time after being attacked Default: 30sec": 0 
}

23 minutes ago, Purge1000x said:

So here's something i cant seem to figure out. 
What is the config i can change to make it if you are inside the RaidArea you cannot repair?

I sill want them to be able to upgrade but dont want them to be able to repair.

update for force wipe

23 minutes ago, Elloco said:

update for force wipe

seconded pls

also, please make this carbon compatible

@mainloot

Carbon support is impossible, it doesn't support invoking in a custom mono-class because they change the set fields from private to public when an oxide plugin is loaded, also the UI system is slightly different enough which breaks the UI system in this plugin. As well as a few other issues like slight hook differences compared to oxides hook locations resulting in different behavior.

So no, carbon support would not be possible. 

3 hours ago, Khan said:

@mainloot

Carbon support is impossible, it doesn't support invoking in a custom mono-class because they change the set fields from private to public when an oxide plugin is loaded, also the UI system is slightly different enough which breaks the UI system in this plugin. As well as a few other issues like slight hook differences compared to oxides hook locations resulting in different behavior.

So no, carbon support would not be possible. 

**Edit** ignore this, I think I figured out what you were referring to as the impossibility regarding your version