Plutonium

I fixed the warnings in the console, I included the explanations at the bottom for those who are curious about it.
I also made it not unnecessarily thread on bots, just a small performance "fix"
Kalitos Maybe this will interest you or maybe you wanna update your script on the OP

#include maps\mp\gametypes\_hud_util; Init() { level thread OnPlayerConnected(); } OnPlayerConnected() { for(;;) { level waittill("connected", player); // Don't thread DisplayPlayerKillstreak() on bots if (isDefined(player.pers["isBot"])) { if (player.pers["isBot"]) { continue; // skip } } player thread DisplayPlayerKillstreak(); } } DisplayPlayerKillstreak() { self endon ("disconnect"); level endon("game_ended"); self.killstreak_text = createFontString( "Objective", 0.65 ); self.killstreak_text setPoint( 0, "TOP", 0, 7.5 ); self.killstreak_text.label = &"^1KILLSTREAK: "; while(true) { if(!IsDefined(self.playerstreak) || self.playerstreak != self.pers["cur_kill_streak"]) { self.playerstreak = self.pers["cur_kill_streak"]; self.killstreak_text setValue(self.pers["cur_kill_streak"]); } wait 0.01; } }

a4ceda64-034c-4d0e-9cdf-4e19d642f79b-image.png
For some reason the game seems to throw a warning when you pass "CENTER" in the setPoint function so I replaced it with 0.

f351ea10-85f0-4ed5-a7e3-411d0d042070-image.png
This was happening because when doing this

if(self.playerstreak != self.pers["cur_kill_streak"]) { self.playerstreak = self.pers["cur_kill_streak"]; self.killstreak_text setValue(self.pers["cur_kill_streak"]); }

the first time the playerstreak variable isn't defined yet because it's a variable created by the script in that if condition.
So to make sure the script works normally I added another case !IsDefined(self.playerstreak) || so that it will work both when our HUD needs to be updated and also when our variable isn't defined yet (first iteration)

b0c22f71-7c72-41a4-8826-e48601349c21-image.png
Same than above, when comparing undefined to a variable the result isn't true or false but undefined (to my understanding)

Solved, I had to download the dlcs from the guide link on my server, my client did work the way I had it. Thank you all. And I used my old copy since I have it in Spanish and the guide only says English.

Yeah, it was immediately abused on our servers. I wouldn't suggest using it.

Wow, buen trabajo titan 👍

Jimo added

Kalitos Only put them in the game folder.

Demon xModRx no u cn only use map specific guns

I doubt it is exposed to GSC, but maybe you are lucky and it is in self.pers

Kalitos said in Contents of the GSc file "_clientids" !Question:

Ox_ I agree with you, although since you mentioned the gsc dump search, I got on it, and if you talk about ".clientid", the game does refer to it, but it directly includes "player.clientid". On the other hand, if we search for level.clientid, we only see that it refers to a single file "_clientids.gsc". It's strange.

The level.clientid part doesn't seem very interesting or relevant, it just increases and then gives the next player the next number.
But each player getting their own clientid field is that interesting part.

Searching for uses of that field (the field owner by a player, not the level) in patch_mp comes back with 70 matches (few of them in dev blocks though) across 14 different gscs.

Sass said in Contents of the GSc file "_clientids" !Question:

I know the file existed back in CoD4, and wasn't even used back then IIRC.

To clarify, player.clientid's do indeed exist and is (somewhat) used in the game. However this file doesn't handle them at all as you can already tell.

If you replace the _clientids gsc with e.g. this

init() { level thread onPlayerConnect(); } onPlayerConnect() { for(;;) { level waittill("connected", player); player thread onPlayerSpawned(); } } onPlayerSpawned() { self endon("disconnect"); level endon("game_ended"); for(;;) { self waittill("spawned_player"); self iprintln(isDefined(self.clientid)); } }

You'll see that that field indeed doesn't exist if we patch _clientids to not create it.
(As opposed to that field working just as expected if we don't patch _clientids)

Makes me wonder how come we're not breaking the functionality in those aforementioned 15 different gscs.
Or perhaps we are, but the functionality there isn't essential. I cba'd to study/test that.

Kalitos

currentround = game["roundsplayed"]+1;

Kalitos A bit off topic, but you should know that you can utilize a HUD element's label attribute in order to prevent unnecessary unique string usage. Here's an example of your code converted:

healthPlayer () { self endon ("disconnect"); self.healthText = createFontString ("Objective", 1.7); self.healthText setPoint ("CENTER", "TOP", 300, "CENTER"); self.healthText.label = &"^2 HEALTH: ^7"; while (true) { self.healthText setValue(self.health); wait 0.25; } }

As you can see, I assigned some text to your HUDs label attribute and replaced setText() with setValue(). This can be done because you only ever need to update the health value and not the text before it. Using this method, you're only using one unique string rather than a new one every time the player's health changes.

Kalitos

finally getting time to try to test this stuff out.

I had created that thread I linked above ( https://forum.plutonium.pw/topic/1121/removing-mms-target-finder-attachments-bo2/2?_=1587664126629 ) - before I found your thread and replied to it. since then TheHiddenHour posted there.

Trying not to double ask the same questions on both threads to keep things more simple. If you wouldnt mind / have time if to post on there, I would be grateful.

Thank you!