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

User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [4]

Post by sektor2111 »

It would be much better to have these XC Add-ons configurable with bool types, letting people to use whatever MapVote they want without any help in reading MAP files. Let them slow if admin wants this. As for transient left-over objects "spawned" by MapVote, that's another bad idea. Like I said, if something is about to have a change - allow it to be disabled on demand, don't force new rules.
After changing that "NetUpdateFrequency" as spoken above and doing small OS precache tweak. At loading 275 maps I did not see "RED-FLAG" anymore not even for a few milliseconds (read from an attached IDE not SATA drive). In several maps tick-rate goes down a bit when game do initializes and Bots enter the stage (reading configs I guess), the rest is smoother.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [4]

Post by sektor2111 »

XC_Core4 sending fake uz (not for the first time saying uz which doesn't exist and without redirect)

Code: Select all

Critical: appError called:
Critical: Assertion failed: Channels[ChIndex]==this [File:\\WIN-HGVQA9NDE9L\ut src\XC_Core\Src\XC_Networking.cpp] [Line: 457]
Critical: Windows GetLastError: The operation completed successfully. (0)
Exit: Executing UObject::StaticShutdownAfterError
Critical: UObject::ConditionalDestroy
Critical: (XC_FileChannel Transient.XC_FileChannel0)
Critical: UChannel::ReceivedAcks
Critical: ReceivedAck
Critical: UNetConnection::ReceivedPacket
Critical: UNetConnection::ReceivedRawPacket
Critical: UpdatePreNet
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Exiting.
Uninitialized: Name subsystem shut down
Edit: Yes, XC_Core3 works properly.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [16] - XC_Core [4]

Post by Higor »

Server version? (test in both v436, v440 (or v451) based ones)


EDIT:
Noticed a lot of octree anomalies, these are probably the cause of some clientside crashes (why only clients anyways?)
Until that long running issue isn't finally tackled I will continue to make experiments and playtest them whenever I can on the Siege server as it's the ONLY place that puts enough stress to crash XC_Engine.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [4]

Post by sektor2111 »

That error occurred in a kind of test-Lan-Server 436, of course (Editor do sucks in 451 anyway - I've already removed all 451 from my drives), else at a moment I could figure 2 nice blue screens which were remembering me by old times - happening AFTER updating XC_Core to v4.
Random occlude::frame bla bla occured in client - total crash, there I'm suspecting Team-Light from Monsters "my stock" which if are too many in place might override Maximum of light render capability or whatever crap... However I did not see that in OpenGL.
The rest of audio drivers tested seems worst than original Galaxy which Never Ever crashed me.

Aside: You can toy with a high loaded MH map - I'll sent you what I was working at MH last time - you can remove "//" remarks to unlock PrimitiveMesh and then... see the tick-rate with 1000++ creatures. I might did wrong a tracker actor but I did not see examples so I developed this how I considered (and I am not a genius). Performance spy get active when tick-rate falls badly and also broadcast when cycles go back to normal. Easy levels works like butter, hard levels I guess can put down even powerful machines.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [16] - XC_Core [4]

Post by Higor »

Better handled anomalies, removed a couple of cases and made it so all anomalies get logged. And no anomalies detected in the octree actor lists, basically actors aren't being stored in the wrong nodes and it's still crashing in very specific maps and cases.
Most of those crashes involve a buildable teleporter and platform... I'll be looking at encroachment checks instead.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [4]

Post by sektor2111 »

In normal TDM games I did not see Telefragging inside team (losing score ?), only Bot was telefragging players. In latest XC stuff playing a MH map (Some WTC whatever) players could be telefragged by other player at first start - which I don't see this a normal way, as long as both are from the same team. I well recall an old crappy one in an old session (but not name) where players spawned inside a cylinder, all of them getting stuck but never telefragging each-other.
I think in future I'll solve spawn-telefrag problem in MH ignoring default rules.
It will react as a spawn-protection. No collision, attaching a permanent actor tracker, in 2 seconds collision returns to normal.
Why returns to normal ? Because if bBlockPlayers=False, a monster does a lower damage to player which I don't understand what has to do Projectile fired by monsters with bBlockPlayers. HOF players figured that and I could see it too - they want powerful monsters not those having hits as cat with tail.

Edit:
Umm... no, I've done it more simple, no new actors, just changing RestartPlayer and modifying startSpot if someone else is located there > use a nearby another NavigationPoint instead... Looks like a in map with 4 PlayerStart actors and 8 hunters won't cause any spawn-telefrag. Not even in 10 sessions.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [16] - XC_Core [4]

Post by Higor »

EDIT:
Tickrate stable relevancy loop, rewritten AddActor/RemoveActor for FCollisionCacus, highly verbose logging, LoadMap fully rewritten with early hook points, playerspeech and teamsay hooks (%z, %a, %h!!!), lots of useless and unused code bloating DLL size.
I can't guarantee it'll be stable, but if it doesn't crash 'much' then we'll be very close to something official.
XC_Engine_gridtest.7z
Pre v17
(116.49 KiB) Downloaded 85 times
==============

So I decided to tackle one of the biggest problems of XC_Engine, hook points.
Now during level initialization all of XC_Engine's script features become available.
This means... GameInfo, Mutator, PlayerPawn init functions can be edited as well. (stuff like FindPlayerStart)
Another advantage of this is that the old collision hash is never initialized.
Log: Browse: CTF-][FL][Atmospheric_MLSG.unr?Game=BotPack.CTFGame?Mutator=LCWeapons_0016.LCMutator?Name=Nigor?team=0?Class=BotPack.TMale2?skin=SoldierSkins.blkt?face=SoldierSkins.Riker?Voice=BotPack.VoiceMaleTwo
Log: XC_LoadMap: CTF-][FL][Atmospheric_MLSG.unr?Game=BotPack.CTFGame?Mutator=LCWeapons_0016.LCMutator?Name=Nigor?team=0?Class=BotPack.TMale2?skin=SoldierSkins.blkt?face=SoldierSkins.Riker?Voice=BotPack.VoiceMaleTwo
XC_Engine: Replacing ULevel vtable...
Log: Collecting garbage
Log: Purging garbage
Log: -0.0ms Unloading: Package UT-Logo-Map
Log: -0.0ms Unloading: Package utmenu23
Init: Shut down moving brush tracker for Level UT-Logo-Map.MyLevel
DevMusic: Unregister music: Music utmenu23.utmenu23
Log: -0.0ms Unloading: Package SoldierSkins
NetComeGo: Close DemoRecConnection0 03/07/16 23:18:30
Log: Closing down demo driver.
Log: -0.0ms Unloading: Package UTBrowser
Log: -0.0ms Unloading: Package SiegeIV_0022
Log: -0.0ms Unloading: Package sgUMedia
Log: -0.0ms Unloading: Package sgMedia
Log: -0.0ms Unloading: Package sgMedia2
Log: -0.0ms Unloading: Package AmbModern
Log: -0.0ms Unloading: Package Extro
Log: -0.0ms Unloading: Package DDay
Log: Garbage: objects: 34927->25069; refs: 382196
XC_Engine: Setting up collision octree [Level Hook] for CTF-][FL][Atmospheric_MLSG
Log: Game class is 'CTFGame'
Log: Bringing Level CTF-][FL][Atmospheric_MLSG.MyLevel up for play (0)...
ScriptLog: InitGame: ?Game=BotPack.CTFGame?Mutator=LCWeapons_0016.LCMutator?Name=Nigor?team=0?Class=BotPack.TMale2?skin=SoldierSkins.blkt?face=SoldierSkins.Riker?Voice=BotPack.VoiceMaleTwo?OverrideClass=
ScriptLog: Base Mutator is CTF-][FL][Atmospheric_MLSG.DMMutator0
ScriptLog: Mutators LCWeapons_0016.LCMutator
ScriptLog: Add mutator LCWeapons_0016.LCMutator
Warning: AddToPackagesMap: Cannot edit the Master Map
Warning: AddToPackagesMap: Cannot edit the Master Map
Init: Initialized moving brush tracker for Level CTF-][FL][Atmospheric_MLSG.MyLevel
Log: Spawning new actor for Viewport WindowsViewport0
ScriptLog: Team 0
ScriptLog: Login: Nigor
Log: Possessed PlayerPawn: TMale2 CTF-][FL][Atmospheric_MLSG.TMale1
DevAudio: Galaxy SetViewport: WindowsViewport0
XC_Engine: Browse() End
DevMusic: Load music: Music WF-ReadyToGo.WF-ReadyToGo
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [4]

Post by sektor2111 »

I hope this is a joke, I cannot pick up weapons any longer in MH2.

Edit:
Neither in original MH... Checking...

Code: Select all

DevNet: NotifyAcceptingChannel File 1 server Level MH-Godz-Last-Chance{UM}.MyLevel: Accepted
DevNet: Client requested file: Allowed
DevNet: Sending '..\Maps\MH-Godz-Last-Chance{UM}.unr.uz'
I don't have any UZ in folder...

Original DM - Cannot get BioRifle
[attachment=1]No_Bio.jpg[/attachment]'
And not PulseGun
[attachment=0]No_Pulse.jpg[/attachment]
I'm right on weapons
Setup:

Code: Select all

bCacheConvertAtJoin=False
bFasterUpload=True
bDisableTimingFix=True
SortMaplistByFolder=False
bAutoTravelManager=False
bCollisionHashHook=True
bUseLevelHook=True
bUseNewRelevancy=False
bDisableBrushTracker=False
bSortMaplistByFolder=False
bSortMaplistGlobal=False
bEnableDebugLogs=True
bUseSetEnemyHook=True
bAutoCompressLZMA=False
bScriptDebug=True
ThreadCount=1
Did I rammed something in setup ?
Attachments
No_Pulse.jpg
No_Bio.jpg
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [16] - XC_Core [4]

Post by Higor »

Examine your log and find these words:
- anomaly
- redundancy
Also tell me the DM maps that show this problem, the grid size has been changed and lots of things may go off.

EDIT:
DM-ArcaneTemple is one of those maps, basically all actors are placed on the wrong nodes, this is gonna be interesting to figure out.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [4]

Post by sektor2111 »

Higor wrote:DM-ArcaneTemple is one of those maps, basically all actors are placed on the wrong nodes, this is gonna be interesting to figure out.
Now I'm curious how many will do work. Looks like in MH2 was a NO, MH was a NO too, DM = NO, NsDm = NO; and all of these were functional. So... what's the deal ? I'm lost right now.
What kinda magic pill do I need to make these functional, Actor.SetLocation(Actor.Location) ? :noidea .
Answer: None, in map shown as demo in topic with "prevent telefrag" suddenly 3 pupae looks like were starting to have sex in a "ménage à trois". For sure they are movable through grid so... However, in Off-Line I could get weapons and items in that "Zero" Level.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [16] - XC_Core [4]

Post by Higor »

This build is FULL of integrity checkers, so the game is likely to crash preemptively before hitting a segfault.
Still, it ran just fine in my 22v22 test bench.
XC_Engine_gridtest2.7z
(115.18 KiB) Downloaded 80 times
PD: Nodes take 32 bytes less than before and node coordinates aren't given by parent node, but generally assigned by the grid system.
I sort of had to go with this because some weird logic between parent nodes and child nodes would end up creating completely off-the-grid nodes over time, or replacing other nodes in the same grid slot.
Hopefully it remains a lot more stable in online play.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [4]

Post by sektor2111 »

This one do seems to work (for firsts attempts), I have to do more tests.
Higor wrote:This build is FULL of integrity checkers, so the game is likely to crash preemptively before hitting a segfault.
Still, it ran just fine in my 22v22 test bench.
To be honest I did not see nasty troubles at v16 yet... If segfault comes in Linux from wrong libs then your efforts might not have results.

The only few troubles caused by v16 was using PrimitiveMesh+MonsterDestruction. Randomly in places I could figure ghost collisions as BSP errors do. Once removed PrimitiveMesh, they were gone.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [16] - XC_Core [4]

Post by Higor »

The problem was extremely difficult to locate... one just as hidden as the original FCollisionHash's one.
It takes joining a >15 player server with a mod that allows you to construct stuff, even brushless movers (let you walk on them) to even trigger a crash...

Not fixing this problem is the same as sticking to the old pre XC_Engine collision crashes, it's something I have to take care of.
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [16] - XC_Core [4]

Post by sektor2111 »

MH-BattleCrypt - Mover as ground set like trap, over Lava. In one of my toy-build I did paths over that mover, and they were functional - nasty job but I've done it properly, at least On-Line +v16 Never crashed me there.

Edit:
And Back in business. XC_Core4 + XC_Engine17 sending LZMA from internal location (not redirect):

Code: Select all

DevNet: Client requested file: Allowed
DevNet: Sending '..\System\MBot.u.lzma'
XC_Engine: Empty connection after 3.026000 seconds.
NetComeGo: Close TcpipConnection0 03/09/16 17:46:18
Critical: appError called:
Critical: Assertion failed: Channels[ChIndex]==this [File:\\WIN-HGVQA9NDE9L\ut src\XC_Core\Src\XC_Networking.cpp] [Line: 457]
Critical: Windows GetLastError: The operation completed successfully. (0)
Exit: Executing UObject::StaticShutdownAfterError
Critical: UObject::ConditionalDestroy
Critical: (XC_FileChannel Transient.XC_FileChannel0)
Critical: UNetConnection::Destroy
Critical: XC_IpDrv::~UTcpipConnection
Critical: UObject::ConditionalDestroy
Critical: (TcpipConnection Transient.TcpipConnection0)
Critical: UNetDriver::TickDispatch
Critical: UpdatePreNet
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 03/09/16 17:46:18
Of course first attempt to join returned failed after a period of "Connecting", after reconnect command I have downloaded a file and then... No Server.

Session 2: XC_Core3, XC_Engine v17. MH2 game, party started, long batle, game end, voted... End of server at garbage collector - stuck... LOG file was not closed.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [16] - XC_Core [4]

Post by Higor »

Oh, net servers appears to be broken in this build, one of those previously mentioned experimental code things I didn't remove lol.
Either way, I won't be messing around too much, as soon as I complete a few games without a single collision crash I'll clean it up and finish adding the missing remaining teamsay macros for v17 release.

PD: UT4 is very unfriendly for modding atm, will delay my plans for that game.
Post Reply