what lines of code determines what user has a key (like OP and Admin)

Search for "oplevel" setting in http://adchpp.sourceforge.net/user_guide/basic_guide.html#_administration_setup

Yeah setting oplevel to let say 7 will have all users with level >= 7 have a key and all op rights
Im trying to setup lets say Vip level - lets say 5 that has a key but is NOT OP! (all permissions inherited form reg profile).

I briefly went through all access scripts and either i cant find it or it isnt there . Is that hardcoded in source maybe?
If so where?

Where can i read on ADC userlevels. I hope there is at least 3 and all have different roles - privileges.
Does Op = Admin in ADC? Is there any difference in permissions?

ADC similarly to NMDC has two type of users, normal and operator. As I said, hubsoftware may implement their own userlevels but in the protocol level those appear either normal users or operators. DC clients user interfaces render this accordingly, operators defined by the protocol have "keys" in their icons in DC++ or other derivative clients.
This restriction does not prevent hubsoftware to implement various user levels and permission systems on their own. You've probably seen this in other hubsoftware, hence your questions.
ADCH++ does not implement such system, here there's commands that anyone can issue and there's a set of functions where the userlevel determines what a user with a certain level allowed to do with other users any level below them and cannot do with users any level above them.
Therefore what you want to achieve in your initial question (allow a certain level of user to use the reg command but not the kick etc..) is not currently possible with ADCH++.
It is possible to add such a permission system using the LUA api but I think that is a largely different approach than what's currently implemented and thus would need a larger rewrite of the scripts currently shipped with ADCH++.

Thanx eMTee.
I think i understand it now.
Thats actuallly a bad news for me. I like adchpp and its nice px scripting support.
Looks like it does not have major issues although i dont have power of thousands of users to give it a real test drive.
Its stable with 100. Maybe some day someone will do some permissions via LUA. It would be a real nice feature upgrade i think.

Once again thank you for helping and sharing your knowledge. U are being missed at dcdev hub.
:)

Such feature set including some more functions which absence makes ADCH++ unuseful for private communitiy purposes would be welcomed I agree.
I've been online and would still happy to be at the dev hub since its inception but unfortunately, these days it's not a happy place to be for me due to the unstoppable shitstorm (one of DCDev member's top notch description) happening there. I'm not sure I willing to participate unless the community and/or the hub owners take definite actions to clear the air there.

Hi Derek,

From my side it's been a really long time since I last played with ADCH++ but I think I did this before.

If you check the Entity.h file you'll see the flag definitions for the different users. These flags are the ones that define whether the user shows up with a key or not. There are a few more than just OP or nothing and how the clients display them depends on the clients themselves. You can use the setFlag method in order to set these flags on the objects.

If you are using the provided lua examples, you'll notice that the flags are set by the function set_level in access.lua You could probably handle your flag setting there by modifying the "if level >= settings.oplevel.value then" line. IIRC these flags only matter on the client side and the lua scripting will use the entity's level to see whether the entity should have access to a specific function.

Hopefully this helps you with your problem.

Thanks klondike for chipping in. I have to change my stance a bit that _as a proper solution_ you would need a larger rewrite of the scripts currently shipped with ADCH++. Yours probably isn't elegant but sounds to be pretty much effective.

I still think a private community friendly fork of ADCH++ would be welcomed. Unfortunately there's those few such pressing issues like this but ADCH++ is really matured, in conjunction with the adchpp_ptokax bridge it's 99% done, but amusingly the it's like just being stopped right before the finish line to be more broadly useful. And it's been staying in this state for many years.
Someone with good LUA experience and a bit of time could make it much more useful.

klondike - u are a Godsend!
This is exactly what i was looking for. Will give it a shot however i doubt i will be able to.
I do low level PHP this is slightly something else that i'm used to. At least i know where it is so now i can try.
If i fail - would u be able to fork it?
Im looking for an extra profile like a vip that has regs permissions but appears with a key in userlist and key is visible to all users not just to himself. So if user regs himself - he gets a key. Jeez it just one mouse click in PX ot ynHub :)

Fork would be great - at least for some testing and trying.
 I can do testing - i'm nowhere near coding skills required nor have adc protocol knowledge at the moment.

ok i cant build it now. So it all sucks.