>>> ServMan Server Management Mod v2 for DCS:BS v1.0.1 Released! <<<

[Ramstein]

From the client side, on a computer, this did not work, it did not expand the amount of lines viewable... I doubled the number sizes for line space. It was worth a try.. I might try this on the server side and see if it can be done there...

 

No, atm there is no option to show pages, and the chat console does not allow scrolling. Heck what do you need so many missions for anyway?!? :)

 

In the Scripts/net/default.cfg file there are the following options:

 

 
chat = {
delay = 5, -- seconds to show every message
height = 10, -- height of message view in pixels
}

 

But afaik changing them won't do anything. Maybe there is another file somewhere that allows you to set the number of message lines displayed in the chat console, I don't know.

 

EDIT: Config/network.cfg contains this entry:

 

chat = {
height = 3,
}

 

Dunno if changing it has any effect.

[Acedy]

Hey Ramstein, I have found the files you need to edit:

 

Ka-50\FUI\Resources\Multiplayer\chat-log.res (for the normal chat list)

 

and

 

Ka-50\FUI\Resources\Multiplayer\chat-say.res (for the chat console).

 

You need to play around with the values for lines, window height...

[Ramstein]

cool,, I wil check them out soon..

thanx.. :thumbup:

[scatter]

I've been trolling through the code to better understand it for modifying - Acedy, this is such an awesome piece of work.

 

Now what I've done, and a question:

I've hacked this short bit of code to kick high pingers and put it in the "on_player_stat(id, stat, value)" function in "events.lua"

 

--kick if ping too high

if(stat == 0 and value > 300) then

serv_msg(string.format("Server automatically kicked %q for high ping", get_name(id)))

return server.kick_ban(id, "Ping too high")

end

 

(I'll probably change the "server.kick_ban" to a "net.kick" as when the server is in the early stages of hosting, pings can be quite high for a short while)

 

Rather than constantly checking ping, I'd much rather just do it at client connection as it'd be rather unfortunate to kick someone half way through a mission for a momentary ping spike. The problem is that I'm unsure of how to do it as it involves two separate events. My only thought is to create a new player "field" (or local variable) called ping that starts at 0 and gets set during the first stat check. Once set to a non-zero value, the stat check for ping is then ignored.

 

Would you have any better suggestions on how to proceed?

[Acedy]

Yeah, kicking for high ping is indeed a delicate problem, that's actually the reason why this feature didn't make it into the first version of ServMan. I have been thinking about various algorithms to determine when a player should be kicked, but I am unsure what would be a good solution.

 

As you say it is not a good idea to kick for single high ping events, so you have to measure and evaluate latency over time. And I don't know if it would be helpful to kick a player directly after connecting. The reason is that the scripts receive ping events as soon as the player connected, and the increased network traffic caused by the mission download may negatively affect his ping. I have not tested this, but it is possible that a player's ping is generally higher after connecting than when the mission download is complete and the player starts flying normally. If so it will also affect the ping of all players when the mission is rotated. However, one could easily remedy this problem by measuring ping only when a player is not spectating. I don't know though if an idling specator also affects server performance, but at least a spectator does not have a problem with warping, and you could simply kick a spectator that has been idling too long.

 

Regarding ping measurement over time I have been thinking about two basic approaches:

 

1. Accumulate ping values over time and calculate some kind of average. There would be an initialization phase where the first values are collected, and after that the average should be continuously compared with the limit. The simplest way would be to sum up all values and divide by the number of measurements, which is easy to do and efficient, but that is not a feasible solution because the more measurements you accumulate, the less influence one value will have on the average. So you want to take only newer values into account, or weigh newer values higher than older ones.

 

2. The 2nd approach does not calculate an average, it counts high ping events and kicks the player if he exceeded the limit too many times. The algorithm could work like this:

 

on new mission do ping_warning = 0

if X ping values > limit during the last Y seconds then ping_warning++

if ping_warning > Z then kick player

 

The problem will be to find good values for X, Y, and Z. :)

Edited May 26, 2009 by Acedy

[Quirkitized]

Acedy, is it possible to setup a kick via usernames? I know you say in your readme its not part of it, because its easy to impersonate and they can easily change there name. But what I was hoping for is something along the lines of a kick only for "unknown" name. Not a kick right away, but say if one joins with this name, they get a message saying they'll be kicked in a minute, and then 30sec, and then a boot. As to not scare away true "new" players, they just get a notification that they'll have to input a name other than default.

 

I'd love to hear your thoughts on this.

[Acedy]

Hi Quirk!, thanks for the suggestion, and yes, this feature is possible and I have added it to my wishlist. The issues related to name banning are related only to automatic banning, but I don't see any problems if the server host specifies unwanted usernames manually. I don't have time to work on ServMan right now, but I am planning an update after the patch has been released. I cannot promise 100% though that I will add a time delay before somebody gets kicked (you should see a message in the lobby why you have been kicked, but this does not work atm), however the whole event management of ServMan is going to be revised so I might as well add something like this. We'll see... :)

Edited June 1, 2009 by Acedy

[Quirkitized]

I'll definitely be looking forward to the new servman whenever you release it (probably a few months...come on patch!). I'd welcome any new additions.

 

Thanks for the reply.

[Panzertard]

I've made a diagram explaining the inner workings of ServMan.

Although it may be a bit over-complicated. A PDF version may soon be available.

If you want to include it as part of your documentation, Acedy, then we probably have to talk royalties.

 

Still - thanks for bringing us ServMan. :)

Edited June 24, 2009 by Panzertard

[Acedy]

That diagram is incomplete I'm afraid. Correct would be:

 

TK'er --> :chair: <-- ServMan

 

Team damaging --> :gun_rifle: :inv: <-- victim ..... ServMan --> :dunno:

 

Victim --> :bash: <-- team basher (i.e. ramming) ............ ServMan --> :Flush:

 

:helpsmilie:

[Panzertard]

:megalol: damn, you' re right. No royalties then I suppose :D

[Rob2222]

Hello,

 

on my server I added the /report <message> command that saves this message in a extra report file. It just was some copy&mod of the chatlog part.

Maybe this command can find a way into the main mod?

Then the players have the possibility to leave map suggestions / TK and Bug reports to the admin.

If you want I can send you the server.lua.

 

 

And another thing: I have a huge MP map and when playing this map as client my game now crashs. Can it be the cause that I am playing as real client while having servman not disabled? (On other times I host with this machine). I read it should be disabled cause it filles a log. Can it be that this needs huge memory on huge maps?

 

BR

Robert

Edited July 10, 2009 by Rob2222

[Acedy]

Hi Rob, sorry for the late reply, didn't see your post.

 

The /report command is already on my wishlist, will add it to v2.

 

Regarding the crash: Currently when you run BS as client with the mod installed it will write error messages to the Error.log file. This is a design fault, I simply didn't think about running BS in client mode. :doh: Anyway, these errors won't crash the server directly, although they may disable certain server/client messages, however what could happen is that the Error.log file grows huge and this in turn may cause problems. That's why it is recommended to uninstall the mod before playing as client. So if I were you I would remove it and test the mission again.

 

Btw, I have recently started to work on the mod again and this flaw was the first thing that I fixed. :)

[Panzertard]

From the readme:

* /logout

Subadmins who are logged in can log out using the '/logout' command, after that they only have regular player rights until they log in again. Subadmins will be logged out automatically when leaving the server, however it is recommended to log out manually before leaving.

I havent looked at the code yet, but I wonder why it is recomended to log out. The statement indicates that it is possible to take over an existing login if a subadmin leaves, and someone else with similar nick/ip joins.

Care to elaborate? :)

[Acedy]

IIRC the reason was this: the on_disconnect() function is responsible for logging out subadmins automatically when they leave the server. Now I observed on one occasion that somebody disconnected from the server, but the function was not called by BS, so it could happen that a subadmin's entry remains in the player table although he has already left the server. But even then it should be impossible that a new player, who is assigned the same, now free id, gains subadmin rights, simply because the player entry corresponding to that id is overwritten by the on_connect() function, and all new players are assigned non-subadmin rights by default. So the recommendation to log out manually is just an additional safety measure if you want to be 100% sure, but it should not really be necessary. The only occasion where it could happen that a player gets subadmin rights this way is when both the on_disconnect() and on_connect() functions are not being called, but I have never seen that happen.

Edited August 5, 2009 by Acedy

[Panzertard]

Cheers, thanks for the explanation :)

So worst case may be a full list / overflow somewhere due to the missing on_discoennect() then.

[Acedy]

No, BS "recycles" unused ids, and the garbage collector will take care of the unreferenced player entry once a new player entry is assigned to the same id. :)

Edited August 5, 2009 by Acedy

[Acedy]

Please note that the current v1 of this mod is not compatible with the BS v1.0.1 patch. There will be some sort of compatibility update available soon. Stay tuned. :)

[PoleCat]

Excellent work Stephan. Servman has been absolutely essential to me for running a DCS server. I can't tell you how much this utility means to the DCS online community. Almost all of the good 1.0 Squadron servers I have seen are using this most excellent admin tool. It makes running your DCS server simple and automated in ways I never thought possible. I look forward to testing and using your 1.01 compatible version as soon as it is available.

 

Thanks again for all of your hard work on this mate, it is most appreciated.

 

Out

Edited August 10, 2009 by PoleCat

[Panzertard]

While waiting, I've enabled the ServMan on our server - seems to be running fine atm, /load /reinit /missions works.

Waiting to see if there are any specific problems.

 

EDIT: Ah, yes - only clients with ServMan installed (events.lua + server.lua) can see the "red" + "blue" messages, The server can as well.

Other clients wont see the "Red nnnn killed Blue nnnn" messages. (At least according to reports over TS here now).

No big deal - remote tools still avail, just waiting to see some reactions to TK's etc.

 

EDIT:

- Kicks for TK's / Friendly kills works.

- Auto pause / unpause / restart when empty works

- MOTD isnt

Worth mentioning: Server DCS = ENG, Server OS = ENG, Regional Settings = ENG.

 

Summary - for now it is viable to run ServMan while waiting for you updated version, Acedy :)

Edited August 11, 2009 by Panzertard

[PoleCat]

Thanks for checking it out Panzer. I will run the older version on our server for now as well.

 

Out

[Ramstein]

any closer to a release of Servman update? Why couldn't we run Black Shark patch it and run Servman? Did the patch change everything so much it just wont work?

 

:joystick:

[Panzertard]

Ramstein, it "works" good enough for you to use in the meantime:

http://forums.eagle.ru/showpost.php?p=729652&postcount=70

[Ramstein]

Ramstein, it "works" good enough for you to use in the meantime:

http://forums.eagle.ru/showpost.php?p=729652&postcount=70

 

ok, so I have BS on my 2nd computer, and I installed Servman over that, do I just run the patch over that? , or do I have to start from scratch, run and install BS, the patch then Servman?

 

thanx

:joystick:

[Panzertard]

1. Vanilla / Clean DCS:BS --> 1.0.1 first

2. Add relevant ServMan files.