Adds an aditional option to XC_Engine.ini: bPatchUdpServerQueryThis option loads an additional package XC_IpServerFix that contains a an improved player listing function, plus a SecureValidate fix for unpatched servers.When the server has 1 or more players, the list will display all players, spectators and bots on the list.SecureValidate fix will deny any query string that isn't 6 characters long.

Step 1: Both U files provided by Higor should go into System including XC_IpServerFix.uStep 2: Add new Boolean value bPatchUdpServerQuery=True into XC_Engine.ini else it will be probably false if doesn't exist

For the case with files which I recompiledStep 1: Upload XC_IpServerFix.u file and new XC files.Step 2: Open and edit XC_Engine.ini file with value bPatchUdpServerQuery=True somewhere through the rest of values.

SC]-[WARTZ_{HoF} wrote:I think most game server admins before xcge have been using this patched IpServer.u...

A few minutes ago I've installed that thing (I had to switch machines because I dropped Athlon in water in bathroom...), I see that IpServer works fine as well, I mean reporting All Player possible. Function in cause seems to have the same purpose so it should be compatible. I did not check XServerQuery.

Another note:

Higor wrote:We'll use this topic to discuss and propose script patcher stuff, with occasinal test builds.

If I'm not disturbing, I might have something to ask to do if you can. I would like to see a few words logged in Editor during building process. So far if Editor has a problem with a brush will say

Actually is hard to figure where is that "sick" brush because it doesn't log any brush-name as it does with bad actors in run-time, or hint me with some "nice console command" for building map.A sample log I think should be:

sektor2111 wrote:Step 1: Both U files provided by Higor should go into System including XC_IpServerFix.uStep 2: Add new Boolean value bPatchUdpServerQuery=True into XC_Engine.ini else it will be probably false if doesn't exist

For the case with files which I recompiledStep 1: Upload XC_IpServerFix.u file and new XC files.Step 2: Open and edit XC_Engine.ini file with value bPatchUdpServerQuery=True somewhere through the rest of values.

Mention:I was using SecureValidate stuff for server.

Yup, The server has these files and entries yet still is not working. Thank you for confirming.

One of my Linux servers also fails to display players too, gonna have to download the IpServer.u package it uses and examine it.=======

Meanwhile, server created a 20mb logfile with spam coming from minigun2.RateSelf, so I decided to raplace and improve.Basically, larger creatures are more likely to get alt-fired and tiny creatures make the bots not want to use it.If ammo is below 50 the rating is linearly saled down.

These RateSelf could do a big deal at improving bot behaviour now that I think about it.

I did not see more such things last time, but for other weaponry. I reduced using altmode at once with AIRating when ammo is missing or ammo is low - we have some funky tick here anyway... Majority of these "RateSelf" doesn't have Ammo checker. I think pawn attempt to "rateself" but nothing says: hey, you are out of ammo, weapon won't work not even in AltMode is not only a low rating, it should never try to fire gun when ammo is none. Or simply pawn is attacking too early when weapon is not loaded yet "GiveAmmo bla bla" immediately after picking up the gun - like that PostRender junkie - ammocount is a null thing because doesn't exist yet - probably not in first tick and even more in Net games. At monster is probably the same problem until I added a small "Sleep" in state attacking letting stuff to initialize before to mock with pawn's combat code.Definitely for preventing A.I. in making troubles, a lot of stuff has to be reconsidered...

Nope...Read above posts. This is about server reporting Players and Bots loaded which can be seen by any player. If server has "nice stuff", then problems are not something unexpected.I've did a check to server set for public visibility with me connected and worked fine - as shown in pictures - using even MBot types. I cannot complain.

Due to these sudden rateself borks toward weaponry and A.I., once again I got a confirmation. When load code forces a load like for enforcer, weapon the mostly goes screwed and not giving ammo or getting late for this task. Pawn does a query which will fail. The better code is Skaarj Code - you can have even a default message on screen without calling other messages for a bad load idea.However, because Skaarj Code might fail in some cases (like I could figure with BioAmmo - falling by default), I did another small research in how to load pawns - and I got this operational without any RateSelf failure. I modified RandWeapon mutator which I did for XCGE environments and now I think I can breath relaxed. Snippet bellow:

I set Owner by default, I'm forcing the state for picking up this item, and before to call the "Touch" I made sure that is enabled (I guess it was not that enabled since item was ignored at random). Now it do works clean and healthy. Pawn loads ammo, then weapon and doesn't mess with switching, leaving pawn to finish RateSelf correctly. And they do seems to be more bad-ass warriors if RateSelf works properly, because sanity checkers won't help at a good rating in this tiny moment.

History:Before testing above code I went into "AddInventory" function for load. You don't wanna see what crap was spread in console and how many ammo have failed to get collected... because that code do seems to have another purpose than bunch-loading.