Jump to content

s1a

Members
  • Posts

    16
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

s1a's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. No worries, I never came back to ask until Hellreturn asked for the autoshuffle based on KD again last week . Thanks!
  2. Hey DIABOLIK, This is just for the server side. Beware, the file is a .zip file, it's not a pk3 so the client isn't downloading this. You need to upload the content of this zip file in your server. It won't change anything for the client but for the admins.
  3. I've poke a bit in the etpub code and realistically it would take more time for me to do the diff than to you to do the addition. The elements we need are in "g_player_rating.c" and are defined as: float overall_killrating; float overall_killvariance; float rating; float rating_variance; Those are part of the "session" (clientSession_t) of a player which is defined in "g_local.h". Which is also part of the following struct (if you look at the 4-5 first variables of that struct in the "g_local.h" file): struct gclient_s Which is what we use to "allow" those variables in g_lua.c (define found in g_lua.h): #define _et_gclient_addfield(n, t, f) {#n, t, offsetof(struct gclient_s, n), FIELD_FLAG_GCLIENT + f} So to sum up, would it be possible to add the following in "static const gentity_field_t gclient_fields[]" in the g_lua.c file: _et_gclient_addfield(sess.overall_killrating, FIELD_FLOAT, FIELD_FLAG_READONLY), _et_gclient_addfield(sess.overall_killvariance, FIELD_FLOAT, FIELD_FLAG_READONLY), _et_gclient_addfield(sess.rating, FIELD_FLOAT, FIELD_FLAG_READONLY), _et_gclient_addfield(sess.rating_variance, FIELD_FLOAT, FIELD_FLAG_READONLY), It would be much faster if you could do it directly since it's a very light change and I'll put it on a temp linux server to see if it works as I expect it. Let me know if you would prefer me to do the changes in etpub to test it. That might take a couple days since I don't have anything to compile etpub at this moment.
  4. I'm up for suggestion on the matter. On the FA Silent server, most of the time the "strong" players already played a couple hours. So ratio is normally already well adjusted. There is some new players joining from time to time, but it's still not happening very often. That's why I was originally suggesting the KR since for a new player that is very good, it will go up very fast. However, it's not always true that a good fragger will change the game. Just to make it clearer, the diff I'll provide is how to make the PWR and KR available to the gentity fields.
  5. If you balance the teams using K/D, it might do that. However, the PWR would be a good way to achieve a balanced team. I saw the other thread about team sorting and it can be done in LUA, the only problem is the availability of the gclient entities for the players. Since you said that the g_lua.c is very similar to etpub, I'll give you some diff on how to make those available in etpub and you can see if it fits for Silent.
  6. This could either be done in LUA or in the mod itself (it would be a great addition). The shuffle is already configurable where you can shuffle by K/D, XP or PWR. We could do the same for changing team "prevention". There is already some code to prevent people from joining a team that has more players. Just add a new cvar to allow the "change team" to be configurable: by amount of players, by K/D, XP or PWR. This way you don't have to lock the teams in a certain way and prevent the players from joining another team as well as not preventing the specs from joining. This would keep the teams balanced by a configurable ratio. In this case, the only way to make the teams unbalanced would be having a lot of players leave one team. Then it's up to the admins to putteam some key people in the other team or in spec. This would also help admins to not always have to putteam people that try to stack. To do it in LUA, I would have to check how to catch and prevent a change team. This would be complicated since it has to be stopped before the class of the player change. I've dig a bit in LUA and there is a way to just break the "/team" command. I could use that to prevent the team changing. I would have to make sure that I'm catching everything command. The limbo menu is using the team command as well as the popup menu. I'm not sure what are the other commands that can be used to switch team (except putteam). I would also have to match for the different teams to join: 1/r/R/a/A/b/B/2/3/s/S, etc. There has to be some logic in the blocking since /team is the way to change class also. Another way that would be much simpler is to lock the team. The check could be done every 100ms and would lock/unlock teams appropriately. I see 2 issues with that way: - there has to be a 100% thrust in the script that it will never forget to unlock a team (it can be achieved by issuing an unlock at each 100ms and locking right after) - the players doesn't get a feedback of why they can't join the team However, I have an issue to finish the 2nd most important part: I couldn't find any gclient fields that are available in LUA that gives the PWR and K/D. This means that until those are available for LUA, this mod can't be done. I think it would be a very good idea to provide the PWR and K/D gclient fields to LUA as RO since that could be useful for other LUA mods. But at this moment, it's not available and LUA can't be used for this purpose until those gclient fields are available. According to gaoesa, the code is the same for the g_lua.c as etpub. By taking a look at the array: static const gentity_field_t gclient_fields[] You can see that it's not available (I've look into ps.stats, sess.game_points and sess.skillpoints since they looked like "ratings"). The g_lua.c file is important for LUA coders and it would be great if all of it could be release to public or just added to the LUA documentation since the ETPro one is becoming more and more obsolete. This file tells what is available for LUA coders. In etpro, the source wasn't available, but they made sure that all the information from the g_lua.c was available at http://wolfwiki.anim...php/Lua_Mod_API. For etpub, they updated the LUA documentation from time to time, but they didn't really care since the source code was available. For Silent, you either have to document every functions that are in that file (you are missing about 10-15) + the gclient fields (you have about 5 more than etpro so their page is obsolete http://wolfwiki.anim...x.php/Fieldname). Even if I gave a good example on how it can be done in LUA, I think it would be a great addition in the mod itself.
  7. But then you have to be an engineer to do that and also, it's easily noticeable which breaks the "detector" category. I was more thinking of something more "invisible" in term of where they step but that you can still destroy. I'm thinking of it like a camera but without giving the output. Like a detector on top of your garage that as soon as you are close, it lights up so you can see. However, from a distance, you can destroy it. So like a tripmine, usable by all the classes, not doing any damage when you pass next to it but just a sound. If you pass next to it, it stays there and alert the "planter". However, the beam has to be "bigger" so it triggers more easily and has to be invisible like a fishing rope. I know it sounds pretty lame, but it could be useful in the cases I mentioned.
  8. What SilencerPL said is more what I had in mind. The camera is too advanced for the game. I also agree with you that the sensor detector might be too early also. A trip mine with a somewhat invisible wire would be better. I would say they used to (in WW2) put something like a fishing rope to do that, but this is from a movie so I don't know if it's true at all. @Phantas, putting a computer in spec and looking at it is cheating and not really my idea since the way I was seeing it is to have that "camera" sitting in the same spot all the time. You can only see that point of view and if you want to move it, you have to destroy and replant it. Think of it more like a landmine or tripmine where you get the warning when it hits someone. Then you run back where you know you planted it to finish him off or defend. This is just an idea since in this mod we seem to bring new guns (ppsh), new tools (trip mines). Then why not a new detector tool. However, will that get ever used... I don't know for the others but I would at some extend if it would assure me to let me know if there was a detection.
  9. I just want to precise that this is an idea and would like to apologize if someone doesn't like it. While I play the game on the defending team, I usually end up having to cycle through the same places. By example, in et_beach_invasion where once you are at the top, you have to defend both sides. Another example would be braundorf where you have to cover the east and west side on top of main. Adlernest is another example where if you don't camp at the objective, you have to cycle everywhere or have full confidence in your team. I basically end up camping in every objective spot and have less fun. Some could say, just go out and play the game if you don't enjoy it. However, I prefer to win than to kill. My idea came from some less skilled players that I use as "decoy". Even though that could sound harsh, they actually make us win the map. When I know I have those kind of players having fun next to the objective and that I see they will stay there. I count on them to be the "decoy". I closely watch the kills while protecting another side and as soon as my "decoy" dies, I rage back to the objective. The idea also came from one of the popular hacks on ET. I remember that one where I had a view of where my mortar would land. It would give me a "camera" of the spot on top of my game. Maybe that one got updated and now has my idea incorporated. It's been a while since I tried the newest hacks on a priv server. Now the idea: Having some sort of destructible enemy detector that could be a camera on top of the ET view. Since this wouldn't be WW2 like, what could be possible is a sensor. As soon as it sees you, it starts an "alert" until you turn it off. It could be like in RTCW where as soon as the enemy sees you, it starts an alarm. Each time it spots an enemy, it rings again until it gets shut off. The tool should be destructible from a distance also alerting the owner of the tool. Let me know what you think of it. What part you think is possible or not. Also if you like the idea or not at all.
×
×
  • Create New...