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

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

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

Woow, Higor :shock: :shock: :shock: ! You are the Man Of The Year !
Finally idiots are getting Redeemer because you have created a path between Teleporter and nearest InventorySpot, else I have to look carefully at Bots (or MBots ), it do seems like they cannot jump with JumpBoots around miniammo, I'm gonna look where issue is coming from... Last time I saw that it was functional.
Edit: Default Bot seems to jump forever in Deck16][ like it has unlimited jumps... even failed shield a few times jumping over it (single Bot spectated) - probably random timing bug.
Edit2: Yep... tiny correction at MBot, it uses properly 3 jumps to get in upper area, it do looks good now.
Edit3:
Now I'm interested in doing some pathing mutator but probably files (attached modules) are going to be U packages, probably a harder job... eh, something with dynamic load "outer.lulupather" etc. then pathnode child, hmm, I gotta learn pathing details but such tutorials probably don't exist... Anyway so far I see new things doable which is a nice step forward. I would like to see more people interested at these debates but maybe they are busy with other things.
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

I do ask some explanations toward my old problem >>

Code: Select all

class XC_PlayerPawn expands PlayerPawn abstract;

var private float LastPathTime;
var private bool bSaidPath;
...
exec function ShowPath()
{
	local Actor Node;
	CheckPath();
}
....
final function CheckPath()
{
	local Actor Node;
	local WayBeacon W, W1;
	local bool bHasBeacon;
/*
	if ( !bAdmin && (Level.NetMode != NM_Standalone) )
		return;
*/
	foreach ChildActors(class'WayBeacon',W)
	{
		W1 = W;
		bHasBeacon = True;
		break;
	}
	if ( LastPathTime + 7 > Level.TimeSeconds )
	{
		if ( !bSaidPath )
		{
			bSaidPath = True;
			if ( bHasBeacon )
				W1.Disable('Touch');
			ClientMessage("Spaming is not allowed... Retry after"@(LastPathTime+7)-Level.TimeSeconds@seconds...);
		}
		GoTo DoNothing;
	}
	else
	{
		if ( bHasBeacon )
			W1.Enable('Touch');
		bSaidPath = False;
		LastPathTime = Level.TimeSeconds;
	}
KeepGoing:
		if ( PointReachable ( Destination ))
		{
			ClientMessage("Destination is Reachable, look around for Lamp-Beacon...");
			if ( bHasBeacon )
			{
				if ( W1.Location != Destination )
					W1.SetLocation(Destination);
			}
			else
				W1 = Spawn(class 'WayBeacon', self, '',Destination);
		}
		else
		{
			Node = FindPathTo(Destination);
			if ( Node != None )
			{
				log(GetHumanName()@found path: $Node.Name);
				if ( bHasBeacon )
				{
					if ( W1.Location != Node.Location )
						W1.SetLocation( Node.Location );
				}
				else
					W1 = Spawn(class 'WayBeacon',self,'',Node.location);
				if (W1 != None)
				{
					if ( Node.Base != None )
						W1.SetBase(Node.Base);
					ClientMessage("Path Found - Look For Lamp-Beacon");
				}
			}
			else
			{
				ClientMessage("Could not find a Path to Destination Spot.");
				log(GetHumanName()@didn't find path.);
			}
		}
DoNothing:
}
I Removed code from XC stuff and I'm using only this one.

It is very operational, then I hit menu to start a tournament or restart map. It drives to End of game >>>
LogFile wrote:

Code: Select all

DevAudio: Galaxy SetViewport: WindowsViewport0
XC_Engine: NotifyLevelChange() begin...
ScriptLog: XC: Helper Win Created
ScriptLog: XC: LevelChange
XC_Engine: NotifyLevelChange() end
Critical: FMallocWindows::Free
Critical: FMallocWindows::Realloc
Critical: 42E7F346 0 FArray
Critical: FArray::Realloc
Critical: 0*2
Critical: FMallocWindows::Free
Critical: UObject::ExitProperties
Critical: (StrProperty Botpack.TournamentPlayer.spreenote)
Critical: UObject::Destroy
Critical: (TFemale1 MH-Akemi_vs_Tomoko_R16.TFemale2)
Critical: AActor::Destroy
Critical: UObject::ConditionalDestroy
Critical: (TFemale1 MH-Akemi_vs_Tomoko_R16.TFemale2)
Critical: ShutupSound
Critical: ULevel::DestroyActor
Critical: (TFemale1 MH-Akemi_vs_Tomoko_R16.TFemale2)
Critical: DissociateViewports
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ClientTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UOpenGLRenderDevice::ShutdownAfterError
Exit: Exiting.
Uninitialized: Name subsystem shut down
Uninitialized: Log file closed, 10/25/16 22:31:30
What do I do wrong here ?
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

The class is using global variables that are not present in the target playerpawn calling the function.

The variable LastPathTime has a certain offset, in this case, sizeof(APlayerpawn) + 0.
In the (for example) TMale2 class that's calling the function, that offset corresponds to a different variable.

One way to solve this, is to globalize all checks by instead accessing a memory region that's not mis-identified.
Basically, you share all the time checks (this affects all players instead) but you operate on an actual separate memory region that doesn't overlap with the player's own variables.

Code: Select all

Replace:
LastPathTime;
with
class'XC_PlayerPawn'.default.LastPathTime;
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

:rock: Now It do Works properly :tu: .
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

I see something wrong at chapter path tweaking, bringing into stage TranslocStart. It's probably more wrong than expected.

If by chance (and I could see this) Bot carrier is passing through such point will lose flag translocating discarding CTF directives by ignoring stupid bCanTranslocate boolean - that query would be more sane than bullshiting with Flag.
What we have in original:

Code: Select all

	if ( (B.MyTranslocator == None) || (B.MyTranslocator.TTarget != None) )
		return None;

	B.TranslocateToTarget(self);	
	return self;
and amazing default properties

Code: Select all

defaultproperties
{
     bSpecialCost=True
     bStatic=False
     bNoDelete=True
}
Excuse me, but I don't see any SpecialCost here defined even is supposed to have one ?
Else probably we need this but I don't know if we will cause a strange effect:

Code: Select all

	if ( /*(B.MyTranslocator == None) || (B.MyTranslocator.TTarget != None) ||*/ !B.bCanTranslocate)
		return None;

	B.TranslocateToTarget(self);	
	return self;
Or another friendly version:

Code: Select all

	if ( (B.MyTranslocator == None) || (B.MyTranslocator.TTarget != None) )
		return None;
	if (B.bCanTranslocate)
		B.TranslocateToTarget(self);	
	return self;
Pass through this LiftExit for another point in Path-Net than TranslocDest ? November and such...
These I don't think are the best without SpecialCost but for sure what we have is not the right thing, Bot losing Flag...
Edit:
Now it looks better (first method). By spectating a heavy match and being "overtime" at end of Level it seems to happen this - not sure how often but I saw it twice:

Code: Select all

Log: Collecting garbage
Log: Purging garbage
Critical: appError called:
Critical: Assertion failed: _Linker->ExportMap(_LinkerIndex)._Object==this [File:C:\UTDev\Core\Src\UnObj.cpp] [Line: 260]
Critical: Windows GetLastError: The operation completed successfully. (0)
Exit: Executing UObject::StaticShutdownAfterError
Exit: Executing UWindowsClient::ShutdownAfterError
Exit: UGalaxyAudioSubsystem::ShutdownAfterError
Log: DirectDraw End Mode
Exit: UOpenGLRenderDevice::ShutdownAfterError
Critical: UObject::SetLinker
Critical: (Palette SGirlSkins.Palette68)
Critical: UObject::Destroy
Critical: (Palette SGirlSkins.Palette68)
Critical: UObject::ConditionalDestroy
Critical: (Palette SGirlSkins.Palette68)
Critical: DispatchDestroy
Critical: (47900: Palette SGirlSkins.Palette68)
Critical: DispatchDestroys
Critical: UObject::PurgeGarbage
Critical: UObject::CollectGarbage
Critical: XCGE_Garbage
Critical: ExitLevel
Critical: UXC_GameEngine::LoadMap
Critical: LocalMapURL
Critical: UGameEngine::Browse
Critical: ServerTravel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: MainLoop
Exit: Exiting.
Resource which I study has a different structure nothing with "_Linker" in line 260, but it is above that... not sure if doesn't occur a call to Level which is removed (or... reloaded) it was a simple restart post game ended using the same map.
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

A random crash occurred today related to state change UObject::blablaState made me to put back TickFix because it looks like it does a good job as usual, now I have on screen tickrate in MH2 and I can see what's the deal with and without TickFix. Looks like has not very nice tick fluctuations and tickrate goes down at empty server (interesting) but switching from state to the same state I don't know if it needs to deliver a crash. Often Bot in "FallingState" calls again "FallingState" with no issues, but for preventing future "fast state cascading" I added a sleep at beginning of Master State "Attacking" for letting tick to breath a bit - this seems to not affect Bot reflexes noticeable. So I saw another occurrence when tick affected turns code execution in trash.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

You don't need TickFix or any timer fixes if you launch the server using XC_Server commandlet, as a matter of fact, tickrate is far better than anything other tools offer.

Some extra stuff to be seen in the release v19 build:
- Actor name resetter on clients. It's a workaround for non-servers to prevent ever-increasing memory usage and name hash complexity.
- Native functions that have an opcode number can now be replaced by (only) other native functions.
- Considering removing the 'same-variables' limitation on replacing replicated functions if they have no parameters, there shouldn't be any problems there.
** Example: CallForHelp()
- Expose to unrealscript the GetMapName and PlayerCanSeeMe fixes.
- Add a 'AllConnections' iterator
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

I'm using CallForHelp as it is - looks helpful, MBot is a Bot, but extended a bit.

So, PlayerCanSeeMe might have an Uscript alias working properly ? Wow, it sounds interesting.
I would like to see an alias for "CanMoveTo" if possible or an UScript translation in DOT or such - eh, my dreams... This one is used by "ActorReachable". Understanding it might help me in properly tweaking some stuff...

Iterator AllConnections - Can we attack Empty connections ? Not bad at all.

I'm still trying to figure a way in tracing nearby terrain like with human eye.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

PlayerCanSeeMe cannot be replaced with a non-native func, it has a numbered opcode.
I'd need a dummy wrapper in order to achieve that.

Expect another test build inbetween this and release.
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

Why this back-to at PlayerCanSeeMe ? It still did cause problems ? I did not see any crash since last fix.
Higor
Godlike
Posts: 1866
Joined: Sun Mar 04, 2012 6:47 pm

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

I intend to expose all of the function related behaviour to the function replacement system, excepting dynamic arrays due to being fully hardcoded in the compiler.
User avatar
Lee_Stricklin
Adept
Posts: 324
Joined: Tue Mar 11, 2008 4:49 am
Location: Midwest

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Lee_Stricklin »

I was told it's possible to use this to force mutators into the singleplayer ladder, but I'm confused as to how to actually do it. Can somebody please help me out with this? I'm really trying to get Nali Weapons 3 Gore Standalone to work in singleplayer.
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Chamberly »

Lee_Stricklin wrote:I was told it's possible to use this to force mutators into the singleplayer ladder, but I'm confused as to how to actually do it. Can somebody please help me out with this? I'm really trying to get Nali Weapons 3 Gore Standalone to work in singleplayer.
We already are working on 1 thread about this, don't need to spread it out making a mess.
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_Engine [18] - XC_Core [7] - XC_IpDrv

Post by Higor »

Beta changes:
* Partially moved AdminLogin hook to function replacement system.
* Moved GetWeapon hook to function replacement system.
* Replicated functions that take no parameters can be replaced.
* Native functions with an opcode number can be replaced (only with other native functions)
* Halfassed clientside name recycler (win32 only)

Function replacer actors can now be loaded on user demand.
Run the game at least once after installing this build and you'll see this new entry in XC_Engine.ini

Code: Select all

[XC_Engine.XC_Engine_Actor_CFG]
Description[0]=This list contains subclasses of XC_Engine.XC_Engine_Actor to be spawned
Description[1]=The main XC_Engine_Actor will call XC_Init() on these actors before InitGame()
Description[2]=The : symbol indicates that a certain package has to be loaded as condition
XCGE_Actors=Unreali:XC_Engine_UT99.XC_Engine_UT99_Actor
XCGE_Actors=s_SWAT:XC_Engine_TOs.XC_Engine_TOs_Actor
You do not have the required permissions to view the files attached to this post.
User avatar
sektor2111
Godlike
Posts: 6438
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: XC_Engine [18] - XC_Core [7] - XC_IpDrv

Post by sektor2111 »

So XCGE_Actors defined in INI are spawned properly by XC_Engine very early, which means that several tweaks are doable without mutators by only defining what we need and XCGE will spawn that for us.
Else, some tweaks might be "waiting" - I was writing some lousy fix for that TriggerControl problem but... I'm waiting 4 seconds for other possible fixes first (by example, morphed to TriggerOpenTimed by a master game-type, etc.). Else the rest of fixes which needs speed might be helpful a lot using this way.

Good work, Higor!

Edit:
But something got a different turn right now, similar to an old problem

Code: Select all

Critical: appError called:
Critical: SkaarjBerserker MH-The-Ancients.SkaarjBerserker3 (Function UnrealShare.ScriptedPawn.SetEnemy:0031) Runaway loop detected (over 10000000 iterations)
Exit: Executing UObject::StaticShutdownAfterError
Critical: FFrame::Serialize
Critical: ScriptDebugV
Critical: SkaarjBerserker3.SetEnemy
Critical: ScriptDebugV
Critical: SkaarjBerserker3.WhatToDoNext
Critical: ScriptDebugV
Critical: SkaarjBerserker3.ChooseAttackMode
Critical: AActor::ProcessState
Critical: Object SkaarjBerserker MH-The-Ancients.SkaarjBerserker3, Old State State UnrealShare.ScriptedPawn.Attacking, New State State UnrealShare.ScriptedPawn.Attacking
Critical: AActor::Tick
Critical: TickAllActors
Critical: ULevel::Tick
Critical: (NetMode=1)
Critical: TickLevel
Critical: UGameEngine::Tick
Critical: UXC_GameEngine::Tick
Critical: UpdateWorld
Critical: UXC_ServerCommandlet::Main
Exit: Exiting.
SetEnemy is still attached in natives and UScript too ? (duplicate multiple executions ?). Now what it's wrong ?
All right I'll change WhatToDoNext using VisibleCollidingActors or... removing stupid code which already exist in function Killed... Epic :wth:. :???: :???: