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

Post Reply
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA
Contact:

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Chamberly »

Started just fine client side, deck16 np.
& I use that UT-Logo-Map lol, got tired of city intro long ago.
Loaded CTF-BT-FrictionV2 (50.1 MB) and got no problem.
Image
Image
Image Edit: Why does my sig not work anymore?
User avatar
papercoffee
Godlike
Posts: 10447
Joined: Wed Jul 15, 2009 11:36 am
Personal rank: coffee addicted !!!
Location: Cologne, the city with the big cathedral.
Contact:

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by papercoffee »

Chamberly wrote:I use that UT-Logo-Map lol, got tired of city intro long ago.
UT Logo map? Rings a bell ... totally forgot about this.
Can you PM me where I can get it (and how I can exchange the Intro map with it)?
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA
Contact:

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Chamberly »

papercoffee wrote:
Chamberly wrote:I use that UT-Logo-Map lol, got tired of city intro long ago.
UT Logo map? Rings a bell ... totally forgot about this.
Can you PM me where I can get it (and how I can exchange the Intro map with it)?
Done.

Edit:
Was chatting to someone about their server commandline and it have the same interface as mine.
Referring to this: viewtopic.php?f=15&t=6134
Spoiler
Image
So here is an interesting question about this. Some server host do not have an option for you to use allow custom commandline so you can add another gametype to start up with. I guess this is why some peoples are using another tool such as ActorCLP(?) or simply having a mapvote in so the other gametype can be voted by mapvote.

Anyway, I went ahead and started my server up like this. This is what I got in return:

Code: Select all

XC_Engine: Browse() Start: unreal  7777
Log: Browse: Index.unr?Name=Player?Class=Botpack.TMale2?team=0?skin=SoldierSkins.blkt?Face=SoldierSkins.Othello?game=Botpack.Assault?mutator=CacusMapVote.CacusMapVote
XC_Engine: LoadMap intercept begin...
Log: LoadMap: Index.unr?Name=Player?Class=Botpack.TMale2?team=0?skin=SoldierSkins.blkt?Face=SoldierSkins.Othello?game=Botpack.Assault?mutator=CacusMapVote.CacusMapVote
Warning: Failed to load 'Index.unr': Can't find file 'Index.unr'
Warning: Failed to load 'Level None.MyLevel': Can't find file 'Index.unr'
XC_Engine: Browse() End
Critical: appError called:
Critical: Failed to enter ?game=Botpack.Assault?mutator=CacusMapVote.CacusMapVote: Can't find file 'Index.unr'
Exit: Executing UObject::StaticShutdownAfterError
Critical: UGameEngine::Init
Critical: UXC_GameEngine::Init
Critical: UServerCommandlet::Main
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 01/29/15 05:07:33
What exactly call Index.unr? I haven't done a test with a batch to see if it's UT doing it or my server host, my guess is UT. But either way, I would probably suggest an implement to allow the engine (if possible?) to randomly select a map for the gametype if none are defined. It should help shave off any extra needy mod for those who been waiting for it I guess.
Spoiler
Image :loool:
Edit again:
It's actually from UT that call Index.unr. My guess matched.
Spoiler
Image
Image
Image
Image Edit: Why does my sig not work anymore?
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Why do you people call null files and cry later? Log speaks everything... In Windows, at home, things can be managed so easy...
All these are in Server.INI or UnrealTournament.INI depending on run-line declaration. It's a pity.
Won't hurt using INI to call game
  • [URL]
    Protocol=unreal
    ProtocolDescription=Unreal Protocol
    Name=SrvOwn
    Map=CTF-Face-SE_R14.unr
    LocalMap=CTF-Face-SE_R14.unr
    Host=
    Portal=
    MapExt=unr
    SaveExt=usa
    Port=7777
    Class=Botpack.TMale1

    [FirstRun]
    FirstRun=436

    [PackageRemap]
    UnrealShare=UnrealI

    [Engine.Engine]
    GameRenderDevice=SoftDrv.SoftwareRenderDevice
    AudioDevice=Galaxy.GalaxyAudioSubsystem
    NetworkDevice=IpDrv.TcpNetDriver
    DemoRecordingDevice=Engine.DemoRecDriver
    Console=UTMenu.UTConsole
    Language=int
    ;GameEngine=Engine.GameEngine
    GameEngine=XC_Engine.XC_GameEngine
    EditorEngine=Editor.EditorEngine
    WindowedRenderDevice=SoftDrv.SoftwareRenderDevice
    RenderDevice=GlideDrv.GlideRenderDevice
    DefaultGame=NsCTF3.CTFGame
    DefaultServerGame=NsCTF3.CTFGame
    ViewportManager=WinDrv.WindowsClient
    Render=Render.Render
    Input=Engine.Input
    Canvas=Engine.Canvas
    ....
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA
Contact:

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Chamberly »

sektor2111 wrote:Why do you people call null files and cry later?
There is no crying. None. I was just trying it out. I thought it was kind of interesting. Why even attack like this?
I forgot all about the local map being called from the ini tho. LOL.
Image
Image
Image Edit: Why does my sig not work anymore?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Higor »

Test 2 changelog:
- Fixed the crash on game startup by detecting the ?entry URL command.
- Removed CylCylLineHit function.
- Instead use UPrimitive's LineCheck for cylinder collisions.
- Replaced LineHitsBox checks with a slab method raycast system (branchless after quick X,Y,Z rejections).
- InsertActor, FastRemoveActor methods are now faster and allow adding actors outside of the ZERO node (safe, no actor is left out).
- FCollisionCacus::ActorLineCheck optimized when 1 or 0 hit detected.
- Created PEncroachQuery on FCollisionOctree for faster Actor<->Actor encroachment checks.
- FCollisionCacus::ActorEncroachmentCheck now only doeas Actor<->Actor encroachment checks if said actors have bBlockActors or bBlockPlayers (and not bStatic).
- Child octree nodes now need to be empty for 255 ticks before deletion (should reduce allocation/deallocation instances).

Results:
Projectile overhead reduced by 50%.
Line check overhead reduced by ~25% (still not as fast as the old hash).

Ideas:
- Dynamizing the ZERO node's size, by measuring all substractive brushes's boxes and making a huge box containing substractive geometry.
This should make the main octree a bit smaller and speedup the line checks, also actors on vector(0,0,0) would no longer end up counting as ZERO node actors, preventing them from being checked on every single trace.
- Indexing every single node and storing in actor's CollisionTag their octree index for faster encroachment queries and actor removal.
- Caching the last removed actor in case it's a simple move and allow it to be readded without extra checks.
Attachments
XC_Engine_octree_test2.7z
(51.46 KiB) Downloaded 78 times
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Chamberly wrote: I thought it was kind of interesting. Why even attack like this?
What attack? I thought an admin is reading a manual first - Internet is a good library. Is not a need to go Off-Topic with a sort of 0 problem as long as Higor is waiting valid feedback for improving XC_Engine.

There, in case of missing a file called, might be good a nice shut-down rather than a lot of critical messages as long as firsts lines already shows the nasty thing happening.

Higor, if a stable collision deal leads to a tiny performance lost, to be honest I prefer server alive rather than a crash. Or a hint ? Trying to speed up other things in order to make things faster?
How works "foreach AllActors" ? I want to know what is the best to be used in UScript codes.

Edit:
I see changes into collisions. Hm, interesting in a way. You can teleport into an enemy using Translocator (Bot , Monster) without problem, and you can make pieces such enemy when you teleport outside of their body - indeed only if Bot is enemy and simple Monster of any kind. It looks like a kind of reversed functionality - I'm not sure if this was in purpose but I'm not disturbed by this new deal, enemy monster will hack an enemy so telefrag kill might be reduced. I'm curious how is acting Bot because in certain moment Bot tends to use Translocator to frag enemy, probably this time will fail to frag enemy.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Higor »

AllActors iterates the callee's XLevel->Actors; (TArray<AActor*>).
It can be slow, which is why I had FerBotz use different ones on the native branch.
Hash iterators are usually the fasterst, provided you specify a radius under 3000 or something.


Current working iterators I know, all perform !bDeleteMe and Actor->IsA(InClass) checks

[AllActors] Iterates XLevel->Actors, extre native checks done in it:
--- Actor->Tag == InTag (if specified)

[BasedActors] Iterates XLevel->Actors:
--- Actor->Base == InBase

[ChildActors] Iterates XLevel->Actors:
--- Actor->Owner == this

[TouchingActors] Iterates Actors.Touching[4]

[RadiusActors] Iterates XLevel->Actors:
--- If Loc isn't parsed, it defaults to this->Location
--- (Actor->Location - Loc).Size() + Actor->CollisionRadius <= InRadius

[TraceActors] Queries the FCollisionHashBase attached to the XLevel via XLevel->LineCheck once, then present the results as a loop.
At least that's how I think it works, otherwise it'd be stupidly inefficient, right?

[VisibleActors] Iterates XLevel->Actors:
--- FCheckResult Hit(1.f); >>>> hitlocation, hitnormal, first hit actor are stored here
--- XLevel->SingleLineCheck( Hit, NULL, Location, Actors(i)->Location, TRACE_Level, OptExtent)

[VisibleCollidingActors] Iterates through Result=XLevel->Hash->ActorRadiusCheck( GMem, InLocation, InRadius, ExtraNodeFlags ); chained results
--- for (FCheckResult* Link=Result ; Link ; Link=Link->GetNext() )
--- HitResult = XLevel->SingleLineCheck( Hit, NULL, Location, Actors(i)->Location, TRACE_Level, OptExtent)
--- for (FCheckResult* HitLink=HitResult ; HitLink ; HitLink = HitLink->GetNext() )
--- HitLink->Actor = Result->Actor
------ In short, query hash for radius actors, trace a line to them, check hit list to see if actor was hit.
[ZoneInfo.ZoneActors] Iterates XLevel->Actors:
--- Actor.IsInZone( this)

[sdkActor.DynamicActors] Iterates XLevel->Actors starting from iFirstDynamicActor:
--- !Actor->bStatic
--- Actor->Tag == InTag (if specified)

[sdkActor.CollidingActors] Iterates through XLevel->Hash->ActorRadiusCheck( GMem, InLocation, InRadius, ExtraNodeFlags ); chained results

[sdkActor.AllObjects] Object list iterator.

[sdkZoneInfo.ZonePawns] Iterates through Level->PawnList (APawn* P), P* = P->nextPawn
--- P->IsInZone( this)

(The Inventory based iterators from UT Community SDK had a bugged functionality last time I checked gotta check them again next release)


[Botz.NavigationActors] Iterates through Level->NavigationPointList (ANavigationPoint* CurNav), CurNav* = CurNav->nextNavigationPoint;
--- OptLoc defaults to calling Botz's location if not specified.
--- if (OptDist > 0) --- OptDist = OptDist*OptDist --- (CurNav->Location - OptLoc).SizeSquared() <= OptDist
--- if ( bTrace ) --- FCheckResult* Hit --- XLevel->SingleLineCheck( Hit, NULL, OptLoc, CurNav->Location, TRACE_Level, FVector(0,0,0))

[Botz.PawnActors] Iterates through Level->PawnList (APawn* P), P* = P->nextPawn
--- OptLoc defaults to calling Botz's location if not specified.
--- if (OptDist > 0) --- OptDist = OptDist*OptDist --- (P->Location - OptLoc).SizeSquared() <= OptDist
--- if (bPRI) --- P->PlayerReplicationInfo


Special mention:
SetPropertyText() loops the entire object list and catches the first object of matching name, putting it on the specified property.
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

I copied previous post, thanks.

So SetPropertyText() is fast ? I guess if scans only an object not multiple might be good. Or string deal it's slower ?
SC]-[WARTZ_{HoF}
Adept
Posts: 426
Joined: Tue Feb 21, 2012 7:29 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by SC]-[WARTZ_{HoF} »

How does this XC_GameEngine handle MH maps that have custom weapons?
Image
Image
Image
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA
Contact:

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Chamberly »

I'm gonna say it seem to be pretty fine, I've added a few maps with custom weapons and have np so far.
Image
Image
Image Edit: Why does my sig not work anymore?
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

SC]-[LONG_{HoF} wrote:How does this XC_GameEngine handle MH maps that have custom weapons?
Assuming those custom weapons aren't something bugged it might work fine.
Higor wrote:[TouchingActors] Iterates Actors.Touching[4]
Lol, I think I have another idea in trying to fix left-over opened "TriggerControl" doors by monsters killed in range. This issue previously was one of my homework to be fixed - and it wasn't really fixed only loved a bit.
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Btw, because I spoke about touching. I got a kind of very interesting deal:

Code: Select all

DevNet: Connection timed out after 15.000000 seconds (15.016217)
NetComeGo: Close TcpipConnection6 02/03/15 22:00:16
Warning: Other object in slot
Warning: This is: Tentacle MH-Miam.Tentacle35
Warning: Other is: Class Engine.NetPendingLevel
Critical: appError called:
Critical: Assertion failed: Actor->Touching[i]->IsValid() [File:G:\dev\nacput\Utpg_451\Engine\Src\UnActor.cpp] [Line: 1140]
Critical: Windows GetLastError: A non-blocking socket operation could not be completed immediately. (10035)
Exit: Executing UObject::StaticShutdownAfterError
Critical: TouchTo
Critical: AActor::BeginTouch
Critical: ULevel::MoveActor
Critical: AActor::physProjectile
Critical: AActor::performPhysics
Critical: AActor::Tick
Critical: TickAllActors
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, 02/03/15 22:06:43
It crashed after 6 minutes in a nice moment of battling. I think I'll forget that a$$ called v451. If UCC is freezing, UT.exe is crashing claiming a lazy socket operation or such... :noidea
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by Higor »

From UnrealEngine 3:

Code: Select all

UBOOL UObject::IsValid()
{
	if( !this )
	{
		debugf( NAME_Warning, TEXT("NULL object") );
		return FALSE;
	}
	else if( !GObjObjects.IsValidIndex(GetIndex()) )
	{
		debugf( NAME_Warning, TEXT("Invalid object index %i"), GetIndex() );
		debugf( NAME_Warning, TEXT("This is: %s"), *GetFullName() );
		return FALSE;
	}
	else if( GObjObjects(GetIndex())==NULL )
	{
		debugf( NAME_Warning, TEXT("Empty slot") );
		debugf( NAME_Warning, TEXT("This is: %s"), *GetFullName() );
		return FALSE;
	}
	else if( GObjObjects(GetIndex())!=this )
	{
		debugf( NAME_Warning, TEXT("Other object in slot") );
		debugf( NAME_Warning, TEXT("This is: %s"), *GetFullName() );
		debugf( NAME_Warning, TEXT("Other is: %s"), *GObjObjects(GetIndex())->GetFullName() );
		return FALSE;
	}
	else return TRUE;
}
So...
We have a MH-Miam.Tentacle35 with an index X, but the core's object list has slot X occupied by Engine.NetPendingLevel.
Some explanations to what's going on here:
- New Object is created, initialized and added to the global object table.
-- If there's available indices, add to them (static TArray<INT> GObjAvailable; // Available object indices.)
-- Otherwise expand object table by 1, add to last.
If the error occurs at object creation, then there's obviously an issue with the GObjAvailable array, but check the following UE3 code:

Code: Select all

// UObject destructor.
//warning: Called at shutdown.
UObject::~UObject()
{
	SCOPE_CYCLE_COUNTER(STAT_DestroyObject);
	// Only in-place replace and garbage collection purge phase is allowed to delete UObjects.
	//@todo: enable again after linkers no longer throw from within constructor: check( GIsReplacingObject || GIsPurgingObject );

	// If not initialized, skip out.
	if( Index!=INDEX_NONE && GObjInitialized && !GIsCriticalError )
	{
		// Validate it.
		check(IsValid());
		// Destroy the object if necessary.
		ConditionalDestroy();
		GObjObjects(Index) = NULL;
		GObjAvailable.AddItem( Index );
	}
	// Free execution stack.
	if( StateFrame )
		delete StateFrame;
}
And this is the only way to add stuff to GObjAvailable, which occurs during garbage collection where the object is deleted.

So, either:
- Something's altering the Index of the first object.
- Something's altering the GObjAvailable table.
- The object table array got corrupted.
- Level switch's doing funky things.

Either way, all I can do on my side is to add a IsValid kind of check to all of the FCollisionOctree checks, at the expense of a little performance drop.
User avatar
sektor2111
Godlike
Posts: 6410
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_GameEngine [build 8 - Faster upload - MH related fixe

Post by sektor2111 »

Here might be indeed a Left-Over problem, crash after a travel, is not loaded first. I gotta admit I can feel a lag at a moment. Some action seems to happen out of sync with other related action. And this crash is randomly not in the same time in the same location. Also I guess contains textures with some custom resolution crap slowing down something. Probably it's time to remove that from map folder because in 436 seems to develop be the same kind of crash. Yeah, I was wonder if a sanity check wouldn't be recommended before to deal with a lost actor or... maybe twice. As I have seen, certain null ammo messages, pickups expired, etc. are shown twice more times. How many trash works twice wasting time with 0 deals in this stupid Engine? Maybe Ferali was pretty wise in his decision to leave. There are older games with a superior engine - I really cannot recall any crash from MK3 and of course I don't have amnesia yet.

Mention: I was trying to rebuild that map and... amazingly if initial map had 20MB after my rebuild was 16MB being the same thing in game and developing the same crash, for sure there is a brush-soup combined with a bad texture doing sucks in there.
Post Reply