Plutonium

You are welcome

Hi Black-maks, even if I send you a fast file with the perks table modified you will still have to give unlimited sprint yourself the perk with another script and I honestly don't remember how to do that.
I just remembered that not too long ago I made a server plugin for pluto IW5 that adds a console command you can use to give yourself unlimited sprint.

marathonPerk <player num>

if you don't know how to create a fast file and do it with GSC this plugin is probably going to make it easier for you. The following plugin does many other things as well so perhaps it's also not entirely suited for this purpose. So I think you still figure out how to create fastfile and give yourself perk with GSC scripts.

DisablePlutoChat

• Get yourself zonetool.dll and zonetool iw5 binary
• Download the repository I linked
• Put the contents of the raw folder inside a folder called zonetool in the game folder of iw5
• Put mod.csv in a folder called zone_source
• Open iw5 zonetool and type buildzone mod
• Go to zone/english and find mod.ff
• Put that in storage/iw5/mods/modname
• Set fs_game dvar
• Enjoy

This is totally possible with minimal effort.

I have a mod that adds the marathon perk (from MW2) to the perkstable.csv
https://github.com/diamante0018/InfectedGSC/blob/main/raw/mp/perkTable.csv#L80

So all you need to do is create a mod that modifies the perks table CSV file. You need zonetool to build a mod fastfile. After that you may just give yourself the perk with a simple GSC script.

PutPut Please make a feature request in the Feature / Bug Bounties section of the forum for the console command "kill".
You should specify in the feature request it's for IW5 only because the other games already have it.

add a call to SetVelocity.

self setVelocity( 0, 0, 0 );

CoNNoUK

:::

:::

If the crosshair is disabled by that dvar then I suggest you find in the game's code where the cross hair is supposed to be rendered and force it to always render. It's not impossible, just difficult.

camera_thirdPerson's value is propagated by the server to all connecting clients, it is cheat protected and has another flag I don't know about.
It's a dvar shared by both game and the server. So I guess it depends what's your definition of client dvar, but I would consider it one.
So, by all means, camera_thirdPerson is good to use because you just need to change it server-side and its value will be updated to all clients.
Since it's cheat protected it will be reset to its original value once a client disconnects from your server so you don't have to worry about messing with client config. So if the reason for not using camera_thirdPerson was because you thought it was not a client dvar, now you know.

Uranium t5x?

I am guessing you are trying to launch the server "headlessly"?

I am quite positive wine needs an actual display to create the window.

If you were to checkout the other guides on the forum they will tell you how to install the Gnome shell and how to connect to it using xrdp.

It happens very often and can only be fixed by shutting down the server and starting a new instance again.
Basically, 1 or more players do not connect successfully to the server and are stuck in the spectator's team with the connecting icon.
The issue is that they take away slots that can't be used anymore so the server's player capacity goes down with each occurrence of this bug. The highest I got was 3 slots occupied by zombie players.
Is there are workaround like enabling "g_inactivity"? I suspect this is an issue caused by recent updates because it's the first time I notice it on my server.

How to reproduce crash step by step (so the devs may investigate further).

• Start a private match
• End the game after reaching the objective (for example I reached the score limit after I killed 30 bots on FFA default dsr configuration)
• Wait for the game to end
• After the game puts you back to the main menu go back to private match
• Press continue when viewing match report/scoreboard
• Crash

Am able to reproduce crash 100% of the times when following these steps.
Here is my dump anyway (MEGA link) : link text

fed I'll accept your solution as a valid workaround. Thank you very much.
Waiting for one of the devs to acknowledge the bug anyway since the underline issue stays.

@Mr-Android Hello, I hope my tag finds you well.
I believe I have located the root of the problem.
https://github.com/momo5502/open-iw5/blob/master/src/game/scripting/parameters.cpp#L98

It seems there is no possibility under the current implementation of chai to use unsigned integers as parameters for game functions because there is no code to unbox them and send them to game functions. I hope this will be considered in a future Pluto release because the vector ds is a chai script feature and while it's unfortunate their .size() function returns a uint I think it should be supported.
Thanks.

Xerxes Triggers the same error.

 var secondaryLength = 0 + secondary.size();
 var a1 = gsc.randomInt(gunListLength);

Also tried multiplying by 1 but it appears chai script doesn't forget it's dealing with an unsigned int.
I will try to look on their Github issue tracker to see if it could be something on their end but I'm afraid it's pluto bug because I would not expect their built-in data structure to cause bugs when attempting to do simple things like this.
As a work around (and because chai script doesn't expose rand()), I have found a simple random number generator online:

def myRandom(max)
{
    var seed = gsc.getTime();
    var a = 1103515245;
    var c = 12345;
    var m = 2147483648;

    seed = (a * seed + c) % m;
    seed = seed % max;

    print("Return random number " + to_string(seed));
    return seed;
}

That is my workaround, but for obvious reasons, the randomness is very wack and when I call it from the same function gsc.getTime(); returns the same seed since it can only return multiples of 50.
It would be great if one on the devs could look at unboxing unsigned integers.

How to replicate bug:

global secondary = ["emp_grenade_mp", "flare_mp", "flash_grenade_mp", "concussion_grenade_mp", "trophy_mp"];
var secondaryLength = secondary.size();
var a2 = gsc.randomInt(secondaryLength);

Output:

******* Script execution error *******
Unable to unbox value of type 'unsigned int'
**************************************

gsc.randomInt(int max); works well when using any other number that does not come from the function .size().
According to documents I found online global variable "secondary" is a vector and the function size should return the number of elements inside the vector.
For some reason this sequence of code breaks. The number that is returned from the function size() can be used for anything else but I simply cannot call gsc functions from what I can gather.
Unfortunately, I can't tell if this is chai script bug or a pluto bug.
Any advice is greatly appreciated.

Kalitos No, I gave up 8 months ago because Chai script lacks everything I am used to when I code in other programming languages.
Recently the clan I'm a part of opened a server on Pluto so I might do something although given the fact IW4M already has a built-in killstreak counter I don't think I will do this specifically.
Also, Pluto doesn't have all the Hud Elements in handy so it's a nightmare to centre text on-screen since different players might have different resolutions.

Hello, this is the first time I post a tutorial so please be kind :).
So this tutorial is for anyone who hosts an MW3 server on a Linux distribution that has UFW (Like Debian, Ubuntu or Arch). I'm sure it can be replicated with iptables alone which is a module present in any Linux distro (or it can be installed on any I think).
The information I have on game ports is true for a good old Tekno MW3 server but I'm sure the same rules apply for a server hosted with Pluto.

Enable UFW:
If you have followed the headless tutorial made by Spectre you have already UFW enabled. Just in case do

sudo ufw status 

It should say

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

If not please follow Spectre tutorial as he explains how to enable ufw on Ubuntu 16/18/(and 20)
So now that you have ufw enabled you probably also have added your custom rules for allowing traffics to the ports used by your game server(s).

Disable IPV6
Open with nano (or another editor) /etc/ufw/ufw.conf and add IPV6=no like this:

# /etc/ufw/ufw.conf
#
IPV6=no
# Set to yes to start on boot. If setting this remotely, be sure to add a rule
# to allow your remote connection before starting ufw. Eg: 'ufw allow 22/tcp'
ENABLED=yes

# Please use the 'ufw' command to set the loglevel. Eg: 'ufw logging medium'.
# See 'man ufw' for details.
LOGLEVEL=low

You don't need IPV6 IPs peeping on your server right now so just block them right away.

Restrict access to net_authPort and net_queryPort
These two ports don't need to be accessible by anyone but your VM/VPS IP address. Let's say that you have already put a general rule in place for these two ports and you want to replace it with a more restrictive one, how do you delete UFW rules?
Type:

sudo ufw status numbered

A numbered list will be printed in your terminal window with all the user rules you have put in place (they can be found in /etc/ufw/user.rules)
Let's say the ports 27017 and 27019 are your net_authPort and net_queryPort and you see this in your terminal window (when a protocol is not specified in a rule ufw will allow both udp and tcp packets and block other protocols):

[ 5] 27017                  ALLOW IN    Anywhere                  
[ 6] 27019                 ALLOW IN    Anywhere  

now proceed to delete the old rules with these commands:

sudo ufw delete 5

(Repeat sudo ufw status numbered as now the order of the rules might have changed then delete what was the 6th rule)

Now that we have deleted the old rules let's restrict the access to the net_authPort and net_queryPort so that only the IP address of our machine can access that port:

sudo ufw allow from VPSIP to any port Game_port

Replace VPSIP with the IP address of you VPS and the game_port with the port of net_authPort and then repeat for the net_queryPort
Now you might think, what would have happened if I didn't bother deleting the old rules? UFW rules are applied in order! So if a packet comes in UFW will check the user's rules in the order printed by sudo ufw status numbered and when ufw finds the first rule that allows the packet to come in it will stop and allow the packet in (if there is a blocking rule afterwards it will be ignored! more on how to prevent this later).

Restrict amounts of packet an IP can send to the master port
I don't think the pluto devs have changed this, but basically it is known that a legitimate IP will send 2 bytes (of packets) to the master port every 10 seconds. The master port is a very vulnerable port and needs to be protected.
We will modify the before.rules found in /etc/ufw/before.rules I will use the nano editor to accomplish this.
The before rules are evaluated before the user rules (added via the command sudo ufw allow) so if you want to avoid messing with the order of the user rules you can modify the before.rules like I'm about to do.
Type

sudo nano /etc/ufw/before.rules

Add these two lines after the *filter

*filter
:ufw-http - [0:0]
:ufw-http-logdrop - [0:0]
(other default lines here)
# End required lines

This is the interesting part, add these rules before the COMMIT line or they won't be processed:

# http
-A ufw-before-input -p tcp --dport 80   -j ufw-http

# https
-A ufw-before-input -p tcp --dport 443  -j ufw-http

# tekno master port (master server port)
-A ufw-before-input -p tcp --dport (your master port here!)  -j ufw-http

# Limit connections per Class C
-A ufw-http -p tcp --syn -m connlimit --connlimit-above 2 --connlimit-mask 24 -j ufw-http-logdrop

# Limit connections per IP
-A ufw-http -m state --state NEW -m recent --name conn_per_ip --set
-A ufw-http -m state --state NEW -m recent --name conn_per_ip --update --seconds 1 --hitcount 1 -j ufw-http-logdrop

# Limit packets per IP
-A ufw-http -m recent --name pack_per_ip --set
-A ufw-http -m recent --name pack_per_ip --update --seconds 1  --hitcount 2  -j ufw-http-logdrop

# Finally accept
-A ufw-http -j ACCEPT

-A ufw-http-logdrop -j DROP
COMMIT

What we did above was basically tell ufw to drop (reject without sending a notice to the source) any packets that don't satisfy these rules. Now your server is protected from most DDOS attacks, I didn't mention the net_port because it seems that no matter how hard it gets ddosed nothing much happens so let's just pretend it doesn't exist (bad advice probably).

BONUS TUTORIAL
Want to IP ban a player you hate a lot?
Open your before.rules again and add this rule (don't forget #comments or else ufw will not considerate a rule without an accompanying comment)

#Block XXX IP from XXX (or whatever notation you want to add)
-A ufw-before-input -s IPAddressHere -j DROP

Again all the packets will drop, dropping means discarding a packet without telling the source, if you wish to send a response to the source about this refusal add -j REJECT instead of -j DROP but I do not recommend this.
If you have UFW logging set to low, all rejection should be logged and saved in /var/log/ufw.log so you can see there (again with nano) who's knocking on your server. You will find that older logs are compressed and their name is changed like ufw5.gz it will be tricky to access these logs as you are not the owner of these files (the mysterious syslog is the owner) so have fun with that.

Verify UFW rules are in place with this command:

sudo iptables -S
sudo iptables --list

Your rules should appear somewhere in the sea of things that are going to be printed

Thanks for reading, leave feedback in the comments below, a friend (shoutout to Zombie if you are reading this) of mine gave me these rules and I thought I wrote a tutorial for the geeks out there.

Thank you, I'll test it as soon as my one of my friends is online and will post an update.