◄► Unreal Tournament v469b Patch Release ◄►

General Announcements about Unreal Tournament and UT99.org
User avatar
Feralidragon
Godlike
Posts: 5300
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Feralidragon » Wed Mar 17, 2021 6:03 pm

Gustavo6046 wrote:
Wed Mar 17, 2021 4:30 pm
OpenGLDrv.so's UOpenGLRenderDevice::DrawComplexSurface(FSceneNode*, FSurfaceInfo&, FSurfaceFacet&) seems to segfault with the Intel driver (i915), which it didn't before; I suspect it's a configuration issue, but I simply set ShaderType to SHADER_ARB, then I set it back to SHADER_None and it still didn't fix it!

It does work with the Nouveau backend (switched by setting the environment vairable DRI_PRIME=1 prior to starting the game), but I'd rather it run on the iGPU. It was working so well before... :<

Code: Select all

Developer Backtrace:
[ 1]  Core.so(_Z12HandleSignali+0x20b) [0xf79746cb]
[ 2]  linux-gate.so.1(__kernel_sigreturn+0) [0xf7f3f560]
[ 3]  /usr/lib32/dri/i965_dri.so(+0x366d74) [0xf5815d74]
[ 4]  /usr/lib32/dri/i965_dri.so(+0xabac7) [0xf555aac7]
[ 5]  /usr/lib32/dri/i965_dri.so(+0x237fa2) [0xf56e6fa2]
[ 6]  OpenGLDrv.so(_ZN19UOpenGLRenderDevice18DrawComplexSurfaceEP10FSceneNodeR12FSurfaceInfoR13FSurfaceFacet+0xb09) [0xdfef7b39]
[ 7]  Render.so(_ZN7URender9DrawFrameEP10FSceneNode+0x132a) [0xe15c401a]
[ 8]  Render.so(_ZN7URender9DrawWorldEP10FSceneNode+0x351) [0xe15c6161]
[ 9]  Engine.so(_ZN11UGameEngine4DrawEP9UViewportiPhPi+0x972) [0xf7c6de72]
[10]  SDLDrv.so(_ZN12USDLViewport7RepaintEi+0x93) [0xf2dd3c83]
[11]  SDLDrv.so(_ZN10USDLClient4TickEv+0x1a6) [0xf2dccf06]
[12]  Engine.so(_ZN11UGameEngine4TickEf+0x19a6) [0xf7c72466]
[13]  XC_Engine.so(_ZN14UXC_GameEngine4TickEf+0xa2) [0xf17bbfc2]
[14]  ./ut-bin(main+0x1018) [0x804eb08]
[15]  /usr/lib32/libc.so.6(__libc_start_main+0xed) [0xf72f1a0d]
[16]  ./ut-bin() [0x804d84f]
Signal: SIGSEGV [segmentation fault]
Aborting.

Signal: SIGSEGV [segmentation fault]

History: UOpenGLRenderDevice::DrawComplexSurface <- URender::DrawFrame <- URender::DrawWorld <- UGameEngine::Draw <- USDLViewport::Repaint <- USDLClient::Tick <- ClientTick <- UGameEngine::Tick <- UXC_GameEngine::Tick <- UpdateWorld <- MainLoopIteration <- MainLoop <- main
note: I don't know the source code, I just demangled the C++ symbol "_ZN19UOpenGLRenderDevice18DrawComplexSurfaceEP10FSceneNodeR12FSurfaceInfoR13FSurfaceFacet".
There was a confirmed problem concerning one of the renderers using Shader 2.0 in 469b, and integrated GPUs not really supporting it.
But I think that was already fixed in the latest snapshot, but I am not entirely sure (feel free to report that in github, or the OldUnreal discord).

1337GameDev wrote:
Wed Mar 17, 2021 3:56 pm
I'm curious, why were triangles not batched before? Was that simply not supported by earlier cards and cards relevant to the game during it's life?
This is something that can be better clarified perhaps by Anth himself.

But my own take at it, is the fact that the main renderer is SoftDrv, in other words, a software renderer that is capable of only working using the CPU (no GPU involved at all).
And it works this way as well (batching polys in SoftDrv won't really give you much gain).

And at the time OpenGL was still in its infancy, and although included it never really worked well, and they only had pretty much D3D7 as one of the main and tested hardware renderers, and graphic cards weren't really a thing yet back then, like they are nowadays.
So it seems to me that they simply replicated what they had done in SoftDrv to the hardware renderers, and it just worked fairly well over time, and it was easy to implement.

So there was no big reason at the time to really batch anything, there were no particular noticeable gains as far as I know doing that back then, especially in a game with such a small amount of polys being rendered overall.
I mean, even working like this, it was still one of the best and fastest engines around at the time.

However, as the years passed, GPUs became much more powerful and also much more autonomous (being even able to store everything in their own memory, and to the point they have their own programmable instructions: shaders).
All of a sudden, even the bus speed of AGP wasn't fast enough and adequate anymore and PCI Express had to created.
So it wasn't until much later on that this type of bottleneck was actually noticeable, especially when mods and maps started to have higher poly meshes and models.

Even nowadays you won't really notice the difference in performance if all you play is the vanilla game.
You will only notice a difference if you use mods that actually take advantage of this, like NW3 itself.

Having that said, one thing I need to clarify: at the moment, this batching is only applied to mesh polys, not BSP surfaces.
BSP surfaces are pretty much still rendered as before, also 1 at a time.

Trying to batch those seems to be more difficult, to the point it was already considered as a possible alternative to simply batch render the entire map, disregarding the BSP nodes completely, since in any GPU from the last 10 years that will likely be much faster than render each one of them at a time.

That's why maps like CTF-Blice (a map I released, meant as one of the benchmarks for 469 in the end) still lag a lot despite this improvement (not the only reason, but one of the reasons).

The ideal end goal is to pass pretty much everything that is currently involving the CPU in some way (rendering-wise) to the GPU.
But for that the rendering pipeline of the engine itself will require a significant rewrite, which will also lead to rewrites of the renderers themselves, which won't really be feasible unless we get rid of some of the renderers (like SoftDrv itself, which is nightmare fuel).

If we ever reach that point, then every single map and mod released to this date will be pretty much lag-free as far as rendering goes, with no FPS loss whatsoever in any reasonably modern system (anything from the last 5-10 years).
Even volumetric fog, one of the slowest engine features, could finally be fast and usable.

But for that the community has to help a bit, like letting go of SoftDrv completely, otherwise it will always be impossible.

1337GameDev
Experienced
Posts: 88
Joined: Thu Apr 16, 2020 3:23 pm
Personal rank: GameDev

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by 1337GameDev » Wed Mar 17, 2021 6:17 pm

Feralidragon wrote:
Wed Mar 17, 2021 6:03 pm
Gustavo6046 wrote:
Wed Mar 17, 2021 4:30 pm
OpenGLDrv.so's UOpenGLRenderDevice::DrawComplexSurface(FSceneNode*, FSurfaceInfo&, FSurfaceFacet&) seems to segfault with the Intel driver (i915), which it didn't before; I suspect it's a configuration issue, but I simply set ShaderType to SHADER_ARB, then I set it back to SHADER_None and it still didn't fix it!

It does work with the Nouveau backend (switched by setting the environment vairable DRI_PRIME=1 prior to starting the game), but I'd rather it run on the iGPU. It was working so well before... :<

Code: Select all

Developer Backtrace:
[ 1]  Core.so(_Z12HandleSignali+0x20b) [0xf79746cb]
[ 2]  linux-gate.so.1(__kernel_sigreturn+0) [0xf7f3f560]
[ 3]  /usr/lib32/dri/i965_dri.so(+0x366d74) [0xf5815d74]
[ 4]  /usr/lib32/dri/i965_dri.so(+0xabac7) [0xf555aac7]
[ 5]  /usr/lib32/dri/i965_dri.so(+0x237fa2) [0xf56e6fa2]
[ 6]  OpenGLDrv.so(_ZN19UOpenGLRenderDevice18DrawComplexSurfaceEP10FSceneNodeR12FSurfaceInfoR13FSurfaceFacet+0xb09) [0xdfef7b39]
[ 7]  Render.so(_ZN7URender9DrawFrameEP10FSceneNode+0x132a) [0xe15c401a]
[ 8]  Render.so(_ZN7URender9DrawWorldEP10FSceneNode+0x351) [0xe15c6161]
[ 9]  Engine.so(_ZN11UGameEngine4DrawEP9UViewportiPhPi+0x972) [0xf7c6de72]
[10]  SDLDrv.so(_ZN12USDLViewport7RepaintEi+0x93) [0xf2dd3c83]
[11]  SDLDrv.so(_ZN10USDLClient4TickEv+0x1a6) [0xf2dccf06]
[12]  Engine.so(_ZN11UGameEngine4TickEf+0x19a6) [0xf7c72466]
[13]  XC_Engine.so(_ZN14UXC_GameEngine4TickEf+0xa2) [0xf17bbfc2]
[14]  ./ut-bin(main+0x1018) [0x804eb08]
[15]  /usr/lib32/libc.so.6(__libc_start_main+0xed) [0xf72f1a0d]
[16]  ./ut-bin() [0x804d84f]
Signal: SIGSEGV [segmentation fault]
Aborting.

Signal: SIGSEGV [segmentation fault]

History: UOpenGLRenderDevice::DrawComplexSurface <- URender::DrawFrame <- URender::DrawWorld <- UGameEngine::Draw <- USDLViewport::Repaint <- USDLClient::Tick <- ClientTick <- UGameEngine::Tick <- UXC_GameEngine::Tick <- UpdateWorld <- MainLoopIteration <- MainLoop <- main
note: I don't know the source code, I just demangled the C++ symbol "_ZN19UOpenGLRenderDevice18DrawComplexSurfaceEP10FSceneNodeR12FSurfaceInfoR13FSurfaceFacet".
There was a confirmed problem concerning one of the renderers using Shader 2.0 in 469b, and integrated GPUs not really supporting it.
But I think that was already fixed in the latest snapshot, but I am not entirely sure (feel free to report that in github, or the OldUnreal discord).

1337GameDev wrote:
Wed Mar 17, 2021 3:56 pm
I'm curious, why were triangles not batched before? Was that simply not supported by earlier cards and cards relevant to the game during it's life?
This is something that can be better clarified perhaps by Anth himself.

But my own take at it, is the fact that the main renderer is SoftDrv, in other words, a software renderer that is capable of only working using the CPU (no GPU involved at all).
And it works this way as well (batching polys in SoftDrv won't really give you much gain).

And at the time OpenGL was still in its infancy, and although included it never really worked well, and they only had pretty much D3D7 as one of the main and tested hardware renderers, and graphic cards weren't really a thing yet back then, like they are nowadays.
So it seems to me that they simply replicated what they had done in SoftDrv to the hardware renderers, and it just worked fairly well over time, and it was easy to implement.

So there was no big reason at the time to really batch anything, there were no particular noticeable gains as far as I know doing that back then, especially in a game with such a small amount of polys being rendered overall.
I mean, even working like this, it was still one of the best and fastest engines around at the time.

However, as the years passed, GPUs became much more powerful and also much more autonomous (being even able to store everything in their own memory, and to the point they have their own programmable instructions: shaders).
All of a sudden, even the bus speed of AGP wasn't fast enough and adequate anymore and PCI Express had to created.
So it wasn't until much later on that this type of bottleneck was actually noticeable, especially when mods and maps started to have higher poly meshes and models.

Even nowadays you won't really notice the difference in performance if all you play is the vanilla game.
You will only notice a difference if you use mods that actually take advantage of this, like NW3 itself.

Having that said, one thing I need to clarify: at the moment, this batching is only applied to mesh polys, not BSP surfaces.
BSP surfaces are pretty much still rendered as before, also 1 at a time.

Trying to batch those seems to be more difficult, to the point it was already considered as a possible alternative to simply batch render the entire map, disregarding the BSP nodes completely, since in any GPU from the last 10 years that will likely be much faster than render each one of them at a time.

That's why maps like CTF-Blice (a map I released, meant as one of the benchmarks for 469 in the end) still lag a lot despite this improvement (not the only reason, but one of the reasons).

The ideal end goal is to pass pretty much everything that is currently involving the CPU in some way (rendering-wise) to the GPU.
But for that the rendering pipeline of the engine itself will require a significant rewrite, which will also lead to rewrites of the renderers themselves, which won't really be feasible unless we get rid of some of the renderers (like SoftDrv itself, which is nightmare fuel).

If we ever reach that point, then every single map and mod released to this date will be pretty much lag-free as far as rendering goes, with no FPS loss whatsoever in any reasonably modern system (anything from the last 5-10 years).
Even volumetric fog, one of the slowest engine features, could finally be fast and usable.

But for that the community has to help a bit, like letting go of SoftDrv completely, otherwise it will always be impossible.
Awesome explanation.

I appreciate the in depth reply.

I'm curious, is there code of SoftDrv somewhere I can look at? I'd love to see some of the routines.

Also, would it be possible to include some new functions natively for future mod/map use (and for backwards compatibility, just use a naive implementation in UC) as to make things faster? Figured there might be some good candidates you've stumbled upon.

Is there a testing plan or document of scenarios to test? If so, I wouldn't mind helping with that and going enough random tests to help further this.

Also... One more thing...

Can you possibly add some changes to UCC compilation that would make coding lives easier? (Such as predefined/dev picked order order of compilation -- such as a keyword/default property, class namespaces -- other game engines just threw older code into a standard namespace for backwards compatibility when they add this, and a way to see quick stack traces -- provided debug data is provided?).

Would be very helpful for development :/ getting a random memory address from an accessed none and only the filename SUCKS.

User avatar
Feralidragon
Godlike
Posts: 5300
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Feralidragon » Wed Mar 17, 2021 6:49 pm

No, SoftDrv is closed source, as part of UE1 itself.
Whereas the other renderers, namely UTGLR OpenGL and D3D9 are open-source for 436, and the updated ones for 469 will also be eventually open-sourced, once Anth is able to assemble the set of libs and settings for anyone to be able to compile them on their own (something close to an SDK).

As far as native functions go, I believe many have been included already, and some modified, hence native packages breaking from one version to another at the moment.
But the public headers and such for those will be released somewhere in the future, also when Anth releases all of this stuff as an SDK.

He intends to include a lot of stuff, not only renderers and public headers (pretty much everything he's allowed to release), but it's all pending on time and some other stuff.

As for UCC, and UnrealScript overall, there are already some things that are kinda planned, or pre-planned, to eventually be added, like ternaries for example.
But of course, nothing is guaranteed as of now, since UnrealScript syntax and debugging features are not really a focus right now.

Right now the priority boils down to:
  1. Optimizations and fixes;
  2. Unreal Editor;
  3. Everything else.
Having better ways to debug the code was something already briefly discussed (a long time ago), but it's also one of those things for when UScript and UCC get their turn to get focused on.

If you want to participate, and have better answers to your questions, I advise you to go to the OldUnreal discord, since it's the "official" discord for everything concerning 469 development (and Unreal 227 as well), and there you can do your questions and the devs will likely answer you:
https://discord.gg/ZjuRmfpC

To clarify: I am not a patch dev myself, I am mostly an "external contributor" or "representative" in a way, and I have access to most of what is going on related with the development, including internal discussions and such, but I have no access to the actual code though, nor am I developing anything for the patch (at the moment at least), so my knowledge is fairly limited on many of those fronts.

User avatar
Gustavo6046
Godlike
Posts: 1160
Joined: Mon Jun 01, 2015 7:08 pm
Personal rank: Zeta Group leader

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Gustavo6046 » Wed Mar 17, 2021 7:15 pm

Are you still only going to provide Visual Studio files? :/

User avatar
Feralidragon
Godlike
Posts: 5300
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Feralidragon » Wed Mar 17, 2021 11:22 pm

No idea.

Ideally, once released, the native SDK should come in different flavors: VS files and make files (Linux/Mac) with the raw headers/resources.
But that's something you can ask to Anth.

Buggie
Adept
Posts: 433
Joined: Sat Mar 21, 2020 5:32 am

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Buggie » Thu Mar 18, 2021 12:04 am

Only CMakeLists.txt, only Hardcore.

User avatar
papercoffee
Godlike
Posts: 9837
Joined: Wed Jul 15, 2009 11:36 am
Personal rank: coffee addicted !!!
Location: Cologne, the city with the big cathedral.

Re: ◄► Unreal Tournament v469a Patch Release ◄►

Post by papercoffee » Thu Mar 18, 2021 1:03 am

1337GameDev wrote:
Wed Mar 17, 2021 1:37 pm
...
Please refrain from double posting within a 24 hours limit ...you can edit your post to answer different people.

User avatar
Gustavo6046
Godlike
Posts: 1160
Joined: Mon Jun 01, 2015 7:08 pm
Personal rank: Zeta Group leader

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Gustavo6046 » Thu Mar 18, 2021 1:30 am

Feralidragon wrote:
Wed Mar 17, 2021 11:22 pm
Ideally, once released, the native SDK should come in different flavors: VS files and make files (Linux/Mac) with the raw headers/resources.
But that's something you can ask to Anth.
GNU Makefiles are not very portable and offer very little room for build configuration by themselves. They are also a pain to write, even with Autotools, which honestly just make writing even harder in exchange for configuration flexibility.

Nowadays those are things of the past. People were already fed of them back when Visual Studio on Windows became a big thing (versus the Watcom or Borland of the DOS days). Luckily, they have naturally been superseded; now you'd expect modern C/C++ projects to use CMake and, more recently, perhaps Meson. Both work on both Linux, WIndows and I believe also Mac, which I am sure would cut on the hassle of porting build configurations to different platforms.
Buggie wrote:
Thu Mar 18, 2021 12:04 am
Only CMakeLists.txt, only Hardcore.
noice :rock: :rock: :rock: :rock: :rock: :rock:

EDIT--
Feralidragon wrote:
Wed Mar 17, 2021 6:03 pm
There was a confirmed problem concerning one of the renderers using Shader 2.0 in 469b, and integrated GPUs not really supporting it.
But I think that was already fixed in the latest snapshot, but I am not entirely sure (feel free to report that in github, or the OldUnreal discord).
CC @Anthrax.

I opened the game again, and suddenly it was working fine in OpenGLDrv. Then I was making a comparison between XOpenGLDrv and OpenGLDrv, so when i set it to XOpenGLDrv, it worked (albeit slower in the OpenGL 3.0+ shader pipeline, because Intel Sandy-Bridge-generation iGPU). Then when I set it back to OpenGLDrv, the errors were occurring again! Very odd.

Between the time OpenGLDrv worked and the last time when it didn't, I had a full reboot. This time, I tried only restarting the display manager, but that didn't do the cut. I don't feel like rebooting right now, though, so we'll see if it is an issue configuration-wise or if it's really some wierd GPU driver segfaulty quirky thing.

User avatar
OjitroC
Godlike
Posts: 2342
Joined: Sat Sep 12, 2015 8:46 pm

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by OjitroC » Thu Mar 18, 2021 12:40 pm

It is possible to 'make' things in 469b Editor that will work fine in 469b but will freeze/crash 436/451 - specifically sounds.

I 'made' a scriptedpawn by subclassing SBHumaneFixesV0SBHumaneFixesV0; swapping the mesh for the ZombieCowboy mesh and importing some sounds. The sounds were (obviously) in wav format - some PCM u8 (u8) codec (sample rate 11025, 8 bits) and others PCM S16 LE (s16) codec (sample rate 22050Hz, 16 bits).

The pawn works fine in 469b with MonsterSpawn - however trying it in MonsterSpawn in both 451 and 436 resulted in the game freezing. After some lenghty effing about, I managed to narrow down the freeze to this pawn and to the specific sounds - the 436 Editor froze on trying to play the sounds. I coverted the PCM u8 sounds, with the result that it now works in all versions of the game.

So just a cautionary note - 469b can handle some sounds that the other versions can't - which is obvious I suppose but worth noting.

Buggie
Adept
Posts: 433
Joined: Sat Mar 21, 2020 5:32 am

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Buggie » Thu Mar 18, 2021 2:10 pm

About issues need write to github. Nobody notice it here. Never be fixed.

Anth not read this topic so CC him is like scream to the void.

Higor
Godlike
Posts: 1832
Joined: Sun Mar 04, 2012 6:47 pm

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Higor » Thu Mar 18, 2021 4:48 pm

@Gustavo6046
Your system is crashing at a glMultiDrawArraysEXT call, the problem with that is that potentially any of the active OpenGL states can be the cause.
Basically you're running a buggy Mesa driver on a very early Intel IGP that's crashing during a draw operation.
ImageImage
Image unreal://23.111.157.138:7777
Image unreal://46.228.199.205:7788

User avatar
Gustavo6046
Godlike
Posts: 1160
Joined: Mon Jun 01, 2015 7:08 pm
Personal rank: Zeta Group leader

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Gustavo6046 » Thu Mar 18, 2021 4:55 pm

@Higor
It is indeed a very early Intel iGPU, a Sandy Bridge one. But it generally works more than well enough for OpenGL up to 3.0. I haven't seen this issue occur in any other game.

I do remember setting the 'use draw arrays', or something, option to True in v436, and that causing issues, so I'd set it to False. I hope you didn't hardcode it in v469b!

EDIT:

This is already set.

Code: Select all

UseMultiDrawArrays=False

gargul2
Average
Posts: 30
Joined: Wed Sep 30, 2020 9:16 am

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by gargul2 » Fri Mar 19, 2021 2:47 pm

Raynor wrote:
Mon Mar 15, 2021 12:21 am
469b Cluster audio balance still feels off compared to Galaxy.
For example ammo pickup, weapon switching and dodge grunt sounds are considerably quieter compared to weapon firing, powerup pickup or elevator sounds.
It is unfortunate there is no option to use Galaxy until such issues are resolved.
There is already a thread on the github bug tracker, with such audio issues: https://github.com/OldUnreal/UnrealTour ... issues/115
So I've posted your issue: https://github.com/OldUnreal/UnrealTour ... -802832974
Alcoholodeck16 wrote:
Tue Mar 16, 2021 5:38 pm
I still have performance issues with XOpenGL. I still get brutal FPS Drops on Win 10, RX 480 and Intel i5 4460. Maybe i should go back to utglr. I wonder if this is actually an AMD issue. OpenGL performance doesn't seem as good as it used to be.
There is already a thread on the github bug tracker, with such performance issues: https://github.com/OldUnreal/UnrealTour ... issues/114
So I've posted your issue: https://github.com/OldUnreal/UnrealTour ... -802839572

User avatar
OjitroC
Godlike
Posts: 2342
Joined: Sat Sep 12, 2015 8:46 pm

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by OjitroC » Fri Mar 19, 2021 3:05 pm

gargul2 wrote:
Fri Mar 19, 2021 2:47 pm
Alcoholodeck16 wrote:
Tue Mar 16, 2021 5:38 pm
I still have performance issues with XOpenGL. I still get brutal FPS Drops on Win 10, RX 480 and Intel i5 4460. Maybe i should go back to utglr. I wonder if this is actually an AMD issue. OpenGL performance doesn't seem as good as it used to be.
There is already a thread on the github bug tracker, with such performance issues: https://github.com/OldUnreal/UnrealTour ... issues/114
So I've posted your issue: https://github.com/OldUnreal/UnrealTour ... -802839572
That issue looks like it's been closed - I presume the devs don't revisit closed issues.

User avatar
Barbie
Godlike
Posts: 2082
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: ◄► Unreal Tournament v469b Patch Release ◄►

Post by Barbie » Sat Mar 20, 2021 10:12 am

I'm afraid that extracting a tar archive to upgrade is not enough:
ut99@ubuntu-x32:~/ut-server/System$ find -iname botpack* -exec ls -l "{}" ";"
-rw-rw-r-- 1 ut99 ut99 116117 Mär 7 17:52 ./Botpack.int
-r--r--r-- 1 ut99 ut99 39016791 Okt 16 2000 ./BotPack.u
-r--r--r-- 1 ut99 ut99 6721 Aug 1 2000 ./BotPack.int
-rw-rw-r-- 1 ut99 ut99 40114923 Mär 7 17:52 ./Botpack.u
Old version of "Botpack" remains and I ask myself what happens if a map has references to "Botpack" and another map to "BotPack"...

What about a little script that checks for such duplicates?
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett