XC_Engine [20] - XC_Core [7b] - XC_IpDrv

[Higor]

Primitives aren't "official", avoid using them.
Second, what's the uscript code for MapVoteX's map generator? At least the part of the loop where it's calling GetMapName.
MapList generation will always be slow, take a look at how a mapvote works:
- Everything in UnrealScript except GetMapName.
- Map filter comparison for each map/one full loop per map filter (depends on mapvote)
- Sorting (?)
- Saving config.
If you want a fast mapvote, the only choice you have is grabbing one of Gust's latest MVLA14 frontends and editing CMV to go full native.

The tickrate fluctuation has been discovered on a server that often has 22 players (not counting specs) in it, I believe you can guess which.
Btw I completely removed threading from the relevancy loop, I was unable to make it stable.

EDIT:
On a different note, the native hooks have worked wonderfully.
I think I'll get v17 to go out if I make the relevancy loop not replicate a crapton of actors on the same frame (space them out better to avoid fluctuations)

[sektor2111]

All right, I have

• MVLA14UUb03.u
  MVLA14UUb05.u
  MVLA14UUb13C.u
  MVLA14UUb17C.u
  MVLAv14UU01.u

Which one you might recommend ? I see that Gust did not participate too much in these debates so hardly I can figure what is wrong/different between these versions, also if they have a separate server-side this doesn't make things better either.
Of course usually I'm not crying for MapVoteX and similars. In random moments I see "bIsPlayer&&PlayerReplicationInfo.Score" which doesn't fascinating me. Also Nowhere Nobody has a source-code posted except LA13 which I did not see how much works over normal limits, that's codes problem or heck knows since some sort of UTBrowser can handle cache which has a lot of things in that "list" getting over 255 bytes to not forget that some "List" code seems able to handle 10000 "Items". Well... looks like I have to learn UWindow which drives me mad.

[sektor2111]

Ummm, I think XC_Engine supports "BitchNode" type. At least looks like it works.
I've done a custom PathNode able to move between 2 points when gets triggered... The same route over and over again looks boring especially when there is more place around. I might want to switch a bit the same route. First Beta looks functional, function Move did not help, I've used SetLocation. I found paths to enemy until this moment but I go to test more... .

Edit:___
Nope, They will move in a sort of square (x,y) switching location based on Core - RandRange(a,b). Then record original reference and move again randomly at next trigger hit. Wheew, so cute...

[sektor2111]

It says:

Code: Select all

ScriptLog: Administrator logged in.
ScriptLog: MV Admin is logged in. Sending admin vars...
XC_Engine: MapCache needs reloading...
XC_Engine: Searching through directory ../Maps/ => Found 46 results
XC_Engine: Searching through directory ../Maps/ => Found 116 results //In don't understand these multiple loads
XC_Engine: Searching through directory ../Maps/ => Found 116 results //there are only 3 columns used 2 DM, 1 CTF
XC_Engine: Searching through directory ../Maps/ => Found 116 results
XC_Engine: Searching through directory ../Maps/ => Found 116 results
ScriptLog: BDBMapVote: Maps Reloaded. Total Maps = 275
ScriptLog: Administrator logged out.
Critical: FCollisionOctree::FastPointQuery
Critical: FCollisionCacus::ActorPointCheck
Critical: CheckWithActors
Critical: ULevel::MultiLineCheck
Critical: ULevel::Trace
Critical: APawn::physWalking
Critical: APawn::performPhysics
Critical: AActor::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UServerCommandlet::Main
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 02/07/16 11:52:49

But no problem with log closing or such...

[Higor]

There's a certain public server that's been seeing nearly a dozen builds already, mostly to try out relevancy and collision problems.
Some of the changes coming over with next release:

- Rewritten line traces, now it's as fast on short traces (and much faster on long ones) than the old hash.
- Relevancy loop with tremendous changes, almost rewritten, no more multithreaded code here and bAlwaysRelevant actors can become irrelevant to free up channels.
- Relevancy loop will apply a couple of netcode enhancements in the form of properties:
-- bNotRelevantToOwner (lag compensators will love this)
-- bNetDirty (emulated, not same as UE2, but should reduce CPU usage on servers with more than 3 players)
- PlayerPawn full of new hooked functions.

=====================

Lol, it means the mapvote isn't doing single-pass loading a general map list, but instead rebuilding the map list using prefixes in a multi-pass fashion.
Basically, that's how all MapVoteLA clones operate.
CacusMapVote is the ONLY mapvote that does single-pass loading of the entire map list.

Code: Select all

XC_Engine: MapCache needs reloading...
XC_Engine: Searching through directory ../Maps/ => Found 46 results
XC_Engine: Searching through directory ../Maps/ => Found 116 results //In don't understand these multiple loads
XC_Engine: Searching through directory ../Maps/ => Found 116 results //there are only 3 columns used 2 DM, 1 CTF
XC_Engine: Searching through directory ../Maps/ => Found 116 results
XC_Engine: Searching through directory ../Maps/ => Found 116 results
ScriptLog: BDBMapVote: Maps Reloaded. Total Maps = 275

[JackGriffin]

You don't get enough love around here Higor. I wish I was 10% as capable.

[Higor]

Just discovered that badly designed mapvotes can cause big CPU usage spikes during replication, potentially affecting tickrate stability.

I'll explain briefly:
- Actor (usually MapVoteWRI) is spawned.
- MapVote map list consists on over 2000 string variables.
- These variables have to be checked for changes every time the actor is considered for replication.
- Relevancy code will continue to compare large arrays, even if the replication block's conditions fail for the first time.

Imagine this

Code: Select all

var string MapList1[256];
var string MapList2[256];
var string MapList3[256];
var string MapList4[256];

replication
{
    reliable if ( Role==ROLE_Authority )
        MapList1, MapList2, MapList3, MapList4;
}

This is what happens:
- MapList1 property selected for checks
- Evaluate MapList1[0] vs old MapList1[0]
>> CHANGED: go ahead.
>> NOT CHANGED: check next in array (ex: MapList1[1] and so on)
- MapList1 replication condition has not been evaluated
-- Evaluate: Role==ROLE_Authority >>>> TRUE
- MapList1 replication condition passed
-- Evaluate MapList1[1-255] vs old MapList1[1-255]
- MapList2 property selected for checks
- Evaluate MapList2[0] vs old MapList2[0]
- MapList2 replication condition has already been evaluated (shared with MapList1)
- Evaluate MapList2[1-255] vs old MapList2[1-255]


So we spot an obvious problem...
Cpu waste on first array check, that can propagate to second array check and so on:

Code: Select all

var string MapList1[256];
var string MapList2[256];
var string MapList3[256];
var string MapList4[256];
var bool bReplicateMapList;

replication
{
    reliable if ( Role==ROLE_Authority && bReplicateMapList )
        MapList1, MapList2, MapList3, MapList4;
}

If bReplicateMapList=False this happens:
- MapList1 property selected for checks
- Evaluate MapList1[0] vs old MapList1[0]
>> CHANGED: go ahead.
>> NOT CHANGED: check next in array (ex: MapList1[1] and so on)
- MapList1 replication condition has not been evaluated
-- Evaluate: Role==ROLE_Authority && bReplicateMapList >>>> FALSE
- MapList1 replication condition failed
-- Still evaluate MapList1[1-255] vs old MapList1[1-255], but do nothing
- MapList2 property selected for checks
- Failed replication condition skips this property completely


We've managed to eliminate the checks of subsequent arrays, IF bReplicateMapList is FALSE
But we've got more problems, the first array is still fully checked.
One ugly workaround, is to force a variable to be sent on every check (1/NetUpdateFrequency)

Code: Select all

var int StopRep;
var string MapList1[256];
var string MapList2[256];
var string MapList3[256];
var string MapList4[256];
var bool bReplicateMapList;

replication {
    reliable if ( Role==ROLE_Authority && bReplicateMapList )
        StopRep, MapList1, MapList2, MapList3, MapList4; }

event Tick( float DeltaTime) { StopRep++; }

If bReplicateMapList=False (again) this happens:
- StopRep property selected for checks
>> CHANGED (100% cases)
- Evaluate replication condition
-- Evaluate: Role==ROLE_Authority && bReplicateMapList >>>> FALSE
- Send StopRep to client
- MapList1 property selected for checks
- Failed replication condition skips this property completely

This is cute and all but presents us with a problem:
- Bandwidth waste which requires us to use a low bNetUpdateFrequency value, we're constantly sending a variable.
- Using too low bNetUpdateFrequency will cause the map list to take ages to be sent (so 4 is good).
- We still have to see when it's appropiate to set bReplicateMapList=False


Let's assume each player has his own MapVoteWRI (should be like this).
We can use an ugly hack here...

Code: Select all

var int StopRep;
var string MapList1[256];
var string MapList2[256];
var string MapList3[256];
var string MapList4[256];
var bool bReplicateMapList;

replication {
    reliable if ( Role==ROLE_Authority && bNetOwner && MapListNeedsReplication() )
        StopRep, MapList1, MapList2, MapList3, MapList4; }

final function bool MapListNeedsReplication() //SLOW, don't use it unless you have lots of string arrays
{
    StopRep++;
    if ( bReplicateMapList )
    {
        bReplicateMapList=False;
        return true;
    }
}

So, everytime we do a map list update (or set it for the first time) we set bReplicateMapList=True.
- First loop (bReplicateMapList=True)
- Evaluate StopRep >>>> CHANGED
- Evaluate replication condition >>>> TRUE (set bReplicateMapList=False)
- Check and send everything
...
- Second and subsequent loops
- Evaluate StopRep >>>> CHANGED (100% chance)
- Evaluate replication condition >>>> FALSE (this is slow, make sure you use it for big string arrays)
- MapList1 property selected for checks
- Failed replication condition skips this property completely


So, the more maps your maplist can send, the higher the CPU impact will be every 0.25s (1/NetUpdateFrequency).
This very ugly and hacky code deals with that in a pretty much automated way.

[sektor2111]

This code is a high load and looks like it does a worst slow-down than a complex iterator, to not mention a lot of replicated data... so we might update maps only when no important game runs there, or the consequences of a stop-action type lag won't be a bless. But a little fine tuning at NetUpdateFrequency probably would be helpful somehow...

Edit: Something perhaps a little stupid in purpose to gain a bit of faster file access based on OS pre-cache outside of UT. Then UT folders are gonna be listed/loaded faster a second time. Helpful or not, I have added these lines in start-server batch:

Code: Select all

echo Precaching stuff...
dir Drive:\ServerLocation\System\*.*
dir Drive:\ServerLocation\Maps\*.Unr
dir Drive:\ServerLocation\Sounds\*.Uax
dir Drive:\ServerLocation\Textures\*.Utx
dir Drive:\ServerLocation\Music\*.Umx
cls
:10
echo Modified UT Baiter server is starting...
...
...

I'm guessing these helps a bit in caching file locations in NON SSD drives. Right ?

[Higor]

XC_Core version 4 update.

Added some SSE FVector4 math functions.
Added extra native symbols to prevent bind crashes (clock, hsize)
XC_ChannelDownload functional on Linux (v436, v440, v451)
>>> See XC_Networking.h for FOutBunch handling macros.

Script:
- Added FindObject.
- Added AllObjects iterator.

** XC_CoreTest edited to show AllObjects usage (finds all textures, counts them, prints time it took)
** EXAMPLE:
** ScriptLog: Fabricate XC_Core.XC_CoreTest
** ScriptLog: Inner clock test, time measured: 0.000002
** ScriptLog: Iterating through all textures...
** ScriptLog: Found 696 textures, time taken: 0.001568
** ScriptLog: Test finished at 33737.378906

[sektor2111]

I have figured how to detect XC_Engine without creating dependencies but I think I need an example of code/command in order to detect XC_Core things because I don't get anything in my attempts until this moment. Do I need a "Dynamicload" ? Do I need a "ConsoleCommand" ? Something set in ini for getting a value from there ?

[Higor]

Not really, I'll just have XC_Engine v17 require XC_Core v4.

[sektor2111]

PrimitiveMesh will have something new ?

[Higor]

Not much, borked extent traces.
This will probably be my last XC_Engine release.
Gonna move to UT4, starting with SiegeIV

[sektor2111]

Then I'm gonna look for v17 and then I'll jump back in my box outta here for doing other stuff. It was a nice time to deal with XC stuff, thanks a lot for your efforts and nights spent working for UT99, you are The Man .
If by chance I'll see some trouble at v17 I suppose that I will not expect whatever patch then...

[Wises]

Second, what's the uscript code for MapVoteX's map generator? At least the part of the loop where it's calling GetMapName.

ProASM has gracefully provided full source code for MapVoteX on his website under UnrealTournament here http://proasm.com/

Take Care.

Direct Links:
http://proasm.com/ut/mapvotex.html

MapVoteX103_Src.zip

Source Code for MapVoteX103 as downloaded
from ProASM's website above

(83.97 KiB) Downloaded 85 times

*Updated Original thread here