XC_Engine megathread

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

Re: XC_Engine megathread

Post by Higor »

UT binaries changed too much for the same XC_Engine codebase to work in all versions.
Also, from the very beginning the aim was to make sure there was absolutely no reason to roll back versions due to something being wrong with the patch.
(Personally I've already stopped playing on v436 for a month already)

In the meantime, already managed to generate a global travel list that unlike the player's travel list, it propagates to any travel actor being referenced.
All you need to do is set bTravel=True and Tag=Travel and anything related to said actor will be added to the list.

This is an example of the internal data:

Code: Select all

Class=CacusCoop_OLExtras.FV_FollowerTravel Name=FV_FollowerTravel0
{
TestHealth=NaliFruit0
NaliFruit'NP04Hyperion.NaliFruit0'
}
Class=UnrealShare.NaliFruit Name=NaliFruit0
{
}
TestHealth variable has 'travel' keyword on it, and the NaliFruit has bTravel=True (it's added even though it's not tagged 'Travel' because it's referenced by FV_FollowerTravel)
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

Higor wrote: Mon Nov 18, 2019 9:27 am (Personally I've already stopped playing on v436 for a month already)
Good to know...
The problem is that I have not seen anything real, something 468 or any beta posted somewhere so I can not test and I stay with what I have for now. After reading about bug fixes in release I tend to think that some stuff still won't work properly, for example toward that PlayerCanSeeMe I don't really see the job with bots because I had X crash-logs without using any Bot. That thing has other problems and you know them - on Youtube there is even a video entirely showing that junk as it is.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

Deployment of betas is not an option until UnrealScript part is feature-frozen.
And I believe it's already more stable than v436 in all aspects.

===
I've already managed to transfer actors from one level to another, now all I need is to code a real life example to showcase it.
Decided to improve a very old Coop gametype I made and add support for multiple coop campaigns that use their own gametype, starting with ONP.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

It raises the question of a player who has played UT in the past about extensions brought to UT, which extension can be used and from which version upwards is no longer valid. When UT 469 comes up, a lot of administrators and players probably won't know what to put and where to put it, these things need to be documented and explained.

Until the release of version 469, I think I'll add configuration variables to XC_Engine version 24, the new collision still has problems so by default I have no reason to use it. After that I'll wait to see how 469 works and how much 469 + XCGE 25 breaks or not everything I did for NavAdder or even the mutator itself. If my work goes downhill I have no reason to make any updates. In the environments that I have configured I have no critical problem, so any potential update that would give me a headache has no way to captivate me. Now, in 2019, I can finally say that I play UT without any problems. It remains to be seen if the updates are indeed compatible with all operating platforms because the libraries written by M$ do not have much in common with each other...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

Let me know what problems you find in CollisionGrid.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

Same oldies:
- Weapon vanished - (see screenshot in v24 thread) - random instances;
- Projectiles pulling me at once with them while are fired - rare but still happens;
- Some movers stuck - that recent map Deck16 redone - mid lift - for me it doesn't work at all with collision active.
Note - These don't happen with collision hook disabled. I'm hoping to not see such collision deal in that UT 469 unless I'll be no.1 at uninstalling it.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

I'll be redesigning CollisionGrid at one point, but not soon.
As usual, a link to maps with mover issues will help finding out what's wrong.

In the meantime, the new savegame feature is coming along pretty well. Been playtesting ONP coop with two players, saving and loading games and everything going smoothly.
The best part is the size of the savegames... between 70 and 130 kb.

The XC repository will be locked as a historic repository, a new one has been opened for UT v469, will still take a while to get everything up.
https://github.com/CacoFFF/XC-UT99-2019
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine megathread

Post by sektor2111 »

Another pretty sensitive point if I think about it. I haven't seen a second of any Demo recorded here. Maybe it's time for XC_Engine for having a demo module of its own to make things go synchronously, or an external lib as CollisionGrid.dll, just my two cents...
Eternity
Skilled
Posts: 166
Joined: Sat Nov 30, 2019 10:56 pm

Re: XC_Engine megathread

Post by Eternity »

There is an issue where opened channel might not be properly closed due to packet losses and therefore further unavailable until Player reconnect to the server.
This occurs when the Actor relevant to Player is destroyed, but does not occur if channel is closed when Actor (not destroyed one) was not relevant to Player longer than RelevantTimeOut time interval.
Is this possible to add the fix for this issue into the further XC_Engine versions? (It seems unlikely v469 update will have this problem fixed)

---

Update:
It has been fixed in v469. Thanks very much to developers. :gj:
It was the most hard bug in v436-v451 we dealt with, within a long time no any solution/workaround was found.
Last edited by Eternity on Thu Sep 24, 2020 12:45 pm, edited 1 time in total.
User avatar
rjmno1
Masterful
Posts: 716
Joined: Fri Aug 12, 2011 9:38 pm
Personal rank: masterfull
Location: https://sites.google.com/view/unrealtou ... oject/home
Contact:

Re: XC_Engine megathread

Post by rjmno1 »

Is that 469 patch already done or stil in wip?
Where can i download that patch?
xc engine more stable then the original games keep up the good works. :tu:
Howto install i the xc engine?
unreal tournament 99
®
Image
Image
ImageImage
https://sites.google.com/view/unrealtou ... oject/home mine home ut99 website.
https://richardmoust105.blogspot.com/20 ... ef-in.html dutch blog page about ut99 settings.
User avatar
papercoffee
Godlike
Posts: 10443
Joined: Wed Jul 15, 2009 11:36 am
Personal rank: coffee addicted !!!
Location: Cologne, the city with the big cathedral.
Contact:

Re: XC_Engine megathread

Post by papercoffee »

rjmno1 wrote: Thu Jan 30, 2020 12:12 am Is that 469 patch already done or stil in wip?
Wrong thread ...better ask here https://www.oldunreal.com/cgi-bin/yabb2 ... 1569587267
rjmno1 wrote: Thu Jan 30, 2020 12:12 am Where can i download that patch?
When it's done you'll notice it.
rjmno1 wrote: Thu Jan 30, 2020 12:12 am xc engine more stable then the original games keep up the good works. :tu:
How can you say it's more stable when...
rjmno1 wrote: Thu Jan 30, 2020 12:12 am Howto install i the xc engine?
...you haven't even installed it
238-2384539_meme-why-jackiechan-freetoedit-jackie-chan-meme-png.png.jpg
238-2384539_meme-why-jackiechan-freetoedit-jackie-chan-meme-png.png.jpg (45.94 KiB) Viewed 1265 times
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

So I've been rushing to finish some previously planned features as the v469 public beta draws near...
The automatic lzma compression on servers always felt off as it left a bunch of LZMA files sitting all over your server directories.
So I decided to add a more 'contained' way of doing it which combines memory and file sources while making it way
more friendly to server admins, to the point it can be left completely unattended.

When a server finishes loading a map, the 'LZMA server' will receive the package list and it'll attempt to do some
storage managment as it compresses sources.

It uses a fast memory cache reserved for the smallest packages, and a file cache for the larger packages.
LzmaCache folder.PNG
LzmaCache folder.PNG (5.47 KiB) Viewed 917 times
This would be a sample of the ini file:

Code: Select all

[Server]
MaxMemCacheMegs=8
MaxFileCacheMegs=256
ForceSourceToFileMegs=16

[LzmaCache]
627DAB834FAC01EBC5E278B4CB181480.lzma=../System469/sgUMedia.u


Both cache sizes are limited, the idea is to:

- When package is registered, try to locate an existing file source (can be a LZMA/UZ file next to it, as done via UCC LZMACOMPRESS or old bAutoCompressLzma)
- If package has no file source, the LZMA server will being a compression process.
- When compressed:
-- If original file larger than ForceSourceToFileMegs > push to file cache directly.
-- Otherwise keep in memory.

As more packages are pushed into memory, the server will count how much is being used and will push the biggest packages to file cache if the total exceeds MaxMemCacheMegs.
As more packages are pushed into the file cache, the oldest files will be purged if the total size exceeds MaxFileCacheMegs
This means a compressed package can potentially have the following lifecycle:
- Compression > Memory > Filesystem > Removal

The LZMA server should automatically delete cache files not referenced in the LzmaCache.ini and delete entries that don't have corresponding files (self maintenance).
Another plan is to temporarily halt download requests from clients to force compression to finish before starting to send data, also, to prioritize
specific packages for compression as more clients request them at the start of the level.

Example logs:
LZMAServer: Autocompressing package ../Maps/CTF-MeinKraft][-v3.unr
ScriptLog: Level change > New Pawn is CTF-MeinKraft][-v3.TBoss0
LZMAServer: Autocompressing package ../Textures/MeinKraftTex.utx
LZMAServer: Autocompressing package ../System469/CacusBlock.u
LZMAServer: Autocompressing package ../System469/XC_Siege_r3.u
LZMAServer: Autocompressing package ../System469/MCHalfSlab.u
LZMAServer: Autocompressing package ../System469/ConformTest.u
LZMAServer: Autocompressing package ../Textures/BossSkins.utx
LZMAServer: Autocompressing package ../System469/FV_Weapons.u
LZMAServer: Autocompressing package ../System469/sgUMedia.u
LZMAServer: Autocompressing package ../System469/SkinPal.u
LZMAServer: Autocompressing package ../System469/BsodPackage.u
LZMAServer: Autocompressing package ../System469/Yoshi.u
LZMAServer: Autocompressing package ../System469/SkeletalChars.u
LZMAServer: Autocompressing package ../System469/LCWeapons_0024.u
LZMAServer: Pushing cache to file [../System469/sgUMedia.u] -> [627DAB834FAC01EBC5E278B4CB181480.lzma]
LZMAServer: Autocompressing package ../System469/CacusBetas0008.u
LZMAServer: All sources processed (40)
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

The LZMA server in action, here it's delaying sending a package until it finishes compressing.
When a client requests a new package, said package gains priority in the compressor queue.
LZMAServer: Purged 0 files from LZMA cache
LZMAServer: Autocompressing package ../Maps/MonsterHunt/MH-EscapeFromNaZaliBeta2.unr
NetComeGo: Open MyLevel 09/22/20 05:39:03 192.168.1.4:61962
DevNet: NotifyAcceptingChannel Control 0 server Level MH-EscapeFromNaZaliBeta2.MyLevel: Accepted
DevNet: Level server received: HELLO REVISION=0 MINVER=432 VER=469
DevNet: Level server received: NETSPEED 200000
Log: Client netspeed is 25000
DevNet: Level server received: LOGIN RESPONSE=1121034609 URL=:7777/MH-EscapeFromNaZaliBeta2?LAN?Name=Higor(afk)?team=255?Class=BotPack.TBoss?skin=BossSkins.Boss?face=BossSkins.Xan?Voice=BotPack.VoiceMaleTwo?OverrideClass=Botpack.CHSpectator
DevNet: Client passed challenge
DevNet: Login request: :7777/MH-EscapeFromNaZaliBeta2?LAN?Name=Higor(afk)?team=255?Class=BotPack.TBoss?skin=BossSkins.Boss?face=BossSkins.Xan?Voice=BotPack.VoiceMaleTwo?OverrideClass=Botpack.CHSpectator
DevNet: NotifyAcceptingChannel File 1 server Level MH-EscapeFromNaZaliBeta2.MyLevel: Accepted
DevNet: Client requested file: Allowed
LZMAServer: Pushing package to file cache (size limit)
LZMAServer: Autocompressing package ../System469/MonsterHunt.u
DevNet: Sending '../Maps/MonsterHunt/MH-EscapeFromNaZaliBeta2.unr (LZMA Server)'
LZMAServer: Autocompressing package ../System469/MonsterHuntCR_0.u
LZMAServer: Autocompressing package ../System469/XC_DripFix1.u
LZMAServer: All sources processed (53)
Some variations in the LZMAServer.ini config and their effects:

Code: Select all

[Server]
MaxMemCacheMegs=0  >>> pushes all compressed packages to the file cache
MaxFileCacheMegs=0    >>> purges all packages in the file cache not actively in use (post level switch)
ForceSourceToFileMegs=0    >>> disables exception case where if a package is too large, it automatically goes to file cache
The default values should do well for most servers and avoid any problems with them running out of memory or storage.

Code: Select all

[Server]
MaxMemCacheMegs=16
MaxFileCacheMegs=256
ForceSourceToFileMegs=8
I'll very likely enable bAutoCompressLZMA by default on XC_Engine v25
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine megathread

Post by Higor »

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

Re: XC_Engine megathread

Post by Higor »

Decided to improve the path rebuilder a bit more.
https://github.com/CacoFFF/XC_Core/comm ... ce999079da

This time it may precalculate the reachability before applying pruning, while this will increase build times, it'll allow the paths builder to do pruning more smartly by creating redundant paths when there is improved reachability or a different locomotion method.
Example: if A-B-C is a route for small pawns and A-C is a route for big pawns, A-C won't be pruned.

Also, the Scout will be moved around a LOT more to find better location for InventorySpots and more precise path heights/widths at short distances.

MaxDistance is back and you can rebuild Selected paths only for testing small areas as well.
If you have any suggestions or improvements, now's the time.
Post Reply