JvIasterMind

I really enjoy having g_skills set to one. I mean, if you can see a landmine, of course you would tell all of your teammates on the battlefield. However, once people have high xp on xp save servers, almost everyone starts to have that ability. This takes away one of the covert ops' greatest abilities, which helps to discourage the teamwork that goes along with needing a covops to help spot landmines. I think it would be a great option to be able to restrict the ability in g_skills 1 to only allow players to spot mines when they are close (can see the white outline). This also makes sense in the game perspective where normal soldiers are not likely able to detect mines from a distance, whereas maybe a covops with special training might be able to. But, if you notice that there is a mine right next to you, you would definitely tell your teammates. I believe that this restriction would be the best of both worlds and help to bring back the usefulness of the covert ops class.

Still, I hope you do consider putting in options that can nerf adrenaline. Our server generally has a lot of players that come from etpro. Quite often, when they see people using adren, they complain or leave the server. I think if we could limit its effectiveness, they wouldn't have as much of a problem with it. So far, I haven't heard these players complain much about the other class upgrades such as the flak jacket. Adrenaline just seems much more overpowered compared to the other rewards. We thought about disabling adren on our server, but there were a few players that were completely against the idea. However, they were fine with the xp requirement increase and I'm sure would be open to settings similar to what I originally proposed (so we can change the xp requirement back to normal). I do think it would be fun to have some settings that encourage teamwork, but even a team player that earned it is still overpowered when using it. It might work fine on "fun" servers, but it's far too much of an advantage on a really competitive server. Because adren is probably the most controversial setting in ET, I would love to see settings for both encouraging teamwork and for limiting adren effectiveness so server admins can mix and match the settings to best suit the server.

I think that is a good idea. The situation where that would feel strange would be if you earn a class skill while not earning enough xp for g_XPSaveMinXP. The next time you would connect you would lose the skill also. Not quite sure how players would react in that situation, but it would be pretty short lived since they can quickly earn the skill again if g_XPSaveMinXP is low. One thing I think we should have would be an entry in the stats window that tells players how much xp they need for xp save. I would imagine the best place would be somewhere near where the xp required to gain a skill level is listed. I don't think I would use an option like that. If you reset the skill upgrades, the xp seems kind of useless (other than showing how much you play). I think most people play on xpsave servers to preserve their skills. Plus, if a player wanted to earn the upgrades again, they could just do a !resetmyxp command. The other issue is that many players use the xp number to gauge how many skills the other players on the server have (ie, a medic playing on a server with 5000 xp likely has adren or an engy playing with 5000xp likely has a flak jacket). Having the values separate might cause some confusion.

Another idea could be to remove the damage reduction if the player using it fires their weapon (like how g_spawnInvulFair works). This would allow players to still use it for running the objective or to make a critical revive in the battlefield, but would still discourage players from using it for battle.

The double boost could be the stamina benefit for the first one and the damage reduction for the second one. That way the rambo medics would only get the stamina increase while the players with teamwork can get the full benefit.

There are some players on our server that keep their xp past the g_XPSaveMaxAge_xp by connecting and then disconnecting again without playing every couple days (our g_XPSaveMaxAge_xp is set to 60h). To combat this, it would be nice to have a cvar that could specify a minimum amount of xp that needs to be gained in a session to reset the xp save timelimit for that player. This way, we could set it to some low value like 100xp to ensure that the player at least plays a little bit and earns the time extension.

I like that one also! Still, even with that limitation, it would be good to also have options to decrease its effectiveness. We should have all three!

I have always felt that adrenaline is way to powerful. Currently, we have adrenaline enabled on our server, since there are a few members/regulars that really enjoy it. However, we also get a lot of complaints with many people suggesting that we disable it. Most of our players feel the same way I do about it and just refuse to use it. Anyways, we have attempted to make it much harder to get it so that it isn't as much of a problem. Our "solution" was to increase the amount of xp needed for level 4 medic to 700. This isn't working very well, as the people who want it tend to connect often enough so that they can use it every time they play (xp save resets after 60h). I am proposing some options to allow server admins to make adrenaline less powerful. Here are a couple possible solutions that I think would work fairly well... First, add an option (likely to g_medics cvar) to make adrenaline use 50% of your charge bar instead of the full 100% Then, add one of the following options... An option (g_medics) to disable the damage reduction that adrenaline gives (so adrenaline only gives the unlimited stamina benefit) This combined with the reduction of charge bar usage would still keep adrenaline useful for running with an objective or running on the battlefield to revive a teammate, but makes it less powerful for rambo medics using it in battle. [*]A cvar to adjust the damage reduction value for adrenaline (as a percentage). This way, server admins could just reduce the damage reduction to a value that they feel is more balanced. You could also accomplish the same thing as the first option and set the damage reduction to 0 (which I think would combine good with the 50% charge bar usage) Using the first option and adding just the two bitmask values to g_medics seems like it would be the more intuitive method as server admins would not need to worry about a new cvar. The second option would be a lot more flexible because you could keep adrenaline using 100% of the charge bar and just tweak the damage reduction down a little bit to help balance it without changing the feel of how adrenaline works currently. What do you guys think?

Yeah, I mean when you shoot a teammate Ah ok, so the wiki is the place to go for the cvars. I was using the silEnT Server Manual (http://mygamingtalk....ual/server.html). I guess it's a bit outdated. Thanks for the link!

That worked! The server manual says that 8 is an unused option. Is this a bug, or is 8 supposed to be the bitflag for enabling the team hitsound? Also, is there any way to get the "Hold your fire!" sound to play?

I have been unable to get the team.wav hitsound working on our testing server running silEnT 4.0. Our server has friendly fire enabled, so it is a problem when you shoot your teammate and it sounds like you are shooting an enemy. I tried using the default hitsounds and also tried custom hitsounds in our pk3 (in the sound/hitsounds/ folder). In both cases, the head.wav and body.wav files both worked, while the team.wav file had no effect. Also, a player pointed out that there is no "Hold your fire!" sound for team damage. I would like to turn this on if possible. Is there a setting that I need to enable to get this sound?

Is the default speed in silEnT faster than it is in etpub or etpro? I am running set g_speed "320" (which I am assuming is the default). At first I didn't notice a difference, but when I tried some trickjumps, they felt quite a bit easier to do. Am I just imagining it? Or, do I have to decrease that value to make it equivalent to the default speed in those other mods?

Thanks for your quick responses, gaoesa! I really am enjoying this community and think you developers are doing an exceptional job! On our ETPub server, we put our hitsounds in a custom folder similar to sound/IoW/hitsounds/. Then we used the path cvars to point to those files. Doesn't that force the client to reload the new files when they connected to our server (even from another server), since the new paths are specified in the server config? That is what I meant for helping to bypass the problem. Still, I do like the idea of not having all those path cvars. It is much cleaner replacing the standard sounds in the pk3. Now, I understand that using a pk3 that starts with a character after 's' allows for modifying the files fairly easily. But, since the client would be using the exact same path on the new server as the server that they arrived from, wouldn't that be part of the problem? By having a specified path (or preferred directory), it seems like it would force the client to reload the files when they connect since it is not referencing the same path anymore (assuming that the preferred directory is not named the same). Hope that clears up what I was thinking. Please correct me if any of that is wrong... I do enjoy hearing your insights on how all of this stuff currently works! Thanks for considering the suggestion!

I was afraid that would be the case. I think we had a problem with this a little while back, but it was probably from somebody that came from another server running the same mod. Did you guys take out the "g_hitsound_" cvars to specify the hitsound paths? I kind of assumed that you did because the references were removed in the server manual. Those cvars kind of helped to bypassed this problem (although it only worked for hitsounds). Could you guys kind of do something similar, but instead have a cvar that specifies a preferred directory (instead of the individual files)? What I mean is to create the (normally top level) file structure within the directory specified by the cvar. Perhaps the mod could check the directory first (if the cvar was specified) and fall back to the main directory if it doesn't find the file. So, I would set the cvar, for example... set sv_preferredDir "IoW" Then, I would put the standard named hitsounds in IoW/sound/hitsounds/ instead of sound/hitsounds. If the game doesn't find the IoW/sound/hitsounds/ directory, it would just load the hitsounds from the sound/hitsounds/ directory that it loaded from silent-0.3.3.pk3. Would something that that be possible?

Here's something that has always bugged me when providing a custom pk3 that overwrites files such as sounds, textures, and other stuff... When I create a pk3 file, say, to override the default hitsounds, I need to name the file in a way that it is opened later than any other that might use the same filenames (and paths). I believe that the pk3s are currently just loaded in alphabetical order, so I noticed that a lot of clans start resorting to prefixing the pk3 name with the letter 'z'. In more extreme cases, since z<filename>.pk3 is already common, I have been seeing many files prefixed with multiple z's. It kind of feels like a little battle because you want your files to always load last to make sure that everything works as intended on your server. Anyways, I think it would be great if there could be a server-side cvar such as "sv_pk3priority" that would ensure that the specified pk3 loads after all of the others. This would be really helpful on my server because I try to prefix all of the custom files with my clan's tags so they are all grouped and easy to pick out both on the server and in the client's folder. In this specific example, I would like to have a line in my server config that reads... set sv_pk3priority "IoW_Required.pk3" (Currently, my IoW_Required.pk3 file (that is attempting to overwrite the hitsounds) loads before silent-0.3.3.pk3 and the hitsounds get reverted back to the ones in the silent pk3.)

I would love to help test version 0.4.0 instead of 0.3.3 on IoW's test server. We get a good amount of traffic on our testing days since we are considering switching from ETPub on our main server.