possibility to active the banner workbench level 3 ?

Definitely possible. It shouldn't be very difficult. The banner just displays the player flags that are networked to the client. Somebody just needs to implement it and submit a patch. The Building Workbench plugin also has some code that could be used as a reference for somebody trying to understand how it works.

The older version did this and players wanted it removed, but we don't have access to those older version... it's not as simple as setting the BasePlayer.PlayerFlags.Workbench3 flag - you need to remain in the trigger? you can't enable this trigger directly ? If you do this then you can remove the loops setting workbenchLevelRequired and craftmode it would be like 2 different versions?

It's likely possible to create a trigger and then just add the player to it, but I haven't tested.

If this feature were introduced, it could be a config option of the plugin rather than two plugins.

just any random trigger!? how does the flags know for what trigger.. I tried parts from the building workbench plugin trying to understand it. Way over my head.. you can't just enable and add player to the games trigger; WorkbenchSource (TriggerWorkbench) ?my failed attempt: https://pastebin.com/5chL4xP4

I'm pretty busy so I don't have time to code this, but I can provide some pointers. Here's what I found when spending 3 minutes looking at the game code.

• The workbench level 1/2/3 player flags are set in PlayerMetabolism.RunMetabolism. This method runs constantly on the server, so whatever it's looking at needs to be kept updated.
• That method derives the craft level from the BasePlayer.currentCraftLevel property.
• The currentCraftLevel getter simply loops the player's triggers, find all instances of TriggerWorkbench, validates that each trigger has a real workbench associated with it, and that the workbench is visible to the player. That fact makes simply using a trigger impossible.
• The currentCraftLevel getter also has a short-circuit code path which returns BasePlayer.cachedCraftLevel, which it uses if BasePlayer.nextCheckTime is in the future. The nextCheckTime is not by anything else so it should be safe to mutate.

Add all this together, and my conclusion is that you can probably achieve your goal by doing the following.

• Hook OnServerInitialized to loop BasePlayer.activePlayerList and set:
  • nextCheckTime to float.MaxValue
  • cachedCraftLevel to 3
• Hook Unload to loop BasePlayer.activePlayerList and set nextCheckTime to Time.realtimeSinceStartup.

spot on, thank you for your time WhiteThunder. I see those things in the building workbench plugin just did not understand them.. I still don't understand why you need to be in this trigger. Anyway I have a working version for @Schnoutre now and for anyone else and included two fixes for the unlock bps function. Thanks again.https://pastebin.com/FLxvevPk

The trigger in the code you provided does nothing and is not needed.

If I comment out the EnterTrigger OnPlayerConnected it does not work..

Ah, I see, the BasePlayer.currentCraftLevel getter requires the player be in a trigger as an optimization I guess. So the trigger is needed.

if (triggers == null)
{
    return 0f;
}​

It's worth testing whether this keeps working after the player gets on a ladder and then off, since that force updates triggers. My concern is that the trigger doesn't contain the player, so it'll reset at some point. You can address this by adding the player to the trigger, not just adding the trigger to the player.

I tested ladders at the lighthouse and the deployable ones, had no problem. Good thing, because I don't understand that trigger difference, or how/why that's even a thing.

I just suggested the ladder test because I was glancing around for code that called BasePlayer.ForceUpdateTriggers and saw ladders. However, upon closer inspection, that code path is only traveled when the player fails anti hack. A better test would be mount and dismount a vehicle.

No problems driving it around, and jumping in and out of an attached flatbed. Is it not as simple as EnterTrigger, and LeaveTrigger to do it the other way? Why would you be able to do it both ways, I don't understand the dual purpose.. so one way must better then the other?

Usually triggers are a two-way street. Meaning, the trigger knows about the player, and the player knows about the trigger. If you only let the player know about the trigger, but not the other way around, some code paths in the game will remove the player from the trigger.