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

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

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by Chamberly »

Higor wrote:Thoughts on JPG screenshotting?
Just throwing ideas.
I prefer PNG.

True, PNG may not be the lowest in size.. but the quality can count.

Tinypic upload: (The one I usually use because photobucket take longer to upload now that what it used to do long time ago.)
PNG: http://i61.tinypic.com/54xeyr.jpg
JPG: http://i59.tinypic.com/1zzjkzk.jpg

Photobucket upload... same result.
Last edited by Chamberly on Mon Jul 20, 2015 11:34 am, edited 1 time in total.
Image
Image
Image Edit: Why does my sig not work anymore?
User avatar
sektor2111
Godlike
Posts: 6418
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by sektor2111 »

At 10% compression with 600 dpi an image in format JPG is compressed smaller and faster than PNG.
Initially had 2,359,350 bytes in bmp, saving it in JPG using Paint it was 52,352 bytes and then with fore-mentioned compression has 91,110 bytes.
PNG saved by Paint = 684,025 bytes and using other application was 555,383 bytes. I don't speak about speed - it's not faster and will lag game during screenshot-ing. Give me at least one good reason for using PNG format.
____
Later I hit key <A> and I got my country on screen...
RocketJedi
Inhuman
Posts: 850
Joined: Wed Mar 12, 2008 7:14 pm
Personal rank: I.T Master
Location: New York
Contact:

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by RocketJedi »

couple other issues with xc engine (sure its due to bad coding in the mods not XC) but rocketx3 and slv2 -slv205 cant pick up flags when xc is enabled.
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
User avatar
sektor2111
Godlike
Posts: 6418
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by sektor2111 »

After solving these...
- mmm maybe a featured internal capture technology (configurable frame-rate, configurable compression type and quality, etc.
- I'll be grateful for a few info related to PHYS_Spider or such PHYS_Trailer because it looks like have small functional fragments - I was checking the deal when I saw those old problems at "adminlogin" and I forgot what I was intended to ask in that time. Short time I could walk on a wall and Bot was running like a crocodile... amazingly not crashed or dumping any error. Eh ?
Mar
Novice
Posts: 26
Joined: Tue Aug 27, 2013 1:04 am

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by Mar »

Qwerty wrote:couple other issues with xc engine (sure its due to bad coding in the mods not XC) but rocketx3 and slv2 -slv205 cant pick up flags when xc is enabled.
I can confirm this, looks like the Collision Octree ignores players with physics set to "PHYS_None" which SLV2 use.

Code: Select all

simulated function updateRider(Pawn p, RiderInfo info, Vector loc) {
	local EPhysics phys;

	if (level.netMode == NM_Standalone || level.netMode == NM_ListenServer && u.hasViewPort(p)) {
		phys = PHYS_Walking;
	} else {
		phys = PHYS_None;
	}

	info.lastLoc = p.location;
	p.setLocation(loc);
	p.velocity = velocity;
	updateTrailers(p, info);
	p.setPhysics(phys);
}
To temporary solve it, you need to turn off the Collision Octree.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by Higor »

Alright!
I see what's up.
We've got the sloppiest player transport code being transferred from old Fighters into the new RX's and SLV.
The modder has two choices:
- Let the player touch objects directly, use Move() instead of SetLocation().
- Transfer touch/bump events from the carrier into the player, use SetLocation and disable all player collision.

Both mod and XC_Engine are at fault here, now given that SetLocation is what is being used... it's safe to assume that the 'Hash' query used is 'Encroachment'.
My 'gridded octree' is open sourced, everyone can check it out.
These are the queries inherited from FCollisionHashBase type into FCollisionCacus.

Code: Select all

	FCheckResult* ActorLineCheck( FMemStack& Mem, FVector End, FVector Start, FVector Extent, BYTE ExtraNodeFlags );
	FCheckResult* ActorPointCheck( FMemStack& Mem, FVector Location, FVector Extent, DWORD ExtraNodeFlags );
	FCheckResult* ActorRadiusCheck( FMemStack& Mem, FVector Location, FLOAT Radius, DWORD ExtraNodeFlags );
	FCheckResult* ActorEncroachmentCheck( FMemStack& Mem, AActor* Actor, FVector Location, FRotator Rotation, DWORD ExtraNodeFlags );
Movement code does ActorLineCheck with an extent, then ActorEncroachmentCheck in most cases to process overlapping.
Strangely enough, teleporting doesn't use preemptive ActorPointCheck against other actors, but goes straight to ActorEncroachmentCheck. Makes sense, because if ActorPointCheck was used, then it would be impossible to teleport into other players using a translocator (players would be solid and negate ability to occupy said space).

I added a lot of conditionals to my variation of ActorEncroachmentCheck to speed it up, because some of UT's default methods were very CPU inefficient, I may have overdone it...
Let's take a look:

Code: Select all

FCheckResult* FCollisionCacus::ActorEncroachmentCheck( FMemStack& Mem, AActor* Actor, FVector Location, FRotator Rotation, DWORD ExtraNodeFlags )
{
	if ( BrushMover(Actor) )
	{
		Exchange( Actor->Location, Location);
		FBox Box = Actor->Brush->GetCollisionBoundingBox( Actor);

		FCheckResult* Result = MEncroachQuery( Mem, Actor, Box);
		Exchange( Actor->Location, Location);
		return Result;
	}
	else if ( Actor->bBlockPlayers || Actor->bBlockActors )
	{
		const FBox ActorBox( Location-Actor->GetCylinderExtent(), Location+Actor->GetCylinderExtent() );
		if ( Actor->bIsPawn && Actor->GetPlayerPawn() )
			return PEncroachQuery( Mem, Actor, Location, ActorBox);
		return AEncroachQuery( Mem, Actor, Location, ActorBox);
	}
	return NULL;
}
I assume SLV and RX don't remove the bBlockPlayers and bBlockActors from player, but I could totally be wrong.
PEncroachQuery looks like the type of query we'd be using...

Code: Select all

//Recursive actor iteration
//Obtains actors touching a player (future loc)
FCheckResult* FCollisionOctree::PEncroachQuery( FMemStack& Mem, AActor* Actor, const FVector& Location, const FBox& ActorBox, FCheckResult* PrevLink)
{
	for ( INT i=0 ; i<Actors.Num() ; i++ )
	{
		if ( !Actors(i).Actor->bBlockPlayers || !BoxBoxIntersect( ActorBox, Actors(i).Box) ) //Quick box rejects, we don't need to perform Z check later
			continue;
		AActor* TestActor = Actors(i).Actor;
		if ( Actor == TestActor )
			continue;
		if ( (FVector(Location.X-Actors(i).Location.X,Location.Y-Actors(i).Location.Y,0.f).SizeSquared2D() < Square( Actor->CollisionRadius+TestActor->CollisionRadius))  )
		{
			PrevLink = new(Mem)FCheckResult( 0.f, PrevLink);
			PrevLink->Actor = TestActor;
			PrevLink->Location = Actors(i).Location;
		}
	}
	for ( i=0 ; i<ChildCount ; i++ )
		if ( BoxBoxIntersect( ActorBox, ReducedChildren[i]->BoundingBox) )
			PrevLink = ReducedChildren[i]->PEncroachQuery( Mem, Actor, Location, ActorBox, PrevLink);
	return PrevLink;
}
Ok here we have it, the target actors also require to have bBlockPlayers.
This means that my octree is completely ignoring touch-on-teleport when the target actor isn't blocking the source actor.
This also means that UT is using EncroachmentQuery for both encroachment and touch-on-teleport events, very different things by the same function... which isn't supposed to do the latter anyways (ActorPointCheck should do this).

The solution will be to simply consider all non-blocking target actors as encroachment candidates.
User avatar
sektor2111
Godlike
Posts: 6418
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by sektor2111 »

The way how you made new collision deal works for me so cute, however at a moment Bot doesn't recover Flag so well using Translocator but mainly works. This doesn't really disturb me, I prefer this new collision deal rather than old crashes. Maybe in some free time I'll try to recreate old crashes modifying spawners (like in older versions trouble makers). Or maybe is a waste of time as long as new octree seems a stable work.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by Higor »

This is my Warzone clusterfuck tester, all I do is load my CTF-Warzone.unr map and execute this batch

Code: Select all

mutate addbotzfaction XC_Force 8 1
mutate addbotzfaction Thunder_crash 14 0
mutate addbotzfaction The_Corrupt 11 0
mutate addbotzfaction Iron_Guard 10 0
mutate addbotzfaction Dark_Phalanx 14 1
mutate addbotzfaction Blood_Reavers 16 1
mutate addbotz _ 0
mutate addbotz _ 0
mutate addbotz _ 0
stat global
showlog
You're guaranteed a crash in less than 30 minutes if you're not using the octree.
I think I'll do a XC_Core update altogether XC_Engine for next release, there's lots of generic stuff added to XC_Engine that's better off in XC_Core.
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA
Contact:

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by Chamberly »

Hehehe I remember when someone joined the server and said, that's a lot of botz! :mrgreen:
Image
Image
Image Edit: Why does my sig not work anymore?
RocketJedi
Inhuman
Posts: 850
Joined: Wed Mar 12, 2008 7:14 pm
Personal rank: I.T Master
Location: New York
Contact:

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by RocketJedi »

i've also noticed on a few maps you can grab flags, and weapons before match start any thoughts?
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_Engine [14b] - XC_Core [1] - LZMA dec

Post by Higor »

Because you're running a 'greatly coded' mod that makes players have collision before match start.

==========
One thing I'm considering:

Protect a set of properties in some classes (ex: Texture), if said properties are changed you won't be able to join any server until the game is restarted or the property is reset.
This would in some way be a basic antitweaking measure that exists in newer Unreal Engine games.
RocketJedi
Inhuman
Posts: 850
Joined: Wed Mar 12, 2008 7:14 pm
Personal rank: I.T Master
Location: New York
Contact:

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by RocketJedi »

thanks for responding :)
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_Engine [14b] - XC_Core [1] - LZMA dec

Post by Higor »

In the meantime I'll be merging UBinary into XC_Core with an additional feature:
- Raw text writing/reading (UTF8) so it can be used to properly replace the StatLogFile implementations.

Other features I'm thinking of is creating a variation of the script parser so that it exports extra text into the c++ header of a native class (equivalent to _cpptext).
User avatar
sektor2111
Godlike
Posts: 6418
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by sektor2111 »

Dude, what I could see seems to be true. The way in how a pawn is finding a path I'm sure about that is absolute wrong.
I was playing in a map with that so called issue "1000 Navigation nodes .... bla bla".
It happens in unusual occurrences. When Bot is moving normally actually we don't have anything. Message occurs when pawn has invalid physics for seeking Network - example is falling away, is getting a strong hit. I'm very convinced that it is simply checking out of any nearby visible node which is a nonsense, else how the heck is passing over 1000 Nodes. Pawn cannot have 1000 Nodes reachable - Why we have tested nodes Unreachable if are considered a possible valid Path Actor if doesn't have any SpecialCost ? Lift considerations ? This need for sure a clamp else this so called "Expensive" cost is very stupid coded, Pawn is checking for a path in All Network if physics are not good for that movement, LOL which is dumbness.

I cannot be sure if I can stop useless processing VIA Uscript. If Pawn is in state "Falling" or such physics being unable to find a reachable Path-Actor it should return NONE rather than bullshitting entire Network. That's why was described expensive the cost to reach into network, in fact is just another trash code similar to PlayerCanSeeMe().

Please tell me a way to prevent stupid processes if you cannot hook these garbage "seekers".

Edit: Yup, by preventing Bot to seek paths while is falling or doesn't include any physics that warn spam is reduced. I got only 15-20 lines in 30-40 minutes of game-play... Let me guess, the rest of occurrences are coming from... Monsters...
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [14b] - XC_Core [1] - LZMA dec

Post by Higor »

Replication checks can now run in separate threads, up to 50% less time on relevancy checks using a single separate thread... now I hit a funny wall here, with asyncronous data access and writing the whole replication is 'barely' stable.
I think I should directly do a 'hard-copy' of some UE4 features regarding multithreading.
Post Reply