Slmod- multiplayer server mod for new mission logic functionality

[Mechanist]

Hi Speed,

 

Absolutely love this mod.

 

I've just created a CA mission with resource system and activatable units and the slmod.CA_chatmsg function is really nice. Something like a strategic game, but I really miss the unit quotes :D

 

Is it possible to get this feature with sound files as well?

Something lik that: slmod.CA_snd (file, coa)

 

It will be usefull for CA based missions to get some vocal feedback when this or that is happening.

 

Also a question: If I assign the "credit system" to a flag value in my mission is it somehow possible to get the value of the flag permanently in my screen (aslo updating when incresed or decresed?

Thanks in advance!

[Speed]

Hi Speed,

 

Absolutely love this mod.

 

I've just created a CA mission with resource system and activatable units and the slmod.CA_chatmsg function is really nice. Something like a strategic game, but I really miss the unit quotes :D

 

Is it possible to get this feature with sound files as well?

Something lik that: slmod.CA_snd (file, coa)

 

It will be usefull for CA based missions to get some vocal feedback when this or that is happening.

Not possible. The reason CA_chatmsg was added was because it is not possible to send a text message/sound message to a Combined Arms player. a_out_text_delay_g/trigger.action.outTextForGroup a_out_sound_g/trigger.action.outSoundForGroup- these don't work on Combined Arms players: they are not in groups.

 

The only way to send them a "private message" is to use chat- slmod.CA_chatmsg identifies which multiplayer clients are in Combined Arms slots, and sends a chat message JUST to those players.

 

Also a question: If I assign the "credit system" to a flag value in my mission is it somehow possible to get the value of the flag permanently in my screen (aslo updating when incresed or decresed?

Thanks in advance!

 

It's better to use the Simulator Scripting Engine for something like this. You're hardly the first to ask about how to do this though:

 

http://forums.eagle.ru/showthread.php?t=98711

http://forums.eagle.ru/showthread.php?t=96235

http://forums.eagle.ru/showthread.php?t=94182

 

However, using a flag value for scoring is... rather crude. Why not use a Lua variable instead? Just make a global variable, name it something like, "score", initialize it to zero, and every time you want the score to go up, just run a script like this:

score = score + X

Where X is the number of points you want the score to increase by.

 

Info on the scripting engine:

http://en.wiki.eagle.ru/wiki/Simulator_Scripting_Engine_(DCS:_World_1.2.1)

 

Grimes and I also released a set of additional functions for the scripting engine here:

MiST

 

See the above thread for multiple examples. Also, see this particular post:

Scoring and weapons impacting in polygon zones example mission

for an example mission that includes a scoring system. It is, however, possibly more complicated than you need (but I don't know what you want so...).

 

Messing around with a simple scoring system would be a great way to introduce yourself to more detailed Lua scripts, if that's what you desire, at least.

------------------------------------------------------------------------

 

On an unrelated note, last night, I got the mission scripting Lua environment and the net Lua environment "talking" to each other using LuaSocket and localhost, which is a significant milestone :). When I first released Slmod, and up until DCS World, such a thing was not possible, because the "sanitization" code for MissionScripting was hidden away in C++, not Lua. Anyway, now that it is, you can expect Slmodv7 to finally do away with the "daemon" and pass commands from mission scripting to net solely through memory. I may keep the old daemon around just as a back-up that could be optionally enabled though. It worked pretty flawlessly for a long time, it was just inefficient and crude.

Edited December 15, 2012 by Speed

[Mechanist]

Thanks Speed for the info, already digged throught the MIST, but I have to learn much about LUA and scripting. Used to write my own scripts in OFP/ARMA but not on an expert level.

[NBEagle]

Thanks for the great mod.

 

 

I ve tried a bit with slmod.units_killed_by but i didnt get this to run:

 

do
    slmod.units_killed_by{init_units = {'[red]'}, init_units = {'[blue]'}, flag = 300}
end

All i ve done with slmod.units_firing works perfectly before, but with this here,... i think i missed something...

 

 

~Regards~

[mwd2]

Thanks for the great mod.

 

 

I ve tried a bit with slmod.units_killed_by but i didnt get this to run:

 

do
    slmod.units_killed_by{init_units = {'[red]'}, init_units = {'[blue]'}, flag = 300}
end

All i ve done with slmod.units_firing works perfectly before, but with this here,... i think i missed something...

 

 

~Regards~

 

you give both, target units and shooter the same variable name, this will not work!

[NBEagle]

you give both, target units and shooter the same variable name, this will not work!

 

Thanks! Now i got it to run.

 

All in all its a great upgrading of MP.

[Paranoik]

It Works Great on the current version.

 

Many Thanks to the developers.

Edited December 29, 2012 by Paranoik

[Wrecking Crew]

Thanks, Speed, for all the time and dedication.

 

Observations:

1. The '-reg' command doesn't work for me on two Clients to a server. Tried '-reg' and also '-reg <password>' where I'd put my all-lower-case-8-character password in the config file. Will try the default password (dcs123 & = nil) tomorrow to see if that will work...

 

--- edit --- figured this out - the password I want needed to be in quotes DOH!

 

2. In your instructions for setting the Missions folder path, the final '\' can come out of your example. If left in, the resulting path will contain two \\'s at the end. I am using this line to point to the <User>\Saved Games\DCS\Missions folder.

 

This is a new Windows 8 Pro 64 bit DCS server and Slmod is working fine with DCS World v1.2.2.7570. Thank you for the -admin commands!

 

Wrecking Crew

Edited January 6, 2013 by Wrecking Crew
Figured out the -reg issue

[Speed]

Thanks, Speed, for all the time and dedication.

 

Observations:

1. The '-reg' command doesn't work for me on two Clients to a server. Tried '-reg' and also '-reg <password>' where I'd put my all-lower-case-8-character password in the config file. Will try the default password (dcs123 & = nil) tomorrow to see if that will work...

 

--- edit --- figured this out - the password I want needed to be in quotes DOH!

 

2. In your instructions for setting the Missions folder path, the final '\' can come out of your example. If left in, the resulting path will contain two \\'s at the end. I am using this line to point to the <User>\Saved Games\DCS\Missions folder.

 

This is a new Windows 8 Pro 64 bit DCS server and Slmod is working fine with DCS World v1.2.2.7570. Thank you for the -admin commands!

 

Wrecking Crew

 

1) You're the second person in this thread to admit this mistake, so that's probably just the tip of the iceberg. If can you tell me a way in which I can make the instructions in the config.lua file more clear, I'd be happy to hear it.

 

2) First, AFAIK, windows doesn't care. It will open paths with double slashes in them, even if they are different.

Secondly, you appear to be incorrect- the file path that Slmod assembles will not contain two slashes, I deliberately set up logic to make a slash at the end of the admin_tools_mission_folder directory optional. See the code in the create_LoadMissionMenuFor function in the SlmodAdminMenu.lua file:

local path
if slmod.config.admin_tools_mission_folder and type(slmod.config.admin_tools_mission_folder) == 'string' then
path = slmod.config.admin_tools_mission_folder
if (path:sub(-1) ~= '\\') or (path:sub(-1) ~= '/') then
	path = path .. '\\'
end
else
path = lfs.writedir() .. [[slmod\Missions\]]
end

The Lua File System (lfs) module returns folder directory strings with slashes as the end of them, which is why I followed that convention. However, you are probably correct that the slash should not be there at the end, because a slash at the end is not required to specify a folder. I'll remove it.

Edited January 10, 2013 by Speed

[BAntDit]

I print messages with display_mode 'chat' and all messages are recording to log.

Is it possible to switch off recording of chat messages to dcs.log

Edited January 12, 2013 by BAntDit

[Speed]

I print messages with display_mode 'chat' and all messages are recording to log.

Is it possible to switch off recording of chat messages to dcs.log

 

I must admit I'm confused. There shouldn't be any recording of chat messages to dcs.log. Can you give me a sample of what you are seeing in dcs.log?

 

By the way, and such output would just be the result of a print statement somewhere. I use them quite liberally for debugging, but any such print statements would/should all be commented out or removed in "release" versions, unless that print statement is outputting some kind of error message.

[BAntDit]

Can you give me a sample of what you are seeing in dcs.log?

 

 

Yes.

 

Here you are:

 

00300.293 UNKNOWN wWorld::initMissionScripting: slmod_pre_cmd_script[3][1]msg_out_net

00300.293 UNKNOWN wWorld::initMissionScripting: slmod_pre_cmd_script[3][2][string]iteration end time: 186.001, iteration next time: 188.001

00300.293 UNKNOWN wWorld::initMissionScripting: slmod_pre_cmd_script[3][3][number]40

00300.293 UNKNOWN wWorld::initMissionScripting: slmod_pre_cmd_script[3][4][string]chat

00300.293 UNKNOWN wWorld::initMissionScripting: slmod_pre_cmd_script[3][5][string]all

00300.293 UNKNOWN wWorld::initMissionScripting: slmod_pre_cmd_script[3][6]END_OF_CMD

 

iteration end time: 186.001, iteration next time: 188.001 - this is my message.

 

I use this scripts code to print messages:

if slmod then
slmod.msg_out(_message, 40, 'chat', 'all');
end

Edited January 13, 2013 by BAntDit

[Speed]

OH OF COURSE... those are necessary. For now.

 

A little history lesson:

From DCS A-10C 1.1.0.1 to 1.1.0.8, the "mission scripting" Lua environment did not exist. All Lua scripts were run in the "main simulation" Lua environment. This meant you could actually make a mission that would mess up your Windows install or install a virus.

 

In patch 1.1.0.9, Saint rectified this problem by creating the "mission scripting" Lua environment and making the mission scripting Lua environment have NO access to dangerous functions. Even some non-dangerous functions were removed, such as the print function. Unfortunately, this made the mission scripting environment virtually useless.

 

Eventually, I was able to figure out a work-around: During mission scripting environment initialization, I could save a reference to the print function before it was "sanitized". Then, with about a thousand lines of Lua and a Visual Basic Script "daemon", I could use dcs.log and the print function as a sort of transport layer to get scripting commands from mission scripting into a Lua environment where they could actually be executed.

 

This is where the situation stood until DCS World came out. Saint moved the sanitization code to MissionScripting.lua (previously, it was done in C++), so it finally became possible to use something PROPER, like UDP via LuaSocket, as a transport layer. However, since the previous print function method Slmod had been using for most of a year seemed to work flawlessly, replacing it wasn't a very high priority for me.

 

My internal versions of Slmod I am working on now use UDP as a transport layer to send information from the mission scripting to the net Lua environment. I was able to replace 1000+ lines with maybe 150, and significantly improve the speed and efficiency of the code. So there are no print statements used anymore. This is one of the code base updates I am working on for Slmod version 7.

 

If you really need a copy of this internal version that uses UDP instead, then send me a PM with your email and I can send it to you. It's an internal version so it could have bugs in it though, and obviously, it's not ready to share with everyone.

Edited January 13, 2013 by Speed

[Wrecking Crew]

1) You're the second person in this thread to admit this mistake, so that's probably just the tip of the iceberg. If can you tell me a way in which I can make the instructions in the config.lua file more clear, I'd be happy to hear it.

 

Hi Speed,

If someone types in '-reg' and the password is not in quotes or is in some way not recognized, how about returning a private text to that person with "password not defined; passwords must be defined in quotes"?

 

 

I am looking forward to understanding the advanced functions in Slmod, Speed. Us DCS junkies who hang at SimHQ are going to have a second server available soon in addition to Eno's Firehouse and both servers will run your mod.

 

WC

[Wrecking Crew]

I re-installed Win8 on my new server, and Slmod. The '-reg' command wouldn't work, again... because I put in my password in the comment section this time instead of in the code section. DOH.

 

All is working fine now.

 

WC

[Speed]

An update:

Refactoring of base Slmod code to new version 7 standards is pretty much complete:

 

-Moved all global variables in all environments into a "slmod" table (90% complete).

-completely re-write all data passing code to use LuaSocket and greatly improve efficiency (complete)

-completely re-write the active units database compilation code to greatly improve efficiency (complete)

-General code reorganization (complete)

-Re-write slmod events output (complete)

 

Now, Slmod runs significantly more efficiently than before. This is thanks to the Eagle Dynamics team fixing a number of bugs in the game, and making improvements to the scripting engine. This has allowed me to remove several thousand lines of old Slmod code, replacing it with a much smaller number of lines of new code that runs more efficiently. Now, this shouldn't really cause a noticeable difference, as Slmod was already programmed to have an undetectable (or, at the very worst, only an extremely slight, in really huge missions) impact on game performance when you are hosting. However, as I add more features, and as missions get bigger (we are no longer limited to just ~800 units anymore!), I will need this extra elbow room.

 

Anyway, with code upgrades pretty much complete, I'm now working full time (definition of full time: all my modding time) on Slmod Stats. This is the design template I am currently pursuing for how your stats record will look in Lua:

 

--[[slmod.stats
version = 1,  -- what version of Slmod stats- could be useful for later, if I need to change the format of this table.
["c893ad9013fc8b03"] = {   -- a unique UCID, one player.
	id = 43, -- identifier ID# - must be local server only- when re-merging separately compiled stats, must be careful with this.
	names = {  -- list of names the player uses
		[1] = "John",
		[2] = "Speed", -- use the highest-numbered name to refer to in menus.			
	},
	time = {   -- flight time, in seconds.
		"A-10C" = 23221,
		"Ka-50" = 10042,
		"CA" = 9531,
		"F-15C" = 6920,
		"Su-27" = 2420,
	},
	
	weapons = {
		--shot: number shot
		--hit: how many actually hit something
		--objHits: total number of objects hit with this weapon
		
		--[[Definition: "weapon tracked"- this means that after a weapon is fired, if that initiator was a human, then
			the human is associated with that weapon.  If that weapon hits anything, then that human gets credit for those hits.
			Periodically, tracked weapons are tested for continued existance; if they don't exist, they are erased.
			
			--CBUs cannot be tracked easily.
	
		]]
		"30mm HE" = {shot = 1039, hit = 140, objHits = 140, acc = 0.212},  -- only non-shells are tracked (for now).
		"30mm AP" = {shot = 7002, hit = 1319, objHits = 1319, acc = 0.191},
		"AIM-9M" = {shot = 10, hit = 4, objHits = 4 },
		"AIM-120C" = {shot = 57, hit = 19, objHits = 19},
		"Mk-84" = {shot = 12, hit = 8, objHits = 21},
		"CBU_97/CBU_105" = {shot = 43, hit = 0, objHits = 91},  -- CBUs not tracked, and they never hit anything themselves.  So must use BLU-108 and BLU-97 for hits.
		"CBU_87/CBU_103" = {shot = 9, hit = 0, objHits = 23},
		...
	},
	
	PvP = { -- these stats only for player-vs-player- 
			-- for fighter: to get a kill, must be killing a fighter.  To get death, he must get shot down by fighter, attack, or helo.
	        -- for attack: to get a kill, must be killing a fighter or attack.  To get death, he must get shot down by attack or helo.
			-- for helo: to get a kill, must be killing a fighter, attack, or helo.  To get death, he must get shot down by a helo.
		kills = 30,  
		deaths = 19,
	},
	
	kills = {
		plane = 26,
		friendlyPlane = 3,
		humanPlane = 10,
		friendlyHumanPlane = 2,
		vehicle = 119,
		friendlyVehicle = 6,
		ship = 2,
		friendlyShip = 0,
		helicopter = 9,
		friendlyHelicopter = 1,
		humanHelicopter = 5,
		friendlyHumanHelicopter = 1,
		static = 9,
		friendlyStatic = 2,
	},
	friendlyKills = {
		planes = { 
			[1] = 1004215421,  -- Unix time.  These will slowly be erased from your record.. according to a setting in config.lua
			[2] = 1004912310,
		},
		vehicles = {
			[1] = 1005031051, 
			[2] = 1005031054,
			[3] = 1005031057,
			[4] = 1005031061, 
		},
	},
	deaths = {
		crash = 15,
		eject = 7,
	},
	
}, -- end of UCID# "c893ad9013fc8b03"


}]]

 

One thing I worry is this: Stats need to be backed-up periodically, and not just when the server shuts down. So, if the server host is having to serialize and save a massive stats file every minute or so, that could lead to a periodic server host stutter. I've created some fairly efficient table serialization functions, but if you're trying to serialize and save a table with like 900 entries in it, each entry of a similar length to the example shown above, that could too much to handle without generating a stutter of greater than ~100ms.

 

There are two potential solutions. The first is for me to try to minimize the size of the stats table. This could definitely lead to less detailed stats being kept. I don't like that. Maybe, however, there could be ways I could logically “compress” the data.

 

The second possible solution is to use a "stats daemon". The stats daemon would be a separate Lua process, started as an executable. I could make this using LÖVE. Data would be sent to the daemon over a UDP or TCP connection through localhost. The daemon would then go through the processor-intensive process of serializing and writing the stats file instead of DCS having to do it.

 

Obviously, the “stats daemon” approach is a lot more work, and I’d like to avoid using it if at all possible. I hope to run a few tests very soon to determine if I need to use the stats daemon approach or not. If I do, it will probably mean a few extra weeks of delay before I finish SlmodStats.

 

I am considering an optional achievements system, but I doubt it will/would make it for the first version.

 

I particularly like the PvP stats system I have thought up. It's pretty simple:

 

If you're in a fighter:

- You get a kill for shooting down a human flown-fighter

- You get a death for being shot down by a human-flown fighter, a human-flown attack aircraft, or a human-flown helo.

 

If you're in an attack aircraft:

- You get a kill for shooting down a human flown-fighter or a human-flown attack aircraft.

- You get a death for being shot down by a human-flown attack aircraft or a human-flown helo.

 

If you're in a helo:

- You get a kill for shooting down a human flown-fighter, a human-flown attack aircraft, or a human-flown helo.

- You get a death for being shot down by a human-flown helo.

 

This way, players are not penalized in the PvP scores by flying a Su-25 or Ka-50 and being shot down by a fighter. They SHOULD be shot down by a fighter in this scenario, so why penalize their scores?

 

Keep in mind that these are PvP stats, separate from the regular air-to-air stats. See the above table.

 

 

Anyway, your stats, and the stats of other players will be accessible to you in-game via the menu system used for the parallel options/tasking lists, the coordinate converter, and the admin menu. I haven't exactly designed it yet, but I do know what some of the commands will be:

 

"-stats" - main menu/help menu.

 

"-statsme" or "-stats me" - get a summary of your own stats.

 

"-stats <optional "for"> name <name of currently connected player>" - view this player's stats

 

"-stats <optional "for"> id <Slmod stats Id of currently connected player>" - view this player's stats

Edited January 30, 2013 by Speed

[Case]

Hi Speed,

 

Great to see that you are working on this!

 

The second possible solution is to use a "stats daemon". The stats daemon would be a separate Lua process, started as an executable. I could make this using LÖVE. Data would be sent to the daemon over a UDP or TCP connection through localhost. The daemon would then go through the processor-intensive process of serializing and writing the stats file instead of DCS having to do it.

 

Obviously, the “stats daemon” approach is a lot more work, and I’d like to avoid using it if at all possible. I hope to run a few tests very soon to determine if I need to use the stats daemon approach or not. If I do, it will probably mean a few extra weeks of delay before I finish SlmodStats.

 

Back in FC1.12 and FC2 this is the approach I used for the 51st stats page. The obvious reason was that I had no (easy) access to the in game tables. Instead I used the mplog for FC1.12 and the debrief.log/mission file in FC2 which both had a time ordered list of events.

 

The steps I used to go from this list of events to an online stats page were the following:

• a logger program ran on the game server. This checked the mplog/debrief.log every second and added UTC timestamps in front of each new line and copied them into a new file
  
• the game server had an FTP server running which allowed outside access to the timestamped files
  
• my linux machine pulled over new files from the FTP server and
  
• it ran a parser program over them. This program did two things; it parsed the logs to connect events to players (just like your table does) and it returned MySQL queries
  
• the MySQL queries were uploaded to a MySQL database
  
• a webserver accessed the MySQL database to form the stats page
  

 

The main advantage to this is that the game server only runs the logger program and the FTP server, which don't require many CPU cycles. The linux machine then does most of the hard work, but only once every 5 minutes to process the events from those last 5 minutes.

 

When I did the global stats page, where the stats from the 51st, 4c, 3Sqn and 104th were all uploaded to the same page, all that needed to change was on my linux machine, pulling logs from 4 servers instead of one.

 

I'd use this approach for DCSW again, mainly to minimize the load on the game server.

 

Your in game stats would work as well, but it depends what you want to do with the results. I know that Mugatu from 3Sqn uploaded the events to a database directly from LUA, so that is still possible. The only downside to that is that stats can not be reparsed and may get lost on server crashes.

[Speed]

Hi Speed,

 

Great to see that you are working on this!

 

 

 

Back in FC1.12 and FC2 this is the approach I used for the 51st stats page. The obvious reason was that I had no (easy) access to the in game tables. Instead I used the mplog for FC1.12 and the debrief.log/mission file in FC2 which both had a time ordered list of events.

 

The steps I used to go from this list of events to an online stats page were the following:

• a logger program ran on the game server. This checked the mplog/debrief.log every second and added UTC timestamps in front of each new line and copied them into a new file
  
• the game server had an FTP server running which allowed outside access to the timestamped files
  
• my linux machine pulled over new files from the FTP server and
  
• it ran a parser program over them. This program did two things; it parsed the logs to connect events to players (just like your table does) and it returned MySQL queries
  
• the MySQL queries were uploaded to a MySQL database
  
• a webserver accessed the MySQL database to form the stats page
  

 

The main advantage to this is that the game server only runs the logger program and the FTP server, which don't require many CPU cycles. The linux machine then does most of the hard work, but only once every 5 minutes to process the events from those last 5 minutes.

 

When I did the global stats page, where the stats from the 51st, 4c, 3Sqn and 104th were all uploaded to the same page, all that needed to change was on my linux machine, pulling logs from 4 servers instead of one.

 

I'd use this approach for DCSW again, mainly to minimize the load on the game server.

 

Your in game stats would work as well, but it depends what you want to do with the results. I know that Mugatu from 3Sqn uploaded the events to a database directly from LUA, so that is still possible. The only downside to that is that stats can not be reparsed and may get lost on server crashes.

 

Well, the daemon does not read events. All the daemon does is offload the process of serializing and writing the stats file. Compiling statistics is all done through Lua, in Slmod. The stats file is written so that:

1) Stats are backed up in case of server crash

2) Stats are re-read into Slmod on server start, so that stats are persistent across multiplayer sessions.

3) Stats can be output to another location, where some other external process can compile them with stats from other servers.

4) Stats can be read into an online database.

Edited January 30, 2013 by Speed

[Speed]

The daemon I mentioned will not be necessary, I have conceived of a better method.

 

When Slmod opens, it will open the stats file, run it, then re-serialize the stats file and output it again to the file, and leave the file handle open for future writing. The purpose of that seemingly unnecessary step will be clear in a moment.

 

I was thinking of how inefficient it is to re-serialize this big table, when most of the data does not change. Then it hit me- to update the stats file, I need only append the stats updates changes to the end of the stats file:

 

Stats = {........  -- the stats, big long file...
} --end of Stats, now the "stats updates" begin
Stats["af920db91402a"][time]["A-10C"] = Stats["af920db91402a"]["time"]["A-10C"] + 5
Stats["af920db91402a"]["weapons"]["AGM-65D"]["shot"] = Stats["af920db91402a"]["weapons"]["AGM-65D"]["shot"] + 1

 

 

So basically, I'm just appending new lines of Lua code to the end of the stats file that change the value within the Stats table. When the file is re-opened the next time Slmod opens, it will just incorporate all these changes into the Stats table. :)

 

You do have to worry now about the Stats file getting "corrupted". If my code is perfect, then it shouldn't be a problem... but you never know. You don't want to lose people's stats. I will need to program in a method to keep an older backup around.

Edited January 31, 2013 by Speed

[Speed]

Work on stats system is proceeding at a good clip. The basic file and stats compilation/updating/persistence system was completed over the weekend. The stats system now keeps persistent records for all clients of flight time in each aircraft/platform (including CA), weapons fired, and weapons hit. Next, I have to tackle a challenging component: the rules for kill and death scoring. This part will take some time, it is about 100X harder than it sounds.

 

The plan is that once SlmodStats is complete or mostly complete, we can start beta testing Slmodv7 on various servers, even some public servers. Beta tests will require that you run Slmodv7 on your server, and report any irregularities/problems to me, and upload dcs.log and Slmod.log files after long hosting sessions. If you'd like to beta test Slmodv7 and the included SlmodStats system on your server, let me know. I expect to be ready for these tests sometime in the next 2-4 weeks.

[Speed]

SlmodStats, at least, the first test-worthy version of it (which might not be the same version I finally settle on for the "official" Slmodv7_0 release), is nearly complete.

 

I have thought of an interesting possibility: a server-only, private messaging system. It would tie-in with SlmodStats, which keeps a database of player names and UCIDs.

 

For example, a player types

 

"-pm id 87 <message>", and the text of <message> will be stored for the recipient with SlmodStats ID# 87. When this player logs in to the server, he will get a notification that he has a "New Private Message", which he can view with "-pm show new" (which will show the latest unread private message).

 

I haven't really fleshed out the details yet, but I think it could be very useful for things like server warnings-

 

RECEIVED CHAT MESSAGE:

"You have 1 new private message(s), Speed. To view it/them, say '-pm show new' in chat."

 

REPLY:

"-pm show new"

 

RECEIVED TRIGGER TEXT:

"PM 4 of 4, from: "Goose" (server admin):

speed you now have 2 warnings for using foul language on our server. one more and you are banned. please watch your mouth, we have a no swearing policy.

Thx, Goose"

 

What do you guys think? It's very doable, and not terribly difficult. The object oriented SlmodMenu class I created last spring is really paying off :)

[NineLine]

SlmodStats, at least, the first test-worthy version of it (which might not be the same version I finally settle on for the "official" Slmodv7_0 release), is nearly complete.

 

I have thought of an interesting possibility: a server-only, private messaging system. It would tie-in with SlmodStats, which keeps a database of player names and UCIDs.

 

For example, a player types

 

"-pm id 87 <message>", and the text of <message> will be stored for the recipient with SlmodStats ID# 87. When this player logs in to the server, he will get a notification that he has a "New Private Message", which he can view with "-pm show new" (which will show the latest unread private message).

 

I haven't really fleshed out the details yet, but I think it could be very useful for things like server warnings-

 

RECEIVED CHAT MESSAGE:

"You have 1 new private message(s), Speed. To view it/them, say '-pm show new' in chat."

 

REPLY:

"-pm show new"

 

RECEIVED TRIGGER TEXT:

"PM 4 of 4, from: "Goose" (server admin):

speed you now have 2 warnings for using foul language on our server. one more and you are banned. please watch your mouth, we have a no swearing policy.

Thx, Goose"

 

What do you guys think? It's very doable, and not terribly difficult. The object oriented SlmodMenu class I created last spring is really paying off :)

 

That sounds very cool... could they be automated as well, maybe so many friendly kills generates a message?

[HiJack]

Great idea Speed! So you think of making an list of foul words in all languages? Or manually managed by querying the logs?

[Speed]

Great idea Speed! So you think of making an list of foul words in all languages? Or manually managed by querying the logs?

 

Negative. I have no intention of working on a swear filter, I'm contemplating a private messaging system. If I decided to make it could be used for anything- giving warnings, coordinating meetings with other players, sending a nine-line, etc. I would think that the biggest problem would be no one realizing it is there or thinking to use it. Sorta like the coordinate converter- I wonder if anyone has ever used it besides me. It's a useful tool, but no one knows about it.

[Paganus]

Units killed is tricky.

 

About the only thing you can do if multiple entities hit a unit is give the kill to the last entity to hit it before the kill.

 

 

In the log parser our group uses, we pull all units killed and then pull each entity that hit it. When you compare time stamps you get the last one to hit it.

 

 

Then there's the "Building" problem.

 

 

It is a pain.

 

Players coming and going, disco's etc. just muddles it up even more.