Page 18 of 72

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Thu Mar 19, 2015 3:57 pm
by sektor2111
Is this 10.1? Haven't seen this yet. I guess you have to disable it until gets fixed bAutoTravelManager=False

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Thu Mar 19, 2015 7:23 pm
by RocketJedi
build 10 wont work on our Rocket x server or our MH server. thanks for the info. I didn't even think to add that to the ini

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Thu Mar 19, 2015 10:18 pm
by SC]-[WARTZ_{HoF}
Qwerty wrote:build 10 wont work on our Rocket x server or our MH server. thanks for the info. I didn't even think to add that to the ini
I haven't had any issues with version 10 with my DM server but MH clients reported the server was a bit too laggy so I uninstalled it from MH servers.

P.S. All our game servers are windows based except one CSGO gameserver.

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Fri Mar 20, 2015 2:54 pm
by RocketJedi
SC]-[LONG_{HoF} wrote:
Qwerty wrote:build 10 wont work on our Rocket x server or our MH server. thanks for the info. I didn't even think to add that to the ini
I haven't had any issues with version 10 with my DM server but MH clients reported the server was a bit too laggy so I uninstalled it from MH servers.

P.S. All our game servers are windows based except one CSGO gameserver.
yeah ours are on windows as well. we are on version 9 for now on all servers.

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Sat Mar 21, 2015 3:22 pm
by sektor2111
Guys, I'm sorry to hear you in fallback at v9 because for me this extension is better than no extension. I was testing a few tens minutes a couple of MH games running MH 5.04 + Mutator to manage a few things, osPower relic mutator, MBot, IpTocountry, Lag-kicker, custom mapvote and... conclusions:
- performance in smaller maps is a bit affected but not so bad to cause real troubles;
- performance in maps loaded seems better than running original engine;
- drop pickup seems a bit lagged on screen but without to disturb significantly.

In other case, a few "default" matches using creatures were a total charm. From me, XC_Engine seems a must have in Win servers.

Don't expect me to speak about whatever Ix core server it's just PentiumD at 2800 MHz using v436 (not 451 any) fired by a launcher in "above normal" priority using both cores.

Let me put a drink into my glass for Higor because... I started posting posts here because of this work, even I've been here from 2010. If I'll see a crash after 30 games this is not the end of world, simply maps need revised and done according to default rules.

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Sat Mar 21, 2015 8:59 pm
by Higor
Doing some progress at finding out how actors are replicated... in the meantime gonna share something you might find interesting:

The hardcoded update rate on Inventory types:

Code: Select all

FLOAT AInventory::UpdateFrequency(AActor *Viewer, FVector &ViewDir, FVector &ViewPos)
{
	if ( bHidden && Owner )
	{
		if ( Owner->IsA( APawn::StaticClass()) )
		{
			if ( ((APawn*)Owner)->Weapon != this )
				return NetUpdateFrequency <= 4.0f ? NetUpdateFrequency : 4.0f;
			return (Owner == Viewer || NetUpdateFrequency <= 10.0f) ? NetUpdateFrequency : 10.0f;
		}
	}
	return NetUpdateFrequency;
}

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Sat Mar 21, 2015 9:50 pm
by sektor2111
After my poor understanding I can translate for me previous code as follows:
If that thing is stuff hidden owned by a Pawn (maybe weapon unused in that moment), if that thing has a NetFrequency smaller or equal with value 4 then set value 4. If can be seen and frequency is smaller or equal with 10 then put it 10.
Is my understanding correct ?

I'll check a bit Inventory class to see how reacts in UScript...

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Sat Mar 21, 2015 10:21 pm
by Higor
This should be better.

Code: Select all

FLOAT AInventory::UpdateFrequency(AActor *Viewer, FVector &ViewDir, FVector &ViewPos)
{
	//Limit frequency on hidden, held items not belonging to the player we're replicating to:
	// 10 if it's the main weapon
	// 4 if not the main weapon (this case occurs when you spectate another player)
	if ( bHidden && Owner
	&& Owner->IsA( APawn::StaticClass()) )
	{
		if ( ((APawn*)Owner)->Weapon != this )
			return NetUpdateFrequency <= 4.0f ? NetUpdateFrequency : 4.0f;
		return (Owner == Viewer || NetUpdateFrequency <= 10.0f) ? NetUpdateFrequency : 10.0f;
	}
	return NetUpdateFrequency;
}
Also, same for Actor base class.
This kinda applies more to projectiles...

Code: Select all

FLOAT AActor::UpdateFrequency(AActor *Viewer, FVector &ViewDir, FVector &ViewPos);
{
	//Limit frequency (max 8hz) on bNetTemporary actors positioned far away or behind the player
	if ( bNetTemporary && !bNetOptional 
	&& ( GetDefaultActor( GetClass())->LifeSpan - 0.2f > LifeSpan )
	&& ( ((Location-ViewPos).SizeSquared() > 1000000.f) || ((Location-ViewPos) | ViewDir < 0)) )
	{
		return NetUpdateFrequency <= 8.f ? NetUpdateFrequency : 8.f;
	}
	return NetUpdateFrequency;
}
Carcass also has a variant of this function, but I won't bother looking at it.

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Mon Mar 23, 2015 7:33 am
by sektor2111
I wanna know something mysterious if you can see that "secret".

What or how reacts native function "FindBestInventoryPath" ? I found something in Bot's state roaming which I don't like at all. Looks like there are chances to see Bot very busy with inventories and won't ever hunt player in certain environment, neither in OneOnOne case - even if map is super extra pathed correctly - it looks like doesn't help if is a big huge giant one, LOL :confused2: .

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Mon Mar 23, 2015 2:44 pm
by RocketJedi
sektor2111 wrote:Guys, I'm sorry to hear you in fallback at v9 because for me this extension is better than no extension. I was testing a few tens minutes a couple of MH games running MH 5.04 + Mutator to manage a few things, osPower relic mutator, MBot, IpTocountry, Lag-kicker, custom mapvote and... conclusions:
- performance in smaller maps is a bit affected but not so bad to cause real troubles;
- performance in maps loaded seems better than running original engine;
- drop pickup seems a bit lagged on screen but without to disturb significantly.

In other case, a few "default" matches using creatures were a total charm. From me, XC_Engine seems a must have in Win servers.

Don't expect me to speak about whatever Ix core server it's just PentiumD at 2800 MHz using v436 (not 451 any) fired by a launcher in "above normal" priority using both cores.

Let me put a drink into my glass for Higor because... I started posting posts here because of this work, even I've been here from 2010. If I'll see a crash after 30 games this is not the end of world, simply maps need revised and done according to default rules.
I'm going to try v10 again today. I agree a lot of MH maps are done horribly wrong.

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Mon Mar 23, 2015 4:16 pm
by RocketJedi
Good to go! Version 10 on MH and Rx8 I had to use the incremental update 10.1 on RX to get rid of the crash I mentioned earlier with travel manager off as recommended earlier

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Tue Mar 24, 2015 12:35 am
by RocketJedi
Critical: FCollisionHash::ActorLineCheck
Critical: CheckWithActors
Critical: ULevel::MultiLineCheck
Critical: ULevel::MoveActor
Critical: APawn::Swim
Critical: APawn::physSwimming
Critical: APawn::performPhysics
Critical: UObject::ProcessEvent
Critical: (ALplayer CTF-(VIP)AA.ALplayer1, Function Engine.PlayerPawn.ServerMove)
Critical: RemoteCall
Critical: HandleStream
Critical: UActorChannel::ReceivedBunch
Critical: (Actor ALplayer1)
Critical: UChannel::ReceivedSequencedBunch
Critical: Direct
Critical: UChannel::ReceivedRawBunch
Critical: DispatchDataToChannel
Critical: BunchData
Critical: UNetConnection::ReceivedPacket
Critical: UNetConnection::ReceivedRawPacket
Critical: UTcpNetDriver::TickDispatch
Critical: UpdatePreNet
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, 03/23/15 19:29:55

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Tue Mar 24, 2015 1:14 am
by Chamberly
Was this error happened from a specific map or so? Could use some detail information.

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Tue Mar 24, 2015 2:58 am
by RocketJedi
sorry I thought u saw the map name in the log. its a map called CTF-(VIP)AA

Re: XC_GameEngine [build 10] [10.1 hotfix]

Posted: Tue Mar 24, 2015 4:20 am
by Higor
Critical: FCollisionHash::ActorLineCheck
XC_GameEngine replaces the FCollisionHash object with a FCollisionCacus octree, for this same reason.
Try this option: bCollisionHashHook=True, be aware that some underwater teleporters may behave unexpectedly due to the traces' behaviour not 100% properly emulated.

EDIT:

Code: Select all

		GNatives[3552] = (Native)&AXC_DummyPawn::execCollidingActors;
Since we're talking about the collision hash/octree, some of you may recognize this function from newer UE versions or UT Community SDK.
Gonna start using it with Siege once I release version 11.

Code: Select all

void AXC_DummyPawn::execCollidingActors( FFrame& Stack, RESULT_DECL )
{
	P_GET_OBJECT(UClass,BaseClass);
	P_GET_ACTOR_REF(OutActor);
	P_GET_FLOAT(Radius);
	P_GET_VECTOR_OPTX(TraceLocation,Location);
	P_FINISH;

	BaseClass = BaseClass ? BaseClass : AActor::StaticClass();
	FMemMark Mark(GMem);
	FIteratorActorList* Link=GetLevel()->Hash->ActorRadiusCheck( GMem, TraceLocation, Radius, 0 );

	PRE_ITERATOR;
		*OutActor = NULL;
		if ( Link )
		{
			while ( Link )
			{	//Actors can be de-collided or killed during the iterator, perform (almost) all checks!
				if( !Link->Actor || Link->Actor->bDeleteMe || Link->Actor->bCollideActors || !Link->Actor->IsA(BaseClass) )
					Link=Link->GetNext();
				else
					break;
			}
			if ( Link )
			{
				*OutActor = Link->Actor;
				Link=Link->GetNext();
			}
		}
		if ( *OutActor == NULL ) 
		{
			Stack.Code = &Stack.Node->Script(wEndOffset + 1);
			break;
		}
	POST_ITERATOR;
	Mark.Pop();
}