This topic is locked
can some1 help me?
This post has been edited by xxsuper: 22 August 2011 - 04:31 PM
Advertisement
Running bots in UT4
Rate Topic:
1 Votes
MultiQuote
#413
=(B@R)=Doe.TwainColts 
Posted 25 February 2012 - 04:14 PM
I have two mc: mapcycle1.txt and mapcycle2.txt
For bots:
ut4_abbey
ut4_algiers
ut4_sanc
w/o bots:
ut4_abbey
ut4_kingdom
{
g_nextmap ut4_algiers
}
ut4_algiers
ut4_casa
{
g_nextmap ut4_sanc
}
ut4_sanc
ut4_turnpike
{
g_nextmap ut4_abbey
}
When there is a low n. of players in (e.g.) kingdom,
a script set mapcycle1.txt as maplist for UrT
and forces a cyclemap and the game go on with algiers,
then bots are managed by another script
(you can see a table at http://saf.forumfree.it/?t=56435960 to see how this works)
Now the problem is something different,
I don't want add maps with bots support,
I would add any 3rd part maps in the 2nd mapcycle (for "humans only"),
but,
it's wellknown that 3rd part maps may cause crash to maps with bots support provided
in the basic UrT game (I mean sanc, abbey, algiers, uptown, ramelle, prague, mandolin, riyadh)
So, what should I check in a 3rd part map EVEN WITHOUT bots support
in order to put the map in q3ut4 folder and play it (even without bots)
in order to be sure that the map will not affect with crashes the three maps
working without problems?
Duplicate filenames, texture, sounds.... or wtf?
For bots:
ut4_abbey
ut4_algiers
ut4_sanc
w/o bots:
ut4_abbey
ut4_kingdom
{
g_nextmap ut4_algiers
}
ut4_algiers
ut4_casa
{
g_nextmap ut4_sanc
}
ut4_sanc
ut4_turnpike
{
g_nextmap ut4_abbey
}
When there is a low n. of players in (e.g.) kingdom,
a script set mapcycle1.txt as maplist for UrT
and forces a cyclemap and the game go on with algiers,
then bots are managed by another script
(you can see a table at http://saf.forumfree.it/?t=56435960 to see how this works)
Now the problem is something different,
I don't want add maps with bots support,
I would add any 3rd part maps in the 2nd mapcycle (for "humans only"),
but,
it's wellknown that 3rd part maps may cause crash to maps with bots support provided
in the basic UrT game (I mean sanc, abbey, algiers, uptown, ramelle, prague, mandolin, riyadh)
So, what should I check in a 3rd part map EVEN WITHOUT bots support
in order to put the map in q3ut4 folder and play it (even without bots)
in order to be sure that the map will not affect with crashes the three maps
working without problems?
Duplicate filenames, texture, sounds.... or wtf?
#414
|P|Nitro
QA member
Posted 25 February 2012 - 06:05 PM
i think the just the very existance of the maps in the folder are enough because server has to load all maps first, so you cant even just transfer the file in and out of the folder when needed either or symlinks, so as far as I know, bots and third party maps can't co-exist without problems.
Lian Li pc-o11dw Der 8auer Edition · Gigabyte x570 Aorus Xtreme · AMD Ryzen 9 5950x 16-Core
32GB DDR4 3800MHz CL16 · 2x 1TB Samsung NVMe RAID 0 · 16GB Radeon RX 6900XT Liquid Cooled
32GB DDR4 3800MHz CL16 · 2x 1TB Samsung NVMe RAID 0 · 16GB Radeon RX 6900XT Liquid Cooled
#415
Runamuk
Posted 26 February 2012 - 01:22 PM
There a few 3rd party maps that work with bots and there are a few that will crash the server just being in the folder. I know that ut4_village and ut4_streets are two maps that will crash the server in bot mode just being installed. You just have to play with the maps and find out which ones work. Chronic is an old map that works well with bots.
Advertisement
#416
=(B@R)=Doe.TwainColts
Posted 27 February 2012 - 11:16 AM
Runamuk, on 26 February 2012 - 01:22 PM, said:
There a few 3rd party maps that work with bots and there are a few that will crash the server just being in the folder. I know that ut4_village and ut4_streets are two maps that will crash the server in bot mode just being installed. You just have to play with the maps and find out which ones work. Chronic is an old map that works well with bots.
I know; the same for ut4_winterassault_2
declared with bot support but crashing even alone in q3ut4 (UrT 4.1 - win32 server).
Even so, 3rd part maps without bot support could be valid for me
if I could understand which ones don't cause crash
to the UrT maps sanc algiers abbey working fine with bots.
But seems impossible... okay eh....
Technology
#417
Rambetter
community dev
Posted 27 February 2012 - 07:03 PM
Hi there, I have a solution for the problem you're having (3rd party maps crashing server when bots are on "working" maps such as Algiers).
I have a special patch written that makes 3rd party maps "invisible" on the server unless you're currently on that map.
To get my patch, you need to use the ioquake3-UrT-server-4.1 branch described in Appendix B on this page: http://daffy.nerius.com/urtserver/ . You can use the instructions on that entire page but apply them to the branch ioquake3-UrT-server-4.1. The patch in particular is called loadonlyneededpaks.patch. You need to apply that patch by hand to the code (procedure also described on that webpage). Then you must set sv_loadOnlyNeededPaks to 1. From the README:
I have a special patch written that makes 3rd party maps "invisible" on the server unless you're currently on that map.
To get my patch, you need to use the ioquake3-UrT-server-4.1 branch described in Appendix B on this page: http://daffy.nerius.com/urtserver/ . You can use the instructions on that entire page but apply them to the branch ioquake3-UrT-server-4.1. The patch in particular is called loadonlyneededpaks.patch. You need to apply that patch by hand to the code (procedure also described on that webpage). Then you must set sv_loadOnlyNeededPaks to 1. From the README:
Quote
========================
loadonlyneededpaks.patch
========================
Introduces some nice features related to map loading.
First, map names are auto-corrected with respect to capitalization. This is
especially useful on third party map servers where map voting is enabled.
Let's say there exists a map pak file called ut4_icyjumps.pk3 containing
maps/ut4_icyjumps.bsp. Someone calls a vote by typing
"/callvote map Ut4_IcyJumps" in the console. The vote passes. The old
behavior was that the map maps/Ut4_IcyJumps.bsp would be loaded (it worked)
and then clients that didn't have the map would attempt to download the file
Ut4_IcyJumps.pk3, which is spelled incorrectly and can't be downloaded. So
anyone not having the map would be shut out from the server. The new
functionality added with this patch is that the names of maps are
auto-corrected with respect to capitalization in a very intelligent way.
Also, "/callvote nextmap ut4_mapname" votes are fixed such that g_NextMap
isn't set unless ut4_mapname is a valid map, and the value that is assigned
to g_NextMap has its capitalization fixed. Note however that direct admin
calls (such as console commands or rcon) that modify g_NextMap do not
undergo this check and correction.
Second, minor improvements in the error reporting when a map cannot be
loaded. There were some cases where an "/rcon map xxxx" in the console
would have loaded a map when it shouldn't have, in particular when the
bsp was not in a pk3 and the server was on sv_pure 1. The logic for
correcting map loading and error reporting also applies to maps being
loaded via mapcycle.txt, g_NextMap, and voting (map, nextmap, and cyclemap).
Third, a minor change related to file search path. With vanilla ioq3ded-UrT,
the base game and base mod directories in fs_homepath are added to the search
path. With this patch, the only fs_homepath directory added to the search
path is the one for the top-level mod, in this case q3ut4. This top-level
fs_homepath directory is the "third party map directory" and will be
discussed below. On UNIX systems, this directory is usually ~/.q3a/q3ut4/.
On all systems it is the directory where q3config*.cfg is saved. fs_homepath
can be overridden by using "+set fs_homepath xxxx" on the command that
launches ioq3ded-UrT. For purposes of the discussion below, the term
"third party map" shall mean any pk3 file in the third party map directory
whose name does not begin with a 'z' or a 'Z'.
Fourth, introduces a new server cvar sv_loadOnlyNeededPaks. When this is
set to a nonzero positive value, the server will only reference a single
third party map: the one that is being loaded. All other third party maps
won't be loaded. This has three big side effects on clients:
- The third party map will be running in a "sandbox" and won't be affected
by resources such as textures and shaders from any other third party maps.
The behavior will be as if though the third party map currently loaded is
the only third party map installed on the server. Some nasty issues such
as missing or incorrect textures might be thus avoided; such issues are
caused by incorrectly made maps. One incorrectly made map can affect
another correctly made map, unfortunately.
- The complete list of third party maps on the server won't show up in the
client's callvote menu. The client will have to manually type
"/callvote map xxxx" to request a third party map.
- A long list of loaded third party maps won't overflow a buffer on the
client, so the client won't get the infamous
"CL_ParseGamestate: bad command byte" error when connecting to the server.
sv_loadOnlyNeededPaks should therefore be set to 1 on jump servers that have
many and/or poorly made maps. By default, sv_loadOnlyNeededPaks is set to 0,
which causes all paks to be loaded. Note that this (meaning loading all pak
files) is the way ioquake3 was meant to work, but Urban Terror decided to
make things work slightly differently by assuming that everything needed to
load a third party map is in a single file <mapname>.pk3.
if you are putting pk3 files into your third party map directory that need
to be loaded on every map (for example containing bot definitions or shader
fixes for base maps), you should make sure that the pk3 files start with the
letter 'z' so that they are always loaded.
loadonlyneededpaks.patch
========================
Introduces some nice features related to map loading.
First, map names are auto-corrected with respect to capitalization. This is
especially useful on third party map servers where map voting is enabled.
Let's say there exists a map pak file called ut4_icyjumps.pk3 containing
maps/ut4_icyjumps.bsp. Someone calls a vote by typing
"/callvote map Ut4_IcyJumps" in the console. The vote passes. The old
behavior was that the map maps/Ut4_IcyJumps.bsp would be loaded (it worked)
and then clients that didn't have the map would attempt to download the file
Ut4_IcyJumps.pk3, which is spelled incorrectly and can't be downloaded. So
anyone not having the map would be shut out from the server. The new
functionality added with this patch is that the names of maps are
auto-corrected with respect to capitalization in a very intelligent way.
Also, "/callvote nextmap ut4_mapname" votes are fixed such that g_NextMap
isn't set unless ut4_mapname is a valid map, and the value that is assigned
to g_NextMap has its capitalization fixed. Note however that direct admin
calls (such as console commands or rcon) that modify g_NextMap do not
undergo this check and correction.
Second, minor improvements in the error reporting when a map cannot be
loaded. There were some cases where an "/rcon map xxxx" in the console
would have loaded a map when it shouldn't have, in particular when the
bsp was not in a pk3 and the server was on sv_pure 1. The logic for
correcting map loading and error reporting also applies to maps being
loaded via mapcycle.txt, g_NextMap, and voting (map, nextmap, and cyclemap).
Third, a minor change related to file search path. With vanilla ioq3ded-UrT,
the base game and base mod directories in fs_homepath are added to the search
path. With this patch, the only fs_homepath directory added to the search
path is the one for the top-level mod, in this case q3ut4. This top-level
fs_homepath directory is the "third party map directory" and will be
discussed below. On UNIX systems, this directory is usually ~/.q3a/q3ut4/.
On all systems it is the directory where q3config*.cfg is saved. fs_homepath
can be overridden by using "+set fs_homepath xxxx" on the command that
launches ioq3ded-UrT. For purposes of the discussion below, the term
"third party map" shall mean any pk3 file in the third party map directory
whose name does not begin with a 'z' or a 'Z'.
Fourth, introduces a new server cvar sv_loadOnlyNeededPaks. When this is
set to a nonzero positive value, the server will only reference a single
third party map: the one that is being loaded. All other third party maps
won't be loaded. This has three big side effects on clients:
- The third party map will be running in a "sandbox" and won't be affected
by resources such as textures and shaders from any other third party maps.
The behavior will be as if though the third party map currently loaded is
the only third party map installed on the server. Some nasty issues such
as missing or incorrect textures might be thus avoided; such issues are
caused by incorrectly made maps. One incorrectly made map can affect
another correctly made map, unfortunately.
- The complete list of third party maps on the server won't show up in the
client's callvote menu. The client will have to manually type
"/callvote map xxxx" to request a third party map.
- A long list of loaded third party maps won't overflow a buffer on the
client, so the client won't get the infamous
"CL_ParseGamestate: bad command byte" error when connecting to the server.
sv_loadOnlyNeededPaks should therefore be set to 1 on jump servers that have
many and/or poorly made maps. By default, sv_loadOnlyNeededPaks is set to 0,
which causes all paks to be loaded. Note that this (meaning loading all pak
files) is the way ioquake3 was meant to work, but Urban Terror decided to
make things work slightly differently by assuming that everything needed to
load a third party map is in a single file <mapname>.pk3.
if you are putting pk3 files into your third party map directory that need
to be loaded on every map (for example containing bot definitions or shader
fixes for base maps), you should make sure that the pk3 files start with the
letter 'z' so that they are always loaded.
This post has been edited by Rambetter: 27 February 2012 - 07:18 PM
#418
=(B@R)=Doe.TwainColts
Posted 27 February 2012 - 09:08 PM
Rambetter, on 27 February 2012 - 07:03 PM, said:
Hi there, I have a solution
First, thanks for all your job rambetter.
I will give a try, and check if I can upload the binary or the binary on the
server is locked by permission or link, in case a will ask.
I've read http://daffy.nerius.com/urtserver/ but I'm wondering how to generate a win32.exe
Sorry to be so apt-noob
PS: have a look to this please: http://www.urbanterr...-some-requests/
Update: about win32.exe, ok, I suppose MinGW or MSVC as described in github.
This post has been edited by doetwaincolts: 28 February 2012 - 01:33 PM
#419
beber888
Posted 04 June 2012 - 08:53 AM
Thanks mister Rambetter. It was 2 years that my serveur run only on official maps because of bot crashing.
Since 2 days whe can play on custom maps (without bots).
Your patch is fantastic...
But I had to modify B3 because in the command !map, B3 send a question to the server to know all the map of the server. (And custom map aren't). Now !map works with a texte file to have the real list of maps...
Thanks to you, good job.
Since 2 days whe can play on custom maps (without bots).
Your patch is fantastic...
But I had to modify B3 because in the command !map, B3 send a question to the server to know all the map of the server. (And custom map aren't). Now !map works with a texte file to have the real list of maps...
Thanks to you, good job.
#420
Rambetter
Posted 02 October 2012 - 11:44 PM
beber, yes there are some problem with the patch as you can see.
E.g. the in-game menu won't list 3rd party maps anymore.
This is just a tradeoff, you fix some things and others are broke.
But I like your method of a text file and hardcoded list of maps for B3.
Unfortunately the nature of the path is the I CANNOT report the full list of maps in the map command, thet's the exact nature of the fix for the patch.
E.g. the in-game menu won't list 3rd party maps anymore.
This is just a tradeoff, you fix some things and others are broke.
But I like your method of a text file and hardcoded list of maps for B3.
Unfortunately the nature of the path is the I CANNOT report the full list of maps in the map command, thet's the exact nature of the fix for the patch.
1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users
Advertisement