That wouldn't surprise me as it is a port of NS2-EmbdStats, which I haven't updated for months, so chances are it's broken at the moment. I'll have a good look at it, thanks for the feedback.
Seeing as there's just so little action in the sub-forum (not surprisingly really, given the state of the game), let me just go ahead and give a status-update on the next version (v8): <ul><li>File-storage for bans: I've finally added this, they're now stored neatly in a XML-formatted file.</li><li>MySQL(Database)-storage for bans: Besides file-support, I decided to go right ahead and add database support as well. At the moment, I've only added MySQL-support, which is a very common db-application (in the gaming-scene anyway).</li><li>Improved query-responder: I fixed the player-response (it tends to return garbled kills\time-connected values), as well as added a whole lot of information in the rule-response. This includes information regarding individual players that I couldn't put in the player-response for the sake of backwards-compatibility (score\deaths\Steam-ID\team\class et cetera).</li><li>A new logger: This (txt-file) logger differs from Spark's default one, in that it is a bit more sophisticated (a lot more detailed).</li><li>Steam-Group priviliges: This one is particularly neat, it allows admins to give players priviliges based on which Steam(Community)-Group they're in. Say you have a group on steam for your regulars-server, you could configure every member of that group to be automatically granted the ReservedSlot-privilige.</li><li>A Field-of-View overrider: This is in reference to <a href="http://www.unknownworlds.com/forums/index.php?showtopic=112963" target="_blank">this</a> thread. It allows you to easely increase the FOV across the board to be more suited for today's widescreens (at the moment, the FOV in NS2 is set a bit too low). Here's an excerpt from the config-file to demonstrate how it works: <!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->--[[------------------- Game(play)-alterations ------------------]]--
--[[ Sets the value with which to multiply all the Field-of-View values Remarks: - The default FOV-values as of build 169 are: Marines=90; Marine\Alien-Commanders=90; Skulks=110; Gorges=95; Lerks=100; Fades=90; Onos=95 - Pass 1 to use the default NS2-values - The recommended value is 1+1/6 (equal to about 1.1666) (results in a FOV of 105 for marines and 128 for skulks) - The highest reasonable value is 1+1/4.5 (equal to about 1.222) (results in a FOV of 110 for marines 134 for skulks) In: FLOAT Multiplier Out: Nill ]]-- NS2GmOvrmind.NS2.SetFOVMultiplier(1+1/6);<!--QuoteEnd--></div><!--QuoteEEnd--></li><li>Multiple servers off 1 config-file: This allows for multiple servers to run off a single config-file without getting in each other's way (internet-port wise). It will be possible to set general-settings (applicable to all servers), and specific settings applicable only to a specific server loading that config-file.</li></ul>
You will notice I only talked about ban-storage, not users, I will add users in due time when the file\db-storage has been streamlined. Right now ban-storage is the most important to have anyway. If there's something missing you think should be up there, do post your suggestions (bonus-points for technically challenging features).
If you hadn't noticed yet, there is a tiny bug in the query-responder (aside from the garbled player-score\timeconnected) that causes the tickrate to not be updated anymore at some point, and get stuck on whatever it was at that time. Not significant really, but every time I look at the server-list I'm annoyed by it, so I'm putting out a fix for it next week.
On a not entirely unrelated note, GmOvrmind is really being bothered by NS2's phantom-client issue as of late. Namely that phantom-clients count as a filled slot, causing the unreserved-slot system to kick in earlier than it should. Unfortunatly there's just nothing I can do about that, and am eagerly awaiting for the devs to fix the issue. In the mean time, an amusing screeny for your leisure: <img src="http://1690247.websites.xs4all.nl/NS2GmOvrmind/phantomomgwtfbbq.png" border="0" class="linked-image" />
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=1838997:date=Mar 27 2011, 01:51 PM:name=player)--><div class='quotetop'>QUOTE (player @ Mar 27 2011, 01:51 PM) <a href="index.php?act=findpost&pid=1838997"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->On a not entirely unrelated note, GmOvrmind is really being bothered by NS2's phantom-client issue as of late. Namely that phantom-clients count as a filled slot, causing the unreserved-slot system to kick in earlier than it should. Unfortunatly there's just nothing I can do about that, and am eagerly awaiting for the devs to fix the issue.<!--QuoteEnd--></div><!--QuoteEEnd-->
Ah, now this makes sense. I've noticed this on servers running OM and figured it was related to the phantom player issue. Maybe as a short-term fix you could exclude clients who have a ping of 0 on the scoreboard from consideration for a slot? That's the quick way you can distinguish from real and phantom players.
I suppose I could omit players with a ping of naught when counting the number of clients already on the server, so actual clients won't be kept out because of them. Of course there's nothing I can do about the Spark-engine side of this (not even allowing connections to a server that it percieves as full). But that's as far as I'm willing to go really, mainly due to this (old quote): <!--QuoteBegin-'player'+--><div class='quotetop'>QUOTE ('player')</div><div class='quotemain'><!--QuoteEBegin-->Also interesting to note, if you quickly look at "UK | ClanPlanet #2 | B168" in that dev-tracker server-list, you'll notice it has 1 player in it, but still a tick-rate of 1. The query-responder used there is the Ovrmind one, which takes it's data from the Lua-state. Now if you look at the server's spark-queryresponder, it'll tell you the server is empty. What we can deduce from this is that the engine has no players (which we can also tell from the fact the server's tickrate has dropped to 1), but the lua-state still has 1 floating around (not being deleted obviously). We're looking at yet another variant of the phantom-client bug here. This would also explain why the server\GmOvrmind crashes if you attempt to kick phantom-clients, as an invalid argument (which it is if the engine-handle to this client doesn't exist anymore) to the DisconnectClient-method causes an engine-crash.
So the phantom-clients expose 2 problems: the engine not properly signaling the lua-state to delete a client, and the DisconnectClient-method not having proper error-handling.<!--QuoteEnd--></div><!--QuoteEEnd--> I'll be taking out the mechanism that kicks phantom-clients because of what I've said above, namely that trying to kick clients that the engine thinks are no longer there can potentially cause a fatal crash.
An increase for the marines' FOV from 90 to 110 caused no drop in (r_stats) FPS whatsoever. This is probably because most people (85-90%) are bottlenecked by their CPU, so I measured GPU-usage as well, and found no %-increase of any kind there either.
So I concluded that the extra area exposed by the higher FOV was in fact already being rendered by the Spark-engine, and simply cut off, meaning there are no performance implications for a higher FOV at this moment in time.
v8 is up. The main additions are the improved query-responder, and the addition of a FOV-modifier. As suggested by ScardyBob the reserved-slot system now ignores players with a ping of naught. Downside of this is that bots (the only other kind of player that has a ping of 0) won't be counted as players, though I don't think this is much of an issue as nobody uses\ever used bots in public servers anyway (they're pretty damn useless right now). The FOV-modifier functions almost perfectly, with the exception for the Lerk. There is a bug in NS2 that causes the client's FOV of the Lerk to NOT be synced with the server's FOV of the Lerk. I'll post about it on getsatisfaction, but aside that, all other classes\species have proper increased FOV.
Heh, I just cut the configuration up into categories, the syntax is pretty much the same. I've set the FOV-multiplier to a recommended value of 1+1/6 by default (giving marines a 105 FOV). There is a chance you might find it a bit too high, as it gives skulks a FOV of 128, giving them a bit of a fishbowl-view that might put some people off (apparently that little view-tilting in NS2 a build ago was enough for hordes of players to complain already, so this might not go down well either). In this case you could try 1+1/9 (giving marines a 100 FOV, which is still do-able for widescreens).
endarJoin Date: 2010-07-27Member: 73256Members, Squad Five Blue
<!--quoteo(post=1838194:date=Mar 22 2011, 01:00 AM:name=player)--><div class='quotetop'>QUOTE (player @ Mar 22 2011, 01:00 AM) <a href="index.php?act=findpost&pid=1838194"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->If there's something missing you think should be up there, do post your suggestions (bonus-points for technically challenging features).<!--QuoteEnd--></div><!--QuoteEEnd--> While I don't think this feature really belongs in a mod such as this of a released game, I sometimes feel that it would be nice to do.
om_cullhydras Bring the current hydra population down, to a % value randomly killing a percentage of them. Or even an integer out of total if you don't want to do % (no real reason to).
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=1839875:date=Apr 5 2011, 04:18 AM:name=endar)--><div class='quotetop'>QUOTE (endar @ Apr 5 2011, 04:18 AM) <a href="index.php?act=findpost&pid=1839875"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->While I don't think this feature really belongs in a mod such as this of a released game, I sometimes feel that it would be nice to do.
om_cullhydras Bring the current hydra population down, to a % value randomly killing a percentage of them. Or even an integer out of total if you don't want to do % (no real reason to).<!--QuoteEnd--></div><!--QuoteEEnd-->
Wouldn't an om_hydralimit be better? Arbitrarily killing hydras seems like a worse idea than preventing excess hydras from being built in the first place.
Done. It'll be in v9 (om_cullhydras #<Percentage>). No bonus-points for you though, it was not difficult.
[NINJA-edit] @ScardyBob: I've done it sequentially, so say there are 10 hydras, and 50% is to be removed, it'll start at the base of the table-index and kill every other hydra (thus thinning out rather than wipping out). Though the hydra-limit has been a pending feature for a while, I'll get around doing a graceful variant of that too at some point.
Can anyone confirm if this works on a linux/wine server. I loaded it. It seems to start without issues but when I am in the game none of the OM commands are recognized. I'll recheck my configuration to see if I am missing something.
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=1839943:date=Apr 5 2011, 01:41 PM:name=player)--><div class='quotetop'>QUOTE (player @ Apr 5 2011, 01:41 PM) <a href="index.php?act=findpost&pid=1839943"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Done. It'll be in v9 (om_cullhydras #<Percentage>). No bonus-points for you though, it was not difficult.
[NINJA-edit] @ScardyBob: I've done it sequentially, so say there are 10 hydras, and 50% is to be removed, it'll start at the base of the table-index and kill every other hydra (thus thinning out rather than wipping out). Though the hydra-limit has been a pending feature for a while, I'll get around doing a graceful variant of that too at some point.<!--QuoteEnd--></div><!--QuoteEEnd-->
On that note, is it possible to include something like om_killbldg where it destroys whatever structure the admin is currently pointed at? That would help deal with people who are exploiting/griefing by blocking things with structures.
Yes, something along the lines of "om_killentity" that will kill any LiveScriptActor (player\building\unit\DI) directly pointed at by the admin. I'll put it in next version.
I've also managed to make the GmOvrmind query-responder connectable. This means you will be able to both query and join the same ip:port. As a consequence "steam://connect/ip:port"-links will finally work. It functions using an internal proxy-server that will relay any UDP-datagrams it doesn't recognize as queries towards the connect-port, assuming it is a SPARKNET-message. As a bonus this will allow for IP-banning internally by GmOvrmind, without the use of a firewall. To top it all off it also allows for deep packet-inspection, which will (among other things) allow GmOvrmind to resolve the IPs of the players on the server (and have them show up in the "om_players"-command).
hmm about not counting phantom players... I dont know if thats a solution. I just had the issue where there was one phantom player so overmind wouldnt count him, but the game would count him, resulting in the reserved slot system not working because the server would see 11 players (the max) whereas overmind only counts 10, allowing the server to get full.
I suspect you already know that kicking a phantom player results in a server crash :\
There are many different incarnations of the phantom-client bug. Sometimes you'll see a mismatch of the players when you're comparing the Spark-queryresponder and the GmOvrmind-queryresponder. This is a variant of the problem where the player is deleted from the engine, but not from the Lua-VM, resulting in the difference between the Spark-queryresponder (which takes it's data from the engine) and the GmOvrmind-queryresponder (which takes it's data from the Lua-VM). It is this variant of the phantom-client bug I temporarily changed the reserved-slot system for, a situation where the engine says there is still a slot left and where the Lua-VM would say there isn't. In this case not counting phantoms does help. What you have seen was a variant of the phantom-client problem where both the Lua-VM and the engine were in on it, unfortunatly there is nothing I can do to fix that. We'll just have to wait for a proper fix from UWE.
As for kicking phantom-clients, you _might_ be able to do that _sometimes_. In the case where you certainly cannot is the one I described above (where the engine doesn't know the player anymore, but the Lua-VM does). This isn't a problem with GmOvrmind, but with the fact that the ClientDisconnect-method (which kicks players) does not have proper error-handling. Thus if a (to the engine) nonexistant player is passed into it, it will cause a cataclysmic crash in the engine. So needless to say I wouldn't risk trying it.
ScardyBobScardyBobJoin Date: 2009-11-25Member: 69528Forum Admins, Forum Moderators, NS2 Playtester, Squad Five Blue, Reinforced - Shadow, WC 2013 - Shadow
<!--quoteo(post=1840297:date=Apr 8 2011, 06:45 AM:name=endar)--><div class='quotetop'>QUOTE (endar @ Apr 8 2011, 06:45 AM) <a href="index.php?act=findpost&pid=1840297"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->do you mean Gui? I think console commands are a UI, it allows a user to interface with it, just not graphically.
I'd imagine that anyone running a server would prefer cli commands though. Then again, could just be me.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think he's talking about something like the radial menus available for other admin mods (or list menus like in sourcemod). Basically, some way for people to type something like 'om_admin' into chat so that a menu pops up on screen. Personally, I prefer typing all commands into the console because its generally faster, but a popup menu system is a nice feature for people not so accustomed to the dev console.
I can imagine cases where both a list-based GUI and a more clunky mouse\sliders\buttons GUI are more pratical than a CLI-based interaction. Kicking\banning\slaying takes typing out 2 commands right now (to retrieve an Overmind-ID and subsequently taking action), where this could take as few as 3 keystrokes in a list-based GUI. When it concerns relatively complex tasks such as altering the map-rotation, a drag-n-drop interface might prove more pratical than commands\lists.
So both of these have their place, and I'll probably end up doing both but it's not very high up on the todo-list. This is because there is no Server-Client synchronization of Lua-files in place at the moment (a GUI would require some new Lua-script to be run on the Client), which means if admins\players want to make use of it right now, they'll have to download a GmOvrmind version (perferably exactly matching the server's) and run "NS2.exe -game NS2GmOvrmind" to get it all to work. Quite a bit of effort I'm sure you'll agree, hence I've put it off for the moment.
McGlaspiewww.team156.comJoin Date: 2010-07-26Member: 73044Members, Super Administrators, Forum Admins, NS2 Developer, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Onos, WC 2013 - Gold, Subnautica Playtester
It looks like b171 isn't compatible with Om v8. I just updated the 156 server and tried to load, no dice. It goes through the normal start-up routine(s) and registers with the master server, but none of the actual game files are loaded. So, you can't connect to the server. If I run it without Om, it works fine. I can post log contents if needed.
It looks like they've made some changes to their Lua-script that breaks it, and decided to rename lua51.dll to lua5.1.dll for some reason (just to mess with me probably).
k, I put out v9 which will work nicely with the new update. I needn't mention that you must not copy-paste your old config into the new one, as it will most likely break, always go through the new config and modify it to what you had before. I didn't expect to have to do an update and thus had to 'sow up' what I was working on (just making excuses in case it doesn't work flawlessly).
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->--[[ Add a server-configuration to the overmind-system Remark: - This will add a new table in the toplevel table (NS2GmOvrmind), accessible via the ServerName-string passed here. - For general settings that have to be applicable to all servers, simply use just the toplevel table (NS2GmOvrmind) In: STRING ServerName Out: Nil ]]-- --NS2GmOvrmind.AddServer("My NS2-Server","My1","ns2_rockdown"); -- Work in progress, do not uncomment<!--QuoteEnd--></div><!--QuoteEEnd-->
I guess the whole functionality of more than one server config is not implemented, right? If it is already, could you explain a little more how to do it?
Oh, and why is the mumble/teamspeak server activated by default? (You may also want to disable rcon by default)
Comments
<ul><li>File-storage for bans: I've finally added this, they're now stored neatly in a XML-formatted file.</li><li>MySQL(Database)-storage for bans: Besides file-support, I decided to go right ahead and add database support as well. At the moment, I've only added MySQL-support, which is a very common db-application (in the gaming-scene anyway).</li><li>Improved query-responder: I fixed the player-response (it tends to return garbled kills\time-connected values), as well as added a whole lot of information in the rule-response. This includes information regarding individual players that I couldn't put in the player-response for the sake of backwards-compatibility (score\deaths\Steam-ID\team\class et cetera).</li><li>A new logger: This (txt-file) logger differs from Spark's default one, in that it is a bit more sophisticated (a lot more detailed).</li><li>Steam-Group priviliges: This one is particularly neat, it allows admins to give players priviliges based on which Steam(Community)-Group they're in. Say you have a group on steam for your regulars-server, you could configure every member of that group to be automatically granted the ReservedSlot-privilige.</li><li>A Field-of-View overrider: This is in reference to <a href="http://www.unknownworlds.com/forums/index.php?showtopic=112963" target="_blank">this</a> thread. It allows you to easely increase the FOV across the board to be more suited for today's widescreens (at the moment, the FOV in NS2 is set a bit too low). Here's an excerpt from the config-file to demonstrate how it works:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->--[[-------------------
Game(play)-alterations
------------------]]--
--[[ Sets the value with which to multiply all the Field-of-View values
Remarks: - The default FOV-values as of build 169 are: Marines=90; Marine\Alien-Commanders=90; Skulks=110; Gorges=95; Lerks=100; Fades=90; Onos=95
- Pass 1 to use the default NS2-values
- The recommended value is 1+1/6 (equal to about 1.1666) (results in a FOV of 105 for marines and 128 for skulks)
- The highest reasonable value is 1+1/4.5 (equal to about 1.222) (results in a FOV of 110 for marines 134 for skulks)
In: FLOAT Multiplier
Out: Nill ]]--
NS2GmOvrmind.NS2.SetFOVMultiplier(1+1/6);<!--QuoteEnd--></div><!--QuoteEEnd--></li><li>Multiple servers off 1 config-file: This allows for multiple servers to run off a single config-file without getting in each other's way (internet-port wise). It will be possible to set general-settings (applicable to all servers), and specific settings applicable only to a specific server loading that config-file.</li></ul>
You will notice I only talked about ban-storage, not users, I will add users in due time when the file\db-storage has been streamlined. Right now ban-storage is the most important to have anyway. If there's something missing you think should be up there, do post your suggestions (bonus-points for technically challenging features).
On a not entirely unrelated note, GmOvrmind is really being bothered by NS2's phantom-client issue as of late. Namely that phantom-clients count as a filled slot, causing the unreserved-slot system to kick in earlier than it should. Unfortunatly there's just nothing I can do about that, and am eagerly awaiting for the devs to fix the issue. In the mean time, an amusing screeny for your leisure:
<img src="http://1690247.websites.xs4all.nl/NS2GmOvrmind/phantomomgwtfbbq.png" border="0" class="linked-image" />
Ah, now this makes sense. I've noticed this on servers running OM and figured it was related to the phantom player issue. Maybe as a short-term fix you could exclude clients who have a ping of 0 on the scoreboard from consideration for a slot? That's the quick way you can distinguish from real and phantom players.
<!--QuoteBegin-'player'+--><div class='quotetop'>QUOTE ('player')</div><div class='quotemain'><!--QuoteEBegin-->Also interesting to note, if you quickly look at "UK | ClanPlanet #2 | B168" in that dev-tracker server-list, you'll notice it has 1 player in it, but still a tick-rate of 1. The query-responder used there is the Ovrmind one, which takes it's data from the Lua-state. Now if you look at the server's spark-queryresponder, it'll tell you the server is empty. What we can deduce from this is that the engine has no players (which we can also tell from the fact the server's tickrate has dropped to 1), but the lua-state still has 1 floating around (not being deleted obviously). We're looking at yet another variant of the phantom-client bug here. This would also explain why the server\GmOvrmind crashes if you attempt to kick phantom-clients, as an invalid argument (which it is if the engine-handle to this client doesn't exist anymore) to the DisconnectClient-method causes an engine-crash.
So the phantom-clients expose 2 problems: the engine not properly signaling the lua-state to delete a client, and the DisconnectClient-method not having proper error-handling.<!--QuoteEnd--></div><!--QuoteEEnd-->
I'll be taking out the mechanism that kicks phantom-clients because of what I've said above, namely that trying to kick clients that the engine thinks are no longer there can potentially cause a fatal crash.
Will increasing the FOV effect video performance?
An increase for the marines' FOV from 90 to 110 caused no drop in (r_stats) FPS whatsoever. This is probably because most people (85-90%) are bottlenecked by their CPU, so I measured GPU-usage as well, and found no %-increase of any kind there either.
So I concluded that the extra area exposed by the higher FOV was in fact already being rendered by the Spark-engine, and simply cut off, meaning there are no performance implications for a higher FOV at this moment in time.
I currently use a wide screen but i run the game in windowed mode because of the FOV limitations.
Also, for the FOV, got any recommendations or comments from experiences?
While I don't think this feature really belongs in a mod such as this of a released game, I sometimes feel that it would be nice to do.
om_cullhydras
Bring the current hydra population down, to a % value randomly killing a percentage of them. Or even an integer out of total if you don't want to do % (no real reason to).
om_cullhydras
Bring the current hydra population down, to a % value randomly killing a percentage of them. Or even an integer out of total if you don't want to do % (no real reason to).<!--QuoteEnd--></div><!--QuoteEEnd-->
Wouldn't an om_hydralimit be better? Arbitrarily killing hydras seems like a worse idea than preventing excess hydras from being built in the first place.
[NINJA-edit]
@ScardyBob: I've done it sequentially, so say there are 10 hydras, and 50% is to be removed, it'll start at the base of the table-index and kill every other hydra (thus thinning out rather than wipping out). Though the hydra-limit has been a pending feature for a while, I'll get around doing a graceful variant of that too at some point.
I loaded it. It seems to start without issues but when I am in the game none of the OM commands are recognized.
I'll recheck my configuration to see if I am missing something.
[NINJA-edit]
@ScardyBob: I've done it sequentially, so say there are 10 hydras, and 50% is to be removed, it'll start at the base of the table-index and kill every other hydra (thus thinning out rather than wipping out). Though the hydra-limit has been a pending feature for a while, I'll get around doing a graceful variant of that too at some point.<!--QuoteEnd--></div><!--QuoteEEnd-->
On that note, is it possible to include something like om_killbldg where it destroys whatever structure the admin is currently pointed at? That would help deal with people who are exploiting/griefing by blocking things with structures.
I've also managed to make the GmOvrmind query-responder connectable. This means you will be able to both query and join the same ip:port. As a consequence "steam://connect/ip:port"-links will finally work. It functions using an internal proxy-server that will relay any UDP-datagrams it doesn't recognize as queries towards the connect-port, assuming it is a SPARKNET-message. As a bonus this will allow for IP-banning internally by GmOvrmind, without the use of a firewall. To top it all off it also allows for deep packet-inspection, which will (among other things) allow GmOvrmind to resolve the IPs of the players on the server (and have them show up in the "om_players"-command).
I suspect you already know that kicking a phantom player results in a server crash :\
As for kicking phantom-clients, you _might_ be able to do that _sometimes_. In the case where you certainly cannot is the one I described above (where the engine doesn't know the player anymore, but the Lua-VM does). This isn't a problem with GmOvrmind, but with the fact that the ClientDisconnect-method (which kicks players) does not have proper error-handling. Thus if a (to the engine) nonexistant player is passed into it, it will cause a cataclysmic crash in the engine. So needless to say I wouldn't risk trying it.
UI > console commands
I'd imagine that anyone running a server would prefer cli commands though. Then again, could just be me.
I'd imagine that anyone running a server would prefer cli commands though. Then again, could just be me.<!--QuoteEnd--></div><!--QuoteEEnd-->
I think he's talking about something like the radial menus available for other admin mods (or list menus like in sourcemod). Basically, some way for people to type something like 'om_admin' into chat so that a menu pops up on screen. Personally, I prefer typing all commands into the console because its generally faster, but a popup menu system is a nice feature for people not so accustomed to the dev console.
So both of these have their place, and I'll probably end up doing both but it's not very high up on the todo-list. This is because there is no Server-Client synchronization of Lua-files in place at the moment (a GUI would require some new Lua-script to be run on the Client), which means if admins\players want to make use of it right now, they'll have to download a GmOvrmind version (perferably exactly matching the server's) and run "NS2.exe -game NS2GmOvrmind" to get it all to work. Quite a bit of effort I'm sure you'll agree, hence I've put it off for the moment.
I'll try and have a new version out later today.
Remark: - This will add a new table in the toplevel table (NS2GmOvrmind), accessible via the ServerName-string passed here.
- For general settings that have to be applicable to all servers, simply use just the toplevel table (NS2GmOvrmind)
In: STRING ServerName
Out: Nil ]]--
--NS2GmOvrmind.AddServer("My NS2-Server","My1","ns2_rockdown"); -- Work in progress, do not uncomment<!--QuoteEnd--></div><!--QuoteEEnd-->
I guess the whole functionality of more than one server config is not implemented, right?
If it is already, could you explain a little more how to do it?
Oh, and why is the mumble/teamspeak server activated by default?
(You may also want to disable rcon by default)