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

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

Re: XC_GameEngine [build 10]

Post by Higor »

This is v10's code, for some reason the PlayerIdMap (TMap) was crashing in Linux and had to replace it with what's in the second block.

Code: Select all

void UXC_TravelManager::PostMapChange( ULevel* NewLevel)
{
	PlayerIdMap.Empty();
	TravelMap.Empty();
	TimerCounter = 0;

	bNoTick = 0;
	if ( !NewLevel || !NewLevel->IsServer() || !NewLevel->Actors.Num() || !NewLevel->NetDriver )
		bNoTick = 1;
}
Apparently it's not safe to call Empty() on an already empty TMap... I know right?

Code: Select all

void UXC_TravelManager::PostMapChange( ULevel* NewLevel)
{
	guard( UXC_TravelManager::PostMapChange);
	guard( PlayerIdMap);
	if ( PlayerIdMap.Num() > 0 )
		PlayerIdMap.Empty();
	unguard;
	guard( TravelMap);
	TravelMap.Empty();
	unguard;
	TimerCounter = 0;

	bNoTick = 0;
	if ( !NewLevel || !NewLevel->IsServer() || !NewLevel->Actors.Num() || !NewLevel->NetDriver )
		bNoTick = 1;
	unguard;
}

=============================
On a different issue, version 436 Linux doesn't have these stupid garbage collector errors so release 11 should work on it 100%.
I guess I'll have to drop v440 and v451 Linux support thanks to UTPG's super amazing tweaks to the GC.
Also, already got the RELIABLE_BUFFER assert virtual memory addresses for the v440 and v451 dll's.
RocketJedi
Inhuman
Posts: 850
Joined: Wed Mar 12, 2008 7:14 pm
Personal rank: I.T Master
Location: New York
Contact:

Re: XC_GameEngine [build 10]

Post by RocketJedi »

you see my crash log post? im not sure if your responding to me or not lol
https://www.vulpinemission.com
Image ROCKET-X8 Server
Image MONSTERHUNT w/ NALI WEAPONS 3 + RX8
Image BUNNYTRACK NY
Image SNIPER DEATHMATCH
Image InstaGib + ComboGib + Jailbreak
Image ROSEBUM ROCKET-X RB
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10]

Post by Higor »

Yes, it does mean that it's fixed for R11.

In the meantime...

ULevel::ServerTickClient function is where the relevancy checks are for an individual connection (so it's called on every frame, X times, X being the amount of active clients).
After learning some ASM on the run I've been able to decode like 40% of the main function, and noticed a secondary static(?) function not included in the headers where the actual visibility checks are done (oh Epic, you worms).
The locations where the visibility checks are done are very interesting...

It's a 4 frame cycle where:
- Tick 0: Trace actor vs your location.
- Tick 1: Trace actor vs your location and your location in the next 0.4 second.
- Tick 2: Trace actor vs your location.
- Tick 3: Trace actor vs your location and your location in the next 0.9 second.
Also, the future location is pre-traced and clamped if it hits a wall, this way it prevents relevancy checks from actors behind walls, when you're running into said wall.

This means relevancy checks do consider the player's velocity (and base velocity as well, elevators for example) when deciding an actor should be sent.
This makes sense because when you're running forward some actors become relevant before they actually enter your field of vision.
This also means that if your ping is above ~800 and the server runs at low tickrates, actors will become relevant IN your field of vision and you'll see them spawn lol.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10]

Post by sektor2111 »

Higor wrote:Also, the future location is pre-traced and clamped if it hits a wall, this way it prevents relevancy checks from actors behind walls, when you're running into said wall.
Using a simple setup I was trying relevance for let's say 3000 seconds. You don't want to see HUD effects in high loaded maps... This part it will be better to stay as it is. Also I was toying at decorations and pawns, game become a mess and it was not what I have expected. Sending data to clients for 4000 Actors will consume a lot of Net resources... and people less good intended will be able to hook what server sends, let's leave this chapter and fix bugs only - it can be improved or messed from UScript so this is not a problem to be solved but that Travel indeed crashed me too, so I set it to False.
For me these XC_Engine hooks should be configurable True or False. By example I don't need SetEnemy hack, Bot hack, Eightball hack, neither even Mover hack because simply I have other Bots and Monsters and they really act as expected. If these values would be configurable I would set them to False, else security buffer, PlayerCanSeeMe, collision, etc. are indeed Win servers problems and they were a NEED to be solved. Hacks related to Siege should be configurable - I have seen last days only 5 Siege servers active using UT native browser so engine doesn't need special hacks because some maps are full of glasses and because people cannot understand On-Line gaming. Actors can be implemented in maps to control certain things it is not a need to change engine for such things. Each change comes with new bugs which is not what admin really wants. Example: actor checking player in radius, making them relevant and less relevant if are out of range - it's mapping, or attach to player an actor controller meant to react in certain conditions, etc.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10]

Post by Higor »

These are facts, not myths:

1 - Player connections are limited to 1023 channels.
2 - If you connect into a zone where there's >1023 relevant actors, your player pawn will fail to be replicated, resulting in your client sitting in "Connecting...", while server spawns your actor and attempts to replicate it (failure).
3 - Channels for actors whose variables don't change don't transmit data.
NPLoader has a bug where NPLReplicationInfo actors don't self-destruct when the owner player disconnects, a populated server with long games like uk Siege will have between 30-150 of these actor channels doing nothing until the map changes, I already reported this bug to anth over 9000 years ago, I may have to design a ServerActor of my own to kill these annoying channel-hoggers.
4 - The local player constantly sends ServerMove functions so that the internal ServerTickClient doesn't interrupt the connection, this occurs because if (Driver->Time - NetConnection->LastReceiveTime) is greater than 1.5 second, the ServerTickClient will always return 0 and interrupt/delay any replication from server.
This can explain certain behaviours, like non-bNetTemporary projectiles failing to disappear on clients after a huge lag spike (never seen a shock ball stuck into a wall?).
5 - Relevancy traces going through translucent surfaces is now default behaviour in Unreal 227, a game with a vastly superior engine than UT.
6 - Replication checks consume CPU resources using a formula of this sort: [Summatory of (update frequency * variable count * player count) for each relevant actor ]
The only loser in increasing the amount of replicated actors, server TickRate or making highly net-unoptimized mods is the Server, the client never sees any performance impact.
Earlier NewNet versions would not be able to go over 12 players due to excessive CPU usage on 100 tickrate servers, for example.
I also devised a tool myself that reduces the PlayerPawn's NetUpdateFrequency dynamically depending on player count, from a configurable table, you can make your Server's client channels never reach the 20k bytes per second mark if you want to, which as a result also decreases CPU usage on replication checks.
7 - Inventory actors do not replicate their Inventory based variables to non-owner players, no matter how much you try messing with the replication checks.
8 - Inventory actors always update at a frequency of 2hz on dedicated servers, no matter what NetUpdateFrequency value you set.
9 - Actors that fail relevancy checks after being relevant will continue to be relevant for a IpDrv.TcpNetDriver.RelevantTimeout (default=5.000000).
10 - Relevancy traces hit the actor in their (0,0,0) spot, this means that a camper on a high position can snipe ppl without becoming relevant to other players, randomizing the Trace End into any point of their box each frame will solve this behaviour.
This also solves such behaviour with huge monsters/non-static decorations.
Also, by the previous rule, actors partially visible won't disappear because said timer will ensure than a new random position becomes visible before it hits zero.
11 - The only things replicated behind walls are actors where:
- Your pawn owns in it's Owner hierarchy (this even works: Actor->Owner->Owner = you)
- Your pawn is the actor's Instigator
- You are within AmbientSound radius (25.0 * SoundRadius i believe?)
- Actor has bAlwaysRelevant=True
- Actors whose relevancy timeout hasn't reached zero.
(I'm certain i'm missing another condition here...)
That's not something I intended to change, I simply want to change what 'visibility blocking wall' means.
Basically by letting traces have the NF_NotCsg + NF_NotVisBlocking flags (they currently stop at anything that blocks them, which is bad for visibility based conditions).
12 - The variable 'NetTag' in an actor determines each replication polling done to it, you can easily measure how many relevancy checks were done to it in a period of time by simply saving 'NetTag' and comparing it again one second later.

Regarding the other hacks, if there's a technical problem with those I fix them. They're there to prevent crashes, speedup the code or keep your log window from spamming.
For example, MonsterHunt servers (at least the old versions) can be greatly speed up if MH gets to know when to forcibly set a monster's Enemy to a Bot, or when not to do it (XC_GE server) because you wouldn't need to loop the pawn list on every AI polling.
The other reason for changing the behaviour of actors instead of the actors themselves is precisely to avoid sending more stuff to the clients, replacing more actors via mutators, etc.

Some things are best handled at UScript level, yes. But you can't derive everything to it, there's a point where it becomes slower, impractical and annoying to clients.
I'll have a 10.5 release for the recently fixed bug in TravelManager and a v436 Linux build, because these are indeed critical things.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10]

Post by sektor2111 »

Higor wrote:1 - Player connections are limited to 1023 channels.
2 - If you connect into a zone where there's >1023 relevant actors, your player pawn will fail to be replicated, resulting in your client sitting in "Connecting...", while server spawns your actor and attempts to replicate it (failure).
This is just perfect for me...
Higor wrote:5 - Relevancy traces going through translucent surfaces is now default behaviour in Unreal 227, a game with a vastly superior engine than UT.
You hear that Mr. MH Mapper which wants 1600 Monsters relevant ? Good.. Go play Unreal 227 instead, LOL. Unreal 227 is probably very Coop Sp dedicated without having so much load as UT's MH has... but if exist a faster solution to transmit data (animations like) from 1600 Actors using 1023 channels then I'm curious even to see a chart to light up my tiny brain. I'm not curious about combining these with Precipitations...
I have only a simple advice, player/admin who need spam, go play UT200X or whatever they think that will match their tastes. UT'99 proved has limited options and it will be better to run stable as it is, else will result in breaking a lot of stuff making XC_Engine less desired.
I have an example - which I have to (re)solve:
In NsCTF Bot is(was) able to recover Flag using Translocator - READ again. AFTER solving collision troubles I have seen many times Bot failing to recover flag using Translocator (I worked almost 1 week coding, testing to make such things possible, and now I'm back into subject due to new options. I have to log Flag.Location, Bot.Location, TranslocatorTarget.Location and I have to draw cylinders, etc.) or I have to use other solutions for Translocator.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10.1]

Post by Higor »

That looks like the Actor<->Actor Encroach code doing something funky.
Will take a better look at it.

EDIT: You sound serious about a MH mapper putting 1600 monsters at the player's fov... you're telling me someone was dumb enough to do that?

================
Binaries update:

Fixed UXC_TravelManager::PostMapChange crash.
Linux build included again (Only supports v436, v440 and v451 crash upon map switch)
Attachments
XC_Engine_v10.1_binary_update.7z
(146.66 KiB) Downloaded 68 times
User avatar
Wises
Godlike
Posts: 1089
Joined: Sun Sep 07, 2008 10:59 am
Personal rank: ...

Re: XC_GameEngine [build 10] [10.1 hotfix]

Post by Wises »

does this version have support for detecting players early?

if so what would the sample code be to get this information ty.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10] [10.1 hotfix]

Post by Higor »

An unexpected limitation is preventing normal UScript code from accessing the extended properties (NetDriver, NetConnection, etc), basically the only way to do it is via GetPropertyText and that has the same crash issue from accessing ServerPackages on very long lists.
Basically, any form of compiled UnrealScript requires the targeted properties to exist in the target Unreal Package file (.U), if said properties are created in runtime your mod's code will fail to load.
It's a pity because dynamic array code is working perfectly :( , i'll just figure out something.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10.1]

Post by sektor2111 »

Higor wrote: EDIT: You sound serious about a MH mapper putting 1600 monsters at the player's fov... you're telling me someone was dumb enough to do that?
It was closer and a genius suggested a ConsoleCommand, ha, ha, some of those "new blood" joined think they can reinvent wheel and warm water. I stopped to wonder myself why these "designers" aren't asking support for server-travel triggers and fixations rather than doing dumb levels having XX MB size, doesn't matter. When 400 monsters are in FOV or all 2000 are Relevant will deliver the same effect for noob player joined at default 2600 speed...

Edit: I'm grateful for solving Unreliable bug problem... this will keep me into UT'99 circle, YAY...
User avatar
Wises
Godlike
Posts: 1089
Joined: Sun Sep 07, 2008 10:59 am
Personal rank: ...

Re: XC_GameEngine [build 10] [10.1 hotfix]

Post by Wises »

was probaly a test lol which obviously exhausted this engines capacity.
they may have moved on to games like Rome Total War II ;)
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 10] [10.1 hotfix]

Post by Higor »

AH SHIET.
I forgot to remove a debug crash before releasing the hotfix... basically, the game will crash if a map file doesn't load. (it's only on the hotfix, default v10 is fine)
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10] [10.1 hotfix]

Post by sektor2111 »

Higor wrote:basically, the game will crash if a map file doesn't load.
It's not the default behavior of engine? How can run a map if a required file cannot be loaded ?

What could be implemented can be Booleans configuration related things for people which don't need all tweaks.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 10] [10.1 hotfix]

Post by sektor2111 »

I got an idea SetEnemy based. I'll rename this function into my creatures as long as I don't have a problem with that and my monsters are OK in habits - I really would like to have this disabled.
RocketJedi
Inhuman
Posts: 850
Joined: Wed Mar 12, 2008 7:14 pm
Personal rank: I.T Master
Location: New York
Contact:

Re: XC_GameEngine [build 10] [10.1 hotfix]

Post by RocketJedi »

XC_Engine: Checking for Moving Brush Tracker insertion...
XC_Engine: Found Mover, inserting tracker...
Init: Initialized moving brush tracker for Level MH-Canyon-Revamp2.MyLevel
Init: Game engine initialized
Critical: UXC_TravelManager::PostMapChange
Critical: UXC_GameEngine::Init
Critical: UServerCommandlet::Main
Exit: Executing UObject::StaticShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 03/19/15 08:52:23
https://www.vulpinemission.com
Image ROCKET-X8 Server
Image MONSTERHUNT w/ NALI WEAPONS 3 + RX8
Image BUNNYTRACK NY
Image SNIPER DEATHMATCH
Image InstaGib + ComboGib + Jailbreak
Image ROSEBUM ROCKET-X RB
Post Reply